PostgreSQL 11.3 commit log

commit   : 0616aed243b23e68b5c06ceb3df3e4ec35e731b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 May 2019 16:46:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 May 2019 16:46:18 -0400    

commit   : 02814c381bbae9d23b19042fe356c000ae31d975    
  
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    

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

commit   : 92880ff8a667f755aa04b54e5cb2c4388c924052    
  
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    

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

commit   : dcbdd1a8d55a4fd8a2b318fd5a2647ba4dbb4275    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 May 2019 14:39:59 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 May 2019 14:39:59 +0200    

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

commit   : 52635c276fe352276c157ccea36d7655729d328d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 May 2019 21:44:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 May 2019 21:44:39 +0900    

With correctly crafted DDLs, this could lead to disclosure of arbitrary  
backend memory a user may have no right to access.  This impacts only  
REL_11_STABLE, as the issue has been introduced by 34295b8.  
  
On HEAD, add regression tests to cover this issue in the future.  
  
Author: Michael Paquier  
Reviewed-by: Noah Misch  
Security: CVE-2019-10129  

commit   : 98dad4cd48e362090b30187441e8c116afb74f58    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 6 May 2019 11:56:37 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 6 May 2019 11:56:37 +0100    

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.  

commit   : 0027ee3c52d824764f7f8391edb2695c3d2b424f    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 6 May 2019 11:41:22 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Mon, 6 May 2019 11:41:22 +0100    

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  

commit   : 60c2951e1bab7e2b03c91bcfe484d6caa0b8c2a4    
  
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    

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!)  

commit   : 69fc9430b892c737efa86e70fde7b4fd43974b10    
  
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    

commit   : 000f557c3111add0e5aa28936ba8ad49ff896667    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 May 2019 13:10:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 May 2019 13:10:07 -0400    

Project style is to check the success of SearchSysCacheN and friends  
by applying HeapTupleIsValid to the result.  A tiny minority of calls  
creatively did it differently.  Bring them into line with the rest.  
  
This is just cosmetic, since HeapTupleIsValid is indeed just a null  
check at the moment ... but that may not be true forever, and in any  
case it puts a mental burden on readers who may wonder why these  
call sites are not like the rest.  
  
Back-patch to v11 just to keep the branches in sync.  (The bulk of these  
errors seem to have originated in v11 or v12, though a few are old.)  
  
Per searching to see if anyplace else had made the same error  
repaired in 62148c352.  

commit   : 030ad0acfa5794c645a9a6093fdd3ed4d4f4788c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 May 2019 12:44:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 May 2019 12:44:32 -0400    

Omitted in commit 05b38c7e6 (though it looks like the original blame  
belongs to 9e9befac4).  A failure is admittedly unlikely, but if it  
did happen, SIGSEGV is not the approved method of reporting it.  
  
Per Coverity.  Back-patch to v11 where the broken code originated.  

commit   : 506af101f3e9d8f475e6a326eb0ad89f7db81eda    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 4 May 2019 19:39:48 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 4 May 2019 19:39:48 +0200    

commit   : bf0720233ec8f82edb6d55d1668347f9ab60e2f6    
  
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    

The newline was incorrectly dropped in  
a98c48debcd0620ab07608d53ee08fdb0e7a1edb.  

commit   : 8b3bce2017b15e05f000c3c5947653a3e2c5a29f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 May 2019 18:27:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 May 2019 18:27:39 -0400    

As usual, the release notes for other branches will be made by cutting  
these down, but put them up for community review first.  

commit   : 727c155cfbfb22b0caa8ef364a8d7587ac0a64ce    
  
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    

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  

commit   : 63c6a24ae4d66422417dfa89527824a7b4b4ceb4    
  
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    

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  

commit   : d264bb51c5ad12708394725eab14dae7be5c0b59    
  
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    

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

commit   : 11ea45ffec9aa818004341171ccbf5bc7ec9b28a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Apr 2019 15:03:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 30 Apr 2019 15:03:35 -0400    

The interaction of these parameters was a bit confused/confusing,  
and in fact v11 entirely misses the opportunity to apply partition  
constraints when a partition is accessed directly (rather than  
indirectly from its parent).  
  
In HEAD, establish the principle that enable_partition_pruning controls  
partition pruning and nothing else.  When accessing a partition via its  
parent, we do partition pruning (if enabled by enable_partition_pruning)  
and then there is no need to consider partition constraints in the  
constraint_exclusion logic.  When accessing a partition directly, its  
partition constraints are applied by the constraint_exclusion logic,  
only if constraint_exclusion = on.  
  
In v11, we can't have such a clean division of these GUCs' effects,  
partly because we don't want to break compatibility too much in a  
released branch, and partly because the clean coding requires  
inheritance_planner to have applied partition pruning to a partitioned  
target table, which it doesn't in v11.  However, we can tweak things  
enough to cover the missed case, which seems like a good idea since  
it's potentially a performance regression from v10.  This patch keeps  
v11's previous behavior in which enable_partition_pruning overrides  
constraint_exclusion for an inherited target table, though.  
  
In HEAD, also teach relation_excluded_by_constraints that it's okay to use  
inheritable constraints when trying to prune a traditional inheritance  
tree.  This might not be thought worthy of effort given that that feature  
is semi-deprecated now, but we have enough infrastructure that it only  
takes a couple more lines of code to do it correctly.  
  
Amit Langote and Tom Lane  
  
