PostgreSQL 10.8 commit log

Stamp 10.8.

commit   : 441190289892c4ae870d0781175aa8edd0ec528e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 May 2019 16:48:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 May 2019 16:48:45 -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

Last-minute updates for release notes.

commit   : 585e8ffd195d868f23318caaed6fd586f8d56a0e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 May 2019 12:45:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 May 2019 12:45:59 -0400    

Click here for diff

Security: CVE-2019-10129, CVE-2019-10130  

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

Revert “Make pg_dump emit ATTACH PARTITION instead of PARTITION OF”

commit   : 40353bcc67cd4a2b70179faf4d90984196d4ffff    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 6 May 2019 12:23:49 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 6 May 2019 12:23:49 -0400    

Click here for diff

... and fallout (from branches 10, 11 and master).  The change was  
ill-considered, and it broke a few normal use cases; since we don't have  
time to fix it, we'll try again after this week's minor releases.  
  
Reported-by: Rushabh Lathia  
Discussion: https://postgr.es/m/CAGPqQf0iQV=PPOv2Btog9J9AwOQp6HmuVd6SbGTR_v3Zp2XT1w@mail.gmail.com  

M doc/src/sgml/release-10.sgml
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl

Translation updates

commit   : f4540a9c9ca163c8afee2259c6425d82e1aea595    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 May 2019 14:43:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 May 2019 14:43:35 +0200    

Click here for diff

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

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

Use checkAsUser for selectivity estimator checks, if it’s set.

commit   : ca74e3e0faadd5731c1bd9e6da21f11162a125f2    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 6 May 2019 11:58:32 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 6 May 2019 11:58:32 +0100    

Click here for diff

In examine_variable() and examine_simple_variable(), when checking the  
user's table and column privileges to determine whether to grant  
access to the pg_statistic data, use checkAsUser for the privilege  
checks, if it's set. This will be the case if we're accessing the  
table via a view, to indicate that we should perform privilege checks  
as the view owner rather than the current user.  
  
This change makes this planner check consistent with the check in the  
executor, so the planner will be able to make use of statistics if the  
table is accessible via the view. This fixes a performance regression  
introduced by commit e2d4ef8de8, which affects queries against  
non-security barrier views in the case where the user doesn't have  
privileges on the underlying table, but the view owner does.  
  