Discussion: https://postgr.es/m/9813f079-f16b-61c8-9ab7-4363cab28d80@lab.ntt.co.jp  
Discussion: https://postgr.es/m/29069.1555970894@sss.pgh.pa.us  

commit   : 14323493dd5313934899db59f5d12a3298dfe7af    
  
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    

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  

commit   : 474982fc398dc848da2d08a911e2900b9575217f    
  
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    

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>  

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

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  

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

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.  

commit   : a97cfd9b829158ba4d9be866c65d0937b7d3519d    
  
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    

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

commit   : 7898d01da35772b16f6fa6d110ee8d2f8cc32af0    
  
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    

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.  

commit   : f6307bacabf555e9343fbf4f91723ce698303b03    
  
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    

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.  

commit   : 02c359eeda50a71c951371c9d3e920ff8f514008    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Apr 2019 17:18:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Apr 2019 17:18:07 -0400    

Fix DefineIndex so that it doesn't attempt to pass down a to-be-reused  
index relfilenode to a child index creation, and fix TryReuseIndex  
to not think that reuse is sensible for a partitioned index.  
  
In v11, this fixes a problem where ALTER TABLE on a partitioned table  
could assign the same relfilenode to several different child indexes,  
causing very nasty catalog corruption --- in fact, attempting to DROP  
the partitioned table then leads not only to a database crash, but to  
inability to restart because the same crash will recur during WAL replay.  
  
Either of these two changes would be enough to prevent the failure, but  
since neither action could possibly be sane, let's put in both changes  
for future-proofing.  
  
In HEAD, no such bug manifests, but that's just an accidental consequence  
of having changed the pg_class representation of partitioned indexes to  
have relfilenode = 0.  Both of these changes still seem like smart  
future-proofing.  
  
This is only a stop-gap because the code for ALTER TABLE on a partitioned  
table with a no-op type change still leaves a great deal to be desired.  
As the added regression tests show, it gets things wrong for comments on  
child indexes/constraints, and it is regenerating child indexes it doesn't  
have to.  However, fixing those problems will take more work which may not  
get back-patched into v11.  We need a fix for the corruption problem now.  
  
Per bug #15672 from Jianing Yang.  
  
Patch by me, regression test cases based on work by Amit Langote,  
who also did a lot of the investigative work.  
  
Discussion: https://postgr.es/m/15672-b9fa7db32698269f@postgresql.org  

commit   : 53f48a2abb7b13a866d62e68e6ecfb11b637b0b1    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 26 Apr 2019 18:10:06 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 26 Apr 2019 18:10:06 +0900    

Author: Laurenz Albe and Etsuro Fujita  
Reviewed-by: Laurenz Albe and Amit Langote  
Backpatch-through: 11 where support for that by FDWs was added  
Discussion: https://postgr.es/m/bf36a0288e8f31b4f2f40952e225bf892dc1ffc5.camel@cybertec.at  

commit   : b1f570b57cccba9275649815be009a3947b48130    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Apr 2019 11:37:08 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 25 Apr 2019 11:37:08 -0400    

When an existing index in a partition is attached to a new index on  
its parent, we forgot to set the "relispartition" flag correctly, which  
meant that it was not possible to find the index in various operations,  
such as adding a foreign key constraint that references that partitioned  
table.  One of four places that was assigning the parent index was  
forgetting to do that, so fix by shifting responsibility of updating the  
flag to the routine that changes the parent.  
  
Author: Amit Langote, Álvaro Herrera  
Reported-by: Hubert "depesz" Lubaczewski  
Discussion: https://postgr.es/m/CA+HiwqHMsRtRYRWYTWavKJ8x14AFsv7bmAV46mYwnfD3vy8goQ@mail.gmail.com  

commit   : a98c48debcd0620ab07608d53ee08fdb0e7a1edb    
  
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    

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  

commit   : f8642fb1789265d0376f238b5a8a1cf794665b6b    
  
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    

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  

commit   : 7a3d055349a98c919d1a4ea45a6a3e8e39391ab8    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 24 Apr 2019 18:31:51 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 24 Apr 2019 18:31:51 +0900    

Commit 3d956d9562 added support for update row movement in postgres_fdw.  
This patch fixes the following issues introduced by that commit:  
  
* When a remote partition chosen to insert routed rows into was also an  
  UPDATE subplan target rel that would be updated later, the UPDATE that  
  used a direct modification plan modified those routed rows incorrectly  
  because those routed rows were visible to the later UPDATE command.  
  The right fix for this would be to have some way in postgres_fdw in  
  which the later UPDATE command ignores those routed rows, but it seems  
  hard to do so with the current infrastructure.  For now throw an error  
  in that case.  
  
* When a remote partition chosen to insert routed rows into was also an  
  UPDATE subplan target rel, fmstate created for the UPDATE that used a  
  non-direct modification plan was mistakenly overridden by another  
  fmstate created for inserting those routed rows into the partition.  
  This caused 1) server crash when the partition would be updated later,  
  and 2) resource leak when the partition had been already updated.  To  
  avoid that, adjust the treatment of the fmstate for the inserting.  As  
  for #1, since we would also have the incorrectness issue as mentioned  
  above, error out in that case as well.  
  
Update the docs to mention that postgres_fdw currently does not handle  
the case where a remote partition chosen to insert a routed row into is  
also an UPDATE subplan target rel that will be updated later.  
  
Author: Amit Langote and Etsuro Fujita  
Reviewed-by: Amit Langote  
Backpatch-through: 11 where row movement in postgres_fdw was added  
Discussion: https://postgr.es/m/21e7eaa4-0d4d-20c2-a1f7-c7e96f4ce440@lab.ntt.co.jp  

commit   : e899df6a24f66ee851f618e7a083ceb811fe7192    
  
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    

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  

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

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  

commit   : cee3cfd75c20b14a3a38c4408e798f1c51701477    
  
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    

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  

commit   : ab01aa8521a5ae8a81a2a10cb8736e35f87cb19b    
  
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    

Backpatch-through: 10  

commit   : 0998f32ca3c4a8368217c6a14eb995ece9c580c6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Apr 2019 11:20:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Apr 2019 11:20:37 -0400    

HoldPinnedPortals() did things in the wrong order: it must not mark  
a portal autoHeld until it's been successfully held.  Otherwise,  
a failure while persisting the portal results in a server crash  
because we think the portal is in a good state when it's not.  
  
Also add a check that portal->status is READY before attempting to  
hold a pinned portal.  We have such a check before the only other  
use of HoldPortal(), so it seems unwise not to check it here.  
  
Lastly, rethink the responsibility for where to call HoldPinnedPortals.  
The comment for it imagined that it was optional for any individual PL  
to call it or not, but that cannot be the case: if some outer level of  
procedure has a pinned portal, failing to persist it when an inner  
procedure commits is going to be trouble.  Let's have SPI do it instead  
of the individual PLs.  That's not a complete solution, since in theory  
a PL might not be using SPI to perform commit/rollback, but such a PL  
is going to have to be aware of lots of related requirements anyway.  
(This change doesn't cause an API break for any external PLs that might  
be calling HoldPinnedPortals per the old regime, because calling it  
twice during a commit or rollback sequence won't hurt.)  
  
Per bug #15703 from Julian Schauder.  Back-patch to v11 where this code  
came in.  
  
Discussion: https://postgr.es/m/15703-c12c5bc0ea34ba26@postgresql.org  

commit   : f993bacdea7a8e8ebd9806f82302b18fb5eef71b    
  
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    

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  

commit   : e13b6a4387a8d7241ee6ee23701069c4053f073c    
  
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    

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  

commit   : 83be50d9a9546e7ca93fa1f8ea4973d17b41e8de    
  
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    

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  

commit   : 7e5569fdee0c2173de564a1b0649cb4d4cc5b890    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Apr 2019 17:30:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Apr 2019 17:30:29 -0400    

The buildfarm points out that UINT64_FORMAT might not work with sscanf;  
it's calibrated for our printf implementation, which might not agree  
with the platform-supplied sscanf.  Fall back to just accepting an  
unsigned long, which is already more than the documentation promises.  
  
Oversight in e6c3ba7fb; back-patch to v11, as that was.  

commit   : 76097b42ae03019784465c29d779c7324bc877fe    
  
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    

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  

commit   : 0d68ad3fc28377d36a3e1dd8b0e2ff47e693e552    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 15 Apr 2019 20:20:43 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 15 Apr 2019 20:20:43 +0300    

Checks inside _bt_vacuum_needs_cleanup() allow division by zero to happen when  
metad->btm_last_cleanup_num_heap_tuples == 0.  This commit adjusts the  
expression so that no division by zero might happen.  
  
Reported-by: Piotr Stefaniak  
Discussion: https://postgr.es/m/DB8PR03MB5931C41F7787A95313F08322F22A0%40DB8PR03MB5931.eurprd03.prod.outlook.com  
Reviewed-by: Masahiko Sawada  
Backpatch-through: 11  

commit   : 51290264346f0afce9752e5f6c957e1bfa3d2391    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Apr 2019 12:34:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 15 Apr 2019 12:34:51 +0900    

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  

commit   : 0bdf6d635e42f415c023393503a575d047940722    
  
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    

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  

commit   : 31e2caaceea99f1a638f3f4a32e99e7fe5bdad90    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 14 Apr 2019 00:42:34 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 14 Apr 2019 00:42:34 -0700    

Per buildfarm member jacana.  Back-patch to v11; earlier branches skip  
the affected test under msys.  
  
Discussion: https://postgr.es/m/GrdLgAdUK9FdyZg8VIcTDKVOkys122ZINEb3CjjoySfGj2KyPiMKTh1zqtRp0TAD7FJ27G-OBB3eplxIB5GhcQH5o8zzGZfp0MuJaXJxVxk=@yesql.se  

commit   : de262941fc9c5492b1a66444cfe87805a1bd6de5    
  
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    

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  

commit   : 089e4d405d0f3b94c74a2c6a54357a84a681754b    
  
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    

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  

commit   : 7ef2b313e6494c2bfece61a2601eea31ebcb3430    
  
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    

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  

commit   : 0ba09cc026985536586b7fd58ceddee16ea739d7    
  
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    

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

commit   : 5db85688a58ca4033c8073cdd9d6b064a4f1e8ea    
  
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    

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

commit   : 930930c476634991d1fa9838b1e41801d024eebf    
  
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    

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  

commit   : 036f7d3782e53573d2080e7d967fff375bc516b5    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 10 Apr 2019 08:36:42 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 10 Apr 2019 08:36:42 +0530    

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  

commit   : 47b6362b58e03aa2e1f55550539f79321375693b    
  
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    

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  

commit   : e45a8ff87149d9f69551b7e7378501e38bb60e8d    
  
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    

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  

commit   : 68e745ed0d230bde188dc4c9b528627d048144be    
  
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    

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  

commit   : f604aa956d4f2540be4c3e7521045c98e6a70baa    
  
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    

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

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

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  

commit   : 6b0208ebc436b33bd80ce264299b4b1b8d59b68a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Apr 2019 13:45:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 8 Apr 2019 13:45:14 +0900    

When trying to insert a tuple into a partitioned table, the routing to  
the correct partition has been messed up by mixing when a tuple needs to  
be stored in an intermediate parent's slot and when a tuple needs to be  
converted because of attribute changes between the immediate parent  
relation and the parent relation one level above that (the grandparent).  
This could trigger errors like the following:  
ERROR: cannot extract attribute from empty tuple slot SQL state: XX000  
  
This was not detected because regression tests with dropped attributes  
only included tests with two levels of partitioning, and this can be  
triggered with three levels or more.  
  
This fixes bug #15733, which has been introduced by 34295b8.  The bug  
happens only on REL_11_STABLE and HEAD gains the regression tests added  
for this bug.  
  
Reported-by: Petr Fedorov  
Author: Amit Langote, Michael Paquier  
Discussion: https://postgr.es/m/15733-7692379e310b80ec@postgresql.org  

commit   : a7ca25cf787c563a92eef5eff1a8d2bb1364a992    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Apr 2019 18:18:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 7 Apr 2019 18:18:59 -0400    

pg_get_indexdef_worker carelessly fetched indoption entries even for  
non-key index columns that don't have one.  99.999% of the time this  
would be harmless, since the code wouldn't examine the value ... but  
some fine day this will be a fetch off the end of memory, resulting  
in SIGSEGV.  
  
Detected through valgrind testing.  Odd that the buildfarm's valgrind  
critters haven't noticed.  

commit   : 10e3991fad8a300ed268878ae30c96074628c1e1    
  
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    

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  

commit   : c2a5fb33d104afbe2c4877ddce2689bccd4eb1f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Apr 2019 15:09:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 6 Apr 2019 15:09:10 -0400    

The foreign-key-checking loop in ATRewriteTables failed to ignore  
relations without storage (e.g., partitioned tables), unlike the  
initial loop.  This accidentally worked as long as RI_Initial_Check  
succeeded, which it does in most practical cases (including all the  
ones exercised in the existing regression tests :-().  However, if  
that failed, as for instance when there are permissions issues,  
then we entered the slow fire-the-trigger-on-each-tuple path.  
And that would try to read from the referencing relation, and fail  
if it lacks storage.  
  
A second problem, recently introduced in HEAD, was that this loop  
had been broken by sloppy refactoring for the tableam API changes.  
  
Repair both issues, and add a regression test case so we have some  
coverage on this code path.  Back-patch as needed to v11.  
  
(It looks like this code could do with additional bulletproofing,  
but let's get a working test case in place first.)  
  
Hadi Moshayedi, Tom Lane, Andres Freund  
  
Discussion: https://postgr.es/m/CAK=1=WrnNmBbe5D9sm3t0a6dnAq3cdbF1vXY816j1wsMqzC8bw@mail.gmail.com  
Discussion: https://postgr.es/m/19030.1554574075@sss.pgh.pa.us  
Discussion: https://postgr.es/m/20190325180405.jytoehuzkeozggxx%40alap3.anarazel.de  

commit   : 7338ed28e2ecaf9c8cb73e7721838cd8f07ad149    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 5 Apr 2019 20:55:07 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 5 Apr 2019 20:55:07 +0900    

The limitations that it is not allowed to create/attach a foreign table  
as a partition of an indexed partitioned table were not documented.  
  
Reported-By: Stepan Yankevych  
Author: Etsuro Fujita  
Reviewed-By: Amit Langote  
Backpatch-through: 11 where partitioned index was introduced  
Discussion: https://postgr.es/m/1553869152.858391073.5f8m3n0x@frv53.fwdcdn.com  

commit   : 392ea22e9b322d790801740f4c7540c53dddf78b    
  
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    

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  

commit   : 064b3fcbdb198f04ee74e01dd48b3d75448b3c4c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Apr 2019 10:38:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 5 Apr 2019 10:38:21 +0900    

Since 11, it is possible to use a non-superuser role when using an  
online source cluster with pg_rewind as long as the role has proper  
permissions to execute on the source all the functions used by  
pg_rewind, and the documentation stated that a superuser is necessary.  
Let's add at the same time all the details needed to create such a  
role.  
  
A second 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  

commit   : 7dbc0759e0207436851ccc7098250a8110efe655    
  
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    

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  

commit   : 1106438c37db44cbd627490dec3b662d4cc5b4f8    
  
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    

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  

commit   : 426d93d24429a0144838c3832674c48b48dd1237    
  
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    

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  

commit   : b2307f8e3184fcfa7a1a789918c455c4e4e5bc06    
  
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    

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  

commit   : 157dcf534f8e12486d425d6c0d111c065fbbb841    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 2 Apr 2019 08:17:04 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 2 Apr 2019 08:17:04 +0100    

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  

commit   : ab7590e9197cd9b1ab691ab0b08794a79f26e592    
  
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    

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  

commit   : 4d6bd92db5105b8ecc2eedff430b080541a5e4de    
  
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    

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

commit   : d70c147fa217c4bae32ac1afb86ab42d98b36fdf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Mar 2019 12:48:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 30 Mar 2019 12:48:19 -0400    

While trying to plan a partitionwise join, we may be faced with cases  
where one or both input partitions for a particular segment of the join  
have been pruned away.  In HEAD and v11, this is problematic because  
earlier processing didn't bother to make a pruned RelOptInfo fully  
valid.  With an upcoming patch to make partition pruning more efficient,  
this'll be even more problematic because said RelOptInfo won't exist at  
all.  
  
The existing code attempts to deal with this by retroactively making the  
RelOptInfo fully valid, but that causes crashes under GEQO because join  
planning is done in a short-lived memory context.  In v11 we could  
probably have fixed this by switching to the planner's main context  
while fixing up the RelOptInfo, but that idea doesn't scale well to the  
upcoming patch.  It would be better not to mess with the base-relation  
data structures during join planning, anyway --- that's just a recipe  
for order-of-operations bugs.  
  
In many cases, though, we don't actually need the child RelOptInfo,  
because if the input is certainly empty then the join segment's result  
is certainly empty, so we can skip making a join plan altogether.  (The  
existing code ultimately arrives at the same conclusion, but only after  
doing a lot more work.)  This approach works except when the pruned-away  
partition is on the nullable side of a LEFT, ANTI, or FULL join, and the  
other side isn't pruned.  But in those cases the existing code leaves a  
lot to be desired anyway --- the correct output is just the result of  
the unpruned side of the join, but we were emitting a useless outer join  
against a dummy Result.  Pending somebody writing code to handle that  
more nicely, let's just abandon the partitionwise-join optimization in  
such cases.  
  
When the modified code skips making a join plan, it doesn't make a  
join RelOptInfo either; this requires some upper-level code to  
cope with nulls in part_rels[] arrays.  We would have had to have  
that anyway after the upcoming patch.  
  
Back-patch to v11 since the crash is demonstrable there.  
  
Discussion: https://postgr.es/m/8305.1553884377@sss.pgh.pa.us  

commit   : 26d4fda37ea10d146e9d35fca70f817a0bfe300c    
  
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    

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  

commit   : fb0b5b0b84a0a07d722f67fee1da8d2541f84172    
  
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    

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  

commit   : 7009f1a2df65598fc6c28368d3a6f1b9e96d69f5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Mar 2019 20:19:39 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Mar 2019 20:19:39 -0300    

ALTER INDEX .. ATTACH PARTITION fails if the partitioned table where the  
index is defined contains more dropped columns than its partition, with  
this message:  
  ERROR:  incorrect attribute map  
The cause was that one caller of CompareIndexInfo was passing the number  
of attributes of the partition rather than the parent, which confused  
the length check.  Repair.  
  
This can cause pg_upgrade to fail when used on such a database.  Leave  
some more objects around after regression tests, so that the case is  
detected by pg_upgrade test suite.  
  
Remove some spurious empty lines noticed while looking for other cases  
of the same problem.  
  
Discussion: https://postgr.es/m/20190326213924.GA2322@alvherre.pgsql  

commit   : e46072dc397fcdde3eebe6c4963d9692058da6e3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Mar 2019 13:04:03 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 26 Mar 2019 13:04:03 -0300    

Bug introduced in my commit bc87f22ef6ef  

commit   : 24df8662e4a4c961a6395d56fb2ee7007b1bd326    
  
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    

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  

commit   : b7ffa0ee8d55af0eb236d7496853c38c266d96d5    
  
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    

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.  

commit   : 89f39736f4845e81f350893dd59fd52cedab8b39    
  
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    

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  

commit   : 7d7435c5c5050f280692d87f250fabd7eabc4af4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 24 Mar 2019 21:01:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 24 Mar 2019 21:01:10 +0900    

Since its introduction in 19dc233c, current_logfiles has been assigned  
the same permissions as a log file, which can be enforced with  
log_file_mode.  This setup can lead to incompatibility problems with  
group access permissions as current_logfiles is not located in the log  
directory, but at the root of the data folder.  Hence, if group  
permissions are used but log_file_mode is more restrictive, a backup  
with a user in the group having read access could fail even if the log  
directory is located outside of the data folder.  
  
Per discussion with the folks mentioned below, we have concluded that  
current_logfiles should not be treated as a log file as it only stores  
metadata related to log files, and that it should use the same  
permissions as all other files in the data directory.  This solution has  
the merit to be simple and fixes all the interaction problems between  
group access and log_file_mode.  
  
Author: Haribabu Kommi  
Reviewed-by: Stephen Frost, Robert Haas, Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/CAJrrPGcEotF1P7AWoeQyD3Pqr-0xkQg_Herv98DjbaMj+naozw@mail.gmail.com  
Backpatch-through: 11, where group access has been added.  

commit   : e319f03d12b1c624bd911be4a589cd635545ad74    
  
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    

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.  

commit   : 7c89f350f109a187740b6f635c97871d6cc46ac1    
  
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    

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  

commit   : 849f87a1c3346df65d0e21b2d4b1c296a61495d5    
  
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    

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  

commit   : 04f9b449aa309410dbbcbf4951802a3f73b42bd0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Mar 2019 17:23:26 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 Mar 2019 17:23:26 -0300    

I unnecessarily removed this check in 3de241dba86f because I  
misunderstood what the final representation of constraints across a  
partitioning hierarchy was to be.  Put it back (in both branches).  
  
Discussion: https://postgr.es/m/201901222145.t6wws6t6vrcu@alvherre.pgsql  

commit   : 08cf04bb4747269dde46b45346b7f38653013002    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Mar 2019 16:58:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Mar 2019 16:58:20 -0400    

Buildfarm member eelpout sometimes reports the wrong error message for  
an SSL connection failure.  In HEAD, this problem is believed to be  
solved by commit 1f39a1c06, but I'm as yet unwilling to back-patch that.  
The problem seems fairly unlikely to be an issue in the field, since (as  
far as we can tell) it happens only during a failure of a local-loopback  
SSL connection, and it's improbable even then.  It seems better to just  
live with it for the time being; but let's tweak the regression test to  
accept the other error message as a "pass".  
  
Needed in v11 only, since older branches didn't check the message  
text anyway.  
  
Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com  

commit   : cba8fc68823e1915b35182e87f507e46b5ac7b67    
  
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    

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  

commit   : 31eb62d55ed97f9879f0bc0df2ba5c03dd76b0a6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 19 Mar 2019 08:53:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 19 Mar 2019 08:53:04 +0900    

5864d24 has introduced a new error message, and I somewhat managed to  
fail adapting the back-patched version correctly with the tool name.  

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

Commit f2dec34e1 changed things so that printtup's output stringinfo  
buffer was allocated outside the per-row temporary context, not inside  
it.  This creates a need to free that buffer explicitly when the temp  
context is freed, but that was overlooked.  In most cases, this is all  
happening inside a portal or executor context that will go away shortly  
anyhow, but that's not always true.  Notably, the stringinfo ends up  
getting leaked when JDBC uses row-at-a-time fetches.  For a query  
that returns wide rows, that adds up after awhile.  
  
Per bug #15700 from Matthias Otterbach.  Back-patch to v11 where the  
faulty code was added.  
  
Discussion: https://postgr.es/m/15700-8c408321a87d56bb@postgresql.org  

commit   : fc8b39a46eb7132edc0165f23b738a2292ee9ca9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 18 Mar 2019 15:21:09 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 18 Mar 2019 15:21:09 -0400    

We should try to prewarm each database only once.  Otherwise, if  
prewarming fails for some reason, it will just keep retrying in an  
infnite loop.  This can happen if, for example, the database has been  
dropped.  The existing code was intended to implement the try-once  
behavior, but failed to do so because it neglected to set  
worker.bgw_restart_time to BGW_NEVER_RESTART.  
  
Mithun Cy, per a report from Hans Buschmann  
  
Discussion: http://postgr.es/m/CA+hUKGKpQJCWcgyy3QTC9vdn6uKAR_8r__A-MMm2GYfj45caag@mail.gmail.com  

commit   : dcf2a0db8529b81a57d421e0fd59297d10d5f0b6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Mar 2019 10:35:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Mar 2019 10:35:01 +0900    

This fixes an issue introduced by 266b6ac, which has added filters to  
exclude file patterns on the target and source data directories to  
reduce the number of files transferred.  Filters get applied to both  
the target and source data files, and include pg_internal.init which is  
present for each database once relations are created on it.  However, if  
the target differed from the source with at least one new database with  
relations, the rewind would fail due to the exclusion filters applied on  
the target files, causing pg_internal.init to still be present on the  
target database folder, while its contents should have been completely  
removed so as there is nothing remaining inside at the time of the  
folder deletion.  
  
Applying exclusion filters on the source files is fine, because this way  
the amount of data copied from the source to the target is reduced.  And  
actually, not applying the filters on the target is what pg_rewind  
should do, because this causes such files to be automatically removed  
during the rewind on the target.  Exclusion filters apply to paths which  
are removed or recreated automatically at startup, so removing all those  
files on the target during the rewind is a win.  
  
The existing set of TAP tests already stresses the rewind of databases,  
but it did not include any tables on those newly-created databases.  
Creating extra tables in this case is enough to reproduce the failure,  
so the existing tests are extended to close the gap.  
  
Reported-by: Mithun Cy  
Author: Michael Paquier  
Discussion: https://postgr.es/m/CADq3xVYt6_pO7ZzmjOqPgY9HWsL=kLd-_tNyMtdfjKqEALDyTA@mail.gmail.com  
Backpatch-through: 11  

commit   : 5864d246099f1619539f20ae53331fbdb772b879    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Mar 2019 09:12:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Mar 2019 09:12:24 +0900    

pg_verify_checksums is compiled with a given block size and has a hard  
dependency to it per the way checksums are calculated via  
checksum_impl.h, and trying to use the tool on a data folder which has  
not the same block size would result in incorrect checksum calculations  
and/or block read errors, meaning that the data folder is corrupted.  
This is harmless as checksums are only checked now, but very confusing  
for the user so issue an error properly if the block size used at  
compilation and the block size used in the data folder do not match.  
  
Reported-by: Sergei Kornilov  
Author: Michael Banck, Michael Paquier  
Reviewed-by: Fabien Coelho, Magnus Hagander  
Discussion: https://postgr.es/m/20190317054657.GA3357@paquier.xyz  
ackpatch-through: 11  

commit   : a1e9508b964155a81ec9a8e6e12be76796d47097    
  
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    

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  

commit   : 5b866005c8b039e7b473ffef1f27b162b0436948    
  
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    

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  

commit   : da453004869d3e818d8529087b680ebbf8842f51    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 14 Mar 2019 14:15:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 14 Mar 2019 14:15:13 +0900    

This fixes an oversight from 5c99513.  This has no actual consequence as  
PG_TEMP_FILE_PREFIX and PG_TEMP_FILES_DIR have the same value so when  
bumping on a temporary path the directory scan was still moving on to  
the next entry instead of skipping the rest of the scan, but let's keep  
the logic correct.  
  
Author: Michael Banck  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20190314.115417.58230569.horiguchi.kyotaro@lab.ntt.co.jp  
Backpatch-through: 11  

commit   : cbfbf2930e9ca534728ad1aef0f96a052a87dd1d    
  
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    

Author: Christoph Berg <myon@debian.org>  

commit   : 501f58359b59af1ffb58f9fbd6f97c4b226c69da    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 13 Mar 2019 09:51:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 13 Mar 2019 09:51:25 +0900    

pg_verify_checksums performs a read of the control file, and the data it  
fetches should be from a data folder compatible with the major version  
of Postgres the binary has been compiled with, but we never actually  
checked that compatibility.  
  
Reported-by: Sergei Kornilov  
Author: Michael Paquier  
Reviewed-by: Sergei Kornilov  
Discussion: https://postgr.es/m/155231347133.16480.11453587097036807558.pgcf@coridan.postgresql.org  
Backpatch-through: 11  

commit   : fd1eaf9202dc3bbd657aa1f46b787329173b261c    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 12 Mar 2019 16:32:27 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 12 Mar 2019 16:32:27 +0900    

In commit 960df2a971 ("Correctly assess parallel-safety of tlists when  
SRFs are used."), the testing of scan/join target was done incorrectly,  
which caused a plan-quality problem.  Backpatch through to v11 where  
the aforementioned commit went in, since this is a regression from v10.  
  
Author: Etsuro Fujita  
Reviewed-by: Robert Haas and Tom Lane  
Discussion: https://postgr.es/m/5C75303E.8020303@lab.ntt.co.jp  

commit   : e7adda86ba9c8dc1d0db07d0049ccfff42082a0e    
  
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    

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

commit   : b16f8a2905820e41cc8390364b0acef4d8a6bfca    
  
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    

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  

commit   : bc2232f2f54442417ca2c9a338a6f5495d430153    
  
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    

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  

commit   : 7d7de6d745344bf811b828693d3d2ad72e242d20    
  
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    

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  

commit   : 40a579b39e180afabd460e8e2c4070ace6bc1137    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 8 Mar 2019 15:10:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 8 Mar 2019 15:10:31 +0900    

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  

commit   : 925f46ffb82f0b25c94e7997caff732eaf14367d    
  
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    

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  

commit   : dadf9814d0dddaa3e5a301e2b13479431108bc5b    
  
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    

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.  

commit   : f1b864ee6774e86ad4c6a5423722c354c7f706fd    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 5 Mar 2019 10:46:21 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 5 Mar 2019 10:46:21 -0500    

This test fails if the containing directory contains a funny character  
such as a space or some perl metacharacter. To avoid that, we check for  
files names using readdir and a regex, rather than using a glob pattern.  
  
Discussion: https://postgr.es/m/CAM6_UM6dGdU39PKAC24T+HD9ouy0jLN9vH6163K8QEEzr__iZw@mail.gmail.com  
  
Author: Fabien COELHO  
Reviewed-by: Raúl Marín Rodríguez  

commit   : 8722c4daccf83411996aa5a18a3eca4ec84b7d41    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 4 Mar 2019 09:50:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 4 Mar 2019 09:50:02 +0900    

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  

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

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  

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

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  

commit   : d9bba27c8bd1cca88f4242deb21b22cd5468be12    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Feb 2019 09:40:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 Feb 2019 09:40:39 +0900    

When using a libpq client linked with OpenSSL 1.0.1 or older to connect  
to a backend linked with OpenSSL 1.0.2 or newer, the server would send  
SCRAM-SHA-256-PLUS and SCRAM-SHA-256 as valid mechanisms for the SASL  
exchange, and the client would choose SCRAM-SHA-256-PLUS even if it does  
not support channel binding, leading to a confusing error.  In this  
case, what the client ought to do is switch to SCRAM-SHA-256 so as the  
authentication can move on and succeed.  
  
So for a SCRAM authentication over SSL, here are all the cases present  
and how we deal with them using libpq:  
1) Server supports channel binding, it sends SCRAM-SHA-256-PLUS and  
SCRAM-SHA-256 as allowed mechanisms.  
1-1) Client supports channel binding, chooses SCRAM-SHA-256-PLUS.  
1-2) Client does not support channel binding, chooses SCRAM-SHA-256.  
2) Server does not support channel binding, sends SCRAM-SHA-256 as  
allowed mechanism.  
2-1) Client supports channel binding, still it has no choice but to  
choose SCRAM-SHA-256.  
2-2) Client does not support channel binding, it chooses SCRAM-SHA-256.  
In all these scenarios the connection should succeed, and the one which  
was handled incorrectly prior this commit is 1-2), causing the  
connection attempt to fail because client chose SCRAM-SHA-256-PLUS over  
SCRAM-SHA-256.  
  