Note that it continues to provide the same safeguards controlling  
access to pg_statistic for direct table access (in which case  
checkAsUser won't be set) and for security barrier views, because of  
the nearby checks on rte->security_barrier and rte->securityQuals.  
  
Back-patch to all supported branches because e2d4ef8de8 was.  
  
Dean Rasheed, reviewed by Jonathan Katz and Stephen Frost.  

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

Fix security checks for selectivity estimation functions with RLS.

commit   : 9408028305ac86d9913eaea49442cd7fdfa8aaca    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 6 May 2019 11:43:09 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 6 May 2019 11:43:09 +0100    

Click here for diff

In commit e2d4ef8de8, security checks were added to prevent  
user-supplied operators from running over data from pg_statistic  
unless the user has table or column privileges on the table, or the  
operator is leakproof. For a table with RLS, however, checking for  
table or column privileges is insufficient, since that does not  
guarantee that the user has permission to view all of the column's  
data.  
  
Fix this by also checking for securityQuals on the RTE, and insisting  
that the operator be leakproof if there are any. Thus the  
leakproofness check will only be skipped if there are no securityQuals  
and the user has table or column privileges on the table -- i.e., only  
if we know that the user has access to all the data in the column.  
  
Back-patch to 9.5 where RLS was added.  
  
Dean Rasheed, reviewed by Jonathan Katz and Stephen Frost.  
  
Security: CVE-2019-10130  

M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql

Remove reindex_catalog test from test schedules.

commit   : 443ca97956eed7fae79ac407ff3c44dc014bc594    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 5 May 2019 23:31:58 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 5 May 2019 23:31:58 -0700    

Click here for diff

As the test currently causes occasional deadlocks (due to the schema  
cleanup from previous sessions potentially still running), and the  
patch from f912d7dec2 has gotten a fair bit of buildfarm coverage,  
remove the test from the test schedules. There's a set of minor  
releases coming up.  
  
Leave the tests in place, so it can manually be run using EXTRA_TESTS.  
  
For now also leave it in master, as there's no imminent release, and  
there's plenty (re-)index related work in 12. But we'll have to  
disable it before long there too, unless somebody comes up with simple  
enough fixes for the deadlock (I'm about to post a vague idea to the  
list).  
  
Discussion: https://postgr.es/m/4622.1556982247@sss.pgh.pa.us  
Backpatch: 9.4-11 (no master!)  

M src/test/regress/expected/reindex_catalog.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/reindex_catalog.sql

Release notes for 11.3, 10.8, 9.6.13, 9.5.17, 9.4.22.

commit   : 1bf4858f86343ce102c8baf8ed79fbb4057645ab    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 May 2019 14:57:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 May 2019 14:57:16 -0400    

Click here for diff

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

pg_dump: Fix newline in error message

commit   : dbe43a4746f1c6a0cdf9710734388de27bf29b54    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 4 May 2019 16:54:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 4 May 2019 16:54:30 +0200    

Click here for diff

The newline was incorrectly dropped in  
5a191f697400560fa8f2cc11817072bf9055de73.  

M src/bin/pg_dump/pg_dump.c

Fix reindexing of pg_class indexes some more.

commit   : 18138066ff3604658c9a753a10c56e9195d37d6b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 May 2019 19:11:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 May 2019 19:11:28 -0400    

Click here for diff

Commits 3dbb317d3 et al failed under CLOBBER_CACHE_ALWAYS testing.  
Investigation showed that to reindex pg_class_oid_index, we must  
suppress accesses to the index (via SetReindexProcessing) before we call  
RelationSetNewRelfilenode, or at least before we do CommandCounterIncrement  
therein; otherwise, relcache reloads happening within the CCI may try to  
fetch pg_class rows using the index's new relfilenode value, which is as  
yet an empty file.  
  
Of course, the point of 3dbb317d3 was that that ordering didn't work  
either, because then RelationSetNewRelfilenode's own update of the index's  
pg_class row cannot access the index, should it need to.  
  
There are various ways we might have got around that, but Andres Freund  
came up with a brilliant solution: for a mapped index, we can really just  
skip the pg_class update altogether.  The only fields it was actually  
changing were relpages etc, but it was just setting them to zeroes which  
is useless make-work.  (Correct new values will be installed at the end  
of index build.)  All pg_class indexes are mapped and probably always will  
be, so this eliminates the problem by removing work rather than adding it,  
always a pleasant outcome.  Having taught RelationSetNewRelfilenode to do  
it that way, we can revert the code reordering in reindex_index.  (But  
I left the moved setup code where it was; there seems no reason why it  
has to run without use of the old index.  If you're trying to fix a  
busted pg_class index, you'll have had to disable system index use  
altogether to get this far.)  
  
Moreover, this means we don't need RelationSetIndexList at all, because  
reindex_relation's hacking to make "REINDEX TABLE pg_class" work is  
likewise now unnecessary.  We'll leave that code in place in the back  
branches, but a follow-on patch will remove it in HEAD.  
  
In passing, do some minor cleanup for commit 5c1560606 (in HEAD only),  
notably removing a duplicate newrnode assignment.  
  
Patch by me, using a core idea due to Andres Freund.  Back-patch to all  
supported branches, as 3dbb317d3 was.  
  
Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us  

M src/backend/catalog/index.c
M src/backend/utils/cache/relcache.c

Run catalog reindexing test from 3dbb317d32 serially, to avoid deadlocks.

commit   : ad791802831e70b2c86cec098139ffd3e24fa450    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 30 Apr 2019 17:45:32 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 30 Apr 2019 17:45:32 -0700    

Click here for diff

The tests turn out to cause deadlocks in some circumstances. Fairly  
reproducibly so with -DRELCACHE_FORCE_RELEASE  
-DCATCACHE_FORCE_RELEASE.  Some of the deadlocks may be hard to fix  
without disproportionate measures, but others probably should be fixed  
- but not in 12.  
  
We discussed removing the new tests until we can fix the issues  
underlying the deadlocks, but results from buildfarm animal  
markhor (which runs with CLOBBER_CACHE_ALWAYS) indicates that there  
might be a more severe, as of yet undiagnosed, issue (including on  
stable branches) with reindexing catalogs. The failure is:  
ERROR: could not read block 0 in file "base/16384/28025": read only 0 of 8192 bytes  
Therefore it seems advisable to keep the tests.  
  
It's not certain that running the tests in isolation removes the risk  
of deadlocks. It's possible that additional locks are needed to  
protect against a concurrent auto-analyze or such.  
  
Per discussion with Tom Lane.  
  
Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us  
Backpatch: 9.4-, like 3dbb317d3  

M src/test/regress/expected/create_index.out
A src/test/regress/expected/reindex_catalog.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/create_index.sql
A src/test/regress/sql/reindex_catalog.sql

Fix unused variable compiler warning in !debug builds.

commit   : d8d5e1ae5ea81f4a36200fdbf88b1822ff8f99bb    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 30 Apr 2019 17:45:32 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 30 Apr 2019 17:45:32 -0700    

Click here for diff

Introduced in 3dbb317d3.  Fix by using the new local variable in more  
places.  
  
Reported-By: Bruce Momjian (off-list)  
Backpatch: 9.4-, like 3dbb317d3  

M src/backend/catalog/indexing.c

Fix potential assertion failure when reindexing a pg_class index.

commit   : f495b65a5659eaca26e7f7778ae31110a73f4483    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 29 Apr 2019 19:39:36 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 29 Apr 2019 19:39:36 -0700    

Click here for diff

When reindexing individual indexes on pg_class it was possible to  
either trigger an assertion failure:  
TRAP: FailedAssertion("!(!ReindexIsProcessingIndex(((index)->rd_id)))  
  
That's because reindex_index() called SetReindexProcessing() - which  
enables an asserts ensuring no index insertions happen into the index  
- before calling RelationSetNewRelfilenode(). That not correct for  
indexes on pg_class, because RelationSetNewRelfilenode() updates the  
relevant pg_class row, which needs to update the indexes.  
  
The are two reasons this wasn't noticed earlier. Firstly the bug  
doesn't trigger when reindexing all of pg_class, as reindex_relation  
has code "hiding" all yet-to-be-reindexed indexes. Secondly, the bug  
only triggers when the the update to pg_class doesn't turn out to be a  
HOT update - otherwise there's no index insertion to trigger the  
bug. Most of the time there's enough space, making this bug hard to  
trigger.  
  
To fix, move RelationSetNewRelfilenode() to before the  
SetReindexProcessing() (and, together with some other code, to outside  
of the PG_TRY()).  
  
To make sure the error checking intended by SetReindexProcessing() is  
more robust, modify CatalogIndexInsert() to check  
ReindexIsProcessingIndex() even when the update is a HOT update.  
  
Also add a few regression tests for REINDEXing of system catalogs.  
  
The last two improvements would have prevented some of the issues  
fixed in 5c1560606dc4c from being introduced in the first place.  
  
Reported-By: Michael Paquier  
Diagnosed-By: Tom Lane and Andres Freund  
Author: Andres Freund  
Reviewed-By: Tom Lane  
Discussion: https://postgr.es/m/20190418011430.GA19133@paquier.xyz  
Backpatch: 9.4-, the bug is present in all branches  

M contrib/test_decoding/expected/rewrite.out
M contrib/test_decoding/sql/rewrite.sql
M src/backend/catalog/index.c
M src/backend/catalog/indexing.c
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql

Fix potential catalog corruption with temporary identity columns

commit   : 10b2675d6e79ad76f2b74c569f4cf1a716a904c1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Apr 2019 08:44:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Apr 2019 08:44:51 +0200    

Click here for diff

If a temporary table with an identity column and ON COMMIT DROP is  
created in a single-statement transaction (not useful, but allowed),  
it would leave the catalog corrupted.  We need to add a  
CommandCounterIncrement() so that PreCommit_on_commit_actions() sees  
the created dependency between table and sequence and can clean it  
up.  
  
The analogous and more useful case of doing this in a transaction  
block already runs some CommandCounterIncrement() before it gets to  
the on-commit cleanup, so it wasn't a problem in practical use.  
  
Several locations for placing the new CommandCounterIncrement() call  
were discussed.  This patch places it at the end of  
standard_ProcessUtility().  That would also help if other commands  
were to create catalog entries that some on-commit action would like  
to see.  
  
Bug: #15631  
Reported-by: Serge Latyntsev <dnsl48@gmail.com>  
Author: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  

M src/backend/tcop/utility.c

Avoid postgres_fdw crash for a targetlist entry that’s just a Param.

commit   : c25e638b1800752fad99d487a3c805db4980db94    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Apr 2019 13:15:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Apr 2019 13:15:55 -0400    

Click here for diff

foreign_grouping_ok() is willing to put fairly arbitrary expressions into  
the targetlist of a remote SELECT that's doing grouping or aggregation on  
the remote side, including expressions that have no foreign component to  
them at all.  This is possibly a bit dubious from an efficiency standpoint;  
but it rises to the level of a crash-causing bug if the expression is just  
a Param or non-foreign Var.  In that case, the expression will necessarily  
also appear in the fdw_exprs list of values we need to send to the remote  
server, and then setrefs.c's set_foreignscan_references will mistakenly  
replace the fdw_exprs entry with a Var referencing the targetlist result.  
  
The root cause of this problem is bad design in commit e7cb7ee14: it put  
logic into set_foreignscan_references that IMV is postgres_fdw-specific,  
and yet this bug shows that it isn't postgres_fdw-specific enough.  The  
transformation being done on fdw_exprs assumes that fdw_exprs is to be  
evaluated with the fdw_scan_tlist as input, which is not how postgres_fdw  
uses it; yet it could be the right thing for some other FDW.  (In the  
bigger picture, setrefs.c has no business assuming this for the other  
expression fields of a ForeignScan either.)  
  
The right fix therefore would be to expand the FDW API so that the  
FDW could inform setrefs.c how it intends to evaluate these various  
expressions.  We can't change that in the back branches though, and we  
also can't just summarily change setrefs.c's behavior there, or we're  
likely to break external FDWs.  
  
As a stopgap, therefore, hack up postgres_fdw so that it won't attempt  
to send targetlist entries that look exactly like the fdw_exprs entries  
they'd produce.  In most cases this actually produces a superior plan,  
IMO, with less data needing to be transmitted and returned; so we probably  
ought to think harder about whether we should ship tlist expressions at  
all when they don't contain any foreign Vars or Aggs.  But that's an  
optimization not a bug fix so I left it for later.  One case where this  
produces an inferior plan is where the expression in question is actually  
a GROUP BY expression: then the restriction prevents us from using remote  
grouping.  It might be possible to work around that (since that would  
reduce to group-by-a-constant on the remote side); but it seems like a  
pretty unlikely corner case, so I'm not sure it's worth expending effort  
solely to improve that.  In any case the right long-term answer is to fix  
the API as sketched above, and then revert this hack.  
  
Per bug #15781 from Sean Johnston.  Back-patch to v10 where the problem  
was introduced.  
  
Discussion: https://postgr.es/m/15781-2601b1002bad087c@postgresql.org  

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

Correct the URL pointing to PL/R

commit   : fc732e006a130feb5ec2ce771c3ca701fba97ec3    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sat, 27 Apr 2019 09:28:01 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sat, 27 Apr 2019 09:28:01 -0400    

Click here for diff

As pointed out by documentation comment, the URL for PL/R  
needs to be updated to the correct current repository. Back-patch  
to all supported branches.  

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

Portability fix for zic.c.

commit   : 7c22e1388420694654c63b2992695a8be2ac3a07    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Apr 2019 21:20:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Apr 2019 21:20:11 -0400    

Click here for diff

Missed an inttypes.h dependency in previous patch.  Per buildfarm.  

M src/timezone/README
M src/timezone/zic.c

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

commit   : fd7474151a9a43c75971fe6175c3c298d37d2378    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Apr 2019 19:46:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Apr 2019 19:46:26 -0400    

Click here for diff

This corrects a small bug in zic that caused it to output an incorrect  
year-2440 transition in the Africa/Casablanca zone.  
  
More interestingly, zic has grown a "-r" option that limits the range of  
zone transitions that it will put into the output files.  That might be  
useful to people who don't like the weird GMT offsets that tzdb likes  
to use for very old dates.  It appears that for dates before the cutoff  
time specified with -r, zic will use the zone's standard-time offset  
as of the cutoff time.  So for example one might do  
  
	make install ZIC_OPTIONS='-r @-1893456000'  
  
to cause all dates before 1910-01-01 to be treated as though 1910  
standard time prevailed indefinitely far back.  (Don't blame me for  
the unfriendly way of specifying the cutoff time --- it's seconds  
since or before the Unix epoch.  You can use extract(epoch ...)  
to calculate it.)  
  
As usual, back-patch to all supported branches.  

M src/timezone/Makefile
M src/timezone/README
M src/timezone/private.h
M src/timezone/tzfile.h
M src/timezone/zic.c

Update time zone data files to tzdata release 2019a.

commit   : 14c28c3b56a65bd6e7581c2bc1414fd78963ca33    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Apr 2019 17:56:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Apr 2019 17:56:26 -0400    

Click here for diff

DST law changes in Palestine and Metlakatla.  
Historical corrections for Israel.  
  
Etc/UCT is now a backward-compatibility link to Etc/UTC, instead  
of being a separate zone that generates the abbreviation "UCT",  
which nowadays is typically a typo.  Postgres will still accept  
"UCT" as an input zone name, but it won't output it.  

M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt

Make pg_dump emit ATTACH PARTITION instead of PARTITION OF

commit   : 5a191f697400560fa8f2cc11817072bf9055de73    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 24 Apr 2019 15:30:37 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 24 Apr 2019 15:30:37 -0400    

Click here for diff

Using PARTITION OF can result in column ordering being changed from the  
database being dumped, if the partition uses a column layout different  
from the parent's.  It's not pg_dump's job to editorialize on table  
definitions, so this is not acceptable; back-patch all the way back to  
pg10, where partitioned tables where introduced.  
  
This change also ensures that partitions end up in the correct  
tablespace, if different from the parent's; this is an oversight in  
ca4103025dfe (in pg12 only).  Partitioned indexes (in pg11) don't have  
this problem, because they're already created as independent indexes and  
attached to their parents afterwards.  
  
This change also has the advantage that the partition is restorable from  
the dump (as a standalone table) even if its parent table isn't  
restored.  
  
Author: David Rowley  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com  
Discussion: https://postgr.es/m/20190423185007.GA27954@alvherre.pgsql  

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

Fix some minor postmaster-state-machine issues.

commit   : a0bbd012d9fec6f2989303639d1682b8795014b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Apr 2019 14:15:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Apr 2019 14:15:44 -0400    

Click here for diff

In sigusr1_handler, don't ignore PMSIGNAL_ADVANCE_STATE_MACHINE based  
on pmState.  The restriction is unnecessary (PostmasterStateMachine  
should work in any state), not future-proof (since it makes too many  
assumptions about why the signal might be sent), and broken even today  
because a race condition can make it necessary to respond to the signal  
in PM_WAIT_READONLY state.  The race condition seems unlikely, but  
if it did happen, a hot-standby postmaster could fail to shut down  
after receiving a smart-shutdown request.  
  
In MaybeStartWalReceiver, don't clear the WalReceiverRequested flag  
if the fork attempt fails.  Leaving it set allows us to try  
again in future iterations of the postmaster idle loop.  (The startup  
process would eventually send a fresh request signal, but this change  
may allow us to retry the fork sooner.)  
  
Remove an obsolete comment and unnecessary test in  
PostmasterStateMachine's handling of PM_SHUTDOWN_2 state.  It's not  
possible to have a live walreceiver in that state, and AFAICT has not  
been possible since commit 5e85315ea.  This isn't a live bug, but the  
false comment is quite confusing to readers.  
  
In passing, rearrange sigusr1_handler's CheckPromoteSignal tests so that  
we don't uselessly perform stat() calls that we're going to ignore the  
results of.  
  
Add some comments clarifying the behavior of MaybeStartWalReceiver;  
I very nearly rearranged it in a way that'd reintroduce the race  
condition fixed in e5d494d78.  Mea culpa for not commenting that  
properly at the time.  
  
Back-patch to all supported branches.  The PMSIGNAL_ADVANCE_STATE_MACHINE  
change is the only one of even minor significance, but we might as well  
keep this code in sync across branches.  
  
Discussion: https://postgr.es/m/9001.1556046681@sss.pgh.pa.us  

M src/backend/postmaster/postmaster.c

Repair assorted issues in locale data extraction.

commit   : 7c02c3f756045349b2269cbb895bf27f67358b0d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Apr 2019 18:51:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Apr 2019 18:51:31 -0400    

Click here for diff

cache_locale_time (extraction of LC_TIME-related info) had never been  
taught the lessons we previously learned about extraction of info related  
to LC_MONETARY and LC_NUMERIC.  Specifically, commit 95a777c61 taught  
PGLC_localeconv() that data coming out of localeconv() was in an encoding  
determined by the relevant locale, but we didn't realize that there's a  
similar issue with strftime().  And commit a4930e7ca hardened  
PGLC_localeconv() against errors occurring partway through, but failed  
to do likewise for cache_locale_time().  So, rearrange the latter  
function to perform encoding conversion and not risk failure while  
it's got the locales set to temporary values.  
  
This time around I also changed PGLC_localeconv() to treat it as FATAL  
if it can't restore the previous settings of the locale values.  There  
is no reason (except possibly OOM) for that to fail, and proceeding with  
the wrong locale values seems like a seriously bad idea --- especially  
on Windows where we have to also temporarily change LC_CTYPE.  Also,  
protect against the possibility that we can't identify the codeset  
reported for LC_MONETARY or LC_NUMERIC; rather than just failing,  
try to validate the data without conversion.  
  
The user-visible symptom this fixes is that if LC_TIME is set to a locale  
name that implies an encoding different from the database encoding,  
non-ASCII localized day and month names would be retrieved in the wrong  
encoding, leading to either unexpected encoding-conversion error reports  
or wrong output from to_char().  The other possible failure modes are  
unlikely enough that we've not seen reports of them, AFAIK.  
  
The encoding conversion problems do not manifest on Windows, since  
we'd already created special-case code to handle that issue there.  
  
Per report from Juan José Santamaría Flecha.  Back-patch to all  
supported versions.  
  
Juan José Santamaría Flecha and Tom Lane  
  
Discussion: https://postgr.es/m/CAC+AXB22So5aZm2vZe+MChYXec7gWfr-n-SK-iO091R0P_1Tew@mail.gmail.com  

M src/backend/utils/adt/pg_locale.c
M src/test/regress/expected/collate.linux.utf8.out
M src/test/regress/sql/collate.linux.utf8.sql

Fix detection of passwords hashed with MD5 or SCRAM-SHA-256

commit   : 15fe91e70ec69ecffad9f250f8e96f3823147195    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Apr 2019 15:43:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Apr 2019 15:43:38 +0900    

Click here for diff

This commit fixes a couple of issues related to the way password  
verifiers hashed with MD5 or SCRAM-SHA-256 are detected, leading to  
being able to store in catalogs passwords which do not follow the  
supported hash formats:  
- A MD5-hashed entry was checked based on if its header uses "md5" and  
if the string length matches what is expected.  Unfortunately the code  
never checked if the hash only used hexadecimal characters, as reported  
by Tom Lane.  
- A SCRAM-hashed entry was checked based on only its header, which  
should be "SCRAM-SHA-256$", but it never checked for any fields  
afterwards, as reported by Jonathan Katz.  
  
Backpatch down to v10, which is where SCRAM has been introduced, and  
where password verifiers in plain format have been removed.  
  
Author: Jonathan Katz  
Reviewed-by: Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/016deb6b-1f0a-8e9f-1833-a8675b170aa9@postgresql.org  
Backpatch-through: 10  

M src/backend/libpq/auth-scram.c
M src/backend/libpq/crypt.c
M src/include/common/md5.h
M src/include/libpq/scram.h
M src/test/regress/expected/password.out
M src/test/regress/sql/password.sql

Fix documentation of pg_start_backup and pg_stop_backup functions.

commit   : 42b962176e7ab196a24e96877845331c255a978f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 23 Apr 2019 02:41:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 23 Apr 2019 02:41:58 +0900    

Click here for diff

This commit adds the description that "non-exclusive" pg_start_backup  
and pg_stop_backup can be executed even during recovery. Previously  
it was wrongly documented that those functions are not allowed to be  
executed during recovery.  
  
Back-patch to 9.6 where non-exclusive backup API was added.  
  
Discussion: https://postgr.es/m/CAHGQGwEuAYrEX7Yhmf2MCrTK81HDkkg-JqsOUh8zw6+zYC5zzw@mail.gmail.com  

M doc/src/sgml/func.sgml

docs: reorder collation regression test order in paragraph

commit   : fba5b1401de000d576ed17edbfd2e154867c1149    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 20 Apr 2019 11:18:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 20 Apr 2019 11:18:43 -0400    

Click here for diff

Backpatch-through: 10  

M doc/src/sgml/regress.sgml

Fix handling of temp and unlogged tables in FOR ALL TABLES publications

commit   : 05d151e1382b969a618491486778a349a4857d9a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 16 Apr 2019 10:37:44 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 16 Apr 2019 10:37:44 +0200    

Click here for diff

If a FOR ALL TABLES publication exists, temporary and unlogged tables  
are ignored for publishing changes.  But CheckCmdReplicaIdentity()  
would still check in that case that such a table has a replica  
identity set before accepting updates.  To fix, have  
GetRelationPublicationActions() return that such a table publishes no  
actions.  
  
Discussion: https://www.postgresql.org/message-id/f3f151f7-c4dd-1646-b998-f60bd6217dd3@2ndquadrant.com  

M src/backend/utils/cache/relcache.c
M src/test/subscription/t/100_bugs.pl

postgresql.conf.sample: add proper defaults for include actions

commit   : fea2cab70de8d190762996c7c447143fb47bcfa3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 17 Apr 2019 18:12:10 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 17 Apr 2019 18:12:10 -0400    

Click here for diff

Previously, include actions include_dir, include_if_exists, and include  
listed commented-out values which were not the defaults, which is  
inconsistent with other entries.  Instead, replace them with '', which  
is the default value.  
  
Reported-by: Emanuel Araújo  
  
Discussion: https://postgr.es/m/CAMuTAkYMx6Q27wpELDR3_v9aG443y7ZjeXu15_+1nGUjhMWOJA@mail.gmail.com  
  
Backpatch-through: 9.4  

M src/backend/utils/misc/postgresql.conf.sample

docs: clarify pg_upgrade’s recovery behavior

commit   : 8b947ab430378e38ff178e37b41906a413c5bf4a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 17 Apr 2019 18:01:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 17 Apr 2019 18:01:02 -0400    

Click here for diff

The previous paragraph trying to explain --check, --link, and no --link  
modes and the various points of failure was too complex.  Instead, use  
bullet lists and sublists.  
  
Reported-by: Daniel Gustafsson  
  
Discussion: https://postgr.es/m/qtqiv7hI87s_Xvz5ZXHCaH-1-_AZGpIDJowzlRjF3-AbCr3RhSNydM_JCuJ8DE4WZozrtxhIWmyYTbv0syKyfGB6cYMQitp9yN-NZMm-oAo=@yesql.se  
  
Backpatch-through: 9.4  

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

Don’t write to stdin of a test process that could have already exited.

commit   : 4dc903947e10b6f6de1de31c31e701d2a4d9516a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 15 Apr 2019 18:13:44 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 15 Apr 2019 18:13:44 -0700    

Click here for diff

Instead, close that stdin.  Per buildfarm member conchuela.  Back-patch  
to 9.6, where the test was introduced.  
  
Discussion: https://postgr.es/m/26478.1555373328@sss.pgh.pa.us  

M src/test/recovery/t/017_shm.pl

Fix SHOW ALL command for non-superusers with replication connection

commit   : ab359624b4c102e308a86959ad74d34d52746db2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Apr 2019 12:35:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Apr 2019 12:35:02 +0900    

Click here for diff

Since Postgres 10, SHOW commands can be triggered with replication  
connections in a WAL sender context, however it missed that a  
transaction context is needed for syscache lookups.  This commit makes  
sure that the syscache lookups can happen correctly by setting a  
transaction context when running SHOW commands in a WAL sender.  
  
Superuser-only parameters can be displayed using SHOW commands not only  
to superusers, but also to members of system role pg_read_all_settings,  
which requires a syscache lookup to check if the connected role is a  
member of this system role or not, or the instance crashes.  Superusers  
do not need to check the syscache so it worked correctly in this case.  
  
New tests are added to cover this issue.  
  
Reported-by: Alexander Kukushkin  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/15734-2daa8761eeed8e20@postgresql.org  
Backpatch-through: 10  

M src/backend/replication/walsender.c
M src/test/perl/PostgresNode.pm
M src/test/recovery/t/001_stream_rep.pl

Test both 0.0.0.0 and 127.0.0.x addresses to find a usable port.

commit   : 4543ef36f0efee9d8c6d7950a05c951a480c0f3a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 14 Apr 2019 20:02:19 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 14 Apr 2019 20:02:19 -0700    

Click here for diff

Commit c098509927f9a49ebceb301a2cb6a477ecd4ac3c changed  
PostgresNode::get_new_node() to probe 0.0.0.0 instead of 127.0.0.1, but  
the new test was less effective for Windows native Perl.  This increased  
the failure rate of buildfarm members bowerbird and jacana.  Instead,  
test 0.0.0.0 and concrete addresses.  This restores the old level of  
defense, but the algorithm is still subject to its longstanding time of  
check to time of use race condition.  Back-patch to 9.6, like the  
previous change.  
  
Discussion: https://postgr.es/m/GrdLgAdUK9FdyZg8VIcTDKVOkys122ZINEb3CjjoySfGj2KyPiMKTh1zqtRp0TAD7FJ27G-OBB3eplxIB5GhcQH5o8zzGZfp0MuJaXJxVxk=@yesql.se  

M src/test/perl/PostgresNode.pm

MSYS: Skip src/test/recovery/t/017_shm.pl.

commit   : 2bc0474792e346c6c7f16cdc33607568e9e92c74    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 14 Apr 2019 00:36:47 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 14 Apr 2019 00:36:47 -0700    

Click here for diff

Commit 947a35014fdc2ec74cbf06c7dbac6eea6fae90c6 relied on a feature  
available in v11 and later, so back-patching it to v10 and v9.6 was  
invalid.  In those branches, revert it and skip the test on msys.  
  
Discussion: https://postgr.es/m/GrdLgAdUK9FdyZg8VIcTDKVOkys122ZINEb3CjjoySfGj2KyPiMKTh1zqtRp0TAD7FJ27G-OBB3eplxIB5GhcQH5o8zzGZfp0MuJaXJxVxk=@yesql.se  

M src/test/perl/PostgresNode.pm
M src/test/recovery/t/017_shm.pl

When Perl “kill(9, …)” fails, try “pg_ctl kill”.

commit   : 61c0962d90d5386a24a30970ff4635cce68051bb    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 13 Apr 2019 11:09:27 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 13 Apr 2019 11:09:27 -0700    

Click here for diff

Per buildfarm member jacana, the former fails under msys Perl 5.8.8.  
Back-patch to 9.6, like the code in question.  
  
Discussion: https://postgr.es/m/GrdLgAdUK9FdyZg8VIcTDKVOkys122ZINEb3CjjoySfGj2KyPiMKTh1zqtRp0TAD7FJ27G-OBB3eplxIB5GhcQH5o8zzGZfp0MuJaXJxVxk=@yesql.se  

M src/test/perl/PostgresNode.pm

Prevent memory leaks associated with relcache rd_partcheck structures.

commit   : d4c50b4b1f86f639992b23eb183575ad6f0653ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Apr 2019 13:22:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 13 Apr 2019 13:22:26 -0400    

Click here for diff

The original coding of generate_partition_qual() just copied the list  
of predicate expressions into the global CacheMemoryContext, making it  
effectively impossible to clean up when the owning relcache entry is  
destroyed --- the relevant code in RelationDestroyRelation() only managed  
to free the topmost List header :-(.  This resulted in a session-lifespan  
memory leak whenever a table partition's relcache entry is rebuilt.  
Fortunately, that's not normally a large data structure, and rebuilds  
shouldn't occur all that often in production situations; but this is  
still a bug worth fixing back to v10 where the code was introduced.  
  
To fix, put the cached expression tree into its own small memory context,  
as we do with other complicated substructures of relcache entries.  
Also, deal more honestly with the case that a partition has an empty  
partcheck list; while that probably isn't a case that's very interesting  
for production use, it's legal.  
  
In passing, clarify comments about how partitioning-related relcache  
data structures are managed, and add some Asserts that we're not leaking  
old copies when we overwrite these data fields.  
  
Amit Langote and Tom Lane  
  
Discussion: https://postgr.es/m/7961.1552498252@sss.pgh.pa.us  

M src/backend/catalog/partition.c
M src/backend/utils/cache/relcache.c
M src/include/utils/rel.h

Consistently test for in-use shared memory.

commit   : 6d81e3c6526b6db229a68dde35593dda230e449f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 12 Apr 2019 22:36:38 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 12 Apr 2019 22:36:38 -0700    

Click here for diff

postmaster startup scrutinizes any shared memory segment recorded in  
postmaster.pid, exiting if that segment matches the current data  
directory and has an attached process.  When the postmaster.pid file was  
missing, a starting postmaster used weaker checks.  Change to use the  
same checks in both scenarios.  This increases the chance of a startup  
failure, in lieu of data corruption, if the DBA does "kill -9 `head -n1  
postmaster.pid` && rm postmaster.pid && pg_ctl -w start".  A postmaster  
will no longer stop if shmat() of an old segment fails with EACCES.  A  
postmaster will no longer recycle segments pertaining to other data  
directories.  That's good for production, but it's bad for integration  
tests that crash a postmaster and immediately delete its data directory.  
Such a test now leaks a segment indefinitely.  No "make check-world"  
test does that.  win32_shmem.c already avoided all these problems.  In  
9.6 and later, enhance PostgresNode to facilitate testing.  Back-patch  
to 9.4 (all supported versions).  
  
Reviewed (in earlier versions) by Daniel Gustafsson and Kyotaro HORIGUCHI.  
  
Discussion: https://postgr.es/m/20190408064141.GA2016666@rfd.leadboat.com  

M src/Makefile.global.in
M src/backend/port/sysv_shmem.c
M src/backend/port/win32_shmem.c
M src/backend/postmaster/postmaster.c
M src/backend/storage/ipc/ipci.c
M src/backend/utils/init/postinit.c
M src/include/storage/ipc.h
M src/include/storage/pg_shmem.h
M src/test/perl/PostgresNode.pm
A src/test/recovery/t/017_shm.pl
M src/tools/msvc/vcregress.pl

Fix off-by-one check that can lead to a memory overflow in ecpg.

commit   : e7e71b9e1ecb8cb6eb490b0c82bdc5aa9604368b    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Thu, 11 Apr 2019 20:56:17 +0200    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Thu, 11 Apr 2019 20:56:17 +0200    

Click here for diff

Patch by Liu Huailing <liuhuailing@cn.fujitsu.com>  

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

doc: adjust libpq wording to be neither/nor

commit   : 2c31332267ea3d924e201054b20b080278c08305    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Apr 2019 13:25:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 11 Apr 2019 13:25:34 -0400    

Click here for diff

Reported-by: postgresql@cohi.at  
  
Discussion: https://postgr.es/m/155419437926.737.10876947446993402227@wrigleys.postgresql.org  
  
Backpatch-through: 9.4  

M doc/src/sgml/libpq.sgml

Fix backwards test in operator_precedence_warning logic.

commit   : 99bbff5c15797de3d958f303e80646d30e0c8fa4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Apr 2019 19:02:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 10 Apr 2019 19:02:21 -0400    

Click here for diff

Warnings about unary minus might have been wrong.  It's a bit  
surprising that nobody noticed yet ... probably the precedence-warning  
feature hasn't really been used much in the field.  
  
Rikard Falkeborn  
  
Discussion: https://postgr.es/m/CADRDgG6fzA8A2oeygUw4=o7ywo4kvz26NxCSgpq22nMD73Bx4Q@mail.gmail.com  

M src/backend/parser/parse_expr.c

Avoid counting transaction stats for parallel worker cooperating transaction.

commit   : 7657072e0ccc01955fddfce22ffcc4d82f9e9e45    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 10 Apr 2019 08:47:39 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 10 Apr 2019 08:47:39 +0530    

Click here for diff

The transaction that is initiated by the parallel worker to cooperate  
with the actual transaction started by the main backend to complete the  
query execution should not be counted as a separate transaction.  The  
other internal transactions started and committed by the parallel worker  
are still counted as separate transactions as we that is what we do in  
other places like autovacuum.  
  
This will partially fix the bloat in transaction stats due to additional  
transactions performed by parallel workers.  For a complete fix, we need to  
decide how we want to show all the transactions that are started internally  
for various operations and that is a matter of separate patch.  
  
Reported-by: Haribabu Kommi  
Author: Haribabu Kommi  
Reviewed-by: Amit Kapila, Jamison Kirk and Rahila Syed  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/CAJrrPGc9=jKXuScvNyQ+VNhO0FZk7LLAShAJRyZjnedd2D61EQ@mail.gmail.com  

M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/postmaster/pgstat.c
M src/include/pgstat.h

Define WIN32_STACK_RLIMIT throughout win32 and cygwin builds.

commit   : 4c9e545724c6a51faed20b2de1f1ef3d3d03b270    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Tue, 9 Apr 2019 08:25:39 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Tue, 9 Apr 2019 08:25:39 -0700    

Click here for diff

The MSVC build system already did this, and commit  
617dc6d299c957e2784320382b3277ede01d9c63 used it in a second file.  
Back-patch to 9.4, like that commit.  
  
Discussion: https://postgr.es/m/CAA8=A7_1SWc3+3Z=-utQrQFOtrj_DeohRVt7diA2tZozxsyUOQ@mail.gmail.com  

M src/backend/tcop/Makefile
M src/makefiles/Makefile.cygwin
M src/makefiles/Makefile.win32

Avoid “could not reattach” by providing space for concurrent allocation.

commit   : f5989b379cefa0f3c858401d671813630e5e4118    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Apr 2019 21:39:00 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 8 Apr 2019 21:39:00 -0700    

Click here for diff

We've long had reports of intermittent "could not reattach to shared  
memory" errors on Windows.  Buildfarm member dory fails that way when  
PGSharedMemoryReAttach() execution overlaps with creation of a thread  
for the process's "default thread pool".  Fix that by providing a second  
region to receive asynchronous allocations that would otherwise intrude  
into UsedShmemSegAddr.  In pgwin32_ReserveSharedMemoryRegion(), stop  
trying to free reservations landing at incorrect addresses; the caller's  
next step has been to terminate the affected process.  Back-patch to 9.4  
(all supported versions).  
  
Reviewed by Tom Lane.  He also did much of the prerequisite research;  
see commit bcbf2346d69f6006f126044864dd9383d50d87b4.  
  
Discussion: https://postgr.es/m/20190402135442.GA1173872@rfd.leadboat.com  

M src/backend/port/win32_shmem.c
M src/backend/postmaster/postmaster.c
M src/include/storage/pg_shmem.h

Fix improper interaction of FULL JOINs with lateral references.

commit   : 051c71c6746309782d9bf1ebb257d3b5f88e6fb7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Apr 2019 16:09:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Apr 2019 16:09:07 -0400    

Click here for diff

join_is_legal() needs to reject forming certain outer joins in cases  
where that would lead the planner down a blind alley.  However, it  
mistakenly supposed that the way to handle full joins was to treat them  
as applying the same constraints as for left joins, only to both sides.  
That doesn't work, as shown in bug #15741 from Anthony Skorski: given  
a lateral reference out of a join that's fully enclosed by a full join,  
the code would fail to believe that any join ordering is legal, resulting  
in errors like "failed to build any N-way joins".  
  
However, we don't really need to consider full joins at all for this  
purpose, because we effectively force them to be evaluated in syntactic  
order, and that order is always legal for lateral references.  Hence,  
get rid of this broken logic for full joins and just ignore them instead.  
  
This seems to have been an oversight in commit 7e19db0c0.  
Back-patch to all supported branches, as that was.  
  
Discussion: https://postgr.es/m/15741-276f1f464b3f40eb@postgresql.org  

M src/backend/optimizer/path/joinrels.c
M src/test/regress/expected/rangefuncs.out
M src/test/regress/sql/rangefuncs.sql

doc: Update serial explanation

commit   : dc92adc4bb8f3026a8eb70b297a8d6dd93e1166c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Apr 2019 22:03:48 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 8 Apr 2019 22:03:48 +0200    

Click here for diff

The CREATE SEQUENCE command should include a data type specification,  
since PostgreSQL 10.  
  
Reported-by: mjf@pearson.co.uk  

M doc/src/sgml/datatype.sgml

Fix EvalPlanQualStart to handle partitioned result rels correctly.

commit   : 1b5bbe4bcc912b070ad705ad7a79806692af18c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Apr 2019 12:20:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 8 Apr 2019 12:20:23 -0400    

Click here for diff

The es_root_result_relations array needs to be shallow-copied in the  
same way as the main es_result_relations array, else EPQ rechecks on  
partitioned result relations fail, as seen in bug #15677 from  
Norbert Benkocs.  
  
Amit Langote, isolation test case added by me  
  
Discussion: https://postgr.es/m/15677-0bf089579b4cd02d@postgresql.org  
Discussion: https://postgr.es/m/19321.1554567786@sss.pgh.pa.us  

M src/backend/executor/execMain.c
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec

Clean up side-effects of commits ab5fcf2b0 et al.

commit   : 67999b3547f7ee8b8c099f41ddab3001e2792202    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Apr 2019 12:54:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Apr 2019 12:54:26 -0400    

Click here for diff

Before those commits, partitioning-related code in the executor could  
assume that ModifyTableState.resultRelInfo[] contains only leaf partitions.  
However, now a fully-pruned update results in a dummy ModifyTable that  
references the root partitioned table, and that breaks some stuff.  
  
In v11, this led to an assertion or core dump in the tuple routing code.  
Fix by disabling tuple routing, since we don't need that anyway.  
(I chose to do that in HEAD as well for safety, even though the problem  
doesn't manifest in HEAD as it stands.)  
  
In v10, this confused ExecInitModifyTable's decision about whether it  
needed to close the root table.  But we can get rid of that altogether  
by being smarter about where to find the root table.  
  
Note that since the referenced commits haven't shipped yet, this  
isn't fixing any bug the field has seen.  
  
Amit Langote, per a report from me  
  
Discussion: https://postgr.es/m/20710.1554582479@sss.pgh.pa.us  

M src/backend/executor/nodeModifyTable.c
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql

Revert “Consistently test for in-use shared memory.”

commit   : 7d18a55c90eb5a83c702c7cd8e23ae25c389a636    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 5 Apr 2019 00:00:52 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 5 Apr 2019 00:00:52 -0700    

Click here for diff

This reverts commits 2f932f71d9f2963bbd201129d7b971c8f5f077fd,  
16ee6eaf80a40007a138b60bb5661660058d0422 and  
6f0e190056fe441f7cf788ff19b62b13c94f68f3.  The buildfarm has revealed  
several bugs.  Back-patch like the original commits.  
  
Discussion: https://postgr.es/m/20190404145319.GA1720877@rfd.leadboat.com  

M src/Makefile.global.in
M src/backend/port/sysv_shmem.c
M src/backend/port/win32_shmem.c
M src/backend/postmaster/postmaster.c
M src/backend/storage/ipc/ipci.c
M src/backend/utils/init/postinit.c
M src/include/storage/ipc.h
M src/include/storage/pg_shmem.h
M src/test/perl/PostgresNode.pm
D src/test/recovery/t/017_shm.pl
M src/tools/msvc/vcregress.pl

Fix some documentation in pg_rewind

commit   : 4b482e94a006ee3ed6df09aba8c526cdcee84496    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Apr 2019 10:38:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Apr 2019 10:38:26 +0900    

Click here for diff

A confusion which comes a lot from users is that it is necessary to  
issue a checkpoint on a freshly-promoted standby so as its control file  
has up-to-date timeline information which is used by pg_rewind to  
validate the operation.  Let's document that properly.  This is  
back-patched down to 9.5 where pg_rewind has been introduced.  
  
Author: Michael Paquier  
Reviewed-by: Magnus Hagander  
Discussion: https://postgr.es/m/CABUevEz5bpvbwVsYCaSMV80CBZ5-82nkMzbb+Bu=h1m=rLdn=g@mail.gmail.com  
Backpatch-through: 9.5  

M doc/src/sgml/ref/pg_rewind.sgml

Silence -Wimplicit-fallthrough in sysv_shmem.c.

commit   : e9d4cbeacb553fc5f4c185ec1156018ea4114fdd    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 3 Apr 2019 23:23:35 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 3 Apr 2019 23:23:35 -0700    

Click here for diff

Commit 2f932f71d9f2963bbd201129d7b971c8f5f077fd added code that elicits  
a warning on buildfarm member flaviventris.  Back-patch to 9.4, like  
that commit.  
  
Reported by Andres Freund.  
  
Discussion: https://postgr.es/m/20190404020057.galelv7by75ekqrh@alap3.anarazel.de  

M src/backend/port/sysv_shmem.c

Make src/test/recovery/t/017_shm.pl safe for concurrent execution.

commit   : 3186d5fac55bdba9364ae2daa5b1180c9eaa8968    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 3 Apr 2019 23:16:37 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 3 Apr 2019 23:16:37 -0700    

Click here for diff

Buildfarm members idiacanthus and komodoensis, which share a host, both  
executed this test in the same second.  That failed.  Back-patch to 9.6,  
where the test first appeared.  
  
Discussion: https://postgr.es/m/20190404020543.GA1319573@rfd.leadboat.com  

M src/test/recovery/t/017_shm.pl

Handle USE_MODULE_DB for all tests able to use an installed postmaster.

commit   : 8541304d5c773d728736bbe055d37a8e8b21fb8b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 3 Apr 2019 17:06:01 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 3 Apr 2019 17:06:01 -0700    

Click here for diff

When $(MODULES) and $(MODULE_big) are empty, derive the database name  
from the first element of $(REGRESS) instead of using a constant string.  
When deriving the database name from $(MODULES), use its first element  
instead of the entire list; the earlier approach would fail if any  
multi-module directory had $(REGRESS) tests.  Treat isolation suites and  
src/pl correspondingly.  Under USE_MODULE_DB=1, installcheck-world and  
check-world no longer reuse any database name in a given postmaster.  
Buildfarm members axolotl, mandrill and frogfish saw spurious "is being  
accessed by other users" failures that would not have happened without  
database name reuse.  (The CountOtherDBBackends() 5s deadline expired  
during DROP DATABASE; a backend for an earlier test suite had used the  
same database name and had not yet exited.)  Back-patch to 9.4 (all  
supported versions), except bits pertaining to isolation suites.  
  
Concept reviewed by Andrew Dunstan, Andres Freund and Tom Lane.  
  
Discussion: https://postgr.es/m/20190401135213.GE891537@rfd.leadboat.com  

M src/Makefile.global.in
M src/makefiles/pgxs.mk

Consistently test for in-use shared memory.

commit   : 7c414cdc39a3f183ff398be4cfcef0646f419281    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 3 Apr 2019 17:03:46 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 3 Apr 2019 17:03:46 -0700    

Click here for diff

postmaster startup scrutinizes any shared memory segment recorded in  
postmaster.pid, exiting if that segment matches the current data  
directory and has an attached process.  When the postmaster.pid file was  
missing, a starting postmaster used weaker checks.  Change to use the  
same checks in both scenarios.  This increases the chance of a startup  
failure, in lieu of data corruption, if the DBA does "kill -9 `head -n1  
postmaster.pid` && rm postmaster.pid && pg_ctl -w start".  A postmaster  
will no longer recycle segments pertaining to other data directories.  
That's good for production, but it's bad for integration tests that  
crash a postmaster and immediately delete its data directory.  Such a  
test now leaks a segment indefinitely.  No "make check-world" test does  
that.  win32_shmem.c already avoided all these problems.  In 9.6 and  
later, enhance PostgresNode to facilitate testing.  Back-patch to 9.4  
(all supported versions).  
  
Reviewed by Daniel Gustafsson and Kyotaro HORIGUCHI.  
  
Discussion: https://postgr.es/m/20130911033341.GD225735@tornado.leadboat.com  

M src/Makefile.global.in
M src/backend/port/sysv_shmem.c
M src/backend/port/win32_shmem.c
M src/backend/postmaster/postmaster.c
M src/backend/storage/ipc/ipci.c
M src/backend/utils/init/postinit.c
M src/include/storage/ipc.h
M src/include/storage/pg_shmem.h
M src/test/perl/PostgresNode.pm
A src/test/recovery/t/017_shm.pl
M src/tools/msvc/vcregress.pl

Perform RLS subquery checks as the right user when going via a view.

commit   : db4bc99948bf746c7035b49cc581eb1c44a30788    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 2 Apr 2019 08:19:09 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 2 Apr 2019 08:19:09 +0100    

Click here for diff

When accessing a table with RLS via a view, the RLS checks are  
performed as the view owner. However, the code neglected to propagate  
that to any subqueries in the RLS checks. Fix that by calling  
setRuleCheckAsUser() for all RLS policy quals and withCheckOption  
checks for RTEs with RLS.  
  
Back-patch to 9.5 where RLS was added.  
  
Per bug #15708 from daurnimator.  
  
Discussion: https://postgr.es/m/15708-d65cab2ce9b1717a@postgresql.org  

M src/backend/rewrite/rowsecurity.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql

Update HINT for pre-existing shared memory block.

commit   : 327399412d035a3951f48d74356ff1449b9b7e91    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 31 Mar 2019 19:32:48 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 31 Mar 2019 19:32:48 -0700    

Click here for diff

One should almost always terminate an old process, not use a manual  
removal tool like ipcrm.  Removal of the ipcclean script eleven years  
ago (39627b1ae680cba44f6e56ca5facec4fdbfe9495) and its non-replacement  
corroborate that manual shm removal is now a niche goal.  Back-patch to  
9.4 (all supported versions).  
  
Reviewed by Daniel Gustafsson and Kyotaro HORIGUCHI.  
  
Discussion: https://postgr.es/m/20180812064815.GB2301738@rfd.leadboat.com  

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

Have pg_upgrade’s Makefile honor NO_TEMP_INSTALL

commit   : f0fd9caef4a5801ff85e6339a00647b986f571fa    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 31 Mar 2019 08:08:14 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 31 Mar 2019 08:08:14 -0400    

Click here for diff

Backpatch to 9.5, when pg_upgrade's location changed.  
  
Discussion: https://postgr.es/m/5506b8fa-7dad-8483-053c-7ca7ef04f01a@2ndQuadrant.com  

M src/bin/pg_upgrade/Makefile

Fix off-by-one error in txid_status().

commit   : 339927797c8716ca14261af48eaf815b5ee24907    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 27 Mar 2019 21:16:50 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 27 Mar 2019 21:16:50 +1300    

Click here for diff

The transaction ID returned by GetNextXidAndEpoch() is in the future,  
so we can't attempt to access its status or we might try to read a  
CLOG page that doesn't exist.  The > vs >= confusion probably stemmed  
from the choice of a variable name containing the word "last" instead  
of "next", so fix that too.  
  
Back-patch to 10 where the function arrived.  
  
Author: Thomas Munro  
Discussion: https://postgr.es/m/CA%2BhUKG%2Buua_BV5cyfsioKVN2d61Lukg28ECsWTXKvh%3DBtN2DPA%40mail.gmail.com  

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

Track unowned relations in doubly-linked list

commit   : 5601f9fb97d108cb26ee92d0941447f354688421    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 27 Mar 2019 02:39:39 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 27 Mar 2019 02:39:39 +0100    

Click here for diff

Relations dropped in a single transaction are tracked in a list of  
unowned relations.  With large number of dropped relations this resulted  
in poor performance at the end of a transaction, when the relations are  
removed from the singly linked list one by one.  
  
Commit b4166911 attempted to address this issue (particularly when it  
happens during recovery) by removing the relations in a reverse order,  
resulting in O(1) lookups in the list of unowned relations.  This did  
not work reliably, though, and it was possible to trigger the O(N^2)  
behavior in various ways.  
  
Instead of trying to remove the relations in a specific order with  
respect to the linked list, which seems rather fragile, switch to a  
regular doubly linked.  That allows us to remove relations cheaply no  
matter where in the list they are.  
  
As b4166911 was a bugfix, backpatched to all supported versions, do the  
same thing here.  
  
Reviewed-by: Alvaro Herrera  
Discussion: https://www.postgresql.org/message-id/flat/80c27103-99e4-1d0c-642c-d9f3b94aaa0a%402ndquadrant.com  
Backpatch-through: 9.4  

M src/backend/storage/smgr/md.c
M src/backend/storage/smgr/smgr.c
M src/include/storage/smgr.h

Doc: clarify that REASSIGN OWNED doesn’t handle default privileges.

commit   : f7dc6ceaae3283b0861f0e6b5b66a6d5eca9c03e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Mar 2019 17:18:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Mar 2019 17:18:05 -0400    

Click here for diff

It doesn't touch regular privileges either, but only the latter was  
explicitly stated.  
  
Discussion: https://postgr.es/m/155348282848.9808.12629518043813943231@wrigleys.postgresql.org  

M doc/src/sgml/ref/drop_owned.sgml
M doc/src/sgml/ref/reassign_owned.sgml

Avoid double-free in vacuumlo error path.

commit   : e484f07015cdcb9b6ba772760f16fdf2d76c8b2f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Mar 2019 15:13:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Mar 2019 15:13:21 -0400    

Click here for diff

The code would do "PQclear(res)" twice if lo_unlink failed, evidently  
due to careless thinking about how far out a "break" would break.  
Remove the extra PQclear and adjust the loop logic so that we'll fall  
out of both levels of loop after an error, as was clearly the intent.  
  
Spotted by Coverity.  I have no idea why it took this long to notice,  
since the bug has been there since commit 67ccbb080.  Accordingly,  
back-patch to all supported branches.  

M contrib/vacuumlo/vacuumlo.c

Fix WAL format incompatibility introduced by backpatching of 52ac6cd2d0

commit   : e23d44016d5193bb824fd637d277cbaa1fc6002c    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 24 Mar 2019 15:26:45 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 24 Mar 2019 15:26:45 +0300    

Click here for diff

52ac6cd2d0 added new field to ginxlogDeletePage and was backpatched to 9.4.  
That led to problems when patched postgres instance applies WAL records  
generated by non-patched one.  WAL records generated by non-patched instance  
don't contain new field, which patched one is expecting to see.  
  
Thankfully, we can distinguish patched and non-patched WAL records by their data  
size.  If we see that WAL record is generated by non-patched instance, we skip  
processing of new field.  This commit comes with some assertions.  In  
particular, if it appears that on some platform struct data size didn't change  
then static assertion will trigger.  
  
Reported-by: Simon Riggs  
Discussion: https://postgr.es/m/CANP8%2Bj%2BK4whxf7ET7%2BgO%2BG-baC3-WxqqH%3DnV4X2CgfEPA3Yu3g%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Simon Riggs, Alvaro Herrera  
Backpatch-through: 9.4  

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

Remove inadequate check for duplicate “xml” PI.

commit   : 581b890c283b6b1b00b580ba261488d6b9bbf21c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Mar 2019 17:40:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Mar 2019 17:40:19 -0400    

Click here for diff

I failed to think about PIs starting with "xml".  We don't really  
need this check at all, so just take it out.  Oversight in  
commit 8d1dadb25 et al.  

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

Revert strlen -> strnlen optimization pre-v11.

commit   : d88d71e3100c0d9687715e4ffa05a72f4599065c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Mar 2019 17:35:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Mar 2019 17:35:04 -0400    

Click here for diff

We don't have a src/port substitute for that function in older branches,  
so it fails on platforms lacking the function natively.  Per buildfarm.  

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

Ensure xmloption = content while restoring pg_dump output.

commit   : de922529fe6211acc008f69a61912e5848091b37    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Mar 2019 16:51:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Mar 2019 16:51:25 -0400    

Click here for diff

In combination with the previous commit, this ensures that valid XML  
data can always be dumped and reloaded, whether it is "document"  
or "content".  
  
Discussion: https://postgr.es/m/CAN-V+g-6JqUQEQZ55Q3toXEN6d5Ez5uvzL4VR+8KtvJKj31taw@mail.gmail.com  

M src/bin/pg_dump/pg_backup_archiver.c

Accept XML documents when xmloption = content, as required by SQL:2006+.

commit   : 754ffcd42006ec6afdf2b3236251a8b277f8f9eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Mar 2019 16:24:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 23 Mar 2019 16:24:30 -0400    

Click here for diff

Previously we were using the SQL:2003 definition, which doesn't allow  
this, but that creates a serious dump/restore gotcha: there is no  
setting of xmloption that will allow all valid XML data.  Hence,  
switch to the 2006 definition.  
  
Since libxml doesn't accept <!DOCTYPE> directives in the mode we  
use for CONTENT parsing, the implementation is to detect <!DOCTYPE>  
in the input and switch to DOCUMENT parsing mode.  This should not  
cost much, because <!DOCTYPE> should be close to the front of the  
input if it's there at all.  It's possible that this causes the  
error messages for malformed input to be slightly different than  
they were before, if said input includes <!DOCTYPE>; but that does  
not seem like a big problem.  
  
In passing, buy back a few cycles in parsing of large XML documents  
by not doing strlen() of the whole input in parse_xml_decl().  
  
Back-patch because dump/restore failures are not nice.  This change  
shouldn't break any cases that worked before, so it seems safe to  
back-patch.  
  
Chapman Flack (revised a bit by me)  
  
Discussion: https://postgr.es/m/CAN-V+g-6JqUQEQZ55Q3toXEN6d5Ez5uvzL4VR+8KtvJKj31taw@mail.gmail.com  

M doc/src/sgml/datatype.sgml
M src/backend/utils/adt/xml.c
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_1.out
M src/test/regress/expected/xml_2.out
M src/test/regress/sql/xml.sql

Make checkpoint requests more robust.

commit   : 693e986d0b88170764bf0b30f979f3750db8089e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Mar 2019 12:49:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Mar 2019 12:49:27 -0400    

Click here for diff

Commit 6f6a6d8b1 introduced a delay of up to 2 seconds if we're trying  
to request a checkpoint but the checkpointer hasn't started yet (or,  
much less likely, our kill() call fails).  However buildfarm experience  
shows that that's not quite enough for slow or heavily-loaded machines.  
There's no good reason to assume that the checkpointer won't start  
eventually, so we may as well make the timeout much longer, say 60 sec.  
  
However, if the caller didn't say CHECKPOINT_WAIT, it seems like a bad  
idea to be waiting at all, much less for as long as 60 sec.  We can  
remove the need for that, and make this whole thing more robust, by  
adjusting the code so that the existence of a pending checkpoint  
request is clear from the contents of shared memory, and making sure  
that the checkpointer process will notice it at startup even if it did  
not get a signal.  In this way there's no need for a non-CHECKPOINT_WAIT  
call to wait at all; if it can't send the signal, it can nonetheless  
assume that the checkpointer will eventually service the request.  
  
A potential downside of this change is that "kill -INT" on the checkpointer  
process is no longer enough to trigger a checkpoint, should anyone be  
relying on something so hacky.  But there's no obvious reason to do it  
like that rather than issuing a plain old CHECKPOINT command, so we'll  
assume that nobody is.  There doesn't seem to be a way to preserve this  
undocumented quasi-feature without introducing race conditions.  
  
Since a principal reason for messing with this is to prevent intermittent  
buildfarm failures, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/27830.1552752475@sss.pgh.pa.us  

M src/backend/postmaster/checkpointer.c
M src/include/access/xlog.h

Fix volatile vs. pointer confusion

commit   : c77f21899ac2bd85d9d30d2dbf60904498ebee2f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 14 Mar 2019 08:25:25 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 14 Mar 2019 08:25:25 +0100    

Click here for diff

Variables used after a longjmp() need to be declared volatile.  In  
case of a pointer, it's the pointer itself that needs to be declared  
volatile, not the pointed-to value.  So we need  
  
    PyObject *volatile items;  
  
instead of  
  
    volatile PyObject *items;  /* wrong */  
  
Discussion: https://www.postgresql.org/message-id/flat/f747368d-9e1a-c46a-ac76-3c27da32e8e4%402ndquadrant.com  

M contrib/hstore_plpython/hstore_plpython.c

Ensure dummy paths have correct required_outer if rel is parameterized.

commit   : d4b754c876d3338f314c9610e424083cfaff0717    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Mar 2019 12:16:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 Mar 2019 12:16:09 -0400    

Click here for diff

The assertions added by commits 34ea1ab7f et al found another problem:  
set_dummy_rel_pathlist and mark_dummy_rel were failing to label  
the dummy paths they create with the correct outer_relids, in case  
the relation is necessarily parameterized due to having lateral  
references in its tlist.  It's likely that this has no user-visible  
consequences in production builds, at the moment; but still an assertion  
failure is a bad thing, so back-patch the fix.  
  
Per bug #15694 from Roman Zharkov (via Alexander Lakhin)  
and an independent report by Tushar Ahuja.  
  
Discussion: https://postgr.es/m/15694-74f2ca97e7044f7f@postgresql.org  
Discussion: https://postgr.es/m/7d72ab20-c725-3ce2-f99d-4e64dd8a0de6@enterprisedb.com  

M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/path/joinrels.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql

Remove extra comma

commit   : 0ca982a6d7489cea81909b672f96b947a3862cbc    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 13 Mar 2019 13:41:14 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 13 Mar 2019 13:41:14 +0100    

Click here for diff

Author: Christoph Berg <myon@debian.org>  

M doc/src/sgml/pageinspect.sgml

Fix potential memory access violation in ecpg if filename of include file is shorter than 2 characters.

commit   : 5469a1e78c92a3ce9ed232583273c53223e83b63    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Mon, 11 Mar 2019 16:11:16 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Mon, 11 Mar 2019 16:11:16 +0100    

Click here for diff

Patch by: "Wu, Fei" <wufei.fnst@cn.fujitsu.com>  

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

Fix documentation on partitioning vs. foreign tables

commit   : cadead6c3c8ed81e09a3cb5101ff453758412f54    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 10 Mar 2019 19:45:29 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 10 Mar 2019 19:45:29 -0300    

Click here for diff

1. The PARTITION OF clause of CREATE FOREIGN TABLE was not explained in  
   the CREATE FOREIGN TABLE reference page.  Add it.  
   (Postgres 10 onwards)  
  
2. The limitation that tuple routing cannot target partitions that are  
   foreign tables was not documented clearly enough.  Improve wording.  
   (Postgres 10 onwards)  
  
3. The UPDATE tuple re-routing concurrency behavior was explained in  
   the DDL chapter, which doesn't seem the right place.  Move it to the  
   UPDATE reference page instead.  (Postgres 11 onwards).  
  
Authors: Amit Langote, David Rowley.  
Reviewed-by: Etsuro Fujita.  
Reported-by: Derek Hans  
Discussion: https://postgr.es/m/CAGrP7a3Xc1Qy_B2WJcgAD8uQTS_NDcJn06O5mtS_Ne1nYhBsyw@mail.gmail.com  

M doc/src/sgml/ref/create_foreign_table.sgml

Disallow NaN as a value for floating-point GUCs.

commit   : f9ec64df8f25ecf69f870682abc6ff0950641610    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Mar 2019 12:58:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 Mar 2019 12:58:52 -0400    

Click here for diff

None of the code that uses GUC values is really prepared for them to  
hold NaN, but parse_real() didn't have any defense against accepting  
such a value.  Treat it the same as a syntax error.  
  
I haven't attempted to analyze the exact consequences of setting any  
of the float GUCs to NaN, but since they're quite unlikely to be good,  
this seems like a back-patchable bug fix.  
  
Note: we don't need an explicit test for +-Infinity because those will  
be rejected by existing range checks.  I added a regression test for  
that in HEAD, but not older branches because the spelling of the value  
in the error message will be platform-dependent in branches where we  
don't always use port/snprintf.c.  
  
Discussion: https://postgr.es/m/1798.1552165479@sss.pgh.pa.us  

M src/backend/utils/misc/guc.c
M src/test/regress/expected/guc.out
M src/test/regress/sql/guc.sql

commit   : 22816ce51345a4ddc890ef3f2fe84712ef3adb8c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Mar 2019 18:42:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 Mar 2019 18:42:19 -0500    

Click here for diff

Now that https://www.postgresql.org/docs/release/ is populated,  
replace the stopgap text we had under "Prior Releases" with  
a pointer to that archive.  
  
Discussion: https://postgr.es/m/e0f09c9a-bd2b-862a-d379-601dfabc8969@postgresql.org  

M doc/src/sgml/release.sgml

Fix function signatures of pageinspect in documentation

commit   : 79893e97c099b92d2b9dbe2b58772ea22d0b4e3b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 8 Mar 2019 15:10:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 8 Mar 2019 15:10:38 +0900    

Click here for diff

tuple_data_split() lacked the type of the first argument, and  
heap_page_item_attrs() has reversed the first and second argument,  
with the bytea argument using an incorrect name.  
  
Author: Laurenz Albe  
Discussion: https://postgr.es/m/8f9ab7b16daf623e87eeef5203a4ffc0dece8dfd.camel@cybertec.at  

M doc/src/sgml/pageinspect.sgml

Fix handling of targetlist SRFs when scan/join relation is known empty.

commit   : 19ff710aaa5f131a15da97484da5a669a3448864    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Mar 2019 14:21:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Mar 2019 14:21:52 -0500    

Click here for diff

When we introduced separate ProjectSetPath nodes for application of  
set-returning functions in v10, we inadvertently broke some cases where  
we're supposed to recognize that the result of a subquery is known to be  
empty (contain zero rows).  That's because IS_DUMMY_REL was just looking  
for a childless AppendPath without allowing for a ProjectSetPath being  
possibly stuck on top.  In itself, this didn't do anything much worse  
than produce slightly worse plans for some corner cases.  
  
Then in v11, commit 11cf92f6e rearranged things to allow the scan/join  
targetlist to be applied directly to partial paths before they get  
gathered.  But it inserted a short-circuit path for dummy relations  
that was a little too short: it failed to insert a ProjectSetPath node  
at all for a targetlist containing set-returning functions, resulting in  
bogus "set-valued function called in context that cannot accept a set"  
errors, as reported in bug #15669 from Madelaine Thibaut.  
  
The best way to fix this mess seems to be to reimplement IS_DUMMY_REL  
so that it drills down through any ProjectSetPath nodes that might be  
there (and it seems like we'd better allow for ProjectionPath as well).  
  
While we're at it, make it look at rel->pathlist not cheapest_total_path,  
so that it gives the right answer independently of whether set_cheapest  
has been done lately.  That dependency looks pretty shaky in the context  
of code like apply_scanjoin_target_to_paths, and even if it's not broken  
today it'd certainly bite us at some point.  (Nastily, unsafe use of the  
old coding would almost always work; the hazard comes down to possibly  
looking through a dangling pointer, and only once in a blue moon would  
you find something there that resulted in the wrong answer.)  
  
It now looks like it was a mistake for IS_DUMMY_REL to be a macro: if  
there are any extensions using it, they'll continue to use the old  
inadequate logic until they're recompiled, after which they'll fail  
to load into server versions predating this fix.  Hopefully there are  
few such extensions.  
  
Having fixed IS_DUMMY_REL, the special path for dummy rels in  
apply_scanjoin_target_to_paths is unnecessary as well as being wrong,  
so we can just drop it.  
  
Also change a few places that were testing for partitioned-ness of a  
planner relation but not using IS_PARTITIONED_REL for the purpose; that  
seems unsafe as well as inconsistent, plus it required an ugly hack in  
apply_scanjoin_target_to_paths.  
  
In passing, save a few cycles in apply_scanjoin_target_to_paths by  
skipping processing of pre-existing paths for partitioned rels,  
and do some cosmetic cleanup and comment adjustment in that function.  
  
I renamed IS_DUMMY_PATH to IS_DUMMY_APPEND with the intention of breaking  
any code that might be using it, since in almost every case that would  
be wrong; IS_DUMMY_REL is what to be using instead.  
  
In HEAD, also make set_dummy_rel_pathlist static (since it's no longer  
used from outside allpaths.c), and delete is_dummy_plan, since it's no  
longer used anywhere.  
  
Back-patch as appropriate into v11 and v10.  
  
Tom Lane and Julien Rouhaud  
  
Discussion: https://postgr.es/m/15669-02fb3296cca26203@postgresql.org  

M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/path/joinrels.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/planner.c
M src/include/nodes/relation.h
M src/test/regress/expected/tsrf.out
M src/test/regress/sql/tsrf.sql

Disable dump_connstr test on Msys2

commit   : c2c937cfc3f55fe6db340b7ba7f5ba041f3c34d5    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 4 Mar 2019 17:11:18 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 4 Mar 2019 17:11:18 -0500    

Click here for diff

For some reason the dump test with names with high bits set fails on  
Msys2 (although not Msys1). Disable the tests for now, so that other  
tests can run.  

M src/bin/pg_dump/t/010_dump_connstr.pl

Fix error handling of readdir() port implementation on first file lookup

commit   : 9aa59e64ba753e5392ea2711a0decb7c633d69ce    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 4 Mar 2019 09:50:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 4 Mar 2019 09:50:06 +0900    

Click here for diff

The implementation of readdir() in src/port/ which gets used by MSVC has  
been added in 399a36a, and since the beginning it considers all errors  
on the first file lookup as ENOENT, setting errno accordingly and  
letting the routine caller think that the directory is empty.  While  
this is normally enough for the case of the backend, this can confuse  
callers of this routine on Windows as all errors would map to the same  
behavior.  So, for example, even permission errors would be thought as  
having an empty directory, while there could be contents in it.  
  
This commit changes the error handling so as readdir() gets a behavior  
similar to native implementations: force errno=0 when seeing  
ERROR_FILE_NOT_FOUND as error and consider other errors as plain  
failures.  
  
While looking at the patch, I noticed that MinGW does not enforce  
errno=0 when looking at the first file, but it gets enforced on the next  
file lookups.  A comment related to that was incorrect in the code.  
  
Reported-by: Yuri Kurenkov  
Diagnosed-by: Yuri Kurenkov, Grigory Smolkin  
Author:	Konstantin Knizhnik  
Reviewed-by: Andrew Dunstan, Michael Paquier  
Discussion: https://postgr.es/m/2cad7829-8d66-e39c-b937-ac825db5203d@postgrespro.ru  
Backpatch-through: 9.4  

M src/port/dirent.c

Further fixing for multi-row VALUES lists for updatable views.

commit   : 0a08446308c8387144e69a99bf738e204f11fc70    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 3 Mar 2019 10:54:55 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 3 Mar 2019 10:54:55 +0000    

Click here for diff

Previously, rewriteTargetListIU() generated a list of attribute  
numbers from the targetlist, which were passed to rewriteValuesRTE(),  
which expected them to contain the same number of entries as there are  
columns in the VALUES RTE, and to be in the same order. That was fine  
when the target relation was a table, but for an updatable view it  
could be broken in at least three different ways ---  
rewriteTargetListIU() could insert additional targetlist entries for  
view columns with defaults, the view columns could be in a different  
order from the columns of the underlying base relation, and targetlist  
entries could be merged together when assigning to elements of an  
array or composite type. As a result, when recursing to the base  
relation, the list of attribute numbers generated from the rewritten  
targetlist could no longer be relied upon to match the columns of the  
VALUES RTE. We got away with that prior to 41531e42d3 because it used  
to always be the case that rewriteValuesRTE() did nothing for the  
underlying base relation, since all DEFAULTS had already been replaced  
when it was initially invoked for the view, but that was incorrect  
because it failed to apply defaults from the base relation.  
  
Fix this by examining the targetlist entries more carefully and  
picking out just those that are simple Vars referencing the VALUES  
RTE. That's sufficient for the purposes of rewriteValuesRTE(), which  
is only responsible for dealing with DEFAULT items in the VALUES  
RTE. Any DEFAULT item in the VALUES RTE that doesn't have a matching  
simple-Var-assignment in the targetlist is an error which we complain  
about, but in theory that ought to be impossible.  
  
Additionally, move this code into rewriteValuesRTE() to give a clearer  
separation of concerns between the 2 functions. There is no need for  
rewriteTargetListIU() to know about the details of the VALUES RTE.  
  
While at it, fix the comment for rewriteValuesRTE() which claimed that  
it doesn't support array element and field assignments --- that hasn't  
been true since a3c7a993d5 (9.6 and later).  
  
Back-patch to all supported versions, with minor differences for the  
pre-9.6 branches, which don't support array element and field  
assignments to the same column in multi-row VALUES lists.  
  
Reviewed by Amit Langote.  
  
Discussion: https://postgr.es/m/15623-5d67a46788ec8b7f@postgresql.org  

M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql

Improve documentation of data_sync_retry

commit   : ab1d9f066aee4f9b81abde6136771debe0191ae8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Feb 2019 11:02:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Feb 2019 11:02:23 +0900    

Click here for diff

Reflecting an updated parameter value requires a server restart, which  
was not mentioned in the documentation and in postgresql.conf.sample.  
  
Reported-by: Thomas Poty  
Discussion: https://postgr.es/m/15659-0cd812f13027a2d8@postgresql.org  

M doc/src/sgml/config.sgml
M src/backend/utils/misc/postgresql.conf.sample

Fix inconsistent out-of-memory error reporting in dsa.c.

commit   : 406e937d124842b3c268f1d96848b73d8defc05a    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 25 Feb 2019 10:54:12 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 25 Feb 2019 10:54:12 +1300    

Click here for diff

Commit 16be2fd1 introduced the flag DSA_ALLOC_NO_OOM to control whether  
the DSA allocator would raise an error or return InvalidDsaPointer on  
failure to allocate.  One edge case was not handled correctly: if we  
fail to allocate an internal "span" object for a large allocation, we  
would always return InvalidDsaPointer regardless of the flag; a caller  
not expecting that could then dereference a null pointer.  
  
This is a plausible explanation for a one-off report of a segfault.  
  
Remove a redundant pair of braces so that all three stanzas that handle  
DSA_ALLOC_NO_OOM match in style, for visual consistency.  
  
While fixing inconsistencies, if FreePageManagerGet() can't supply the  
pages that our book-keeping says it should be able to supply, then we  
should always report a FATAL error.  Previously we treated that as a  
regular allocation failure in one code path, but as a FATAL condition  
in another.  
  
Back-patch to 10, where dsa.c landed.  
  
Author: Thomas Munro  
Reported-by: Jakub Glapa  
Discussion: https://postgr.es/m/CAEepm=2oPqXxyWQ-1o60tpOLrwkw=VpgNXqqF1VN2EyO9zKGQw@mail.gmail.com  

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

Fix ecpg bugs caused by missing semicolons in the backend grammar.

commit   : 8ec638e69c01e589a3e0c11fbe9ad21c0a3549f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Feb 2019 12:51:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Feb 2019 12:51:50 -0500    

Click here for diff

The Bison documentation clearly states that a semicolon is required  
after every grammar rule, and our scripts that generate ecpg's  
grammar from the backend's implicitly assumed this is true.  But it  
turns out that only ancient versions of Bison actually enforce that.  
There have been a couple of rules without trailing semicolons in  
gram.y for some time, and as a consequence, ecpg's grammar was faulty  
and produced wrong output for the affected statements.  
  
To fix, add the missing semis, and add some cross-checks to ecpg's  
scripts so that they'll bleat if we mess this up again.  
  
The cases that were broken were:  
* "SET variable = DEFAULT" (but not "SET variable TO DEFAULT"),  
  as well as allied syntaxes such as ALTER SYSTEM SET ... DEFAULT.  
  These produced syntactically invalid output that the server  
  would reject.  
* Multiple type names in DROP TYPE/DOMAIN commands.  Only the  
  first type name would be listed in the emitted command.  
  
Per report from Daisuke Higuchi.  Back-patch to all supported versions.  
  
Discussion: https://postgr.es/m/1803D792815FC24D871C00D17AE95905DB51CE@g01jpexmbkw24  

M src/backend/parser/gram.y
M src/interfaces/ecpg/preproc/check_rules.pl
M src/interfaces/ecpg/preproc/parse.pl

Tolerate EINVAL when calling fsync() on a directory.

commit   : bcf6278343444aa1de93b7c131b30c608a5b6e45    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 24 Feb 2019 23:48:52 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 24 Feb 2019 23:48:52 +1300    

Click here for diff

Previously, we tolerated EBADF as a way for the operating system to  
indicate that it doesn't support fsync() on a directory.  Tolerate  
EINVAL too, for older versions of Linux CIFS.  
  
Bug #15636.  Back-patch all the way.  
  
Reported-by: John Klann  
Discussion: https://postgr.es/m/15636-d380890dafd78fc6@postgresql.org  

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

Tolerate ENOSYS failure from sync_file_range().

commit   : 387483e89b2851247e091013bfdbfd1c448cb7df    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 24 Feb 2019 13:38:15 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 24 Feb 2019 13:38:15 +1300    

Click here for diff

One unintended consequence of commit 9ccdd7f6 was that Windows WSL  
users started getting a panic whenever we tried to initiate data  
flushing with sync_file_range(), because WSL does not implement that  
system call.  Previously, they got a stream of periodic warnings,  
which was also undesirable but at least ignorable.  
  
Prevent the panic by handling ENOSYS specially and skipping the panic  
promotion with data_sync_elevel().  Also suppress future attempts  
after the first such failure so that the pre-existing problem of  
noisy warnings is improved.  
  
Back-patch to 9.6 (older branches were not affected in this way by  
9ccdd7f6).  
  
Author: Thomas Munro and James Sewell  
Tested-by: James Sewell  
Reported-by: Bruce Klein  
Discussion: https://postgr.es/m/CA+mCpegfOUph2U4ZADtQT16dfbkjjYNJL1bSTWErsazaFjQW9A@mail.gmail.com  

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

Fix plan created for inherited UPDATE/DELETE with all tables excluded.

commit   : 58947fbd56d1481a86a03087c81f728fdf0be866    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Feb 2019 12:23:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Feb 2019 12:23:00 -0500    

Click here for diff

In the case where inheritance_planner() finds that every table has  
been excluded by constraints, it thought it could get away with  
making a plan consisting of just a dummy Result node.  While certainly  
there's no updating or deleting to be done, this had two user-visible  
problems: the plan did not report the correct set of output columns  
when a RETURNING clause was present, and if there were any  
statement-level triggers that should be fired, it didn't fire them.  
  
Hence, rather than only generating the dummy Result, we need to  
stick a valid ModifyTable node on top, which requires a tad more  
effort here.  
  
It's been broken this way for as long as inheritance_planner() has  
known about deleting excluded subplans at all (cf commit 635d42e9c),  
so back-patch to all supported branches.  
  
Amit Langote and Tom Lane, per a report from Petr Fedorov.  
  
Discussion: https://postgr.es/m/5da6f0f0-1364-1876-6978-907678f89a3e@phystech.edu  

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

Report correct name in autovacuum “work items” activity

commit   : 398cc6fb93814423f205dee435d1a174068c041a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 Feb 2019 13:00:15 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 Feb 2019 13:00:15 -0300    

Click here for diff

We were reporting the database name instead of the relation name to  
pg_stat_activity.  Repair.  
  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20190220185552.GR28750@telsasoft.com  

M src/backend/postmaster/autovacuum.c

Speed up match_eclasses_to_foreign_key_col() when there are many ECs.

commit   : affee8b14c68d8ac8815406be39a68403c4a815e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Feb 2019 20:53:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Feb 2019 20:53:08 -0500    

Click here for diff

Check ec_relids before bothering to iterate through the EC members.  
On a perhaps extreme, but still real-world, query in which  
match_eclasses_to_foreign_key_col() accounts for the bulk of the  
planner's runtime, this saves nearly 40% of the runtime.  It's a bit  
of a stopgap fix, but it's simple enough to be back-patched to 9.6  
where this code came in; so let's do that.  
  
David Rowley  
  
Discussion: https://postgr.es/m/6970.1545327857@sss.pgh.pa.us  

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

Make object address handling more robust

commit   : ddad002dea73cf2ad08b0916d4d9eb84fc18edad    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Feb 2019 09:12:02 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Feb 2019 09:12:02 -0300    

Click here for diff

pg_identify_object_as_address crashes when passed certain tuples from  
inconsistent system catalogs.  Make it more defensive.  
  
Author: Álvaro Herrera  
Reviewed-by: Michaël Paquier  
Discussion: https://postgr.es/m/20190218202743.GA12392@alvherre.pgsql  

M src/backend/catalog/objectaddress.c

Fix DEFAULT-handling in multi-row VALUES lists for updatable views.

commit   : 2b1971c0318bae45317386877621642cd5ce7849    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 20 Feb 2019 08:27:24 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 20 Feb 2019 08:27:24 +0000    

Click here for diff

INSERT ... VALUES for a single VALUES row is implemented differently  
from a multi-row VALUES list, which causes inconsistent behaviour in  
the way that DEFAULT items are handled. In particular, when inserting  
into an auto-updatable view on top of a table with a column default, a  
DEFAULT item in a single VALUES row gets correctly replaced with the  
table column's default, but for a multi-row VALUES list it is replaced  
with NULL.  
  
Fix this by allowing rewriteValuesRTE() to leave DEFAULT items in the  
VALUES list untouched if the target relation is an auto-updatable view  
and has no column default, deferring DEFAULT-expansion until the query  
against the base relation is rewritten. For all other types of target  
relation, including tables and trigger- and rule-updatable views, we  
must continue to replace DEFAULT items with NULL in the absence of a  
column default.  
  
This is somewhat complicated by the fact that if an auto-updatable  
view has DO ALSO rules attached, the VALUES lists for the product  
queries need to be handled differently from the original query, since  
the product queries need to act like rule-updatable views whereas the  
original query has auto-updatable view semantics.  
  
Back-patch to all supported versions.  
  
Reported by Roger Curley (bug #15623). Patch by Amit Langote and me.  
  
Discussion: https://postgr.es/m/15623-5d67a46788ec8b7f@postgresql.org  

M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql

Mark correctly initial slot snapshots with MVCC type when built

commit   : a80f5c279bd5625f349afbfb1572cfad0b429b8d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Feb 2019 12:31:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Feb 2019 12:31:32 +0900    

Click here for diff

When building an initial slot snapshot, snapshots are marked with  
historic MVCC snapshots as type with the marker field being set in  
SnapBuildBuildSnapshot() but not overriden in SnapBuildInitialSnapshot().  
Existing callers of SnapBuildBuildSnapshot() do not care about the type  
of snapshot used, but extensions calling it actually may, as reported.  
  
Author: Antonin Houska  
Reviewed-by: Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/23215.1527665193@localhost  
Backpatch-through: 9.4  

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

Fix omissions in ecpg/test/sql/.gitignore.

commit   : 3b940cd9dc7bc61d1af2b523142d0b175ed9b12d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Feb 2019 21:24:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 Feb 2019 21:24:38 -0500    

Click here for diff

Oversights in commits 050710b36 and e81f0e311.  

M src/interfaces/ecpg/test/sql/.gitignore

Sync ECPG’s CREATE TABLE AS statement with backend’s.

commit   : f647a5fb0d63c43de7daf7c31a59a6fc98b9a6a1    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Mon, 18 Feb 2019 11:57:34 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Mon, 18 Feb 2019 11:57:34 +0100    

Click here for diff

Author: Higuchi-san ("Higuchi, Daisuke" <higuchi.daisuke@jp.fujitsu.com>)  

M src/interfaces/ecpg/preproc/ecpg.trailer
M src/interfaces/ecpg/test/ecpg_schedule
A src/interfaces/ecpg/test/expected/sql-createtableas.c
A src/interfaces/ecpg/test/expected/sql-createtableas.stderr
A src/interfaces/ecpg/test/expected/sql-createtableas.stdout
M src/interfaces/ecpg/test/sql/Makefile
A src/interfaces/ecpg/test/sql/createtableas.pgc

Fix race in dsm_unpin_segment() when handles are reused.

commit   : 7718a992035501933cb4359d075908075da22f1f    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 18 Feb 2019 09:53:26 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 18 Feb 2019 09:53:26 +1300    

Click here for diff

Teach dsm_unpin_segment() to skip segments that are in the process  
of being destroyed by another backend, when searching for a handle.  
Such a segment cannot possibly be the one we are looking for, even  
if its handle matches.  Another slot might hold a recently created  
segment that has the same handle value by coincidence, and we need  
to keep searching for that one.  
  
The bug caused rare "cannot unpin a segment that is not pinned"  
errors on 10 and 11.  Similar to commit 6c0fb941 for dsm_attach().  
  
Back-patch to 10, where dsm_unpin_segment() landed.  
  
Author: Thomas Munro  
Reported-by: Justin Pryzby  
Tested-by: Justin Pryzby (along with other recent DSA/DSM fixes)  
Discussion: https://postgr.es/m/20190216023854.GF30291@telsasoft.com  

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

commit   : c1769970499833e451d0125ed1bc43d116ad3160    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sun, 17 Feb 2019 13:14:58 -0500    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sun, 17 Feb 2019 13:14:58 -0500    

Click here for diff

The dblink documentation claims that an empty string is returned if there  
has been no error, however OK is actually returned in that case. Also,  
clarify that an async error may not be seen unless dblink_is_busy() or  
dblink_get_result() have been called first.  
  
Backpatch to all supported branches.  
  
Reported-by: realyota  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/153371978486.1298.2091761143788088262@wrigleys.postgresql.org  

M doc/src/sgml/dblink.sgml

Fix CREATE VIEW to allow zero-column views.

commit   : b355be443b74d2749db00242d068fabc2df39f27    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Feb 2019 12:37:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 17 Feb 2019 12:37:32 -0500    

Click here for diff

We should logically have allowed this case when we allowed zero-column  
tables, but it was overlooked.  
  
Although this might be thought a feature addition, it's really a bug  
fix, because it was possible to create a zero-column view via  
the convert-table-to-view code path, and then you'd have a situation  
where dump/reload would fail.  Hence, back-patch to all supported  
branches.  
  
Arrange the added test cases to provide coverage of the related  
pg_dump code paths (since these views will be dumped and reloaded  
during the pg_upgrade regression test).  I also made them test  
the case where pg_dump has to postpone the view rule into post-data,  
which disturbingly had no regression coverage before.  
  
Report and patch by Ashutosh Sharma (test case by me)  
  
Discussion: https://postgr.es/m/CAE9k0PkmHdeSaeZt2ujnb_cKucmK3sDDceDzw7+d5UZoNJPYOg@mail.gmail.com  

M src/backend/commands/view.c
M src/test/regress/expected/create_view.out
M src/test/regress/expected/rules.out
M src/test/regress/expected/sanity_check.out
M src/test/regress/sql/create_view.sql

Doc: remove ancient comment.

commit   : 6e5c270318c92bdb1689da45304d27f85aeb0b91    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 17 Feb 2019 20:40:43 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 17 Feb 2019 20:40:43 +0900    

Click here for diff

There's a very old comment in rules.sgml added back to 2003.  It  
expected to a feature coming back but it never happened. So now we can  
safely remove the comment. Back-patched to all supported branches.  
  
Discussion: https://postgr.es/m/20190211.191004.219630835457494660.t-ishii%40sraoss.co.jp  

M doc/src/sgml/rules.sgml

Fix CLogTruncationLock documentation.

commit   : 468b1af66088923bb045d112c3574a8738e4989e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 17 Feb 2019 00:51:11 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 17 Feb 2019 00:51:11 -0800    

Click here for diff

Back-patch to v10, which introduced the lock.  

M doc/src/sgml/monitoring.sgml

Fix support for CREATE TABLE IF NOT EXISTS AS EXECUTE

commit   : 3a2923a9bfd8e769d5bafeef4284fbf1ba953cbf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 15 Feb 2019 17:12:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 15 Feb 2019 17:12:36 +0900    

Click here for diff

The grammar IF NOT EXISTS for CTAS is supported since 9.5 and documented  
as such, however the case of using EXECUTE as query has never been  
covered as EXECUTE CTAS statements and normal CTAS statements are parsed  
separately.  
  
Author: Andreas Karlsson  
Discussion: https://postgr.es/m/2ddcc188-e37c-a0be-32bf-a56b07c3559e@proxel.se  
Backpatch-through: 9.5  

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

Fix race in dsm_attach() when handles are reused.

commit   : cb3d674e1709362d84b5e25c94e690e98599a33c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 15 Feb 2019 10:19:11 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 15 Feb 2019 10:19:11 +1300    

Click here for diff

DSM handle values can be reused as soon as the underlying shared memory  
object has been destroyed.  That means that for a brief moment we  
might have two DSM slots with the same handle.  While trying to attach,  
if we encounter a slot with refcnt == 1, meaning that it is currently  
being destroyed, we should continue our search in case the same handle  
exists in another slot.  
  
The race manifested as a rare "dsa_area could not attach to segment"  
error, and was more likely in 10 and 11 due to the lack of distinct  
seed for random() in parallel workers.  It was made very unlikely in  
in master by commit 197e4af9, and older releases don't usually create  
new DSM segments in background workers so it was also unlikely there.  
  
This fixes the root cause of bug report #15585, in which the error  
could also sometimes result in a self-deadlock in the error path.  
It's not yet clear if further changes are needed to avoid that failure  
mode.  
  
Back-patch to 9.4, where dsm.c arrived.  
  
Author: Thomas Munro  
Reported-by: Justin Pryzby, Sergei Kornilov  
Discussion: https://postgr.es/m/20190207014719.GJ29720@telsasoft.com  
Discussion: https://postgr.es/m/15585-324ff6a93a18da46@postgresql.org  

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

Fix rare dsa_allocate() failures due to freepage.c corruption.

commit   : 2cfdf24e7c6867c768999ccd809a32d53d226d82    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 13 Feb 2019 13:14:10 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 13 Feb 2019 13:14:10 +1300    

Click here for diff

In a corner case, a btree page was allocated during a clean-up operation  
that could cause the tracking of the largest contiguous span of free  
space to get out of whack.  That was supposed to be prevented by the use  
of the "soft" flag to avoid allocating internal pages during incidental  
clean-up work, but the flag was ignored in the case where the FPM was  
promoted from singleton format to btree format.  Repair.  
  
Remove an obsolete comment in passing.  
  
Back-patch to 10, where freepage.c arrived (as support for dsa.c).  
  
Author: Robert Haas  
Diagnosed-by: Thomas Munro and Robert Haas  
Reported-by: Justin Pryzby, Rick Otten, Sand Stone, Arne Roland and others  
Discussion: https://postgr.es/m/CAMAYy4%2Bw3NTBM5JLWFi8twhWK4%3Dk_5L4nV5%2BbYDSPu8r4b97Zg%40mail.gmail.com  

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

Relax overly strict assertion

commit   : f5f9a760a3bc2be95f8716e476150ce128efa22b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 Feb 2019 18:42:37 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 Feb 2019 18:42:37 -0300    

Click here for diff

Ever since its birth, ReorderBufferBuildTupleCidHash() has contained an  
assertion that a catalog tuple cannot change Cmax after acquiring one.  But  
that's wrong: if a subtransaction executes DDL that affects that catalog  
tuple, and later aborts and another DDL affects the same tuple, it will  
change Cmax.  Relax the assertion to merely verify that the Cmax remains  
valid and monotonically increasing, instead.  
  
Add a test that tickles the relevant code.  
  
Diagnosed by, and initial patch submitted by: Arseny Sher  
Co-authored-by: Arseny Sher  
Discussion: https://postgr.es/m/874l9p8hyw.fsf@ars-thinkpad  

M contrib/test_decoding/expected/ddl.out
M contrib/test_decoding/sql/ddl.sql
M src/backend/replication/logical/reorderbuffer.c

Fix erroneous error reports in snapbuild.c.

commit   : 2a0edae47af453ef27ef7ff013beb7201f8549d8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Feb 2019 01:12:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Feb 2019 01:12:52 -0500    

Click here for diff

It's pretty unhelpful to report the wrong file name in a complaint  
about syscall failure, but SnapBuildSerialize managed to do that twice  
in a span of 50 lines.  Also fix half a dozen missing or poorly-chosen  
errcode assignments; that's mostly cosmetic, but still wrong.  
  
Noted while studying recent failures on buildfarm member nightjar.  
I'm not sure whether those reports are actually giving the wrong  
filename, because there are two places here with identically  
spelled error messages.  The other one is specifically coded not  
to report ENOENT, but if it's this one, how could we be getting  
ENOENT from open() with O_CREAT?  Need to sit back and await results.  
  
However, these ereports are clearly broken from birth, so back-patch.  

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