Reported-by: Hugh Ranalli  
Diagnosed-by: Peter Eisentraut  
Author: Michael Paquier  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/CAAhbUMO89SqUk-5mMY+OapgWf-twF2NA5sCucbHEzMfGbvcepA@mail.gmail.com  
Backpatch-through: 11  

commit   : 50ae619035be84e084c4f59b59598a03ba38286c    
  
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    

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  

commit   : de94ed89d5b013acf9729ac04e52166bbb8ca736    
  
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    

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  

commit   : 4d67357dbf5016836dc9ea9a8789cc539dfa3b60    
  
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    

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  

commit   : 30dcb6270c915691fb82477f6b3c489977cae050    
  
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    

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  

commit   : 07fba9ad9b71c87a63f87a0ff16b6165ff08fc5e    
  
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    

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  

commit   : 630de1131dca80fd63cecfbe6a14b8a5b405b434    
  
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    

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  

commit   : c08b65bc4371f0154566447a8cb4bc7691bf0815    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 21 Feb 2019 15:39:37 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 21 Feb 2019 15:39:37 +0100    

In previous releases, the input file of dbtoepub was postgres.xml, and  
dbtoepub knows to derive the output file name postgres.epub from that  
automatically.  But now the intput file is postgres.sgml (since  
postgres.sgml is itself an XML file and we no longer need the  
intermediate postgres.xml file), but dbtoepub doesn't know how to deal  
with the .sgml suffix, so the automatically derived output file name  
becomes postgres.sgml.epub.  Fix by adding an explicit -o option.  

commit   : e22bfe94e4dfc9abedf17026c3081bca9877163d    
  
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    

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  

commit   : 93ec0c90cde7e0188c96bca9a8ba815b58c00d24    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Feb 2019 13:36:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Feb 2019 13:36:55 -0500    

The recursion in contain_nonstrict_functions_walker() was done wrong,  
causing the strictness check to be bypassed for a parse node that  
is the immediate input of an ArrayCoerceExpr node.  This could allow,  
for example, incorrect decisions about whether a strict SQL function  
can be inlined.  
  
I didn't add a regression test, because (a) the bug is so narrow  
and (b) I couldn't think of a test case that wasn't dependent on a  
large number of other behaviors, to the point where it would likely  
soon rot to the point of not testing what it was intended to.  
  
I broke this in commit c12d570fa, so back-patch to v11.  
  
Discussion: https://postgr.es/m/27571.1550617881@sss.pgh.pa.us  

commit   : 728ac262d18e17342c28183846c1405768f93d13    
  
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    

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  

commit   : fbec6fa38ade6fd0c4c5c5984f723ba351a44e85    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 20 Feb 2019 08:28:42 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Wed, 20 Feb 2019 08:28:42 +0000    

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  

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

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  

commit   : 7eedd66edcd9bf211f88e071e2a1a96a3d86e689    
  
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    

Oversights in commits 050710b36 and e81f0e311.  

commit   : 3530c508ca68d47cd5a30a1a28f99bdd23cb90c8    
  
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    

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

commit   : 51be67346ef9dd29dd914ecac220044769efcad6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Feb 2019 14:23:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 18 Feb 2019 14:23:44 +0900    

ee9e145 has fixed the tests of pg_basebackup for checksums a first time,  
still one seek() call missed the shot.  Also, the data written in files  
to emulate corruptions was not actually writing zeros as the quoting  
style was incorrect.  
  
Author: Michael Banck  
Discussion: https://postgr.es/m/1550153276.796.35.camel@credativ.de  
Backpatch-through: 11  

commit   : 1d93d180454f9da74677dd0498f5408efe6b603d    
  
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    

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  

commit   : 7f39f0344129706979174ba530f8cc21b7d9f4a3    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sun, 17 Feb 2019 13:15:06 -0500    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sun, 17 Feb 2019 13:15:06 -0500    

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  

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

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  

commit   : d43a1ff8f28c2895ac24326f0c8bbf2088f28cc5    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 17 Feb 2019 20:35:09 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 17 Feb 2019 20:35:09 +0900    

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  

commit   : 3cbbd3515aa61600389830ece74c57aa8a98c4a9    
  
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    

Back-patch to v10, which introduced the lock.  

commit   : 75aba11ec5edf7e2f0f45a8bc67f4f20d0a33282    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 15 Feb 2019 17:12:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 15 Feb 2019 17:12:31 +0900    

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  

commit   : faf132449c0cafd31fe9f14bbf29ca0318a89058    
  
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    

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  

commit   : b8386b0362b28bded0a7a00a90ac0c302b1e182a    
  
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    

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  

commit   : 364857f738982da58c0be33cf968d2bbbd496efd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Feb 2019 18:38:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Feb 2019 18:38:33 -0500    

We're only going to consider key columns when creating indexquals,  
so there is no point in having the outer loops in indxpath.c iterate  
further than nkeycolumns.  
  
Doing so in match_pathkeys_to_index() is actually wrong, and would have  
caused crashes by now, except that we have no index AMs supporting both  
amcanorderbyop and amcaninclude.  
  
It's also wrong in relation_has_unique_index_for().  The effect there is  
to fail to prove uniqueness even when the index does prove it, if there  
are extra columns.  
  
Also future-proof examine_variable() for the day when extra columns can  
be expressions, and fix what's either a thinko or just an oversight in  
btcostestimate(): we should consider the number of key columns, not the  
total, when deciding whether to derate correlation.  
  
None of these things seemed important enough to risk changing in a  
just-before-wrap patch, but since we're past the release wrap window,  
time to fix 'em.  
  
Discussion: https://postgr.es/m/25526.1549847928@sss.pgh.pa.us  

commit   : c2e0954be36390f06e1a8821921648bc258c38bf    
  
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    

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  

commit   : a4c6a73aa438d6c44fbe1e5e0c8878051e8c2b54    
  
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    

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.  

commit   : 6af8c79868a3d51d9d0ae96c71596bba33780c59    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 12 Feb 2019 12:02:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 12 Feb 2019 12:02:31 +0900    

The current wording can confuse the reader about constraint exclusion  
being available at query execution, but this only applies to partition  
pruning.  
  
Reported-by: Shouyu Luo  
Author: David Rowley  
Reviewed-by: Chapman Flack, Amit Langote  
Discussion: https://postgr.es/m/15629-2ef8b22e61f8333f@postgresql.org