PostgreSQL 13.0 (upcoming) commit log

commit   : affdde2e15d9df6e9736bbb7e7cd9d56049d2f5a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 20 Jan 2020 23:26:51 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 20 Jan 2020 23:26:51 -0800    

The code checking whether an aggregate transition value needs to be  
reparented into the current context has always only compared the  
transition return value with the previous transition value by datum,  
i.e. without regard for NULLness.  This normally works, because when  
the transition function returns NULL (via fcinfo->isnull), it'll  
return a value that won't be the same as its input value.  
  
But there's no hard requirement that that's the case. And it turns  
out, it's possible to hit this case (see discussion or reproducers),  
leading to a non-null transition value not being reparented, followed  
by a crash caused by that.  
  
Instead of adding another comparison of NULLness, instead have  
ExecAggTransReparent() ensure that pergroup->transValue ends up as 0  
when the new transition value is NULL. That avoids having to add an  
additional branch to the much more common cases of the transition  
function returning the old transition value (which is a pointer in  
this case), and when the new value is different, but not NULL.  
  
In branches since 69c3936a149, also deduplicate the reparenting code  
between the expression evaluation based transitions, and the path for  
ordered aggregates.  
  
Reported-By: Teodor Sigaev, Nikita Glukhov  
Author: Andres Freund  
Discussion: https://postgr.es/m/bd34e930-cfec-ea9b-3827-a8bc50891393@sigaev.ru  
Backpatch: 9.4-, this issue has existed since at least 7.4  

commit   : 62c9b522311afd791fd92fe46a294f7e21f10540    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Jan 2020 13:46:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 21 Jan 2020 13:46:39 +0900    

This helps integration of extensions with Windows.  The following  
parameters are changed:  
- idle_in_transaction_session_timeout (9.6 and newer versions)  
- lock_timeout  
- statement_timeout  
- track_activities  
- track_counts  
- track_functions  
  
Author: Pascal Legrand  
Reviewed-by: Amit Kamila, Julien Rouhaud, Michael Paquier  
Discussion: https://postgr.es/m/1579298868581-0.post@n3.nabble.com  
Backpatch-through: 9.4  

commit   : 31f403e95fdf88338d3fc9c6af80fcf6d8241044    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jan 2020 14:26:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jan 2020 14:26:56 -0500    

Some buildfarm members were still warning about this, because in  
9c679a08f I'd missed decorating one of the ereport() code paths  
with a dummy return.  
  
Also, adjust the error messages to be more in line with project  
style guide.  

commit   : cd23a2019c4b8da47905e91c8a841cadac978a32    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jan 2020 12:57:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Jan 2020 12:57:17 -0500    

sigTermHandler() tried to be careful to invoke only operations that  
are safe to do in a signal handler.  But for some reason we forgot  
that exit(3) is not among those, because it calls atexit handlers  
that might do various random things.  (pg_dump itself installs no  
atexit handlers, but e.g. OpenSSL does.)  That led to crashes or  
lockups when attempting to terminate a parallel dump or restore  
via a signal.  
  
Fix by calling _exit() instead.  
  
Per bug #16199 from Raúl Marín.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16199-cb2f121146a96f9b@postgresql.org  

commit   : 4c87010981f3a9a41751e5550f6eb889ab5667e8    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 20 Jan 2020 10:36:35 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 20 Jan 2020 10:36:35 +0200    

The BRIN add_value() and union() functions need to make a longer-lived  
copy of the argument, if they want to store it in the BrinValues struct  
also passed as argument. The functions for the "inclusion operator  
classes" used with box, range and inet types didn't take into account  
that the union helper function might return its argument as is, without  
making a copy. Check for that case, and make a copy if necessary. That  
case arises at least with the range_union() function, when one of the  
arguments is an 'empty' range:  
  
CREATE TABLE brintest (n numrange);  
CREATE INDEX brinidx ON brintest USING brin (n);  
INSERT INTO brintest VALUES ('empty');  
INSERT INTO brintest VALUES (numrange(0, 2^1000::numeric));  
INSERT INTO brintest VALUES ('(-1, 0)');  
  
SELECT brin_desummarize_range('brinidx', 0);  
SELECT brin_summarize_range('brinidx', 0);  
  
Backpatch down to 9.5, where BRIN was introduced.  
  
Discussion: https://www.postgresql.org/message-id/e6e1d6eb-0a67-36aa-e779-bcca59167c14%40iki.fi  
Reviewed-by: Emre Hasegeli, Tom Lane, Alvaro Herrera  

commit   : 40d964ec997f64227bc0ff5e058dc4a5770a70a9    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 20 Jan 2020 07:57:49 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 20 Jan 2020 07:57:49 +0530    

This feature allows the vacuum to leverage multiple CPUs in order to  
process indexes.  This enables us to perform index vacuuming and index  
cleanup with background workers.  This adds a PARALLEL option to VACUUM  
command where the user can specify the number of workers that can be used  
to perform the command which is limited by the number of indexes on a  
table.  Specifying zero as a number of workers will disable parallelism.  
This option can't be used with the FULL option.  
  
Each index is processed by at most one vacuum process.  Therefore parallel  
vacuum can be used when the table has at least two indexes.  
  
The parallel degree is either specified by the user or determined based on  
the number of indexes that the table has, and further limited by  
max_parallel_maintenance_workers.  The index can participate in parallel  
vacuum iff it's size is greater than min_parallel_index_scan_size.  
  
Author: Masahiko Sawada and Amit Kapila  
Reviewed-by: Dilip Kumar, Amit Kapila, Robert Haas, Tomas Vondra,  
Mahendra Singh and Sergei Kornilov  
Tested-by: Mahendra Singh and Prabhat Sahu  
Discussion:  
https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com  
https://postgr.es/m/CAA4eK1J-VoR9gzS5E75pcD-OH0mEyCdp8RihcwKrcuw7J-Q0+w@mail.gmail.com  

commit   : 44f1fc8df5dadbc5e80661660903aab4076d868f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jan 2020 19:15:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jan 2020 19:15:15 -0500    

ecpg_build_params() would crash on a null pointer dereference if  
realloc() failed, due to updating the persistent "stmt" struct  
too aggressively.  (Even without the crash, this would've leaked  
the old storage that we were trying to realloc.)  
  
Per Coverity.  This seems to have been broken in commit 0cc050794,  
so back-patch into v12.  

commit   : 9c679a08f0cdedcf7f084daea3cba6ae9c3cbced    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jan 2020 16:04:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Jan 2020 16:04:36 -0500    

Ensure that ClassifyUtilityCommandAsReadOnly() has defined behavior  
even if TransactionStmt.kind has a value that's not one of the  
declared values for its enum.  
  
Suppress warnings from compilers that don't know that elog(ERROR)  
doesn't return, in ClassifyUtilityCommandAsReadOnly() and  
jsonb_set_lax().  
  
Per Coverity and buildfarm.  

commit   : 7aaefadaac6452b2e813fae4ea531cb12d022531    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 19 Jan 2020 13:54:58 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Sun, 19 Jan 2020 13:54:58 +0200    

This data was only in separate files because it was the most convenient  
way to handle it with a shell script. Now that we use a general-purpose  
programming language, it's easy to assemble the data into the same format  
as the rest of the catalogs and output it into postgres.bki. This allows  
removal of some special-purpose code from initdb.c.  
  
Discussion: https://www.postgresql.org/message-id/CACPNZCtVFtjHre6hg9dput0qRPp39pzuyA2A6BT8wdgrRy%2BQdA%40mail.gmail.com  
Author: John Naylor  

commit   : e0ed6817c0ee218a3681920807404603e042ff04    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 19 Jan 2020 18:55:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 19 Jan 2020 18:55:51 +0900    

Clarify the description related to the use of characters which can be  
encoded, and add an example.  
  
Author: Jobin Augustine  
Reviewed-by: Peter Eisentraut, Alvaro Herrera, Heikki Linnakangas,  
Michael Paquier, Alex Shulgin  
Discussion: https://postgr.es/m/CANaTPsrYgSgE2fuj3=4x=Jmx1c+NgkEDzftNknZbrMuqL+aBhQ@mail.gmail.com  

commit   : 34a0a81bfb388504deaa51b16a8bb531b827e519    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jan 2020 17:51:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Jan 2020 17:51:03 -0500    

Rather than intermixing the discussion of text-string and binary-string  
functions, make a clean break, moving all discussion of binary-string  
operations into section 9.5.  This involves some duplication of  
function descriptions between 9.4 and 9.5, but it seems cleaner on the  
whole since the individual descriptions are clearer (and on the other  
side of the coin, it gets rid of some duplicated descriptions, too).  
  
Move the convert*/encode/decode functions to a separate table, because  
they don't quite seem to fit under the heading of "binary string  
functions".  
  
Also provide full documentation of the textual formats supported by  
encode() and decode() (which was the original goal of this patch  
series, many moons ago).  
  
Also move the table of built-in encoding conversions out of section 9.4,  
where it no longer had any relevance whatsoever, and put it into section  
23.3 about character sets.  I chose to put both that and table 23.2  
(multibyte-translation-table) into a new <sect2> so as not to break up  
the flow of discussion in 23.3.3.  
  
Also do a bunch of minor copy-editing on the function descriptions  
in 9.4 and 9.5.  
  
Karl Pinc, reviewed by Fabien Coelho, further hacking by me  
  
Discussion: https://postgr.es/m/20190304163347.7bca4897@slate.meme.com  

commit   : 41aadeeb124ee5f8e7d154a16a74d53286882b74    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 18 Jan 2020 12:32:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 18 Jan 2020 12:32:43 +0900    

Mixing incorrect bounds set in the SSL context leads to confusing error  
messages generated by OpenSSL which are hard to act on.  New checks are  
added within the GUC machinery to improve the user experience as they  
apply to any SSL implementation, not only OpenSSL, and doing the checks  
beforehand avoids the creation of a SSL during a reload (or startup)  
which we know will never be used anyway.  
  
Backpatch down to 12, as those parameters have been introduced by  
e73e67c.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/20200114035420.GE1515@paquier.xyz  
Backpatch-through: 12  

commit   : 4b754d6c16e16cc1a1adf12ab0f48603069a0efd    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 18 Jan 2020 01:11:39 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sat, 18 Jan 2020 01:11:39 +0300    

The strategy of GIN index scan is driven by opclass-specific extract_query  
method.  This method that needed search mode is GIN_SEARCH_MODE_ALL.  This  
mode means that matching tuple may contain none of extracted entries.  Simple  
example is '!term' tsquery, which doesn't need any term to exist in matching  
tsvector.  
  
In order to handle such scan key GIN calculates virtual entry, which contains  
all TIDs of all entries of attribute.  In fact this is full scan of index  
attribute.  And typically this is very slow, but allows to handle some queries  
correctly in GIN.  However, current algorithm calculate such virtual entry for  
each GIN_SEARCH_MODE_ALL scan key even if they are multiple for the same  
attribute.  This is clearly not optimal.  
  
This commit improves the situation by introduction of "exclude only" scan keys.  
Such scan keys are not capable to return set of matching TIDs.  Instead, they  
are capable only to filter TIDs produced by normal scan keys.  Therefore,  
each attribute should contain at least one normal scan key, while rest of them  
may be "exclude only" if search mode is GIN_SEARCH_MODE_ALL.  
  
The same optimization might be applied to the whole scan, not per-attribute.  
But that leads to NULL values elimination problem.  There is trade-off between  
multiple possible ways to do this.  We probably want to do this later using  
some cost-based decision algorithm.  
  
Discussion: https://postgr.es/m/CAOBaU_YGP5-BEt5Cc0%3DzMve92vocPzD%2BXiZgiZs1kjY0cj%3DXBg%40mail.gmail.com  
Author: Nikita Glukhov, Alexander Korotkov, Tom Lane, Julien Rouhaud  
Reviewed-by: Julien Rouhaud, Tomas Vondra, Tom Lane  

commit   : 41c6f9db25b5e3a8bb8afbb7d6715cff541fd41e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jan 2020 16:17:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Jan 2020 16:17:17 -0500    

Commit 9b63c13f0 turns out to have been fundamentally misguided:  
the parent node's subPlan list is by no means the only way in which  
a child SubPlan node can be hooked into the outer execution state.  
As shown in bug #16213 from Matt Jibson, we can also get short-lived  
tuple table slots added to the outer es_tupleTable list.  At this point  
I have little faith that there aren't other possible connections as  
well; the long time it took to notice this problem shows that this  
isn't a heavily-exercised situation.  
  
Therefore, revert that fix, returning to the coding that passed a  
NULL parent plan pointer down to the transiently-built subexpressions.  
That gives us a pretty good guarantee that they won't hook into the  
outer executor state in any way.  But then we need some other solution  
to make SubPlans work.  Adopt the solution speculated about in the  
previous commit's log message: do expression initialization at plan  
startup for just those VALUES rows containing SubPlans, abandoning the  
goal of reclaiming memory intra-query for those rows.  In practice it  
seems unlikely that queries containing a vast number of VALUES rows  
would be using SubPlans in them, so this should not give up much.  
  
(BTW, this test case also refutes my claim in connection with the prior  
commit that the issue only arises with use of LATERAL.  That was just  
wrong: some variants of SubLink always produce SubPlans.)  
  
As with previous patch, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16213-871ac3bc208ecf23@postgresql.org  

commit   : 15cac3a523cc06dba1331635f3f67445fa202a44    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 17 Jan 2020 18:00:39 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 17 Jan 2020 18:00:39 -0300    

... specifically, set it incrementally as each individual change is  
spilled down to disk.  This way, it is set correctly when the  
transaction disappears without trace, ie. without leaving an XACT_ABORT  
wal record.  (This happens when the server crashes midway through a  
transaction.)  
  
Failing to have final_lsn prevents ReorderBufferRestoreCleanup() from  
working, since it needs the final_lsn in order to know the endpoint of  
its iteration through spilled files.  
  
Commit df9f682c7bf8 already tried to fix the problem, but it didn't set  
the final_lsn in all cases.  Revert that, since it's no longer needed.  
  
Author: Vignesh C  
Reviewed-by: Amit Kapila, Dilip Kumar  
Discussion: https://postgr.es/m/CALDaNm2CLk+K9JDwjYST0sPbGg5AQdvhUt0jbKyX_HdAE0jk3A@mail.gmail.com  

commit   : 543852fd8bf0adc56192aeb25ff83f1a12c30368    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 17 Jan 2020 14:06:28 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 17 Jan 2020 14:06:28 +0100    

The bitmap used by SlabCheck to cross-check free chunks in a block used  
to be allocated for each SlabCheck call, and was never freed. The memory  
leak could be fixed by simply adding a pfree call, but it's actually a  
bad idea to do any allocations in SlabCheck at all as it assumes the  
state of the memory management as a whole is sane.  
  
So instead we allocate the bitmap as part of SlabContext, which means  
we don't need to do any allocations in SlabCheck and the bitmap goes  
away together with the SlabContext.  
  
Backpatch to 10, where the Slab context was introduced.  
  
Author: Tomas Vondra  
Reported-by: Andres Freund  
Reviewed-by: Tom Lane  
Backpatch-through: 10  
Discussion: https://www.postgresql.org/message-id/20200116044119.g45f7pmgz4jmodxj%40alap3.anarazel.de  

commit   : 4b0e0f67f2f16c077b4e5c8a3d70c6af4355db09    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Jan 2020 16:24:13 +1030    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Jan 2020 16:24:13 +1030    

commit   : a83586b5543b948f9e621462537a7303b113c482    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Jan 2020 11:41:35 +1030    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Jan 2020 11:41:35 +1030    

jsonb_set_lax() is the same as jsonb_set, except that it takes and extra  
argument that specifies what to do if the value argument is NULL. The  
default is 'use_json_null'. Other possibilities are 'raise_exception',  
'return_target' and 'delete_key', all these behaviours having been  
suggested as reasonable by various users.  
  
Discussion: https://postgr.es/m/375873e2-c957-3a8d-64f9-26c43c2b16e7@2ndQuadrant.com  
  
Reviewed by: Pavel Stehule  

commit   : f7cd5896a69621818189fbdd209fb2e1fc008102    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Jan 2020 10:06:17 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Jan 2020 10:06:17 +0900    

Two routines have been added in OpenSSL 1.1.0 to set the protocol bounds  
allowed within a given SSL context:  
- SSL_CTX_set_min_proto_version  
- SSL_CTX_set_max_proto_version  
  
As Postgres supports OpenSSL down to 1.0.1 (as of HEAD), equivalent  
replacements exist in the tree, which are only available for the  
backend.  A follow-up patch is planned to add control of the SSL  
protocol bounds for libpq, so move those routines to src/common/ so as  
libpq can use them.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/4F246AE3-A7AE-471E-BD3D-C799D3748E03@yesql.se  

commit   : 5afaa2e42655811461044c4216e2f821cadc766d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 18:08:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 18:08:21 -0500    

Move all the backend-only code that'd crept into wchar.c and encnames.c  
into mbutils.c.  
  
To remove the last few #ifdef dependencies from wchar.c and encnames.c,  
also make the following changes:  
  
* Adjust get_encoding_name_for_icu to return NULL, not throw an error,  
for unsupported encodings.  Its sole caller can perfectly well throw an  
error instead.  (While at it, I also made this function and its sibling  
is_encoding_supported_by_icu proof against out-of-range encoding IDs.)  
  
* Remove the overlength-name error condition from pg_char_to_encoding.  
It's completely silly not to treat that just like any other  
the-name-is-not-in-the-table case.  
  
Also, get rid of pg_mic_mblen --- there's no obvious reason why  
conv.c shouldn't call pg_mule_mblen instead.  
  
Other than that, this is just code movement and comment-polishing with  
no functional changes.  Notably, I reordered declarations in pg_wchar.h  
to show which functions are frontend-accessible and which are not.  
  
Discussion: https://postgr.es/m/CA+TgmoYO8oq-iy8E02rD8eX25T-9SmyxKWqqks5OMHxKvGXpXQ@mail.gmail.com  

commit   : 3d4cb5d6c180e38ebf84f6403cfa18c09d0b738e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 15:58:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 15:58:24 -0500    

Bring these into common style (including having proper copyright  
notices) and adjust their self-declaration of where they live.  
  
Discussion: https://postgr.es/m/CA+TgmoYO8oq-iy8E02rD8eX25T-9SmyxKWqqks5OMHxKvGXpXQ@mail.gmail.com  

commit   : e6afa8918c461c1dd80c5063a950518fa4e950cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 15:56:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 15:56:32 -0500    

Formerly, various frontend directories symlinked these two sources  
and then built them locally.  That's an ancient, ugly hack, and  
we now have a much better way: put them into libpgcommon.  
So do that.  (The immediate motivation for this is the prospect  
of having to introduce still more symlinking if we don't.)  
  
This commit moves these two files absolutely verbatim, for ease of  
reviewing the git history.  There's some follow-on work to be done  
that will modify them a bit.  
  
Robert Haas, Tom Lane  
  
Discussion: https://postgr.es/m/CA+TgmoYO8oq-iy8E02rD8eX25T-9SmyxKWqqks5OMHxKvGXpXQ@mail.gmail.com  

commit   : 2eb34ac369741c110b593e2dc2195c57d29ab8e8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 16 Jan 2020 12:11:31 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 16 Jan 2020 12:11:31 -0500    

Previously, check_xact_readonly() was responsible for determining  
which types of queries could not be run in a read-only transaction,  
standard_ProcessUtility() was responsibility for prohibiting things  
which were allowed in read only transactions but not in recovery, and  
utility commands were basically prohibited in bulk in parallel mode by  
calls to CommandIsReadOnly() in functions.c and spi.c.  This situation  
was confusing and error-prone. Accordingly, move all the checks to a  
new function ClassifyUtilityCommandAsReadOnly(), which determines the  
degree to which a given statement is read only.  
  
In the old code, check_xact_readonly() inadvertently failed to handle  
several statement types that actually should have been prohibited,  
specifically T_CreatePolicyStmt, T_AlterPolicyStmt, T_CreateAmStmt,  
T_CreateStatsStmt, T_AlterStatsStmt, and T_AlterCollationStmt.  As a  
result, thes statements were erroneously allowed in read only  
transactions, parallel queries, and standby operation. Generally, they  
would fail anyway due to some lower-level error check, but we  
shouldn't rely on that.  In the new code structure, future omissions  
of this type should cause ClassifyUtilityCommandAsReadOnly() to  
complain about an unrecognized node type.  
  
As a fringe benefit, this means we can allow certain types of utility  
commands in parallel mode, where it's safe to do so. This allows  
ALTER SYSTEM, CALL, DO, CHECKPOINT, COPY FROM, EXPLAIN, and SHOW.  
It might be possible to allow additional commands with more work  
and thought.  
  
Along the way, document the thinking process behind the current set  
of checks, as per discussion especially with Peter Eisentraut. There  
is some interest in revising some of these rules, but that seems  
like a job for another patch.  
  
Patch by me, reviewed by Tom Lane, Stephen Frost, and Peter  
Eisentraut.  
  
Discussion: http://postgr.es/m/CA+TgmoZ_rLqJt5sYkvh+JpQnfX0Y+B2R+qfi820xNih6x-FQOQ@mail.gmail.com  

commit   : 0db7c67051806f28a9129d50695efc19372d3af2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 11:31:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Jan 2020 11:31:30 -0500    

Remove duplicated code (apparently introduced by commit c8ea87e4b).  
Also get rid of some PG_USED_FOR_ASSERTS_ONLY variables we don't  
really need to have.  
  
Li Japin, Tom Lane  
  
Discussion: https://postgr.es/m/PS1PR0601MB3770A5595B6E5E3FD6F35724B6360@PS1PR0601MB3770.apcprd06.prod.outlook.com  

commit   : 1281a5c907b41e992a66deb13c3aa61888a62268    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Jan 2020 18:49:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 15 Jan 2020 18:49:24 -0500    

We've had numerous bug reports about how (1) IF NOT EXISTS clauses in  
ALTER TABLE don't behave as-expected, and (2) combining certain actions  
into one ALTER TABLE doesn't work, though executing the same actions as  
separate statements does.  This patch cleans up all of the cases so far  
reported from the field, though there are still some oddities associated  
with identity columns.  
  
The core problem behind all of these bugs is that we do parse analysis  
of ALTER TABLE subcommands too soon, before starting execution of the  
statement.  The root of the bugs in group (1) is that parse analysis  
schedules derived commands (such as a CREATE SEQUENCE for a serial  
column) before it's known whether the IF NOT EXISTS clause should cause  
a subcommand to be skipped.  The root of the bugs in group (2) is that  
earlier subcommands may change the catalog state that later subcommands  
need to be parsed against.  
  
Hence, postpone parse analysis of ALTER TABLE's subcommands, and do  
that one subcommand at a time, during "phase 2" of ALTER TABLE which  
is the phase that does catalog rewrites.  Thus the catalog effects  
of earlier subcommands are already visible when we analyze later ones.  
(The sole exception is that we do parse analysis for ALTER COLUMN TYPE  
subcommands during phase 1, so that their USING expressions can be  
parsed against the table's original state, which is what we need.  
Arguably, these bugs stem from falsely concluding that because ALTER  
COLUMN TYPE must do early parse analysis, every other command subtype  
can too.)  
  
This means that ALTER TABLE itself must deal with execution of any  
non-ALTER-TABLE derived statements that are generated by parse analysis.  
Add a suitable entry point to utility.c to accept those recursive  
calls, and create a struct to pass through the information needed by  
the recursive call, rather than making the argument lists of  
AlterTable() and friends even longer.  
  
Getting this to work correctly required a little bit of fiddling  
with the subcommand pass structure, in particular breaking up  
AT_PASS_ADD_CONSTR into multiple passes.  But otherwise it's mostly  
a pretty straightforward application of the above ideas.  
  
Fixing the residual issues for identity columns requires refactoring of  
where the dependency link from an identity column to its sequence gets  
set up.  So that seems like suitable material for a separate patch,  
especially since this one is pretty big already.  
  
Discussion: https://postgr.es/m/10365.1558909428@sss.pgh.pa.us  

commit   : a166d408eb0b35023c169e765f4664c3b114b52e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 15 Jan 2020 11:02:09 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 15 Jan 2020 11:02:09 -0300    

This uses the progress reporting infrastructure added by c16dc1aca5e0,  
adding support for ANALYZE.  
  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Co-authored-by: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>  
Reviewed-by: Julien Rouhaud, Robert Haas, Anthony Nowocien, Kyotaro Horiguchi,  
	Vignesh C, Amit Langote  

commit   : 16a4a3d59cd5574fdc697ea16ef5692ce34c54d5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jan 2020 10:15:06 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 15 Jan 2020 10:15:06 +0100    

For historical reasons, libpq used a separate libpq.rc file for the  
Windows builds while all other components use a common file  
win32ver.rc.  With a bit of tweaking, the libpq build can also use the  
win32ver.rc file.  This removes a bit of duplicative code.  
  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/ad505e61-a923-e114-9f38-9867d161073f@2ndquadrant.com  

commit   : ac5bdf62617507b1942f6124a2696c04a16fca04    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jan 2020 13:58:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Jan 2020 13:58:33 +0900    

The logic introduced in this routine as of 246a6c8 would report an  
incorrect result when a session calls it to check if the temporary  
namespace owned by the session is in use or not.  It is possible to  
optimize more the routine in this case to avoid a PGPROC lookup, but  
let's keep the logic simple.  As this routine is used only by autovacuum  
for now, there were no live bugs, still let's be correct for any future  
code involving it.  
  
Author: Michael Paquier  
Reviewed-by: Julien Rouhaud  
Discussion: https://postgr.es/m/20200113093703.GA41902@paquier.xyz  
Backpatch-through: 11  

commit   : 4d8a8d0c738410ec02aab46b1ebe1835365ad384    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 15 Jan 2020 07:24:14 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 15 Jan 2020 07:24:14 +0530    

Introduce new fields amusemaintenanceworkmem and amparallelvacuumoptions  
in IndexAmRoutine for parallel vacuum.  The amusemaintenanceworkmem tells  
whether a particular IndexAM uses maintenance_work_mem or not.  This will  
help in controlling the memory used by individual workers as otherwise,  
each worker can consume memory equal to maintenance_work_mem.  The  
amparallelvacuumoptions tell whether a particular IndexAM participates in  
a parallel vacuum and if so in which phase (bulkdelete, vacuumcleanup) of  
vacuum.  
  
Author: Masahiko Sawada and Amit Kapila  
Reviewed-by: Dilip Kumar, Amit Kapila, Tomas Vondra and Robert Haas  
Discussion:  
https://postgr.es/m/CAD21AoDTPMgzSkV4E3SFo1CH_x50bf5PqZFQf4jmqjk-C03BWg@mail.gmail.com  
https://postgr.es/m/CAA4eK1LmcD5aPogzwim5Nn58Ki+74a6Edghx4Wd8hAskvHaq5A@mail.gmail.com  

commit   : fe233366f2e3ca44609c805ce0604c1e2122c3f9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 23:59:18 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 23:59:18 +0100    

On 64-bit Windows, pid_t is long long int, so a %d format isn't  
enough.  

commit   : 0e936a2148472e6c364aee8c3e298dc16dc4240a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jan 2020 13:13:04 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jan 2020 13:13:04 -0500    

The new wording was determined to be more accurate.  Also, update  
release note links that reference these sections.  
  
Reported-by: rirans@comcast.net  
  
Discussion: https://postgr.es/m/157742545062.1149.11052653770497832538@wrigleys.postgresql.org  
  
Backpatch-through: 9.6  

commit   : 344c26915136fa54c4a1bf54074ba15090b32721    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jan 2020 11:28:07 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jan 2020 11:28:07 -0500    

This reverts part of commit 7559d8ebfa.  The copyright script has  
already been updated to skip *.key files.  
  
Reported-by: Alvaro Herrera  
  
Discussion: https://postgr.es/m/20200102184059.GA25435@alvherre.pgsql  
  
Backpatch-through: master  

commit   : 7316f11be03863858fa7acb5eee97ec35c91fca4    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jan 2020 10:51:58 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 14 Jan 2020 10:51:58 -0500    

Reported-by: Alvaro Herrera  
  
Discussion: https://postgr.es/m/20200102184059.GA25435@alvherre.pgsql  
  
Backpatch-through: master  

commit   : 329730827848f61eb8d353d5addcbd885fa823da    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 14:07:11 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 14:07:11 +0100    

If no permanent replication slot is configured using  
primary_slot_name, the walreceiver now creates and uses a temporary  
replication slot.  A new setting wal_receiver_create_temp_slot can be  
used to disable this behavior, for example, if the remote instance is  
out of replication slots.  
  
Reviewed-by: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/CA%2Bfd4k4dM0iEPLxyVyme2RAFsn8SUgrNtBJOu81YqTY4V%2BnqZA%40mail.gmail.com  

commit   : ee4ac46c8eb289bc200d0fd682e75d11b4c55b5a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 14:05:25 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 14:05:25 +0100    

This will be used by a subsequent patch.  
  
Reviewed-by: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/CA%2Bfd4k4dM0iEPLxyVyme2RAFsn8SUgrNtBJOu81YqTY4V%2BnqZA%40mail.gmail.com  

commit   : f595117e24a79db6072979ab5a757431fd17232f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 13:09:31 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 14 Jan 2020 13:09:31 +0100    

Add an ALTER TABLE subcommand for dropping the generated property from  
a column, per SQL standard.  
  
Reviewed-by: Sergei Kornilov <sk@zsrv.org>  
Discussion: https://www.postgresql.org/message-id/flat/2f7f1d9c-946e-0453-d841-4f38eb9d69b6%402ndquadrant.com  

commit   : d751ba523546df2b2709c1ffd4d12d6a25e25bf6    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 14 Jan 2020 09:52:21 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Tue, 14 Jan 2020 09:52:21 +0000    

A view with conditional INSTEAD rules and no unconditional INSTEAD  
rules or INSTEAD OF triggers is not auto-updatable. Previously we  
relied on a check in the executor to catch this, but that's  
problematic since the planner may fail to properly handle such a query  
and thus return a particularly unhelpful error to the user, before  
reaching the executor check.  
  
Instead, trap this in the rewriter and report the correct error there.  
Doing so also allows us to include more useful error detail than the  
executor check can provide. This doesn't change the existing behaviour  
of updatable views; it merely ensures that useful error messages are  
reported when a view isn't updatable.  
  
Per report from Pengzhou Tang, though not adopting that suggested fix.  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAG4reAQn+4xB6xHJqWdtE0ve_WqJkdyCV4P=trYr4Kn8_3_PEA@mail.gmail.com  

commit   : ed7bb5c311ce059294807cf4abfa9406d95feec0    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 11 Jan 2020 10:24:48 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 11 Jan 2020 10:24:48 +0530    

This test was trying to test the mechanism to release kernel FDs as needed  
to get us under the max_safe_fds limit in case of spill files.  To do that,  
it needs to set max_files_per_process to a very low value which doesn't  
even permit starting of the server in the case when there are a few already  
opened files.  This test also won't work on platforms where we use one FD  
per semaphore.  
  
Backpatch-through: 10, till where this test was added  
Discussion:  
https://postgr.es/m/CAA4eK1LHhERi06Q+MmP9qBXBBboi+7WV3910J0aUgz71LcnKAw@mail.gmail.com  
https://postgr.es/m/6485.1578583522@sss.pgh.pa.us  

commit   : 7f380c59f800f7e0fb49f45a6ff7787256851a59    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jan 2020 15:04:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jan 2020 15:04:31 -0500    

Previously, the core scanner's yy_transition[] array had 37045 elements.  
Since that number is larger than INT16_MAX, Flex generated the array to  
contain 32-bit integers.  By reimplementing some of the bulkier scanner  
rules, this patch reduces the array to 20495 elements.  The much smaller  
total length, combined with the consequent use of 16-bit integers for  
the array elements reduces the binary size by over 200kB.  This was  
accomplished in two ways:  
  
1. Consolidate handling of quote continuations into a new start condition,  
rather than duplicating that logic for five different string types.  
  
2. Treat Unicode strings and identifiers followed by a UESCAPE sequence  
as three separate tokens, rather than one.  The logic to de-escape  
Unicode strings is moved to the filter code in parser.c, which already  
had the ability to provide special processing for token sequences.  
While we could have implemented the conversion in the grammar, that  
approach was rejected for performance and maintainability reasons.  
  
Performance in microbenchmarks of raw parsing seems equal or slightly  
faster in most cases, and it's reasonable to expect that in real-world  
usage (with more competition for the CPU cache) there will be a larger  
win.  The exception is UESCAPE sequences; lexing those is about 10%  
slower, primarily because the scanner now has to be called three times  
rather than one.  This seems acceptable since that feature is very  
rarely used.  
  
The psql and epcg lexers are likewise modified, primarily because we  
want to keep them all in sync.  Since those lexers don't use the  
space-hogging -CF option, the space savings is much less, but it's  
still good for perhaps 10kB apiece.  
  
While at it, merge the ecpg lexer's handling of C-style comments used  
in SQL and in C.  Those have different rules regarding nested comments,  
but since we already have the ability to keep track of the previous  
start condition, we can use that to handle both cases within a single  
start condition.  This matches the core scanner more closely.  
  
John Naylor  
  
Discussion: https://postgr.es/m/CACPNZCvaoa3EgVWm5yZhcSTX6RAtaLgniCPcBVOCwm8h3xpWkw@mail.gmail.com  

commit   : 259bbe177808986e5d226ea7ce5a1ebb74657791    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jan 2020 13:27:39 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Jan 2020 13:27:39 +0100    

The use of pg_atoi() for parsing a string into an Oid fails for values  
larger than INT32_MAX, since OIDs are unsigned.  Instead, use  
atooid().  While this has less error checking, the contents of the  
data directory are expected to be trustworthy, so we don't need to go  
out of our way to do full error checking.  
  
Discussion: https://www.postgresql.org/message-id/flat/dea47fc8-6c89-a2b1-07e3-754ff1ab094b%402ndquadrant.com  

commit   : 23d0dfa8fa016f7f8af25b1040d7a55ba77da6fc    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jan 2020 14:44:55 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jan 2020 14:44:55 +0530    

Reported-by: Antonin Houska  
Author: Antonin Houska  
Backpatch-through: 11, where it was introduced  
Discussion: https://postgr.es/m/2246.1578900133@antos  

commit   : 7689d907bbb177fa2a8f5aca3f968761dd16bf28    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Jan 2020 17:57:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 13 Jan 2020 17:57:38 +0900    

Improvement per suggestion from Tom Lane.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/FED18699-4270-4778-8DA8-10F119A5ECF3@yesql.se  

commit   : cebf9d6e6ee13cbf9f1a91ec633cf96780ffc985    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 13 Jan 2020 18:08:09 +1030    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 13 Jan 2020 18:08:09 +1030    

Othrwise there is a security risk.  
  
Discussion: https://postgr.es/m/20200109103014.GA4192@msg.df7cb.de  

commit   : 4e514c6180fbf71cf7a0171867c828c63afd1c37    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jan 2020 07:59:44 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Jan 2020 07:59:44 +0530    

Earlier, we use to postpone deleting empty pages till the second stage of  
vacuum to amortize the cost of scanning internal pages.  However, that can  
sometimes (say vacuum is canceled or errored between first and second  
stage) delay the pages to be recycled.  
  
Another thing is that to facilitate deleting empty pages in the second  
stage, we need to share the information about internal and empty pages  
between different stages of vacuum.  It will be quite tricky to share this  
information via DSM which is required for the upcoming parallel vacuum  
patch.  
  
Also, it will bring the logic to reclaim deleted pages closer to nbtree  
where we delete empty pages in each pass.  
  
Overall, the advantages of deleting empty pages in each pass outweigh the  
advantages of postponing the same.  
  
Author: Dilip Kumar, with changes by Amit Kapila  
Reviewed-by: Sawada Masahiko and Amit Kapila  
Discussion: https://postgr.es/m/CAA4eK1LGr+MN0xHZpJ2dfS8QNQ1a_aROKowZB+MPNep8FVtwAA@mail.gmail.com  

commit   : eae056c19ee8f5ebc45ac0fe13181f91c8791e00    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 13 Jan 2020 01:20:57 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 13 Jan 2020 01:20:57 +0100    

Until now we've only used a single multivariate MCV list per relation,  
covering the largest number of clauses. So for example given a query  
  
    SELECT * FROM t WHERE a = 1 AND b =1 AND c = 1 AND d = 1  
  
and extended statistics on (a,b) and (c,d), we'd only pick and use one  
of them. This commit improves this by repeatedly picking and applying  
the best statistics (matching the largest number of remaining clauses)  
until no additional statistics is applicable.  
  
This greedy algorithm is simple, but may not be optimal. A different  
choice of statistics may leave fewer clauses unestimated and/or give  
better estimates for some other reason.  
  
This can however happen only when there are overlapping statistics, and  
selecting one makes it impossible to use the other. E.g. with statistics  
on (a,b), (c,d), (b,c,d), we may pick either (a,b) and (c,d) or (b,c,d).  
But it's not clear which option is the best one.  
  
We however assume cases like this are rare, and the easiest solution is  
to define statistics covering the whole group of correlated columns. In  
the future we might support overlapping stats, using some of the clauses  
as conditions (in conditional probability sense).  
  
Author: Tomas Vondra  
Reviewed-by: Mark Dilger, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20191028152048.jc6pqv5hb7j77ocp@development  

commit   : aaa6761876ba5b06a5c3fa914b2951ace1e31dee    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 13 Jan 2020 01:20:57 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 13 Jan 2020 01:20:57 +0100    

When considering functional dependencies during selectivity estimation,  
it's not necessary to bother with selecting the best extended statistic  
object and then use just dependencies from it. We can simply consider  
all applicable functional dependencies at once.  
  
This means we need to deserialie all (applicable) dependencies before  
applying them to the clauses. This is a bit more expensive than picking  
the best statistics and deserializing dependencies for it. To minimize  
the additional cost, we ignore statistics that are not applicable.  
  
Author: Tomas Vondra  
Reviewed-by: Mark Dilger  
Discussion: https://postgr.es/m/20191028152048.jc6pqv5hb7j77ocp@development  

commit   : 652686a334b437f57f9bd0e3baa5dbd245a9e15d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Jan 2020 14:36:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Jan 2020 14:36:59 -0500    

When estimating the selectivity of "range_var <@ range_constant" or  
"range_var @> range_constant", if the upper (or respectively lower)  
bound of the range_constant was above the last bin of the range_var's  
histogram, the code would access uninitialized memory and potentially  
crash (though it seems the probability of a crash is quite low).  
Handle the endpoint cases explicitly to fix that.  
  
While at it, be more paranoid about the possibility of getting NaN  
or other silly results from the range type's subdiff function.  
And improve some comments.  
  
Ordinarily we'd probably add a regression test case demonstrating  
the bug in unpatched code.  But it's too hard to get it to crash  
reliably because of the uninitialized-memory dependence, so skip that.  
  
Per bug #16122 from Adam Scott.  It's been broken from the beginning,  
apparently, so backpatch to all supported branches.  
  
Diagnosis by Michael Paquier, patch by Andrey Borodin and Tom Lane.  
  
Discussion: https://postgr.es/m/16122-eb35bc248c806c15@postgresql.org  

commit   : 1088729e84cc382270c592ac8c57c323836f40ca    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 12 Jan 2020 22:43:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 12 Jan 2020 22:43:45 +0900    

On the publisher, it was assumed that an INSERT change cannot happen for  
a relation with no replica identity.  However this is true only for a  
change that needs references to old rows, aka UPDATE or DELETE, so  
trying to use logical replication with a relation that has no replica  
identity led to an assertion failure in the publisher when issuing an  
INSERT.  This commit removes the incorrect assertion, and adds more  
regression tests to provide coverage for relations without replica  
identity.  
  
Reported-by: Neha Sharma  
Author: Dilip Kumar, Michael Paquier  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/CANiYTQsL1Hb8_Km08qd32svrqNumXLJeoGo014O7VZymgOhZEA@mail.gmail.com  
Backpatch-through: 10  

commit   : 2c0cdc8183654c090c9a1e2f1b5e96ba4634e16a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2020 17:14:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2020 17:14:08 -0500    

Fix assorted bugs in handling of non-blocking I/O when using GSSAPI  
encryption.  The encryption layer could return the wrong status  
information to its caller, resulting in effectively dropping some data  
(or possibly in aborting a not-broken connection), or in a "livelock"  
situation where data remains to be sent but the upper layers think  
transmission is done and just go to sleep.  There were multiple small  
thinkos contributing to that, as well as one big one (failure to think  
through what to do when a send fails after having already transmitted  
data).  Note that these errors could cause failures whether the client  
application asked for non-blocking I/O or not, since both libpq and  
the backend always run things in non-block mode at this level.  
  
Also get rid of use of static variables for GSSAPI inside libpq;  
that's entirely not okay given that multiple connections could be  
open at once inside a single client process.  
  
Also adjust a bunch of random small discrepancies between the frontend  
and backend versions of the send/receive functions -- except for error  
handling, they should be identical, and now they are.  
  
Also extend the Kerberos TAP tests to exercise cases where nontrivial  
amounts of data need to be pushed through encryption.  Before, those  
tests didn't provide any useful coverage at all for the cases of  
interest here.  (They still might not, depending on timing, but at  
least there's a chance.)  
  
Per complaint from pmc@citylink and subsequent investigation.  
Back-patch to v12 where this code was introduced.  
  
Discussion: https://postgr.es/m/20200109181822.GA74698@gate.oper.dinoex.org  

commit   : c67a55da4ea0caa18547fd1533110e9126ba8d47    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Jan 2020 09:00:19 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Jan 2020 09:00:19 +0100    

Some callers are not using it, so it's wasteful to have to specify it.  
  
Reviewed-by: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/CA+fd4k4BcYrYucNfTnK-CQX3+jsG+PRPEhHAUSo-W4P0Lec57A@mail.gmail.com  

commit   : c096a804d9dcc46f1a8ebf2742696aca90b2dfcf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Dec 2019 09:09:20 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Dec 2019 09:09:20 +0100    

Replace the solitary use with a bool.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/a6f91ead-0ce4-2a34-062b-7ab9813ea308%402ndquadrant.com  

commit   : 38fc056074e034087af8a1589507631682a279d1    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 10 Jan 2020 18:31:22 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 10 Jan 2020 18:31:22 -0800    

FileClose() failure ordinarily causes a PANIC.  Suppose the user  
disables that PANIC via data_sync_retry=on.  After mdclose() issued a  
FileClose() that failed, calls into md.c raised SIGSEGV.  This fix adds  
repalloc() calls during mdclose(); update a comment about ignoring  
repalloc() cost.  The rate of relation segment count change is a minor  
factor; more relevant to overall performance is the rate of mdclose()  
and subsequent re-opening of segments.  Back-patch to v10, where commit  
45e191e3aa62d47a8bc1a33f784286b2051f45cb introduced the bug.  
  
Reviewed by Kyotaro Horiguchi.  
  
Discussion: https://postgr.es/m/20191222091930.GA1280238@rfd.leadboat.com  

commit   : 1a4a0329650b0545a54afb3c317aa289fd817f8a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Jan 2020 13:15:28 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Jan 2020 13:15:28 -0800    

Author: Peter Geoghegan  
Reviewed-By: Heikki Linnakangas  

commit   : a0dc3c19ed1cffed6616f8b8b5f21ad7d6830045    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Jan 2020 13:12:50 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Jan 2020 13:12:50 -0800    

Author: Peter Geoghegan  
Reviewed-By: Heikki Linnakangas  

commit   : a7b6ab5db1d35438112f74f3531354ddd61970b5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 10 Jan 2020 17:46:57 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 10 Jan 2020 17:46:57 -0300    

This simplifies addition of further flags.  
  
Author: Nikhil Sontakke  
Discussion: https://postgr.es/m/CAMGcDxeViP+R-OL7QhzUV9eKCVjURobuY1Zijik4Ay_Ddwo4Cg@mail.gmail.com  

commit   : 00b047fa67e9f4428a682bd90d5e6b08d2f8a87b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Jan 2020 09:36:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Jan 2020 09:36:55 +0900    

Reported-by: Tham Nguyen  
Discussion: https://postgr.es/m/157851402876.29175.12977878383183540468@wrigleys.postgresql.org  
Backpatch-through: 9.4  

commit   : 39a5f2a94f8a3bcfdb3da7391427a63f8f88b210    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Jan 2020 09:02:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Jan 2020 09:02:25 +0900    

This is a follow-up of 30a3e772, making the output more consistent when  
using --debug for meta-command execution.  
  
Author: Michael Paquier  
Reviewed-by: Fabien Coelho  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1912241100390.3339@pseudo  

commit   : e7ee433137b6eb3678deeebc68be53d58aa1e5d3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jan 2020 16:46:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jan 2020 16:46:05 -0500    

Experience so far suggests that getting these tests to pass on  
all libedit versions that are out there may be impossible, or  
require dumbing down the tests to the point of uselessness.  
So we need to provide a way to skip them when the user knows they'll  
fail.  An environment variable is probably the most convenient way  
to deal with this; it's easy for, e.g., a buildfarm animal's  
configuration to set up.  
  
Discussion: https://postgr.es/m/9594.1578586797@sss.pgh.pa.us  

commit   : 9ce77d75c5ab094637cc4a446296dc3be6e3c221    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jan 2020 11:56:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Jan 2020 11:56:59 -0500    

The core idea of this patch is to make the parser generate join alias  
Vars (that is, ones with varno pointing to a JOIN RTE) only when the  
alias Var is actually different from any raw join input, that is a type  
coercion and/or COALESCE is necessary to generate the join output value.  
Otherwise just generate varno/varattno pointing to the relevant join  
input column.  
  
In effect, this means that the planner's flatten_join_alias_vars()  
transformation is already done in the parser, for all cases except  
(a) columns that are merged by JOIN USING and are transformed in the  
process, and (b) whole-row join Vars.  In principle that would allow  
us to skip doing flatten_join_alias_vars() in many more queries than  
we do now, but we don't have quite enough infrastructure to know that  
we can do so --- in particular there's no cheap way to know whether  
there are any whole-row join Vars.  I'm not sure if it's worth the  
trouble to add a Query-level flag for that, and in any case it seems  
like fit material for a separate patch.  But even without skipping the  
work entirely, this should make flatten_join_alias_vars() faster,  
particularly where there are nested joins that it previously had to  
flatten recursively.  
  
An essential part of this change is to replace Var nodes'  
varnoold/varoattno fields with varnosyn/varattnosyn, which have  
considerably more tightly-defined meanings than the old fields: when  
they differ from varno/varattno, they identify the Var's position in  
an aliased JOIN RTE, and the join alias is what ruleutils.c should  
print for the Var.  This is necessary because the varno change  
destroyed ruleutils.c's ability to find the JOIN RTE from the Var's  
varno.  
  
Another way in which this change broke ruleutils.c is that it's no  
longer feasible to determine, from a JOIN RTE's joinaliasvars list,  
which join columns correspond to which columns of the join's immediate  
input relations.  (If those are sub-joins, the joinaliasvars entries  
may point to columns of their base relations, not the sub-joins.)  
But that was a horrid mess requiring a lot of fragile assumptions  
already, so let's just bite the bullet and add some more JOIN RTE  
fields to make it more straightforward to figure that out.  I added  
two integer-List fields containing the relevant column numbers from  
the left and right input rels, plus a count of how many merged columns  
there are.  
  
This patch depends on the ParseNamespaceColumn infrastructure that  
I added in commit 5815696bc.  The biggest bit of code change is  
restructuring transformFromClauseItem's handling of JOINs so that  
the ParseNamespaceColumn data is propagated upward correctly.  
  
Other than that and the ruleutils fixes, everything pretty much  
just works, though some processing is now inessential.  I grabbed  
two pieces of low-hanging fruit in that line:  
  
1. In find_expr_references, we don't need to recurse into join alias  
Vars anymore.  There aren't any except for references to merged USING  
columns, which are more properly handled when we scan the join's RTE.  
This change actually fixes an edge-case issue: we will now record a  
dependency on any type-coercion function present in a USING column's  
joinaliasvar, even if that join column has no references in the query  
text.  The odds of the missing dependency causing a problem seem quite  
small: you'd have to posit somebody dropping an implicit cast between  
two data types, without removing the types themselves, and then having  
a stored rule containing a whole-row Var for a join whose USING merge  
depends on that cast.  So I don't feel a great need to change this in  
the back branches.  But in theory this way is more correct.  
  
2. markRTEForSelectPriv and markTargetListOrigin don't need to recurse  
into join alias Vars either, because the cases they care about don't  
apply to alias Vars for USING columns that are semantically distinct  
from the underlying columns.  This removes the only case in which  
markVarForSelectPriv could be called with NULL for the RTE, so adjust  
the comments to describe that hack as being strictly internal to  
markRTEForSelectPriv.  
  
catversion bump required due to changes in stored rules.  
  
Discussion: https://postgr.es/m/7115.1577986646@sss.pgh.pa.us  

commit   : ed10f32e37e9a16814c25e400d7826745ae3c797    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jan 2020 10:59:07 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jan 2020 10:59:07 -0500    

This tells you about allocations that have been made from the main  
shared memory segment. The original patch also tried to show information  
about dynamic shared memory allocation as well, but I decided to  
leave that problem for another time.  
  
Andres Freund and Robert Haas, reviewed by Michael Paquier, Marti  
Raudsepp, Tom Lane, Álvaro Herrera, and Kyotaro Horiguchi.  
  
Discussion: http://postgr.es/m/20140504114417.GM12715@awork2.anarazel.de  

commit   : 5acf6d8bb4ec23349604c7c15111959e657ff294    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jan 2020 09:01:37 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 9 Jan 2020 09:01:37 -0500    

Per the buildfarm, via Michael Paquier.  
  
Discussion: http://postgr.es/m/20200108032648.GE3413@paquier.xyz  

commit   : e3019f631d1f2e21667ad05f903c52d904b9048c    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 9 Jan 2020 10:48:22 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 9 Jan 2020 10:48:22 +0100    

Reported-by: Octopus ZHANG  
Author: Daniel Gustafsson  

commit   : f85a485f89e2eb38499558c7489f108994410952    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Jan 2020 09:54:47 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Jan 2020 09:54:47 +0100    

We currently have several sets of files generated from data provided  
by Unicode.  These all have ad hoc rules and instructions for updating  
when new Unicode versions appear, and it's not done consistently.  
  
This patch centralizes and automates the process and makes it part of  
the release checklist.  The Unicode and CLDR versions are specified in  
Makefile.global.in.  There is a new make target "update-unicode" that  
downloads all the relevant files and runs the generation script.  
  
There is also a new script for generating the table of combining  
characters for ucs_wcwidth().  That table is now in a separate include  
file rather than hardcoded into the middle of other code.  This is  
based on the script that was used for generating  
d8594d123c155aeecd47fc2450f62f5100b2fbf0, but the script itself wasn't  
committed at that time.  
  
Reviewed-by: John Naylor <john.naylor@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/c8d05f42-443e-6c23-819b-05b31759a37c@2ndquadrant.com  

commit   : f5fd995a1a24e6571d26b1e29c4dc179112b1003    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 9 Jan 2020 18:39:54 +1030    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 9 Jan 2020 18:39:54 +1030    

This allows different users to authenticate with different certificates.  
  
Author: Craig Ringer  

commit   : 45223fd9cefe483daa4af7740f15c004486636eb    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jan 2020 21:48:44 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jan 2020 21:48:44 +0100    

Change the exception syntax used in the tests to use the more current  
  
    except Exception as ex:  
  
rather than the old  
  
    except Exception, ex:  
  
Since support for Python <2.6 has been removed, all supported versions  
now support the new style, and we can save one step in the Python 3  
compatibility conversion.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/98b69261-298c-13d2-f34d-836fd9c29b21%402ndquadrant.com  

commit   : 37f21ed132d1c5aee88e81fee0a0b7e735673d35    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jan 2020 21:48:44 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jan 2020 21:48:44 +0100    

Supporting very old Python versions is a maintenance burden,  
especially with the several variant test files to maintain for Python  
<2.6.  
  
Since we have dropped support for older OpenSSL versions in  
7b283d0e1d1d79bf1c962d790c94d2a53f3bb38a, RHEL 5 is now effectively  
desupported, and that was also the only mainstream operating system  
still using Python versions before 2.6, so it's a good time to drop  
those as well.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/98b69261-298c-13d2-f34d-836fd9c29b21%402ndquadrant.com  

commit   : f5d28710c707ad602cd869602e092cc9d538cbb9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 8 Jan 2020 14:33:49 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 8 Jan 2020 14:33:49 -0300    

Make the value null only at pg_stat_activity-output time, as suggested  
by Tom Lane, instead of messing with the internal state.  This should  
appease buildfarm members with force_parallel_mode=regress, which are  
running parallel queries on logical replication walsenders.  
  
The fact that walsenders can run parallel queries should perhaps be  
studied more carefully, but for the moment let's get rid of the red  
blots in buildfarm.  
  
Backpatch to pg10, like the previous commit.  
  
Discussion: https://postgr.es/m/30804.1578438763@sss.pgh.pa.us  

commit   : 913bbd88dc6b859c70ebb48107b38d693c4c6673    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jan 2020 11:07:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jan 2020 11:07:53 -0500    

Use the parser's standard type coercion machinery to convert the  
output column(s) of a SQL function's final SELECT or RETURNING  
to the type(s) they should have according to the function's declared  
result type.  We'll allow any case where an assignment-level  
coercion is available.  Previously, we failed unless the required  
coercion was a binary-compatible one (and the documentation ignored  
this, falsely claiming that the types must match exactly).  
  
Notably, the coercion now accounts for typmods, so that cases where  
a SQL function is declared to return a composite type whose columns  
are typmod-constrained now behave as one would expect.  Arguably  
this aspect is a bug fix, but the overall behavioral change here  
seems too large to consider back-patching.  
  
A nice side-effect is that functions can now be inlined in a  
few cases where we previously failed to do so because of type  
mismatches.  
  
Discussion: https://postgr.es/m/18929.1574895430@sss.pgh.pa.us  

commit   : 8dd1511e39acd729020e151deb15a958300ebff5    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Wed, 8 Jan 2020 10:57:09 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Wed, 8 Jan 2020 10:57:09 -0500    

The original comment was a bit confusing, pointed out by Alvaro Herrera.  
  
Thread: https://postgr.es/m/20191224151520.GA16435%40alvherre.pgsql  

commit   : 4ac8aaa36fa24639989849c8109f8b52e9544fd1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jan 2020 09:42:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jan 2020 09:42:53 -0500    

ALTER TABLE failed if a column referenced in a GENERATED expression  
had been added or changed in type earlier in the ALTER command.  
That's because the GENERATED expression needs to be evaluated  
against the table's updated tuples, but it was being evaluated  
against the original tuples.  (Fortunately the executor has adequate  
cross-checks to notice the mismatch, so we just got an obscure error  
message and not anything more dangerous.)  
  
Per report from Andreas Joseph Krogh.  Back-patch to v12 where  
GENERATED was added.  
  
Discussion: https://postgr.es/m/VisenaEmail.200.231b0a41523275d0.16ea7f800c7@tc7-visena  

commit   : 30a3e772b4013d6593e4141cebd5ebfaff4d71a8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jan 2020 14:23:55 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Jan 2020 14:23:55 +0100    

Author: Fabien COELHO <coelho@cri.ensmp.fr>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1912241100390.3339@pseudo  

commit   : 65192e02441cedd106b6abebe0036fb8cc124fb3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jan 2020 10:36:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jan 2020 10:36:12 +0900    

This reverts commit a052f6c, following complains from Robert Haas and  
Tom Lane.  Backpatch down to 9.4, like the previous commit.  
  
Discussion: https://postgr.es/m/CA+TgmobL4npEX5=E5h=5Jm_9mZun3MT39Kq2suJFVeamc9skSQ@mail.gmail.com  
Backpatch-through: 9.4  

commit   : b0b6196386681383b8f0cb76df4fd35178a7371e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jan 2020 10:02:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Jan 2020 10:02:55 +0900    

Failures in allocations could lead to crashes with NULL pointer  
dereferences .  Memory context TopMemoryContext is used instead to keep  
alive the plans allocated in the session.  A more specific context could  
be used here, but this is left for later.  
  
Reported-by: Jian Zhang  
Author: Michael Paquier  
Reviewed-by: Tom Lane, Andres Freund  
Discussion: https://postgr.es/m/16190-70181c803641c3dc@postgresql.org  

commit   : b175bd59fa54a90d21bc541f812643ac45281b98    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jan 2020 17:38:48 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Jan 2020 17:38:48 -0300    

Returning a non-NULL time is pointless, sinc a walsender is not a  
process that would be running normal transactions anyway, but the code  
was unintentionally exposing the process start time intermittently,  
which was not only bogus but it also confused monitoring systems looking  
for idle transactions.  Fix by avoiding all updates in walsenders.  
  
Backpatch to 11, where walsenders started appearing in pg_stat_activity.  
  
Reported-by: Tomas Vondra  
Discussion: https://postgr.es/m/20191209234409.exe7osmyalwkt5j4@development  

commit   : ce242ae154dde3217971c6f262705d80999f4e00    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jan 2020 14:35:48 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jan 2020 14:35:48 -0500    

Instead of always calling heap_fetch_toast_slice during detoasting,  
invoke a table AM callback which, when the toast table is a heap  
table, will be heap_fetch_toast_slice.  
  
This makes it possible for a table AM other than heap to be used  
as a TOAST table. It also completes the series of commits intended  
to improve the interaction of tableam with TOAST that began with  
commit 8b94dab06617ef80a0901ab103ebd8754427ef5a; detoast.c is  
now, hopefully, fully AM-independent.  
  
Patch by me, reviewed by Andres Freund and Peter Eisentraut.  
  
Discussion: http://postgr.es/m/CA+TgmoZv-=2iWM4jcw5ZhJeL18HF96+W1yJeYrnGMYdkFFnEpQ@mail.gmail.com  

commit   : 83322e38da1aa054e1b144cb37e6074a86854199    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jan 2020 14:23:25 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jan 2020 14:23:25 -0500    

Previously, the toast table had to be implemented by the same AM that  
was used for the main table, which was bad, because the detoasting  
code won't work with anything but heap. This commit doesn't fix the  
latter problem, although there's another patch coming which does,  
but it does let you pick something that works (i.e. heap, right now).  
  
Patch by me, reviewed by Andres Freund.  
  
Discussion: http://postgr.es/m/CA+TgmoZv-=2iWM4jcw5ZhJeL18HF96+W1yJeYrnGMYdkFFnEpQ@mail.gmail.com  

commit   : 814727858918154bdde9dbdfb99c544b52eb8818    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jan 2020 12:14:19 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 7 Jan 2020 12:14:19 -0500    

This one-line change provoked a lot of discussion, but ultimately  
the consensus seems to be that allowing a larger value might be  
useful to somebody, and probably won't hurt anyone who chooses  
not to take advantage of the higher maximum limit.  
  
Vyacheslav Makarov, reviewed by many people.  
  
Discussion: http://postgr.es/m/7b5ecc5a9991045e2f13c84e3047541d@postgrespro.ru  

commit   : 2bd0735b954b14dcfab85d57fc4a0c7f9826fbb1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jan 2020 20:56:32 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jan 2020 20:56:32 -0500    

Instead of hard-wiring the netmask as /32, allow it to be specified  
where we specify the server address.  This will ease changing the  
test to use IPv6, when/if somebody wants to do that.  
  
Also remove the hard-wired pg_hba.conf entries for IPv6 (::1/128).  
These have never had any usefulness, because the client side  
of the tests has always explicitly connected to $SERVERHOSTADDR  
which has always been set to IPv4 (127.0.0.1).  All they accomplish  
is to break the test on non-IPv6-supporting hosts, and besides  
that they violate the express intent of the code to minimize the  
server's range of allowed connections.  
  
This could be back-patched, perhaps, but for now I don't see  
a need to.  
  
Discussion: https://postgr.es/m/1899.1578356089@sss.pgh.pa.us  

commit   : e369f3708636c66718796fc8269d253432410392    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jan 2020 16:42:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jan 2020 16:42:20 -0500    

Since the WAL flush position only moves forward, it's safe to cache  
its previous value within each walsender process, and update from  
shared memory only once we've caught up to the previously-seen value.  
When there are many active walsenders, this makes for a very significant  
reduction in the amount of contention on the XLogCtl->info_lck spinlock.  
  
This patch also adjusts the logic so that we update our idea of the  
flush position after processing a WAL record, rather than beforehand.  
This may cause us to realize we're not caught up when the preceding  
coding would've thought that we were, but that seems all to the good;  
it may avoid a useless sleep-and-wakeup cycle.  
  
Back-patch to v12.  The contention problem exists in prior branches,  
but it's much less severe (due to inefficiencies elsewhere) so there  
seems no need to take any risk of back-patching further.  
  
Pierre Ducroquet, reviewed by Julien Rouhaud  
  
Discussion: https://postgr.es/m/2931018.Vxl9zapr77@pierred-pdoc  

commit   : 20d6225d1656102534a73d9675bc531ff0e5203b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jan 2020 12:13:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Jan 2020 12:13:53 -0500    

These allow better control of trailing zeroes in numeric values.  
  
Pavel Stehule, based on an old proposal of Marko Tiikkaja's;  
review by Karl Pinc  
  
Discussion: https://postgr.es/m/CAFj8pRDjs-navGASeF0Wk74N36YGFJ+v=Ok9_knRa7vDc-qugg@mail.gmail.com  

commit   : b9c130a1fdf16cd99afb390c186d19acaea7d132    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Jan 2020 08:21:14 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Jan 2020 08:21:14 +0100    

The logical replication apply worker did not fire per-column update  
triggers because the updatedCols bitmap in the RTE was not populated.  
This fixes that.  
  
Reviewed-by: Euler Taveira <euler@timbira.com.br>  
Discussion: https://www.postgresql.org/message-id/flat/21673e2d-597c-6afe-637e-e8b10425b240%402ndquadrant.com  

commit   : 7b283d0e1d1d79bf1c962d790c94d2a53f3bb38a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Jan 2020 12:51:44 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Jan 2020 12:51:44 +0900    

Support is out of scope from all the major vendors for these versions  
(for example RHEL5 uses a version based on 0.9.8, and RHEL6 uses 1.0.1),  
and it created some extra maintenance work.  Upstream has stopped  
support of 0.9.8 in December 2015 and of 1.0.0 in February 2016.  
  
Since b1abfec, note that the default SSL protocol version set with  
ssl_min_protocol_version is TLSv1.2, whose support was added in OpenSSL  
1.0.1, so there is no point to enforce ssl_min_protocol_version to TLSv1  
in the SSL tests.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson, Tom Lane  
Discussion: https://postgr.es/m/20191205083252.GE5064@paquier.xyz  

commit   : fc3100112395485f1c65848b273b3235de4aad07    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 5 Jan 2020 17:42:13 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 5 Jan 2020 17:42:13 -0800    

The fastpath insert optimization's incomplete split flag Assert() is  
redundant.  We'll reach the more general Assert() within  
_bt_findinsertloc() in all cases. (Besides, Assert()'ing that the  
rightmost page doesn't have the flag set never made much sense.)  

commit   : 8c081a2f4e8eec11747e709c1ea4c3485ef129dd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jan 2020 11:35:45 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Jan 2020 11:35:45 -0500    

Use qr// syntax for regex values.  
Include the regex that failed to match in diagnostic reports.  
  
Dagfinn Ilmari Mannsåker  
  
Discussion: https://postgr.es/m/87k16610xk.fsf@wibble.ilmari.org  

commit   : 955f1213012361e32d88976c3ce03ae62153c355    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 5 Jan 2020 19:45:37 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 5 Jan 2020 19:45:37 +0900    

Per suggestion from Tom Lane.  
Discussion: https://postgr.es/m/flat/20191230.093451.1762483750956466101.t-ishii%40sraoss.co.jp  

commit   : 48e03583cd373ce67827f4d8a99dcef8242364b0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 21:33:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 21:33:34 -0500    

The true explanation for Peter Geoghegan's trouble report turns out  
to be that he has a ~/.inputrc that affects readline's behavior  
enough to break this test.  Prevent readline from reading that file.  
  
Also, the best way to prevent TERM from affecting the results seems  
to be to unset it altogether, not to set it to "xterm".  The latter  
choice licenses readline to emit xterm escape sequences, and there's  
a lot of variation in exactly what it will emit.  
  
Revert changes that attempted to account exactly for xterm escape  
sequences.  We shouldn't need that with TERM unset, and it was not  
looking like a maintainable solution anyway.  
  
Discussion: https://postgr.es/m/23181.1578167938@sss.pgh.pa.us  

commit   : 7e42478186aa8b41a8706f3f53b44e25a427bde9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 16:40:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 16:40:56 -0500    

Right at the moment, this is making things worse not better in the  
buildfarm.  I'm not happy with anything about the current state,  
but let's at least try to have a green buildfarm report while further  
investigation continues.  
  
Discussion: https://postgr.es/m/23181.1578167938@sss.pgh.pa.us  

commit   : 60ab7c80b4de2c3591e50dfb5ed0fd4002f0f2f2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 15:05:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 15:05:24 -0500    

I'm curious to see what values are prevailing in the buildfarm.  
  
Discussion: https://postgr.es/m/23181.1578167938@sss.pgh.pa.us  

commit   : 5b630501e9fa58c5069b36247d63fc460d912c7f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 4 Jan 2020 11:31:42 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 4 Jan 2020 11:31:42 -0800    

It has undefined behavior.  Follow the precedent of commit  
9a9473f3cce1a21c25d6cc7569710e832d2b180b.  No back-patch, since the  
master branch alone has this function.  
  
Discussion: https://postgr.es/m/20191229070221.GA13873@gust.leadboat.com  

commit   : fac1c04feca6d01f2d324088c5899485f55b6217    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 14:29:28 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2020 14:29:28 -0500    

Depending on as-yet-incompletely-explained factors, readline/libedit  
might choose to emit screen-control escape sequences as part of  
repainting the display.  I'd tried to make the test patterns avoid  
matching parts of the output that are likely to contain such, but  
it seems that there's really no way around matching them explicitly  
in some places, unless we want to just give up testing some behaviors  
such as display of alternatives.  
  
Per report from Peter Geoghegan.  
  
Discussion: https://postgr.es/m/CAH2-WznPzfWHu8PQwv1Qjpf4wQVPaaWpoO5NunFz9zsYKB4uJA@mail.gmail.com  

commit   : 3fd40b628c7db4c4bcf03b548f9a55f85e327e25    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 4 Jan 2020 11:56:58 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 4 Jan 2020 11:56:58 +0100    

Pass ParseState into the functions called from  
standard_ProcessUtility() instead passing the query string and query  
environment separately.  No functionality change, but it makes the  
notation consistent.  We had already started moving things into  
that direction piece by piece, and this completes it.  
  
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/6e7aa4a1-be6a-1a75-b1f9-83a678e5184a@2ndquadrant.com  

commit   : d2e5e20e57111cca9e14f6e5a99a186d4c66a5b7    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 3 Jan 2020 12:18:13 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 3 Jan 2020 12:18:13 -0800    

Commit 558a9165e08 taught _bt_delitems_delete() to produce its own XID  
horizon on the primary.  Standbys no longer needed to generate their own  
latestRemovedXid, since they could just use the explicitly logged value  
from the primary instead.  The deleted offset numbers array from the  
xl_btree_delete WAL record was no longer used by the REDO routine for  
anything other than deleting the items.  
  
This enables a minor optimization:  We now treat the array as buffer  
state, not generic WAL data, following _bt_delitems_vacuum()'s example.  
This should be a minor win, since it allows us to avoid including the  
deleted items array in cases where XLogInsert() stores the whole buffer  
anyway.  The primary goal here is to make the code more maintainable,  
though.  Removing inessential differences between the two functions  
highlights the fundamental differences that remain.  
  
Also change xl_btree_delete to use uint32 for the size of the array of  
item offsets being deleted.  This brings xl_btree_delete closer to  
xl_btree_vacuum.  Furthermore, it seems like a good idea to use an  
explicit-width integer type (the field was previously an "int").  
  
Bump XLOG_PAGE_MAGIC because xl_btree_delete changed.  
  
Discussion: https://postgr.es/m/CAH2-Wzkz4TjmezzfAbaV1zYrh=fr0bCpzuJTvBe5iUQ3aUPsCQ@mail.gmail.com  

commit   : 56a3921a2f5102f804bd0ff741e144a0e6f1c0b6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jan 2020 12:54:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jan 2020 12:54:13 -0500    

Escape non-printable characters in failure reports, by using Data::Dumper  
in Useqq mode.  Also, bump $Test::Builder::Level so the diagnostic  
references the calling line, and use diag() instad of note(),  
so it shows even in non-verbose mode (per request from Christoph Berg).  
  
Also, give up on trying to test for the specific way that readline  
chooses to overwrite existing text in the \DRD -> \drds test.  
There are too many variants, it seems, at least on the libedit  
side of things.  
  
Dagfinn Ilmari Mannsåker and Tom Lane  
  
Discussion: https://postgr.es/m/20200103110128.GA28967@msg.df7cb.de  

commit   : ddd87d564508bb1c80aac0a4439cfe74a3c203a9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jan 2020 11:15:26 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Jan 2020 11:15:26 -0500    

Debian unstable is shipping a broken version of libedit: it de-escapes  
words before passing them to the application's tab completion function,  
preventing us from recognizing backslash commands.  Fortunately,  
we have enough information available to dig the original text out of  
rl_line_buffer, so ignore the string argument and do that.  
  
I view this as a temporary workaround to get the affected buildfarm  
members back to green in the wake of 7c015045b.  I hope we can get  
rid of it once somebody fixes Debian's libedit; hence, no back-patch,  
at least for now.  
  
Discussion: https://postgr.es/m/20200103110128.GA28967@msg.df7cb.de  

commit   : 04334fde69132f335d9d70cfefe419bd1276b232    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 3 Jan 2020 10:44:13 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 3 Jan 2020 10:44:13 +0100    

Author: Fabien COELHO <coelho@cri.ensmp.fr>  

commit   : d5b6b6515b35b11c82ce620fa84c989f246068aa    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Jan 2020 10:52:46 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 3 Jan 2020 10:52:46 +0530    

Reported-by: Jon Jensen  
Author: Jon Jensen  
Reviewed-by: Amit Kapila and Robert Haas  
Backpatch-through: 10  
Discussion: https://postgr.es/m/nycvar.YSQ.7.76.1912301807510.9899@ybpnyubfg  

commit   : 0c41c83d8ff44ed8f9753885e2c11b3277babcce    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jan 2020 18:30:25 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jan 2020 18:30:25 -0800    

Adjust a comment that describes how alignment of the new left page high  
key works in btree_xlog_split(), the nbtree page split REDO routine.  
The wording used before commit 2c03216d831 is much clearer, so go back  
to that.  

commit   : 90d7f6604b6ed2dcedee2884c3b01541600515cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 19:44:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 19:44:43 -0500    

Satisfy perlcritic, mostly.  Per buildfarm.  

commit   : 44e44bd258a71162444d41a1044c795f2c6dd3d1    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jan 2020 13:30:40 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jan 2020 13:30:40 -0800    

The expectation within _bt_delitems_vacuum() is that caller has a  
super-exclusive/cleanup buffer lock (not just a pin and a write lock).  

commit   : 1fa846f1c9afe6bb185d4bb60bed8102a8eacb8f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 2 Jan 2020 17:04:24 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 2 Jan 2020 17:04:24 -0300    

When row triggers exist in partitioned partitions that are not either  
part of FKs or deferred unique constraints, they are not correctly  
cloned to their partitions.  That's because they are marked "internal",  
and those are purposefully skipped when doing the clone triggers dance.  
Fix by relaxing the condition on which internal triggers are skipped.  
  
Amit Langote initially diagnosed the problem and proposed a fix, but I  
used a different approach.  
  
Reported-by: Petr Fedorov  
Discussion: https://postgr.es/m/6b3f0646-ba8c-b3a9-c62d-1c6651a1920f@phystech.edu  

commit   : 7c015045b9141cc30272930ea88cfa5df47240b7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 15:02:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 15:02:21 -0500    

Up to now, psql's tab-complete.c has had exactly no regression test  
coverage.  This patch is an experimental attempt to add some.  
  
This needs Perl's IO::Pty module, which isn't installed everywhere,  
so the test script just skips all tests if that's not present.  
There may be other portability gotchas too, so I await buildfarm  
results with interest.  
  
So far this just covers a few very basic keyword-completion and  
query-driven-completion scenarios, which should be enough to let us  
get a feel for whether this is practical at all from a portability  
standpoint.  If it is, there's lots more that can be done.  
  
Discussion: https://postgr.es/m/10967.1577562752@sss.pgh.pa.us  

commit   : 915c04f091f13dbbc0fde833e612dc90b70103ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 14:02:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 14:02:46 -0500    

On further reflection about commit 4d02eb017, it occurs to me that  
expandRTE() had better agree with what addRangeTableEntryForFunction()  
is doing.  So teach that about functions possibly having typmods, too.  

commit   : a412f469880ede9f52336a7b383905129c2b03a0    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jan 2020 10:57:15 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 2 Jan 2020 10:57:15 -0800    

Make the function prototype order consistent with the definition order  
in nbtpage.c.  

commit   : 4d02eb017e3c1268762fd1a10ec3c569515c047d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 13:48:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 13:48:54 -0500    

One code path in addRangeTableEntryForFunction() neglected to assign  
a collation to the tupdesc entry it constructs (which is a bit odd  
considering the other path did do so).  This didn't matter before commit  
5815696bc, because nothing would look at the type data in this tupdesc;  
but now it does.  
  
While at it, make sure we assign the correct typmod as well.  Most  
function expressions don't have a determinate typmod, but some do.  
  
Per buildfarm, which showed failures in non-C collations, a case  
I'd not thought to test for this patch :-(  

commit   : 5815696bc66b3092f6361f53e0394909647042c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 11:29:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Jan 2020 11:29:01 -0500    

When I added the ParseNamespaceItem data structure (in commit 5ebaaa494),  
it wasn't very tightly integrated into the parser's APIs.  In the wake of  
adding p_rtindex to that struct (commit b541e9acc), there is a good reason  
to make more use of it: by passing around ParseNamespaceItem pointers  
instead of bare RTE pointers, we can get rid of various messy methods for  
passing back or deducing the rangetable index of an RTE during parsing.  
Hence, refactor the addRangeTableEntryXXX functions to build and return  
a ParseNamespaceItem struct, not just the RTE proper; and replace  
addRTEtoQuery with addNSItemToQuery, which is passed a ParseNamespaceItem  
rather than building one internally.  
  
Also, add per-column data (a ParseNamespaceColumn array) to each  
ParseNamespaceItem.  These arrays are built during addRangeTableEntryXXX,  
where we have column type data at hand so that it's nearly free to fill  
the data structure.  Later, when we need to build Vars referencing RTEs,  
we can use the ParseNamespaceColumn info to avoid the rather expensive  
operations done in get_rte_attribute_type() or expandRTE().  
get_rte_attribute_type() is indeed dead code now, so I've removed it.  
This makes for a useful improvement in parse analysis speed, around 20%  
in one moderately-complex test query.  
  
The ParseNamespaceColumn structs also include Var identity information  
(varno/varattno).  That info isn't actually being used in this patch,  
except that p_varno == 0 is a handy test for a dropped column.  
A follow-on patch will make more use of it.  
  
Discussion: https://postgr.es/m/2461.1577764221@sss.pgh.pa.us  

commit   : 198c7153dccb11950e3030dec564fdc6e59b4451    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 2 Jan 2020 14:40:18 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 2 Jan 2020 14:40:18 +0100    

The comment was apparently copy-and-pasted and did not reflect the  
actual test outcome.  

commit   : d207038053837ae9365df2776371632387f6f655    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 14 Dec 2019 11:41:37 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 14 Dec 2019 11:41:37 +0530    

Currently while decoding changes, if the number of changes exceeds a  
certain threshold, we spill those to disk.  And this happens for each  
(sub)transaction.  Now, while reading all these files, we don't close them  
until we read all the files.  While reading these files, if the number of  
such files exceeds the maximum number of file descriptors, the operation  
errors out.  
  
Use PathNameOpenFile interface to open these files as that internally has  
the mechanism to release kernel FDs as needed to get us under the  
max_safe_fds limit.  
  
Reported-by: Amit Khandekar  
Author: Amit Khandekar  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/CAJ3gD9c-sECEn79zXw4yBnBdOttacoE-6gAyP0oy60nfs_sabQ@mail.gmail.com  

commit   : 4b25f5d0ba0197af80e3af0de7441ca9c88c1e24    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 1 Jan 2020 17:29:41 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 1 Jan 2020 17:29:41 -0800    

_bt_delitems_vacuum() comments claimed that it isn't worth another scan  
of the page to avoid falsely unsetting the BTP_HAS_GARBAGE page flag  
hint (this happens to be the same wording that was removed from  
_bt_delitems_delete() by my recent commit fe97c61c).  The comments made  
little sense, though.  The issue can't have much to do with performing a  
second scan of the target leaf page, since an LP_DEAD test could easily  
be performed in the first scan of the page anyway (the scan that takes  
place in btvacuumpage() caller).  
  
Revise the explanation.  It makes much more sense to frame this as an  
issue about recovery conflicts.  _bt_delitems_vacuum() cannot easily  
generate an XID cutoff in the same way that _bt_delitems_delete() is  
designed to.  
  
Falsely unsetting the page flag is not ideal, and is likely to happen  
more often than was supposed by the original comments.  Explain why it  
usually isn't a problem in practice.  There may be an argument for  
_bt_delitems_vacuum() not clearing the BTP_HAS_GARBAGE bit, removing the  
question of it being falsely unset by VACUUM (there may even be an  
argument for not using a page level hint at all).  This can be revisited  
later.  

commit   : 823e739d4a7257cf0ca58fc6eff3c4cec308fccf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Jan 2020 19:31:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Jan 2020 19:31:41 -0500    

If we have, say, an int column that is left-joined to a bigint column  
with USING, the merged column is the int column promoted to bigint.  
GROUP BY's tests for whether grouping on the merged column allows a  
reference to the underlying column, or vice versa, should know about  
that relationship --- and they do.  But I nearly broke this case with  
an ill-advised optimization, so the lack of any test coverage for it  
seems like a bad idea.  

commit   : c5f3b53b0ef2e8ae78e7488148c12bfe5939ca17    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 1 Jan 2020 11:32:07 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 1 Jan 2020 11:32:07 -0800    

Commit fe97c61c updated LP_DEAD item deletion comments, but missed a  
minor discrepancy on the REDO side.  Fix it now.  
  
In passing, don't talk about the btree_xlog_vacuum() behavior within  
btree_xlog_delete().  The reliance on XLOG_HEAP2_CLEANUP_INFO records  
for recovery conflicts is already discussed within btvacuumpage() and  
mentioned again in passing above btree_xlog_vacuum(), which seems  
sufficient.  

commit   : 7559d8ebfa11d98728e816f6b655582ce41150f3    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 1 Jan 2020 12:21:45 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 1 Jan 2020 12:21:45 -0500    

Backpatch-through: update all files in master, backpatch legal files through 9.4  

commit   : b55413d77f96b9fa2dfae4ddec43412b90ebf588    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 31 Dec 2019 10:35:16 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 31 Dec 2019 10:35:16 +0100    

Change the exception syntax used in the documentation to use the more  
current  
  
    except Exception as ex:  
  
rather than the old  
  
    except Exception, ex:  
  
We keep the old syntax in the test code since Python <2.6 is still  
supported there, but the documentation might as well use the modern  
syntax.  

commit   : 0ce38730ac72029f3f2c95ae80b44f5b9060cbcc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Dec 2019 17:21:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Dec 2019 17:21:17 -0500    

Use __builtin_clz() where available.  Where it isn't, we can still win  
a little by using the pg_leftmost_one_pos[] lookup table instead of  
having a private table.  
  
Also drop the initial right shift by ALLOC_MINBITS in favor of  
subtracting ALLOC_MINBITS from the leftmost-one-pos result.  This  
is a win because the compiler can fold that adjustment into other  
constants it'd have to add anyway, making the shift-removal free.  
  
Also, we can explain this coding as an unrolled form of  
pg_leftmost_one_pos32(), even though that's a bit ahistorical  
since it long predates pg_bitutils.h.  
  
John Naylor, with some cosmetic adjustments by me  
  
Discussion: https://postgr.es/m/CACPNZCuNUGMxjK7WTn_=WZnRbfASDdBxmjsVf2+m9MdmeNw_sg@mail.gmail.com  

commit   : 27a3b2ad836c9e7dd243bfebc760a9df9d6fd5a3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Dec 2019 18:34:30 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Dec 2019 18:34:30 -0300    

This currently works, but add this test to ensure it continues to work.  
Lack of this test became evident after a recent bugfix submission that  
would have inadvertently broken it, in  
https://postgr.es/m/CA+HiwqFM2=i+uHB9o4OkLbE2S3sjPHoVe2wXuAD1GLJ4+Pk9eg@mail.gmail.com  

commit   : a9760d0f3cb523336b5fdd9d6c5985e39a8588a1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 27 Dec 2019 14:49:08 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 27 Dec 2019 14:49:08 -0500    

Unique expression indexes can constrain data in creative ways, so show  
two examples.  
  
Reported-by: Tuomas Leikola  
  
Discussion: https://postgr.es/m/156760275564.1127.12321702656456074572@wrigleys.postgresql.org  
  
Backpatch-through: 9.4  

commit   : 650692a18d29c44c8019545c02ba42c3efd2c964    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 27 Dec 2019 14:33:30 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 27 Dec 2019 14:33:30 -0500    

The previous docs referenced these distinct ideas confusingly.  
  
Reported-by: Eugen Konkov  
  
Discussion: https://postgr.es/m/376945611.20191026161529@yandex.ru  
  
Backpatch-through: 9.4  

commit   : a052f6cbb84e5630d50b68586cecc127e64be639    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Dec 2019 17:58:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Dec 2019 17:58:43 +0900    

This operation was possible for the owner of the schema or a superuser.  
Down to 9.4, doing this operation would cause inconsistencies in a  
session whose temporary schema was dropped, particularly if trying to  
create new temporary objects after the drop.  A more annoying  
consequence is a crash of autovacuum on an assertion failure when  
logging information about an orphaned temp table dropped.  Note that  
because of 246a6c8 (present in v11~), which has made the removal of  
orphaned temporary tables more aggressive, the failure could be  
triggered more easily, but it is possible to reproduce down to 9.4.  
  
Reported-by: Mahendra Singh, Prabhat Sahu  
Author: Michael Paquier  
Reviewed-by: Kyotaro Horiguchi, Mahendra Singh  
Discussion: https://postgr.es/m/CAKYtNAr9Zq=1-ww4etHo-VCC-k120YxZy5OS01VkaLPaDbv2tg@mail.gmail.com  
Backpatch-through: 9.4  

commit   : 7854e07f25be3a3dfa9c94011a30767eca3c10ba    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Dec 2019 08:09:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Dec 2019 08:09:00 +0900    

This follows multiple complains from Peter Geoghegan, Andres Freund and  
Alvaro Herrera that this issue ought to be dug more before actually  
happening, if it happens.  
  
Discussion: https://postgr.es/m/20191226144606.GA5659@alvherre.pgsql  

commit   : 4ba4bfaf256c17fe4c8f497924b74eb98241b84f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Dec 2019 15:19:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Dec 2019 15:19:39 -0500    

When revalidate_rectypeid() acts to update a stale record type OID  
in plpgsql's data structures, it fixes the active PLpgSQL_rec struct  
as well as the PLpgSQL_type struct it references.  However, the latter  
is shared across function executions while the former is not.  In a  
later function execution, the PLpgSQL_rec struct would be reinitialized  
by copy_plpgsql_datums and would then contain a stale type OID,  
typically leading to "could not open relation with OID NNNN" errors.  
revalidate_rectypeid() can easily fix this, fortunately, just by  
treating typ->typoid as authoritative.  
  
Per report and diagnosis from Ashutosh Sharma, though this is not his  
suggested fix.  Back-patch to v11 where this code came in.  
  
Discussion: https://postgr.es/m/CAE9k0Pkd4dZwt9J5pS9xhJFWpUtqs05C9xk_GEwPzYdV=GxwWg@mail.gmail.com  

commit   : fbe0232358c14792e1b94b902d0f7a9b55154275    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Dec 2019 11:20:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Dec 2019 11:20:05 -0500    

Mark the fields that should be accessed via partitioning-related  
functions, as we already did for some other fields.  
  
Amit Langote  
  
Discussion: https://postgr.es/m/CA+HiwqFnK6LbVMACMCaqwWrvoSFTecZzufKRahg2qGvLPYMX=g@mail.gmail.com  

commit   : b541e9accb28c90656388a3f827ca3a68dd2a308    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Dec 2019 11:16:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Dec 2019 11:16:42 -0500    

Instead of passing around a pointer to the RangeTblEntry that  
provides the desired column, pass a pointer to the associated  
ParseNamespaceItem.  The RTE is trivially reachable from the nsitem,  
and having the ParseNamespaceItem allows access to additional  
information.  As proof of concept for that, add the rangetable index  
to ParseNamespaceItem, and use that to get rid of RTERangeTablePosn  
searches.  
  
(I have in mind to teach the parser to generate some different  
representation for Vars that are nullable by outer joins, and  
keeping the necessary information in ParseNamespaceItems seems  
like a reasonable approach to that.  But whether that ever  
happens or not, this seems like good cleanup.)  
  
Also refactor the code around scanRTEForColumn so that the  
"fuzzy match" stuff does not leak out of parse_relation.c.  
  
Discussion: https://postgr.es/m/26144.1576858373@sss.pgh.pa.us  

commit   : 044b319cd77c589507291f9591994093ad30931d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 26 Dec 2019 22:26:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 26 Dec 2019 22:26:09 +0900    

confirmed_flush is part of a replication slot's information, but not  
confirmed_lsn.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20191226.175919.17237335658671970.horikyota.ntt@gmail.com  
Backpatch-through: 11  

commit   : 1ab41a3c8edcf5d7751e61d6ab83bf43b494668b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 26 Dec 2019 17:01:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 26 Dec 2019 17:01:23 +0900    

The part in charge of doing the vacuum on all the indexes of a relation  
was duplicated, with the same handling for progress reporting done.  
While on it, update the progress reporting for heap vacuuming in the  
subroutine doing the actual work, keeping the status update local.  This  
way, any future caller of lazy_vacuum_heap() does not have to worry  
about doing any progress reporting update.  
  
Author: Justin Pryzby, Michael Paquier  
Discussion: https://postgr.es/m/20191120210600.GC30362@telsasoft.com  

commit   : 1ab029d528dcb409fb371d5ad826a67ec78b2b4e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Dec 2019 15:07:43 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 26 Dec 2019 15:07:43 +0900    

Column defaults may be specified separately for each partition.  
But INSERT via a partitioned table ignores those partition's default values.  
The former is documented, but the latter restriction not.  
This commit adds the note about that restriction into the document.  
  
Author: Fujii Masao  
Reviewed-by: Amit Langote  
Discussion: https://postgr.es/m/CAHGQGwEs-59omrfGF7hOHz9iMME3RbKy5ny+iftDx3LHTEn9sA@mail.gmail.com  

commit   : bb4114a4e2c65f27931cc074214c051dba2876c3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Dec 2019 15:44:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Dec 2019 15:44:15 -0500    

In the wake of commit 5b9312378, there's no particular reason  
for this restriction (previously, it was problematic because of  
the implied rowtype reference).  A simple constraint on a whole-row  
Var probably isn't that useful, but conceivably somebody would want  
to pass one to a function that extracts a partitioning key.  Besides  
which, we're expending much more code to enforce the restriction than  
we save by having it, since the latter quantity is now zero.  
So drop the restriction.  
  
Amit Langote  
  
Discussion: https://postgr.es/m/CA+HiwqFUzjfj9HEsJtYWcr1SgQ_=iCAvQ=O2Sx6aQxoDu4OiHw@mail.gmail.com  

commit   : 42f74f49367bee1d3da28c4b383faec29364f320    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Dec 2019 14:45:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Dec 2019 14:45:57 -0500    

This is dead code in the wake of the previous commit.  
We can always add it back if we need it again someday.  
  
Discussion: https://postgr.es/m/CA+HiwqFUzjfj9HEsJtYWcr1SgQ_=iCAvQ=O2Sx6aQxoDu4OiHw@mail.gmail.com  

commit   : 5b9312378e2f8fb35ef4584aea351c3319a10422    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Dec 2019 14:43:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Dec 2019 14:43:13 -0500    

Formerly the rd_partkey and rd_partdesc data structures were always  
populated immediately when a relcache entry was built or rebuilt.  
This patch changes things so that they are populated only when they  
are first requested.  (Hence, callers *must* now always use  
RelationGetPartitionKey or RelationGetPartitionDesc; just fetching  
the pointer directly is no longer acceptable.)  
  
This seems to have some performance benefits, but the main reason to do  
it is that it eliminates a recursive-reload failure that occurs if the  
partkey or partdesc expressions contain any references to the relation's  
rowtype (as discovered by Amit Langote).  In retrospect, since loading  
these data structures might result in execution of nearly-arbitrary code  
via eval_const_expressions, it was a dumb idea to require that to happen  
during relcache entry rebuild.  
  
Also, fix things so that old copies of a relcache partition descriptor  
will be dropped when the cache entry's refcount goes to zero.  In the  
previous coding it was possible for such copies to survive for the  
lifetime of the session, as I'd complained of in a previous discussion.  
(This management technique still isn't perfect, but it's better than  
before.)  Improve the commentary explaining how that works and why  
it's safe to hand out direct pointers to these relcache substructures.  
  
In passing, improve RelationBuildPartitionDesc by using the same  
memory-context-parent-swap approach used by RelationBuildPartitionKey,  
thereby making it less dependent on strong assumptions about what  
partition_bounds_copy does.  Avoid doing get_rel_relkind in the  
critical section, too.  
  
Patch by Amit Langote and Tom Lane; Robert Haas deserves some credit  
for prior work in the area, too.  Although this is a pre-existing  
problem, no back-patch: the patch seems too invasive to be safe to  
back-patch, and the bug it fixes is a corner case that seems  
relatively unlikely to cause problems in the field.  
  
Discussion: https://postgr.es/m/CA+HiwqFUzjfj9HEsJtYWcr1SgQ_=iCAvQ=O2Sx6aQxoDu4OiHw@mail.gmail.com  
Discussion: https://postgr.es/m/CA+TgmoY3bRmGB6-DUnoVy5fJoreiBJ43rwMrQRCdPXuKt4Ykaw@mail.gmail.com  

commit   : 8ce3aa9b5914d1ac45ed3f9bc484f66b3c4850c7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Dec 2019 10:23:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Dec 2019 10:23:39 +0900    

The following renaming is done so as source files related to index  
access methods are more consistent with table access methods (the  
original names used for index AMs ware too generic, and could be  
confused as including features related to table AMs):  
- amapi.h -> indexam.h.  
- amapi.c -> indexamapi.c.  Here we have an equivalent with  
backend/access/table/tableamapi.c.  
- amvalidate.c -> indexamvalidate.c.  
- amvalidate.h -> indexamvalidate.h.  
- genam.c -> indexgenam.c.  
- genam.h -> indexgenam.h.  
  
This has been discussed during the development of v12 when table AM was  
worked on, but the renaming never happened.  
  
Author: Michael Paquier  
Reviewed-by: Fabien Coelho, Julien Rouhaud  
Discussion: https://postgr.es/m/20191223053434.GF34339@paquier.xyz  

commit   : c4dcd9144ba64946c9f9466748bdb2c51719c8a3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 24 Dec 2019 12:37:13 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 24 Dec 2019 12:37:13 -0300    

Using \ is unnecessary and ugly, so remove that.  While at it, stitch  
the literals back into a single line: we've long discouraged splitting  
error message literals even when they go past the 80 chars line limit,  
to improve greppability.  
  
Leave contrib/tablefunc alone.  
  
Discussion: https://postgr.es/m/20191223195156.GA12271@alvherre.pgsql  

commit   : cce64a51cabc1e59d202d95bb0b92ed22bac73cf    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 24 Dec 2019 12:14:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 24 Dec 2019 12:14:08 +0900    

Since d6c55de1, src/port/snprintf.c is able to use %m instead of  
strerror().  A couple of utilities in src/bin/ have already done the  
switch, and do it now for pg_waldump as this reduces the workload for  
translators.  
  
Note that more could be done, particularly with pgbench.  Thanks to  
Kyotaro Horiguchi for the discussion.  
  
Discussion: https://postgr.es/m/20191129065115.GM2505@paquier.xyz  

commit   : e69d644547785cc9f079650d29118a3688bc5039    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 24 Dec 2019 11:31:24 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 24 Dec 2019 11:31:24 +1300    

Our algorithm for choosing batch numbers turned out not to work  
effectively for multi-billion key inner relations.  We would use  
more hash bits than we have, and effectively concentrate all tuples  
into a smaller number of batches than we intended.  While ideally  
we should switch to wider hashes, for now, change the algorithm to  
one that effectively gives up bits from the bucket number when we  
don't have enough bits.  That means we'll finish up with longer  
bucket chains than would be ideal, but that's better than having  
batches that don't fit in work_mem and can't be divided.  
  
Batch-patch to all supported releases.  
  
Author: Thomas Munro  
Reviewed-by: Tom Lane, thanks also to Tomas Vondra, Alvaro Herrera, Andres Freund for testing and discussion  
Reported-by: James Coleman  
Discussion: https://postgr.es/m/16104-dc11ed911f1ab9df%40postgresql.org  

commit   : d5b9c2baff662aac22cd2a497d5bcd3b5a916fd0    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Mon, 23 Dec 2019 13:33:25 -0500    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Mon, 23 Dec 2019 13:33:25 -0500    

While building a hash map of categories in load_categories_hash,  
resulting category names have not thus far been checked to ensure  
they are not null. Prior to pg12 null category names worked to the  
extent that they did not crash on some platforms. This is because  
those system libraries have an snprintf which can deal with being  
passed a null pointer argument for a string. But even in those cases  
null categories did nothing useful. And on some platforms it crashed.  
As of pg12, our own version of snprintf gets called, and it does  
not deal with null pointer arguments at all, and crashes consistently.  
  
Fix that by disallowing null categories. They never worked usefully,  
and no one has ever asked for them to work previously. Back-patch to  
all supported branches.  
  
Reported-By: Ireneusz Pluta  
Discussion: https://postgr.es/m/16176-7489719b05e4303c@postgresql.org  

commit   : 39ebb943de9dd64e305d17329b8989e3061d03a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Dec 2019 12:53:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Dec 2019 12:53:12 -0500    

This wasn't checked originally, but it should have been, because  
in general pseudo-types can't be stored to and retrieved from disk.  
Notably, partition bound values of type "record" would not be  
interpretable by another session.  
  
In v12 and HEAD, add another flag to CheckAttributeType's repertoire  
so that it can produce a specific error message for this case.  That's  
infeasible in older branches without an ABI break, so fall back to  
a slightly-less-nicely-worded error message in v10 and v11.  
  
Problem noted by Amit Langote, though this patch is not his initial  
solution.  Back-patch to v10 where partitioning was introduced.  
  
Discussion: https://postgr.es/m/CA+HiwqFUzjfj9HEsJtYWcr1SgQ_=iCAvQ=O2Sx6aQxoDu4OiHw@mail.gmail.com  

commit   : fc7695891d357a54f0258142de85f88520796b9b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Dec 2019 12:08:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Dec 2019 12:08:23 -0500    

We probably should have thought of this case when ranges were added,  
but we didn't.  (It's not the fault of commit eb51af71f, because  
ranges didn't exist then.)  
  
It's an old bug, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/7782.1577051475@sss.pgh.pa.us  

commit   : 0fd8cfb20d2d41d4c2df021a5f355965fd8d21bc    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 23 Dec 2019 12:47:36 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 23 Dec 2019 12:47:36 -0300    

Use get_publication_oid() instead of reimplementing it.  
  
Discussion: https://postgr.es/m/20191220201017.GA17292@alvherre.pgsql  

commit   : 696cc3a0cabd5f11d0c8a187b7561f6d0d39c5e0    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 22 Dec 2019 20:07:45 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 22 Dec 2019 20:07:45 -0800    

Make a function prototype argument's name match the function  
definition's argument name.  

commit   : fe97c61c8777858cc1a271e657a7d812e100ef00    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 22 Dec 2019 19:57:35 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sun, 22 Dec 2019 19:57:35 -0800    

Comments about the consequences of clearing the BTP_HAS_GARBAGE page  
flag bit that apply only to VACUUM were added to code that deals with  
opportunistic deletion of LP_DEAD items by commit a760893d.  The same  
comment block was added to both _bt_delitems_vacuum() and  
_bt_delitems_delete().  Correct _bt_delitems_delete()'s copy of the  
comment block.  
  
_bt_delitems_delete() reliably deletes items that were found by caller  
to have their LP_DEAD bit set.  There is no question about whether or  
not unsetting the BTP_HAS_GARBAGE bit can miss some LP_DEAD items that  
were set recently.  
  
Also tweak a related section of the nbtree README.  

commit   : b265aa1f39b672d263e37bdb715516d32128d0c4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Dec 2019 18:00:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Dec 2019 18:00:17 -0500    

If the first transaction block in these tests were entered exactly  
at midnight (California time), they'd report a bogus failure due  
to 'now' and 'midnight' having the same values.  Commit 8c2ac75c5  
had dismissed this as being of negligible probability, but we've  
now seen it happen in the buildfarm, so let's prevent it.  We can  
get pretty much the same test coverage without an it's-not-midnight  
assumption by moving the does-'now'-work cases into their own test step.  
  
While here, apply commit 47169c255's s/DELETE/TRUNCATE/ change to  
timestamptz as well as timestamp (not sure why that didn't  
occur to me at the time; the risk of failure is the same).  
  
Back-patch to all supported branches, since the main point is  
to get rid of potential buildfarm failures.  
  
Discussion: https://postgr.es/m/14821.1577031117@sss.pgh.pa.us  

commit   : 127ccb37251744c0fad2df0f3f67dd2c38fe8389    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 22 Dec 2019 23:20:00 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 22 Dec 2019 23:20:00 +0100    

_GNU_SOURCE is required to get the prototype, so just define that  
globally, as was already done in the linux template.  
  
Discussion: https://www.postgresql.org/message-id/flat/6b467edc-4018-521f-ab18-171f098557ca%402ndquadrant.com  

commit   : 5406513e997f5ee9de79d4076ae91c04af0c52f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Dec 2019 17:39:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Dec 2019 17:39:36 -0500    

This fixes a performance problem introduced by commit 6d7547c21.  
ERROR_ACCESS_DENIED is returned in some other cases besides the  
delete-pending case considered by that commit; notably, if the  
given path names a directory instead of a plain file.  In that  
case we'll uselessly loop for 1 second before returning the  
failure condition.  That slows down some usage scenarios enough  
to cause test timeout failures on our Windows buildfarm critters.  
  
To fix, try to stat() the file, and sleep/loop only if that fails.  
It will fail in the delete-pending case, and also in the case where  
the deletion completed before we could stat(), so we have the cases  
where we want to loop covered.  In the directory case, the stat()  
should succeed, letting us exit without a wait.  
  
One case where we'll still wait uselessly is if the access-denied  
problem pertains to a directory in the given pathname.  But we don't  
expect that to happen in any performance-critical code path.  
  
There might be room to refine this further, but I'll push it now  
in hopes of making the buildfarm green again.  
  
Back-patch, like the preceding commit.  
  
Alexander Lakhin and Tom Lane  
  
Discussion: https://postgr.es/m/23073.1576626626@sss.pgh.pa.us  

commit   : 4376fdbae11de9333012a31ba8d3a4f4b5d7a692    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 21 Dec 2019 17:02:38 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 21 Dec 2019 17:02:38 -0500    

Document why no indentation and why no non-whitespace postfix is  
supported.  
  
Backpatch-through: master  

commit   : 4cab43ec806a6298a545a399415ee8c4fe9307a8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sat, 21 Dec 2019 12:44:38 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sat, 21 Dec 2019 12:44:38 -0500    

Previously it was unclear how COPY FROM handled cases where not all  
columns were specified, or if the order didn't match.  
  
Reported-by: pavlo.golub@gmail.com  
  
Discussion: https://postgr.es/m/157487729344.7213.14245726713444755296@wrigleys.postgresql.org  
  
Backpatch-through: 9.4  

commit   : 0af0504da91e5e15f0b203309a1e49a4829dac64    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Dec 2019 15:45:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Dec 2019 15:45:37 -0500    

Per project policy, transient roles created by regression test cases  
should be named "regress_something", to reduce the risks of running  
such cases against installed servers.  And no such role should ever  
be left behind after running a test.  
  
Discussion: https://postgr.es/m/11297.1576868677@sss.pgh.pa.us  

commit   : e60b480d39ee3401727a994988dd9117a3b48466    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Dec 2019 15:34:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Dec 2019 15:34:07 -0500    

We realized years ago that it's better for libpq to accept all  
connection parameters syntactically, even if some are ignored or  
restricted due to lack of the feature in a particular build.  
However, that lesson from the SSL support was for some reason never  
applied to the GSSAPI support.  This is causing various buildfarm  
members to have problems with a test case added by commit 6136e94dc,  
and it's just a bad idea from a user-experience standpoint anyway,  
so fix it.  
  
While at it, fix some places where parameter-related infrastructure  
was added with the aid of a dartboard, or perhaps with the aid of  
the anti-pattern "add new stuff at the end".  It should be safe  
to rearrange the contents of struct pg_conn even in released  
branches, since that's private to libpq (and we'd have to move  
some fields in some builds to fix this, anyway).  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/11297.1576868677@sss.pgh.pa.us  

commit   : 77f416af6e821b40649c971ded43089e0450791a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 20 Dec 2019 12:26:01 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 20 Dec 2019 12:26:01 +0100    

Most of the MSVC Perl code uses forward slashes for file paths.  Make  
the few places that use backslashes the same.  This also helps running  
that code on non-Windows.  

commit   : 8f4fb4c648ee8df00f78bee3f8099a6ae510071a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 20 Dec 2019 08:54:42 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 20 Dec 2019 08:54:42 +0100    

Previously, the Windows MSVC build generated pg_config.h from a  
hard-coded pg_config.h.win32 with some ad hoc postprocessing.  The  
pg_config.h.win32 file required manual maintenance and was as a result  
frequently out of date.  
  
Instead, have the MSVC build scripts emulate what configure and  
config.status do: collect a list of defines and then create  
pg_config.h from pg_config.h.in by changing the appropriate lines.  
  
The previous setup was made to support old Windows build systems that  
didn't have any text processing capabilities, but the current system  
has Perl, so it's not a problem.  pg_config.h.win32 is removed.  
  
In order to try to keep the Windows side of things more up to date in  
the future, we now also require that all symbols found in  
pg_config.h.in are defined in the MSVC build system.  So if there is a  
change in configure that results in a new symbol, an update in  
Solution.pm will be required.  
  
The other headers managed by AC_CONFIG_HEADERS in configure, namely  
src/include/pg_config_ext.h and  
src/interfaces/ecpg/include/ecpg_config.h, get the same treatment, so  
this removes even more ad hoc code in the MSVC build scripts.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/1441b834-f434-e0bf-46ed-9c4d5c29c2d4%402ndquadrant.com  

commit   : df7fe9e2d707da69a4437fb6f9e695c070882160    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 20 Dec 2019 08:25:43 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 20 Dec 2019 08:25:43 +0100    

This was previously not covered by allow_system_table_mods, but now it  
is.  The impact in practice is probably low, but this makes it  
consistent with most other DDL commands.  
  
Reviewed-by: Robert Haas <robertmhaas@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/ee9df1af-c0d8-7c82-5be7-39ce4e3b0a9d%402ndquadrant.com  

commit   : 8c6d30f211390df911072d33f0114a31f066a4cd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 20 Dec 2019 08:04:24 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 20 Dec 2019 08:04:24 +0100    

The PS_USE_NONE case in ps_status.c left a couple of unused variables  
exposed.  
  
Discussion: https://www.postgresql.org/message-id/flat/6b467edc-4018-521f-ab18-171f098557ca%402ndquadrant.com  

commit   : 6136e94dcb88c50b6156aa646746565400e373d4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 20 Dec 2019 16:23:34 +1030    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 20 Dec 2019 16:23:34 +1030    

Currently postgres_fdw doesn't permit a non-superuser to connect to a  
foreign server without specifying a password, or to use an  
authentication mechanism that doesn't use the password. This is to avoid  
using the settings and identity of the user running Postgres.  
  
However, this doesn't make sense for all authentication methods. We  
therefore allow a superuser to set "password_required 'false'" for user  
mappings for the postgres_fdw. The superuser must ensure that the  
foreign server won't try to rely solely on the server identity (e.g.  
trust, peer, ident) or use an authentication mechanism that relies on the  
password settings (e.g. md5, scram-sha-256).  
  
This feature is a prelude to better support for sslcert and sslkey  
settings in user mappings.  
  
Author: Craig Ringer.  
Discussion: https://postgr.es/m/075135da-545c-f958-fed0-5dcb462d6dae@2ndQuadrant.com  

commit   : 16a4e4aecd47da7a6c4e1ebc20f6dd1a13f9133b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 19 Dec 2019 14:56:20 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 19 Dec 2019 14:56:20 -0500    

A new function EmitProcSignalBarrier() can be used to emit a global  
barrier which all backends that participate in the ProcSignal  
mechanism must absorb, and a new function WaitForProcSignalBarrier()  
can be used to wait until all relevant backends have in fact  
absorbed the barrier.  
  
This can be used to coordinate global state changes, such as turning  
checksums on while the system is running.  
  
There's no real client of this mechanism yet, although two are  
proposed, but an enum has to have at least one element, so this  
includes a placeholder type (PROCSIGNAL_BARRIER_PLACEHOLDER) which  
should be replaced by the first real client of this mechanism to  
get committed.  
  
Andres Freund and Robert Haas, reviewed by Daniel Gustafsson and,  
in earlier versions, by Magnus Hagander.  
  
Discussion: http://postgr.es/m/CA+TgmoZwDk=BguVDVa+qdA6SBKef=PKbaKDQALTC_9qoz1mJqg@mail.gmail.com  

commit   : 9f83468b3536caf6fb7fe8f9dcdbb108a98d1257    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 19 Dec 2019 11:35:55 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 19 Dec 2019 11:35:55 -0800    

The REDO routine for nbtree's xl_btree_vacuum record type hasn't  
performed a "pin scan" since commit 3e4b7d87 went in, so clearly there  
isn't any point in VACUUM WAL-logging information that won't actually be  
used.  Finish off the work of commit 3e4b7d87 (and the closely related  
preceding commit 687f2cd7) by removing the code that generates this  
unused information.  Also remove the REDO routine code disabled by  
commit 3e4b7d87.  
  
Replace the unneeded lastBlockVacuumed field in xl_btree_vacuum with a  
new "ndeleted" field.  The new field isn't actually needed right now,  
since we could continue to infer the array length from the overall  
record length.  However, an upcoming patch to add deduplication to  
nbtree needs to add an "items updated" field to xl_btree_vacuum, so we  
might as well start being explicit about the number of items now.  
(Besides, it doesn't seem like a good idea to leave the xl_btree_vacuum  
struct without any fields; the C standard says that that's undefined.)  
  
nbtree VACUUM no longer forces writing a WAL record for the last block  
in the index.  Writing out a WAL record with no items for the final  
block was supposed to force processing of a lastBlockVacuumed field by a  
pin scan.  
  
Bump XLOG_PAGE_MAGIC because xl_btree_vacuum changed.  
  
Discussion: https://postgr.es/m/CAH2-WzmY_mT7UnTzFB5LBQDBkKpdV5UxP3B5bLb7uP%3D%3D6UQJRQ%40mail.gmail.com  

commit   : b93e9a5c94b4c89932a637798bd560971fe790d7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 19 Dec 2019 11:19:10 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 19 Dec 2019 11:19:10 -0500    

Reverts commit 05684c8255.  
  
Reported-by: Tom Lane  
  
Discussion: https://postgr.es/m/404.1576770942@sss.pgh.pa.us  
  
Backpatch-through: master  

commit   : 05684c8255af57258386c00354c61155ec519707    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 19 Dec 2019 10:33:48 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 19 Dec 2019 10:33:48 -0500    

Reported-by: Ranier Vilela  
  
Discussion: https://postgr.es/m/MN2PR18MB2927BB876D12A70FDBE8F35AE3450@MN2PR18MB2927.namprd18.prod.outlook.com  
  
Backpatch-through: master  

commit   : 2b93e3d96b941740877b2ae196511564e5cc989b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 19 Dec 2019 12:08:30 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 19 Dec 2019 12:08:30 -0300    

Discussion: https://postgr.es/m/20191218221326.GA25537@alvherre.pgsql  

commit   : 54fbd155cc6fdbf875185035b3d9823f739b617d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Dec 2019 09:42:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Dec 2019 09:42:39 -0500    

The "auth-methods" <sect1> used to include descriptions of all our  
authentication methods.  Commit 56811e573 promoted its child <sect2>'s  
to <sect1>'s, which has advantages but also created some issues:  
* The auth-methods page itself is essentially empty/useless.  
* Links that pointed to "auth-methods" as a placeholder for all  
auth methods were rendered a bit nonsensical.  
* DocBook no longer provides a subsection table-of-contents here,  
which formerly was a useful if terse summary of available auth methods.  
  
To improve matters, add a handwritten list of all the auth methods.  
  
Per gripe from Dave Cramer.  Back-patch to v11 where the previous  
commit came in.  
  
Discussion: https://postgr.es/m/CADK3HH+xQLhcPgg=kWqfogtXGGZr-JdSo=x=WQC0PkAVyxUWyQ@mail.gmail.com  

commit   : 7cdcc747a9fe588f9e9b3a5d3feb650340093fb2    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 19 Dec 2019 09:24:44 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 19 Dec 2019 09:24:44 -0500    

Commit d986d4e87f61c68f52c68ebc274960dc664b7b4e renamed a variable  
but neglected to update the corresponding comment.  
  
Amit Langote  

commit   : 303640199d0436c5e7acdf50b837a027b5726594    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 19 Dec 2019 09:06:54 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 19 Dec 2019 09:06:54 -0500    

The previous coding imagined that it could call before_shmem_exit()  
when a non-exclusive backup began and then remove the previously-added  
handler by calling cancel_before_shmem_exit() when that backup  
ended. However, this only works provided that nothing else in the  
system has registered a before_shmem_exit() hook in the interim,  
because cancel_before_shmem_exit() is documented to remove a callback  
only if it is the latest callback registered. It also only works  
if nothing can ERROR out between the time that sessionBackupState  
is reset and the time that cancel_before_shmem_exit(), which doesn't  
seem to be strictly true.  
  
To fix, leave the handler installed for the lifetime of the session,  
arrange to install it just once, and teach it to quietly do nothing if  
there isn't a non-exclusive backup in process.  
  
This is a bug, but for now I'm not going to back-patch, because the  
consequences are minor. It's possible to cause a spurious warning  
to be generated, but that doesn't really matter. It's also possible  
to trigger an assertion failure, but production builds shouldn't  
have assertions enabled.  
  
Patch by me, reviewed by Kyotaro Horiguchi, Michael Paquier (who  
preferred a different approach, but got outvoted), Fujii Masao,  
and Tom Lane, and with comments by various others.  
  
Discussion: http://postgr.es/m/CA+TgmobMjnyBfNhGTKQEDbqXYE3_rXWpc4CM63fhyerNCes3mA@mail.gmail.com  

commit   : e975c1a6026adb9e248a408fe3ca2629bc8c0084    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Dec 2019 08:28:37 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Dec 2019 08:28:37 +0100    

It's basically a variant of Cygwin, so use that template.  
  
Discussion: https://www.postgresql.org/message-id/flat/6b467edc-4018-521f-ab18-171f098557ca%402ndquadrant.com  

commit   : 9aafc4529f50e027f05037d993c6dd60a6cde54d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 18 Dec 2019 13:03:41 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 18 Dec 2019 13:03:41 -0500    

Commit 7dbfea3c455e83a77213a92b9dfdc1c0577441ea thought it could get  
away with removing this, but Thomas Munro reports, on behalf of the  
buildfarm, that it's still needed at least on Windows to avoid  
compiler warnings.  

commit   : e9fd0415e6e27c8ce5f40152aa98347ca6fe4385    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Wed, 18 Dec 2019 11:08:59 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Wed, 18 Dec 2019 11:08:59 -0500    

The new function, heap_fetch_toast_slice, is shared between  
toast_fetch_datum_slice and toast_fetch_datum, and does all the  
work of scanning the TOAST table, fetching chunks, and storing  
them into the space allocated for the result varlena.  
  
As an incidental side effect, this allows toast_fetch_datum_slice  
to perform the scan with only a single scankey if all chunks are  
being fetched, which might have some tiny performance benefit.  
  
Discussion: http://postgr.es/m/CA+TgmobBzxwFojJ0zV0Own3dr09y43hp+OzU2VW+nos4PMXWEg@mail.gmail.com  

commit   : bf7427bdd389aa6c266768f2a07214a2a02b85c9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Dec 2019 10:22:50 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 18 Dec 2019 10:22:50 -0500    

Older gcc versions are not happy with having multiple declarations  
for the same typedef name (not struct name).  I'm a bit dubious  
as to how well-thought-out that patch was at all, but for the moment  
just fix it enough so I can get some work done today.  
  
Discussion: https://postgr.es/m/20191218101338.GB325369@paquier.xyz  

commit   : ecb09cd5de5279ab9cfa20a58fd3da44f7df5779    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 18 Dec 2019 09:08:23 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 18 Dec 2019 09:08:23 +0100    

The main use right now is getting properly spaced diff views on  
GitHub, but perhaps this will also help developers with editors that  
we currently don't have setup recipes for.  
  
The settings mirror mostly what's currently in .dir-locals.el.  
  
Discussion: https://www.postgresql.org/message-id/flat/273cb788-bbb2-ff34-ad6f-5192b44e5049%402ndquadrant.com  

commit   : 2032645b195a53519b43dad57f55bc163b99f0ef    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Dec 2019 16:55:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Dec 2019 16:55:25 +0900    

Oversight in commit e1551f9.  
  
Reported-by: Erik Rijkers  
Discussion: https://postgr.es/m/b7ad911d3eaa29af9fcdb9ccb26c363c@xs4all.nl  

commit   : e1551f96e643a52a035c3b35777d968bc073f7fc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Dec 2019 16:23:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Dec 2019 16:23:02 +0900    

Tuple conversion support in tupconvert.c is able to convert rowtypes  
between two relations, inner and outer, which are logically equivalent  
but have a different ordering or even dropped columns (used mainly for  
inheritance tree and partitions).  This makes use of attribute mappings,  
which are simple arrays made of AttrNumber elements with a length  
matching the number of attributes of the outer relation.  The length of  
the attribute mapping has been treated as completely independent of the  
mapping itself until now, making it easy to pass down an incorrect  
mapping length.  
  
This commit refactors the code related to attribute mappings and moves  
it into an independent facility called attmap.c, extracted from  
tupconvert.c.  This merges the attribute mapping with its length,  
avoiding to try to guess what is the length of a mapping to use as this  
is computed once, when the map is built.  
  
This will avoid mistakes like what has been fixed in dc816e58, which has  
used an incorrect mapping length by matching it with the number of  
attributes of an inner relation (a child partition) instead of an outer  
relation (a partitioned table).  
  
Author: Michael Paquier  
Reviewed-by: Amit Langote  
Discussion: https://postgr.es/m/20191121042556.GD153437@paquier.xyz  

commit   : 04c8a69c0cccbc271e0feeb22a74c69fbd87c37e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 16 Dec 2019 15:23:46 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 16 Dec 2019 15:23:46 +0530    

This patch allows building the local relmap cache for a subscribed  
relation after processing pending invalidation messages and potential  
relcache updates.  Without this, the attributes in the local cache don't  
tally with the updated relcache entry leading to invalid memory access.  
  
Reported-by Jehan-Guillaume de Rorthais  
Author: Jehan-Guillaume de Rorthais and Vignesh C  
Reviewed-by: Amit Kapila  
Backpatch-through: 10  
Discussion: https://postgr.es/m/20191025175929.7e90dbf5@firost  

commit   : 52dcfda48778d16683c64ca4372299a099a15b96    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Dec 2019 11:07:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Dec 2019 11:07:36 +0900    

That's more consistent with the style we have been using with for  
example EXPLAIN, VACUUM or ANALYZE (this one had only one option in  
v11).  Based on a suggestion from Pavel Stehule.  
  
Author: Josef Šimánek  
Discussion: https://postgr.es/m/CAFj8pRCrUS+eMFvssVPGZN-VDEMP3XN+1Dop0=CmeBq2D+dqOg@mail.gmail.com  
Discussion: https://postgr.es/m/CAFp7QwpeMPEtAR5AYpsG623ooMWX03wMjq5cpZn=X+6OCkfwJw@mail.gmail.com  

commit   : aa3ef7ff505305d8ee5f733090b076c301a32cc8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Dec 2019 10:42:40 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Dec 2019 10:42:40 +0900    

These have been missed in 01368e5, and count for plpython and the  
backend's tsearch code.  
  
Author: Mahendra Singh  
Discussion: https://postgr.es/m/CAKYtNAo4mxRRyDB0YqE6QLh17XD7pPQotpGm3GnHS+gQKz4zQQ@mail.gmail.com  

commit   : 181932a03212751102fb2c105fe556a26aee6ed7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 17 Dec 2019 20:37:22 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 17 Dec 2019 20:37:22 -0500    

Reported-by: Ranier Vilela  
  
Discussion: https://postgr.es/m/MN2PR18MB2927E73FADCA8967B2302469E3490@MN2PR18MB2927.namprd18.prod.outlook.com  
  
Author: Ranier Vilela  
  
Backpatch-through: master  

commit   : 70116493a8e07713f7e1270646ca1147898b4f6d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Dec 2019 10:11:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 18 Dec 2019 10:11:13 +0900    

This changes the routines in charge of recycling WAL segments past the  
last redo LSN to not use anymore "RedoRecPtr" as a local variable, which  
is also available in the context of the session as a static declaration,  
replacing it with "lastredoptr".  This confusion has been introduced by  
d9fadbf, so backpatch down to v11 like the other commit.  
  
Thanks to Tom Lane, Robert Haas, Alvaro Herrera, Mark Dilger and Kyotaro  
Horiguchi for the input provided.  
  
Author: Ranier Vilela  
Discussion: https://postgr.es/m/MN2PR18MB2927F7B5F690065E1194B258E35D0@MN2PR18MB2927.namprd18.prod.outlook.com  
Backpatch-through: 11  

commit   : 2acab054b3ff8e46707727980ce3fa1a1897381f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Dec 2019 17:44:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Dec 2019 17:44:27 -0500    

If CheckAttributeType() threw an error about the datatype of an  
index expression column, it would report an empty column name,  
which is pretty unhelpful and certainly not the intended behavior.  
I (tgl) evidently broke this in commit cfc5008a5, by not noticing  
that the column's attname was used above where I'd placed the  
assignment of it.  
  
In HEAD and v12, this is trivially fixable by moving up the  
assignment of attname.  Before v12 the code is a bit more messy;  
to avoid doing substantial refactoring, I took the lazy way out  
and just put in two copies of the assignment code.  
  
Report and patch by Amit Langote.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/CA+HiwqFA+BGyBFimjiYXXMa2Hc3fcL0+OJOyzUNjhU4NCa_XXw@mail.gmail.com  

commit   : 5184f110aa4130ec87b0b3e0834292cd8cb1fd8a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 15:53:17 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 15:53:17 -0500    

Commit d5406dea25b600408e7acf17d5a06e82d3ce6d0d used a slightly  
novel, and wrong, approach to compute the length of the last  
toast chunk. It worked fine unless the last chunk happened to  
have the largest possible size.  

commit   : d5406dea25b600408e7acf17d5a06e82d3ce6d0d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 22 Nov 2019 08:43:28 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 22 Nov 2019 08:43:28 -0500    

Rework some of the checks for bad TOAST chunks to be a bit simpler  
and easier to understand. These checks verify that (1) we get all  
and only the chunk numbers we expect to see and (2) each chunk has  
the expected size. However, the existing code was a bit hard to  
understand, at least for me; try to make it clearer.  
  
As part of that, have toast_fetch_datum_slice check the relationship  
between endchunk and totalchunks only with an Assert() rather than  
checking every chunk number against both values. There's no need to  
check that relationship in production builds because it's not a  
function of whether on-disk corruption is present; it's just a  
question of whether the code does the right math.  
  
Also, have toast_fetch_datum_slice() use ereport(ERROR) rather than  
elog(ERROR). Commit fd6ec93bf890314ac694dc8a7f3c45702ecc1bbd made  
the two functions inconsistent with each other.  
  
Rename assorted variables for better clarity and consistency, and  
move assorted variables from function scope to the function's main  
loop. Remove a few variables that are used only once entirely.  
  
Patch by me, reviewed by Peter Eisentraut.  
  
Discussion: http://postgr.es/m/CA+TgmobBzxwFojJ0zV0Own3dr09y43hp+OzU2VW+nos4PMXWEg@mail.gmail.com  

commit   : da41d71070d14ecd9e2f4bbe275c98a136826d4b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 14:11:14 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 14:11:14 -0500    

Commit 48995040d5e7b1e9bac35d72aff326cae002219d removed the largest  
barrier to use of simplehash in frontend code, but there's one more  
problem: it uses elog(ERROR, ...) or elog(LOG, ...) in a couple of  
places. Work around that by changing those to pg_log_error() and  
pg_log_info() when FRONTEND is defined.  
  
Patch by me, reviewed by Andres Freund.  
  
Discussion: http://postgr.es/m/CA+Tgmob8oyh02NrZW=xCScB+5GyJ-jVowE3+TWTUmPF=FsGWTA@mail.gmail.com  

commit   : 48995040d5e7b1e9bac35d72aff326cae002219d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 14:06:25 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 14:06:25 -0500    

If the SH_RAW_ALLOCATOR is defined, it will be used to allocate bytes  
for the hash table, and no dependencies on MemoryContext will exist.  
This means, in particular, that the SH_CREATE function will not take  
a MemoryContext argument.  
  
Patch by me, reviewed by Andres Freund.  
  
Discussion: http://postgr.es/m/CA+Tgmob8oyh02NrZW=xCScB+5GyJ-jVowE3+TWTUmPF=FsGWTA@mail.gmail.com  

commit   : b1cc572f1274c946da42ed13ae4065e08b13262a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 13:56:19 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 13:56:19 -0500    

Commit 5910d6c7e311f0b14e3d3cb9ce3597c01d3a3cde got this wrong.  
  
Report and patch by Andrew Gierth.  
  
Discussion: http://postgr.es/m/8736diaj98.fsf@news-spur.riddles.org.uk  

commit   : 7dbfea3c455e83a77213a92b9dfdc1c0577441ea    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 13:14:28 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 13:14:28 -0500    

Where possible, share signal handler code and main loop interrupt  
checking. This saves quite a bit of code and should simplify  
maintenance, too.  
  
This commit intends not to change the way anything works, even  
though that might allow more code to be unified. It does unify  
a bunch of individual variables into a ShutdownRequestPending  
flag that has is now used by a bunch of different process types,  
though.  
  
Patch by me, reviewed by Andres Freund and Daniel Gustafsson.  
  
Discussion: http://postgr.es/m/CA+TgmoZwDk=BguVDVa+qdA6SBKef=PKbaKDQALTC_9qoz1mJqg@mail.gmail.com  

commit   : 1e53fe0e70f610c34f4c9e770d108cd94151342c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 13:03:57 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 13:03:57 -0500    

There seems to be no reason for every background process to have  
its own flag indicating that a config-file reload is needed.  
Instead, let's just use ConfigFilePending for that purpose  
everywhere.  
  
Patch by me, reviewed by Andres Freund and Daniel Gustafsson.  
  
Discussion: http://postgr.es/m/CA+TgmoZwDk=BguVDVa+qdA6SBKef=PKbaKDQALTC_9qoz1mJqg@mail.gmail.com  

commit   : 5910d6c7e311f0b14e3d3cb9ce3597c01d3a3cde    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 12:55:13 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 17 Dec 2019 12:55:13 -0500    

Some auxiliary processes, as well as the autovacuum launcher,  
have interrupt handling code directly in their main loops.  
Try to abstract things a little better by moving it into  
separate functions.  
  
This doesn't make any functional difference, and leaves  
in place relatively large differences among processes in how  
interrupts are handled, but hopefully it at least makes it  
easier to see the commonalities and differences across  
process types.  
  
Patch by me, reviewed by Andres Freund and Daniel Gustafsson.  
  
Discussion: http://postgr.es/m/CA+TgmoZwDk=BguVDVa+qdA6SBKef=PKbaKDQALTC_9qoz1mJqg@mail.gmail.com  

commit   : af3290f5e790dcd1be3ac209be1805626f4ebac8    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 12 Dec 2019 11:51:30 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 12 Dec 2019 11:51:30 +0530    

This Assert thought that an overflowed transaction can never get registered  
for the group update.  But that is not true, because even when the number  
of children for a transaction got reduced, the overflow flag is not  
changed.  And, for group update, we only care about the current number of  
children for a transaction that is being committed.  
  
Based on comments by Andres Freund, remove a redundant Assert in  
TransactionIdSetPageStatus as we already had a static Assert for the same  
condition a few lines earlier.  
  
Reported-by: Vignesh C  
Author: Dilip Kumar  
Reviewed-by: Amit Kapila  
Backpatch-through: 11  
Discussion: https://postgr.es/m/CAFiTN-s5=uJw-Z6JC9gcqtBSjXsrHnU63PXBrA=pnBjqnkm5UA@mail.gmail.com  

commit   : fcf3b6917bd8f6f9f463e3e42e53d6ff9612e327    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 16 Dec 2019 17:49:45 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 16 Dec 2019 17:49:45 -0800    

Rename two function-style macros, removing the word "inner".  This makes  
things more consistent.  

commit   : 5d43c3c54d77f39135fe463539f5f438f460ae7e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 17 Dec 2019 10:44:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 17 Dec 2019 10:44:25 +0900    

The refactoring done in a4fd3aa for query cancellation has messed up  
with the logic in psql by mixing CancelRequested and cancel_pressed,  
breaking for example \watch.  The former would be switched to true if a  
cancellation request has been attempted and that it actually succeeded,  
and the latter tracks if a cancellation attempt has been done.  
  
This commit brings back the code of psql to a state consistent to what  
it was before a4fd3aa, without giving up on the refactoring pieces  
introduced.  It should be actually possible to merge more both flags as  
their concepts are close enough, however note that psql's --single-step  
mode relies on cancel_pressed to be always set, so this requires more  
careful analysis left for later.  
  
While on it, fix the declarations of CancelRequested (in cancel.c) and  
cancel_pressed (in psql) to be volatile sig_atomic_t.  Previously,  
both were declared as booleans, which should be fine on modern  
platforms, but the C standard recommends the use of sig_atomic_t for  
variables used in signal handlers.  Note that since its introduction in  
a1792320, CancelRequested declaration was not volatile.  
  
Reported-by: Jeff Janes  
Author: Michael Paquier  
Discussion: https://postgr.es/m/CAMkU=1zpoUDGKqWKuMWkj7t-bOCaJDx0r=5te_-d0B2HVLABXg@mail.gmail.com  

commit   : b925a00f4ef65db9359e1c60fbf0e56d05afb25a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Dec 2019 20:14:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Dec 2019 20:14:25 -0500    

force_parallel_mode = regress is supposed to force use of a Gather  
node without having any impact on EXPLAIN output.  But it failed to  
accomplish that if both ANALYZE and VERBOSE are given, because that  
enables per-worker output data that you wouldn't see if the Gather  
hadn't been inserted.  Improve the logic so that we suppress the  
per-worker data too.  
  
This allows putting the new test case added by commit 5935917ce  
back into the originally intended form (cf. 776a2c887, 22864f6e0).  
We can also get rid of a kluge in subselect.sql, which previously  
had to clean up after force_parallel_mode's failure to do what it  
said on the tin.  
  
Discussion: https://postgr.es/m/18445.1576177309@sss.pgh.pa.us  

commit   : 9067b83955da5fde49a2605510900e6d9fa273af    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 16 Dec 2019 17:11:35 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 16 Dec 2019 17:11:35 -0800    

get_actual_variable_range() hasn't used a dirty snapshot since commit  
3ca930fc3, which invented a new snapshot type specifically to meet  
selfuncs.c's requirements (HeapTupleSatisfiesNonVacuumable() type  
snapshots were added).  
  
Discussion: https://postgr.es/m/CAH2-Wzn2pSqEOcBDAA40CnO82oEy-EOpE2bNh_XL_cfFoA86jw@mail.gmail.com  

commit   : 6d7547c219adf2436323cdbd4bebc5e872d53546    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Dec 2019 15:10:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 16 Dec 2019 15:10:55 -0500    

Attempting to open a file fails with ERROR_ACCESS_DENIED if the file  
is flagged for deletion but not yet actually gone (another in a long  
list of reasons why Windows is broken, if you ask me).  This seems  
likely to explain a lot of irreproducible failures we see in the  
buildfarm.  This state generally persists for only a millisecond or so,  
so just wait a bit and retry.  If it's a real permissions problem,  
we'll eventually give up and report it as such.  If it's the pending  
deletion case, we'll see file-not-found and report that after the  
deletion completes, and the caller will treat that in an appropriate  
way.  
  
In passing, rejigger the existing retry logic for some other error  
cases so that we don't uselessly wait an extra time when we're  
not going to retry anymore.  
  
Alexander Lakhin (with cosmetic tweaks by me).  Back-patch to all  
supported branches, since this seems like a pretty safe change and  
the problem is definitely real.  
  
Discussion: https://postgr.es/m/16161-7a985d2f1bbe8f71@postgresql.org  

commit   : 91fca4bb60e8c00e8b0e2755555b39f4b1c1659c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Dec 2019 14:23:56 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Dec 2019 14:23:56 -0300    

recoveryDelayUntilTime was introduced by commit 36da3cfb457b as a global  
because its method of operation was devilishly intrincate.  Commit  
c945af80cfda removed all that complexity and could have turned it into a  
local variable, but didn't.  Do so now.  
  
Discussion: https://postgr.es/m/20191213200751.GA10731@alvherre.pgsql  
Reviewed-by: Michaël Paquier, Daniel Gustafsson  

commit   : 741b884353e4803abc15d4392ad287b0d5953fc4    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 16 Dec 2019 13:57:41 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 16 Dec 2019 13:57:41 +0200    

Commit a7ee7c8513 fixed a bug in GiST page split during index creation,  
where we failed to re-find the position of a downlink after the page  
containing it was split. However, that fix was incomplete; the other call  
to gistinserttuples() in the same function needs to also clear  
'downlinkoffnum'.  
  
Fixes bug #16134 reported by Alexander Lakhin, for real this time. The  
previous fix was enough to fix the crash with the reproducer script for  
bug #16162, but the original script for #16134 was still crashing.  
  
Backpatch to v12, like the previous incomplete fix.  
  
Discussion: https://www.postgresql.org/message-id/d869f537-abe4-d2ea-0510-38cd053f5152%40gmail.com  

commit   : 502423180a8cc9214861bffcb8405a42f146f160    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 Dec 2019 11:48:01 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 16 Dec 2019 11:48:01 +0100    

Commit f14413b684d57211068ee56ee04695efcc87a23a broke the build of  
Perl-using modules on Windows.  
  
Perl might have its own definitions of uid_t and gid_t, so we hide  
ours, but then we can't use ours in our header files such as port.h  
which don't see the Perl definition.  
  
Hide our definition of getpeereid() on Windows in Perl-using modules,  
using PLPERL_HAVE_UID_GID define.  That means we can't portably use  
getpeeruid() is such modules right now, but there is no need anyway.  

commit   : f14413b684d57211068ee56ee04695efcc87a23a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 30 Oct 2019 12:58:32 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 30 Oct 2019 12:58:32 +0100    

The getpeereid() uses have so far been protected by HAVE_UNIX_SOCKETS,  
so they didn't ever care about Windows support.  But in anticipation  
of Unix-domain socket support on Windows, that needs to be handled  
differently.  
  
Windows doesn't support getpeereid() at this time, so we use the  
existing not-supported code path.  We let configure do its usual thing  
of picking up the replacement from libpgport, instead of the custom  
overrides that it was doing before.  
  
But then Windows doesn't have struct passwd, so this patch sprinkles  
some additional #ifdef WIN32 around to make it work.  This is similar  
to existing code that deals with this issue.  
  
Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/5974caea-1267-7708-40f2-6009a9d653b0@2ndquadrant.com  

commit   : 956ef5875341c22a602fb825e6c98eaabb1ecce7    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 16 Dec 2019 17:00:15 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 16 Dec 2019 17:00:15 +0900    

Also, add a comment explaining a test case.  
  
Back-patch to 11 where the regression test was added.  
  
Discussion: https://postgr.es/m/CAPmGK15adZPh2B%2BmGUjSOMH%2BH39ogDRWfCfm4G6jncZCAs9V_Q%40mail.gmail.com  

commit   : e5a02e0fc68bd57048f2c74a89f5412dbf87015e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 15 Dec 2019 22:05:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 15 Dec 2019 22:05:33 +0900    

This has been introduced by c16dc1a since progress reporting for VACUUM  
has been added.  As this issue just causes some extra work and is  
harmless, no backpatch is done.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20191213030831.GT2082@telsasoft.com  

commit   : baa32ce28b39eccdf384e979dac5ad8be91ff44e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Dec 2019 15:01:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Dec 2019 15:01:56 -0500    

It appears that a concurrent autovacuum/autoanalyze run can cause  
changes in the plans expected by this test.  To prevent that, change  
the tables it uses to be temp tables --- there's no need for them  
to be permanent, and this should save a few cycles too.  
  
Discussion: https://postgr.es/m/3244.1576160824@sss.pgh.pa.us  

commit   : 6ea364e7e7d5f298fc965006caa6c228c743fe77    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Dec 2019 13:49:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Dec 2019 13:49:15 -0500    

The RTE_RESULT simplification logic added by commit 4be058fe9 had a  
flaw: it would collapse out a RTE_RESULT that is due to compute a  
PlaceHolderVar, and reassign the PHV to the parent join level, even if  
another input relation of the join contained a lateral reference to  
the PHV.  That can't work because the PHV would be computed too late.  
In practice it led to failures of internal sanity checks later in  
planning (either assertion failures or errors such as "failed to  
construct the join relation").  
  
To fix, add code to check for the presence of such PHVs in relevant  
portions of the query tree.  Notably, this required refactoring  
range_table_walker so that a caller could ask to walk individual RTEs  
not the whole list.  (It might be a good idea to refactor  
range_table_mutator in the same way, if only to keep those functions  
looking similar; but I didn't do so here as it wasn't necessary for  
the bug fix.)  
  
This exercise also taught me that find_dependent_phvs(), as it stood,  
could only safely be used on the entire Query, not on subtrees.  
Adjust its API to reflect that; which in passing allows it to have  
a fast path for the common case of no PHVs anywhere.  
  
Per report from Will Leinweber.  Back-patch to v12 where the bug  
was introduced.  
  
Discussion: https://postgr.es/m/CALLb-4xJMd4GZt2YCecMC95H-PafuWNKcmps4HLRx2NHNBfB4g@mail.gmail.com  

commit   : e0e569e1d192c3fed942257302f24b550cf982f4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 14 Dec 2019 18:17:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 14 Dec 2019 18:17:31 +0900    

When loading DH parameters used for the generation of ephemeral DH keys  
in the backend, the code has never bothered releasing the memory used  
for the DH information loaded from a file or from libpq's default.  This  
commit makes sure that the information is properly free()'d.  
  
Note that as SSL parameters can be reloaded, this can cause an accumulation  
of memory leaked.  As the leak is minor, no backpatch is done.  
  
Reported-by: Dmitry Uspenskiy  
Discussion: https://postgr.es/m/16160-18367e56e9a28264@postgresql.org  

commit   : 7c85be08a2d404ec2a1a6a3b089e7f08d62e5db8    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 14 Dec 2019 17:38:09 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 14 Dec 2019 17:38:09 +1300    

The previous commit failed to consider that FileGetRawDesc() might  
not return a valid fd, as discovered on the build farm.  Switch to  
using the File interface only.  
  
Back-patch to 12, like the previous commit.  

commit   : 7bb3102cea02101efcbb4c4fba3fdd452a52bdab    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 14 Dec 2019 15:54:31 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 14 Dec 2019 15:54:31 +1300    

_mdfd_getseg() opens all segments up to the requested one.  That  
causes problems for mdsyncfiletag(), if mdunlinkfork() has  
already unlinked other segment files.  Open the file we want  
directly by name instead, if it's not already open.  
  
The consequence of this bug was a rare panic in the checkpointer,  
made more likely if you saturated the sync request queue so that  
the SYNC_FORGET_REQUEST messages for a given relation were more  
likely to be absorbed in separate cycles by the checkpointer.  
  
Back-patch to 12.  Defect in commit 3eb77eba.  
  
Author: Thomas Munro  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20191119115759.GI30362%40telsasoft.com  

commit   : a7ee7c85132221ff7231b6f910915a1b3ce1ecbc    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 13 Dec 2019 23:58:10 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 13 Dec 2019 23:58:10 +0200    

The bug was similar to the one that was fixed in commit 22251686f0. When  
we split page X and insert the downlink for the new page, the parent page  
might also need to be split. When that happens, the downlink offset number  
we remembered for X is no longer valid. We correctly called  
gistFindCorrectParent() to re-find it, but gistFindCorrectParent() doesn't  
do anything if the LSN of the page hasn't changed, and we stopped updating  
LSNs during index build in commit 9155580fd5. The buggy codepath was taken  
if the page was split into three or more pages, and inserting the downlink  
caused the parent page to split. To fix, explicitly mark the downlink  
offset number as invalid, to force gistFindCorrectParent() to re-find it.  
  
Fixes bug #16134 reported by Alexander Lakhin, reported again as #16162 by  
Andreas Kunert. Thanks to Jeff Janes, Tom Lane and Tomas Vondra for  
debugging. Backpatch to v12, where we stopped WAL-logging during index  
build.  
  
Discussion: https://www.postgresql.org/message-id/16134-0423f729671dec64%40postgresql.org  
Discussion: https://www.postgresql.org/message-id/16162-45d21b7b6c1a3105%40postgresql.org  

commit   : 5e7bedc5adba570b526d89746201481616756779    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Dec 2019 11:16:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Dec 2019 11:16:33 -0500    

Prefer to call "rl_filename_completion_function" and  
"rl_completion_matches", rather than using the names without the rl_  
prefix.  This matches Readline's documentation, and makes our code  
a little clearer about which names are external.  On platforms that  
only have the un-prefixed names (just some very ancient versions of  
libedit, AFAICT), reverse the direction of the compatibility macro  
definitions to match.  
  
Also, remove our extern declaration of "filename_completion_function";  
whatever libedit versions may have failed to declare that are surely  
dead and buried.  
  
Discussion: https://postgr.es/m/23608.1576248145@sss.pgh.pa.us  

commit   : 22864f6e02f8fc19f6167442f13d1f917e36548e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Dec 2019 13:49:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Dec 2019 13:49:54 -0500    

This undoes my hurried commit 776a2c887, restoring the removed test case  
in a form that passes with or without force_parallel_mode = regress.  
  
It turns out that force_parallel_mode = regress simply fails to mask  
the Worker lines that will be produced by EXPLAIN (ANALYZE, VERBOSE).  
I'd say that's a bug in that feature, as its entire alleged reason  
for existence is to make the EXPLAIN output the same.  It's certainly  
not a bug in the plan node pruning logic.  Fortunately, this test case  
doesn't really need to use ANALYZE, so just drop that.  
  
Discussion: https://postgr.es/m/18891.1576109690@sss.pgh.pa.us  

commit   : 1a3efa1eb67ab752231a6fff2743a77ae55808d5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Dec 2019 12:30:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Dec 2019 12:30:43 -0500    

The test cases added by commit 26ae3aa80 exposed an old oversight in  
timestamp[tz]_part: they didn't correct the result of date2isoyear()  
for BC years, so that we produced an off-by-one answer for such years.  
Fix that, and back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/SG2PR06MB37762CAE45DB0F6CA7001EA9B6550@SG2PR06MB3776.apcprd06.prod.outlook.com  

commit   : 26ae3aa80e337261203ba4442452bed261ff9888    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Dec 2019 12:12:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Dec 2019 12:12:35 -0500    

The DTK_DOW/DTK_ISODOW and DTK_DOY switch cases in timestamp_part() and  
timestamptz_part() contained calls of timestamp2tm() that were fully  
redundant with the ones done just above the switch.  This evidently crept  
in during commit 258ee1b63, which relocated that code from another place  
where the calls were indeed needed.  Just delete the redundant calls.  
  
I (tgl) noted that our test coverage of these functions left quite a  
bit to be desired, so extend timestamp.sql and timestamptz.sql to  
cover all the branches.  
  
Back-patch to all supported branches, as the previous commit was.  
There's no real issue here other than some wasted cycles in some  
not-too-heavily-used code paths, but the test coverage seems valuable.  
  
Report and patch by Li Japin; test case adjustments by me.  
  
Discussion: https://postgr.es/m/SG2PR06MB37762CAE45DB0F6CA7001EA9B6550@SG2PR06MB3776.apcprd06.prod.outlook.com  

commit   : 8ed428dc977f6d3e454892ddca089f17e150384f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Dec 2019 13:45:15 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Dec 2019 13:45:15 -0300    

gcc-based Windows buildfarm animals are not happy about a multiline  
regular expression I added recently.  Try to accomodate; existing  
pg_basebackup tests suggest that \n should work instead of a bare  
newline, but throw in \r also.  This being perl, TIMTOWTDI.  
Also remove the pointless $ at the end of the pattern, for extra luck.  
  
(If this doesn't work, I'll probably just split the regex in two.)  
  
Per buildfarm members jacana and fairywren.  
  
Discussion: https://postgr.es/m/3562.1576161217@sss.pgh.pa.us  

commit   : a41a1456c4a1040974939db23a81101a2f6ade6f    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 12 Dec 2019 15:45:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 12 Dec 2019 15:45:00 +0900    

commit   : 591d404b9cd2c562bfe7fe60d76988d49b5ba2b1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2019 19:08:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2019 19:08:16 -0500    

This is made necessary by the fact that commit 6ef77cf46 added  
AppendRelInfos to plan trees.  I'd concluded that this extra code was  
not necessary because we don't transmit that data to parallel workers  
... but I forgot about -DWRITE_READ_PARSE_PLAN_TREES.  Per buildfarm.  

commit   : 776a2c887480977a4327108945364fb4d84a817f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2019 18:53:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2019 18:53:53 -0500    

The buildfarm says this produces some unexpected output with  
force_parallel_mode = regress.  There's probably a bug underneath  
that, but for the moment just delete the test case to make the  
buildfarm green again.  
  
(I now notice that the case had also failed to get updated to follow  
commit d52eaa094, which made plan_cache_mode = force_generic_plan  
prevail throughout partition_prune.sql; it was thereby managing to  
break a later test.  When/if we put this back in, *don't* include the  
SET and RESET commands.)  

commit   : 5935917ce59e2e613ac7a4b54ed49a7b9f8f28ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2019 17:05:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2019 17:05:30 -0500    

Previously, if the startup pruning logic proved that all child nodes  
of an Append or MergeAppend could be pruned, we still kept one, just  
to keep EXPLAIN from failing.  The previous commit removed the  
ruleutils.c limitation that required this kluge, so drop it.  That  
results in less-confusing EXPLAIN output, as per a complaint from  
Yuzuko Hosoya.  
  
David Rowley  
  
Discussion: https://postgr.es/m/001001d4f44b$2a2cca50$7e865ef0$@lab.ntt.co.jp  

commit   : 6ef77cf46e81f45716ec981cb08781d426181378    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2019 17:05:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2019 17:05:18 -0500    

This patch causes EXPLAIN to always assign a separate table alias to the  
parent RTE of an append relation (inheritance set); before, such RTEs  
were ignored if not actually scanned by the plan.  Since the child RTEs  
now always have that same alias to start with (cf. commit 55a1954da),  
the net effect is that the parent RTE usually gets the alias used or  
implied by the query text, and the children all get that alias with "_N"  
appended.  (The exception to "usually" is if there are duplicate aliases  
in different subtrees of the original query; then some of those original  
RTEs will also have "_N" appended.)  
  
This results in more uniform output for partitioned-table plans than  
we had before: the partitioned table itself gets the original alias,  
and all child tables have aliases with "_N", rather than the previous  
behavior where one of the children would get an alias without "_N".  
  
The reason for giving the parent RTE an alias, even if it isn't scanned  
by the plan, is that we now use the parent's alias to qualify Vars that  
refer to an appendrel output column and appear above the Append or  
MergeAppend that computes the appendrel.  But below the append, Vars  
refer to some one of the child relations, and are displayed that way.  
This seems clearer than the old behavior where a Var that could carry  
values from any child relation was displayed as if it referred to only  
one of them.  
  
While at it, change ruleutils.c so that the code paths used by EXPLAIN  
deal in Plan trees not PlanState trees.  This effectively reverts a  
decision made in commit 1cc29fe7c, which seemed like a good idea at  
the time to make ruleutils.c consistent with explain.c.  However,  
it's problematic because we'd really like to allow executor startup  
pruning to remove all the children of an append node when possible,  
leaving no child PlanState to resolve Vars against.  (That's not done  
here, but will be in the next patch.)  This requires different handling  
of subplans and initplans than before, but is otherwise a pretty  
straightforward change.  
  
Discussion: https://postgr.es/m/001001d4f44b$2a2cca50$7e865ef0$@lab.ntt.co.jp  

commit   : ba79cb5dc841104cf4810b5c23af4f881079dbb5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 11 Dec 2019 18:03:35 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 11 Dec 2019 18:03:35 -0300    

This makes such log entries more useful, since the cause of the error  
can be dependent on the parameter values.  
  
Author: Alexey Bashtanov, Álvaro Herrera  
Discussion: https://postgr.es/m/0146a67b-a22a-0519-9082-bc29756b93a2@imap.cc  
Reviewed-by: Peter Eisentraut, Andres Freund, Tom Lane  

commit   : 16114f2ea0c0aba75d10b622797d31bcd296fadd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2019 15:09:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2019 15:09:54 -0500    

Since its inception, our Windows signal emulation code has worked by  
running a main signal thread that just watches for incoming signal  
requests, and then spawns a new thread to handle each such request.  
That design is meant for servers in which requests can take substantial  
effort to process, and it's worth parallelizing the handling of  
requests.  But those assumptions are just bogus for our signal code.  
It's not much more than pg_queue_signal(), which is cheap and can't  
parallelize at all, plus we don't really expect lots of signals to  
arrive at the same backend at once.  More importantly, this approach  
creates failure modes that we could do without: either inability to  
spawn a new thread or inability to create a new pipe handle will risk  
loss of signals.  Hence, dispense with the separate per-signal threads  
and just service each request in-line in the main signal thread.  This  
should be a bit faster (for the normal case of one signal at a time)  
as well as more robust.  
  
Patch by me; thanks to Andrew Dunstan for testing and Amit Kapila  
for review.  
  
Discussion: https://postgr.es/m/4412.1575748586@sss.pgh.pa.us  

commit   : 105eb360f2513523d221302b2d52880a14afae34    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Dec 2019 08:59:18 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Dec 2019 08:59:18 +0100    

It was once possible to do ALTER TABLE ... SET STATISTICS on system  
tables without allow_sytem_table_mods.  This was changed apparently by  
accident between PostgreSQL 9.1 and 9.2, but a code comment still  
claimed this was possible.  Without that functionality, having a  
separate ATPrepSetStatistics() is useless, so use the generic  
ATSimplePermissions() instead and move the remaining custom code into  
ATExecSetStatistics().  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/cc8d2648-a0ec-7a86-13e5-db473484e19e%402ndquadrant.com  

commit   : b802412106e82ccf1aef36a4984e321082c122cb    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Dec 2019 08:42:17 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 11 Dec 2019 08:42:17 +0100    

Several off-by-more-than-one errors caused the output in case of a  
test failure to be truncated and unintelligible.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/6a7a8516-7d11-8fbd-0e8b-eadb4f0679eb%402ndquadrant.com  

commit   : c341c7d391e256f80cfbae53b4f55278bffca699    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Dec 2019 10:01:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Dec 2019 10:01:06 +0900    

gcc-7 used with a sufficient optimization level complains about warnings  
around do_to_timestamp() regarding the initialization and handling of  
some of its variables.  Recent commits 66c74f8 and d589f94 made things  
made the interface more confusing, so document which variables are  
always expected and initialize properly the optional ones when they are  
set.  
  
Author: Andrey Lepikhov, Michael Paquier  
Discussion: https://postgr.es/m/a7e28b83-27b1-4e1c-c76b-4268c4b785bc@postgrespro.ru  

commit   : 8729fa72483f8a9acf299508bb2cbae1aa9a29b8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Dec 2019 17:51:46 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Dec 2019 17:51:46 -0500    

Oversight in commit 2e4db241b.  
  
Nathan Bossart  
  
Discussion: https://postgr.es/m/1B616360-396A-4482-AA28-375566C86160@amazon.com  

commit   : 877b61e9ce95934c71a9c01614db4be1b395fff6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 Dec 2019 21:15:30 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 10 Dec 2019 21:15:30 +0100    

Clean up some comments (some generated by old versions of autoconf)  
and some random ordering differences, so it's easier to diff this  
against the default pg_config.h or pg_config.h.in.  Remove LOCALEDIR  
handling from pg_config.h.win32 altogether because it's already in  
pg_config_paths.h.  

commit   : 6cafde1bd43f1c28b044953cac2f2999eb425b22    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Dec 2019 17:09:32 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Dec 2019 17:09:32 -0300    

This provides a mechanism to emit literal values in informative  
messages, such as query parameters.  The new code is more complex than  
what it replaces, primarily because it wants to be more efficient.  
It also has the (currently unused) additional optional capability of  
specifying a maximum size to print.  
  
The new function lives out of common/stringinfo.c so that frontend users  
of that file need not pull in unnecessary multibyte-encoding support  
code.  
  
Author: Álvaro Herrera and Alexey Bashtanov, after a suggestion from Andres Freund  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/20190920203905.xkv5udsd5dxfs6tr@alap3.anarazel.de  

commit   : 0da33c762b85aeada111aa1371c33ac6737f8396    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Dec 2019 13:17:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Dec 2019 13:17:08 -0500    

On Windows, we use CMD.EXE to redirect the postmaster's stdout/stderr  
into a log file.  CMD.EXE will open that file with non-sharing-friendly  
parameters, and the file will remain open for a short time after the  
postmaster has removed postmaster.pid.  This can result in an  
ERROR_SHARING_VIOLATION failure if we attempt to start a new postmaster  
immediately with the same log file (e.g. during "pg_ctl restart").  
This seems to explain intermittent buildfarm failures we've been seeing  
on Windows machines.  
  
To fix, just open and close the log file using our own pgwin32_open(),  
which will wait if necessary to avoid the failure.  (Perhaps someday  
we should stop using CMD.EXE, but that would be a far more complex  
patch, and it doesn't seem worth the trouble ... yet.)  
  
Back-patch to v12.  This only solves the problem when frontend fopen()  
is redirected to pgwin32_fopen(), which has only been true since commit  
0ba06e0bf.  Hence, no point in back-patching further, unless we care  
to back-patch that change too.  
  
Diagnosis and patch by Alexander Lakhin (bug #16154).  
  
Discussion: https://postgr.es/m/16154-1ccf0b537b24d5e0@postgresql.org  

commit   : 5a20b0219e7684788a1b63e812dd44b31361b259    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 10 Dec 2019 18:00:30 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 10 Dec 2019 18:00:30 +0900    

AfterTriggerExecute() retrieves a fresh tuple or pair of tuples from a  
tuplestore and then stores the tuple(s) in the passed-in slot(s) if  
AFTER_TRIGGER_FDW_FETCH, while it uses the most-recently-retrieved  
tuple(s) stored in the slot(s) if AFTER_TRIGGER_FDW_REUSE.  This was  
done correctly before 12, but commit ff11e7f4b broke it by mistakenly  
clearing the tuple(s) stored in the slot(s) in that function, leading to  
an assertion failure as reported in bug #16139 from Alexander Lakhin.  
  
Also, fix some other issues with the aforementioned commit in passing:  
  
* For tg_newslot, which is a slot added to the TriggerData struct by the  
  commit to store new updated tuples, it didn't ensure the slot was NULL  
  if there was no such tuple.  
* The commit failed to update the documentation about the trigger  
  interface.  
  
Author: Etsuro Fujita  
Backpatch-through: 12  
Discussion: https://postgr.es/m/16139-94f9ccf0db6119ec%40postgresql.org  

commit   : 28e6a2fd6358c1b75ce2f4e7cb3fcff979dbe539    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Dec 2019 15:03:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Dec 2019 15:03:51 -0500    

pg_signal_dispatch_thread() responded to the client (signal sender)  
and disconnected the pipe before actually setting the shared variables  
that make the signal visible to the backend process's main thread.  
In the worst case, it seems, effective delivery of the signal could be  
postponed for as long as the machine has any other work to do.  
  
To fix, just move the pg_queue_signal() call so that we do it before  
responding to the client.  This essentially makes pgkill() synchronous,  
which is a stronger guarantee than we have on Unix.  That may be  
overkill, but on the other hand we have not seen comparable timing bugs  
on any Unix platform.  
  
While at it, add some comments to this sadly underdocumented code.  
  
Problem diagnosis and fix by Amit Kapila; I just added the comments.  
  
Back-patch to all supported versions, as it appears that this can cause  
visible NOTIFY timing oddities on all of them, and there might be  
other misbehavior due to slow delivery of other signals.  
  
Discussion: https://postgr.es/m/32745.1575303812@sss.pgh.pa.us  

commit   : 99351a8b5a3882ee5d131bd37d03a67ab07b4fea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Dec 2019 14:31:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Dec 2019 14:31:57 -0500    

isolationtester.c had a hard-wired limit of 3 minutes per test step.  
It now emerges that this isn't quite enough for some of the slowest  
buildfarm animals.  This isn't the first time we've had to raise  
this limit (cf. 1db439ad4), so let's make it configurable.  This  
patch raises the default to 5 minutes, and introduces an environment  
variable PGISOLATIONTIMEOUT that can be set if more time is needed,  
following the precedent of PGCTLTIMEOUT.  
  
Also, modify isolationtester so that when the timeout is hit,  
it explicitly reports having sent a cancel.  This makes the regression  
failure log considerably more intelligible.  (In the worst case, a  
timed-out test might actually be reported as "passing" without this  
extra output, so arguably this is a bug fix in itself.)  
  
In passing, update the README file, which had apparently not gotten  
touched when we added "make check" support here.  
  
Back-patch to 9.6; older versions don't have comparable timeout logic.  
  
Discussion: https://postgr.es/m/22964.1575842935@sss.pgh.pa.us  

commit   : 2d0fdfaccec8b314895e026018874dcc5565b43e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 9 Dec 2019 08:39:34 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 9 Dec 2019 08:39:34 +0530    

Commit f13ea95f9e moved the description of postmaster.pid file contents  
from miscadmin.h to pidfile.h, but missed to update the comments in  
miscinit.c.  
  
Author: Hadi Moshayedi  
Reviewed-by: Amit Kapila  
Backpatch-through: 10  
Discussion: https://postgr.es/m/CAK=1=WpYEM9x3LGkaxgXaxeYQjnkdW8XLsxrYRTE2Gq-H83FMw@mail.gmail.com  

commit   : fd5e16e782fc6cd829b27e2c83c623b8020e5774    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 8 Dec 2019 11:06:26 -0800    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 8 Dec 2019 11:06:26 -0800    

Commit 5770172cb0c9df9e6ce27c507b449557e5b45124 wrote, incorrectly, that  
certain schema usage patterns are secure against CREATEROLE users and  
database owners.  When an untrusted user is the database owner or holds  
CREATEROLE privilege, a query is secure only if its session started with  
SELECT pg_catalog.set_config('search_path', '', false) or equivalent.  
Back-patch to 9.4 (all supported versions).  
  
Discussion: https://postgr.es/m/20191013013512.GC4131753@rfd.leadboat.com  

commit   : a395e21e989af0c2aab9dd1b1e0a1842ca42a063    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Dec 2019 10:36:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Dec 2019 10:36:29 -0500    

Tatsuo Ishii complained that this para wasn't very intelligible.  
Try to make it better.  
  
Discussion: https://postgr.es/m/20191207.200500.989741087350666720.t-ishii@sraoss.co.jp  

commit   : e75b1e33710249d1699850920c0390fb08ea5673    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 7 Dec 2019 09:20:53 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 7 Dec 2019 09:20:53 -0500    

This partially reverts commit 4dc6355210.  
  
The information returned by the function can be obtained by calling  
PQconninfo(), so the function is redundant.  

commit   : 830d1c73b3f4524bc897ddab5c6c3b47840c915a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Dec 2019 17:40:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Dec 2019 17:40:24 -0500    

While fooling around with the EXPLAIN improvements I've been working  
on, I noticed that there were some large gaps in our test coverage  
of ruleutils.c, according to the code coverage report.  This commit  
just adds a few test cases to improve coverage of:  
get_name_for_var_field()  
get_update_query_targetlist_def()  
isSimpleNode()  
get_sublink_expr()  

commit   : 30d47723fd151641e89d18ce775f1a102ff07ae2    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 6 Dec 2019 11:47:59 -0800    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 6 Dec 2019 11:47:59 -0800    

Commit 5dfc1981 missed updating some comments.  
  
Also, fix a comment typo found in passing.  
  
Author: Jeff Davis  
Discussion: https://postgr.es/m/9723131d247b919f94699152647fa87ee0bc02c2.camel%40j-davis.com  

commit   : fbbf68094c5ff3d513969d072126c92932e484da    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Dec 2019 11:25:09 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Dec 2019 11:25:09 -0500    

When creating a uniqueness constraint using a pre-existing index,  
we have always required that the index have the same properties you'd  
get if you just let a new index get built.  However, when collations  
were added, we forgot to add the index's collation to that check.  
  
It's hard to trip over this without intentionally trying to break it:  
you'd have to explicitly specify a different collation in CREATE  
INDEX, then convert it to a pkey or unique constraint.  Still, if you  
did that, pg_dump would emit a script that fails to reproduce the  
index's collation.  The main practical problem is that after a  
pg_upgrade the index would be corrupt, because its actual physical  
order wouldn't match what pg_index says.  A more theoretical issue,  
which is new as of v12, is that if you create the index with a  
nondeterministic collation then it wouldn't be enforcing the normal  
notion of uniqueness, causing the constraint to mean something  
different from a normally-created constraint.  
  
To fix, just add collation to the conditions checked for index  
acceptability in ADD PRIMARY KEY/UNIQUE USING INDEX.  We won't try  
to clean up after anybody who's already created such a situation;  
it seems improbable enough to not be worth the effort involved.  
(If you do get into trouble, a REINDEX should be enough to fix it.)  
  
In principle this is a long-standing bug, but I chose not to  
back-patch --- the odds of causing trouble seem about as great  
as the odds of preventing it, and both risks are very low anyway.  
  
Per report from Alexey Bashtanov, though this is not his preferred  
fix.  
  
Discussion: https://postgr.es/m/b05ce36a-cefb-ca5e-b386-a400535b1c0b@imap.cc  

commit   : 7d0bcb04771764aa3023e5a5089459d40dbd5e65    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Dec 2019 15:13:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Dec 2019 15:13:55 +0900    

This function is supported down to OpenSSL 0.9.8, which is the oldest  
version supported since 593d4e4 (from Postgres 10 onwards), and is used  
since e3bdb2d (from 11 onwards).  It is defined as a macro from OpenSSL  
0.9.8 to 1.0.2, and as a function in 1.1.0 and newer versions.  However,  
the configure check present is only adapted for functions.  So, even if  
the code would be able to compile, configure fails to detect the macro,  
causing it to be ignored when compiling the code with OpenSSL from 0.9.8  
to 1.0.2.  
  
The code needs a configure check as per a364dfa, which has fixed a  
compilation issue with a past version of LibreSSL in NetBSD 5.1.  On  
HEAD, just remove the configure check as the last release of NetBSD 5 is  
from 2014 (and we have no more buildfarm members for it).  In 11 and 12,  
improve the configure logic so as both macros and functions are  
correctly detected.  This makes NetBSD 5 still work on already-released  
branches, but not for 13 onwards.  
  
The patch for HEAD is from me, and Daniel has written the version to use  
for the back-branches.  
  
Author: Michael Paquier, Daniel Gustaffson  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/20191205083252.GE5064@paquier.xyz  
Discussion: https://postgr.es/m/98F7F99E-1129-41D8-B86B-FE3B1E286881@yesql.se  
Backpatch-through: 11  

commit   : 690c880269bf08dfb3f5bffb02be67e7e2a6c0f3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Dec 2019 11:55:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Dec 2019 11:55:04 +0900    

When restoring database schemas on a new cluster, database "template1"  
is processed first, followed by all other databases in parallel,  
including "postgres".  Both "postgres" and "template1" have some extra  
handling to propagate each one's properties, but comments were confusing  
regarding which one is processed where.  
  
Author: Julien Rouhaud  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/CAOBaU_a2iviTG7FE10yO_gcW+zQCHNFhRA_NDiktf3UR65BHdw@mail.gmail.com  

commit   : 28f4bba66b572d6b3b8dc4fcf4e585821e0a5363    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Dec 2019 09:41:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Dec 2019 09:41:32 +0900    

This function has been added in OpenSSL 0.9.8, which is the oldest  
version supported on HEAD, so checking for it at configure time is  
useless.  Both the frontend and backend code did not even bother to use  
it.  
  
Reported-by: Daniel Gustafsson  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson, Tom Lane  
Discussion: https://postgr.es/m/20191205083252.GE5064@paquier.xyz  
Discussion: https://postgr.es/m/98F7F99E-1129-41D8-B86B-FE3B1E286881@yesql.se  

commit   : 431ba7bebf139b6edf5544ce18f39a1a4dcb8110    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 5 Dec 2019 15:14:09 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 5 Dec 2019 15:14:09 -0500    

Add a new function ReceiveCopyData that does just that, taking a  
callback as an argument to specify what should be done with each chunk  
as it is received. This allows a single copy of the logic to be shared  
between ReceiveTarFile and ReceiveAndUnpackTarFile, and eliminates  
a few #ifdef conditions based on HAVE_LIBZ.  
  
While this is slightly more code, it's arguably clearer, and  
there is a pending patch that introduces additional calls to  
ReceiveCopyData.  
  
This commit is not intended to result in any functional change.  
  
Discussion: http://postgr.es/m/CA+TgmoYZDTHbSpwZtW=JDgAhwVAYvmdSrRUjOd+AYdfNNXVBDg@mail.gmail.com  

commit   : 42f362967d9f82043608610c689c24046e07497c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 5 Dec 2019 07:53:12 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 5 Dec 2019 07:53:12 -0500    

Remove a duplicated word. Add "of" or "# of" in a couple places  
for clarity and consistency. Start comments with a lower case  
letter as we do elsewhere in this file.  
  
Rafia Sabih  

commit   : 9a798234963cd1f746ded41453392c257a4f9fdd    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 4 Dec 2019 20:15:11 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 4 Dec 2019 20:15:11 -0300    

It now needs libpgcommon in order to get pnstrdup.  
  
Per buildfarm.  

commit   : 0b9466fce2cf4f8c32b3a9170ca272829aa11e66    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 4 Dec 2019 19:36:06 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 4 Dec 2019 19:36:06 -0300    

We already had it on the backend.  Frontend can also use it now.  
  
Discussion: https://postgr.es/m/20191204144021.GA17976@alvherre.pgsql  

commit   : b1abfec825472434ea445b9700eaa80cde9da86a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Dec 2019 21:40:17 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 4 Dec 2019 21:40:17 +0100    

Change default of ssl_min_protocol_version to TLSv1.2 (from TLSv1,  
which means 1.0).  Older versions are still supported, just not by  
default.  
  
TLS 1.0 is widely deprecated, and TLS 1.1 only slightly less so.  All  
OpenSSL versions that support TLS 1.1 also support TLS 1.2, so there  
would be very little reason to, say, set the default to TLS 1.1  
instead on grounds of better compatibility.  
  
The test suite overrides this new setting, so it can still run with  
older OpenSSL versions.  
  
Discussion: https://www.postgresql.org/message-id/flat/b327f8df-da98-054d-0cc5-b76a857cfed9%402ndquadrant.com  

commit   : 4af77aa797d95f9f77d7b88a41b4e02bc62d8975    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 4 Dec 2019 12:45:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 4 Dec 2019 12:45:00 +0900    

commit   : d37ddb745be07502814635585cbf935363c8a33d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Dec 2019 11:33:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Dec 2019 11:33:14 +0900    

This is similar to what pg_basebackup and pg_rewind do when reporting  
cumulative data, and that's more user-friendly.  Carriage returns are  
now used when stderr points to a terminal, and newlines are used in  
other cases, like a redirection to a log file.  
  
Author: Amit Langote  
Reviewed-by: Fabien Coelho  
Discussion: https://postgr.es/m/CA+HiwqFNwEjPeVaQsp2L7DyCPv1Eg1guwhrVhzMYqUJUk8ULKg@mail.gmail.com  

commit   : 85b9ef5fe7533e5d07dcf2a2b67c8855a34e5125    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Dec 2019 10:06:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Dec 2019 10:06:45 +0900    

This variable is now part of the refactored code for query cancellation  
in fe_utils.  This fixes an oversight in commit a4fd3aa.  While on it,  
improve some header includes in bin/scripts/.  
  
Author: Michael Paquier  
Reviewed-by: Fabien Coelho  
Discussion: https://postgr.es/m/20191203101625.GF1634@paquier.xyz  

commit   : b5273943679d22f58f1e1e269ad75e791172f557    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 3 Dec 2019 16:55:51 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 3 Dec 2019 16:55:51 +0100    

The dict_int text search dictionary template accepts maxlen parameter,  
which is then used to cap the length of input strings. The value was  
not properly checked, and the code simply does  
  
    txt[d->maxlen] = '\0';  
  
to insert a terminator, leading to segfaults with negative values.  
  
This commit simply rejects values less than 1. The issue was there since  
dct_int was introduced in 9.3, so backpatch all the way back to 9.4  
which is the oldest supported version.  
  
Reported-by: cili  
Discussion: https://postgr.es/m/16144-a36a5bef7657047d@postgresql.org  
Backpatch-through: 9.4  

commit   : bf39b3af6a9c6a036aae0742cf339fce662eee3a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Dec 2019 12:25:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 3 Dec 2019 12:25:56 -0500    

EXPLAIN generally only adds schema qualifications to table names when  
VERBOSE is specified.  In postgres_fdw's "Relations" output, table  
names were always so qualified, but that was an implementation  
restriction: in the original coding, we didn't have access to the  
verbose flag at the time the string was generated.  After the code  
rearrangement of commit 4526951d5, we do have that info available  
at the right time, so make this output follow the normal rule.  
  
Discussion: https://postgr.es/m/12424.1575168015@sss.pgh.pa.us  

commit   : 68ab982906187fba3530a01b01eb065ea9134298    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Dec 2019 18:59:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Dec 2019 18:59:09 +0900    

Error messages referring to incorrect WAL segment names could have been  
generated for a fsync() failure or when creating a new segment at the  
end of recovery.  

commit   : 88d45ac752ae49dbfafeb163b07381d3b8a6b601    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Dec 2019 09:14:35 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Dec 2019 09:14:35 +0100    

Add workaround for disabling ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS  
warning for the test that tries to create a tablespace with a reserved  
name.  
  
Discussion: https://www.postgresql.org/message-id/flat/E1iacW7-0003h6-6U%40gemulon.postgresql.org  

commit   : 9989d37d1c8dff12f20a1de8e1f470093136c893    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Dec 2019 15:06:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Dec 2019 15:06:04 +0900    

XLogFileNameP() is a wrapper routine able to build a palloc'd string for  
a WAL segment name, which is used for error string generation.  There  
were several code paths where it gets called in a critical section,  
where memory allocation is not allowed.  This results in triggering  
an assertion failure instead of generating the wanted error message.  
  
Another, more annoying, problem is that if the allocation to generate  
the WAL segment name fails on OOM, then the failure would be escalated  
to a PANIC.  
  
This removes the routine and all its callers are replaced with a logic  
using a fixed-size buffer.  This way, all the existing mistakes are  
fixed and future ones are prevented.  
  
Author: Masahiko Sawada  
Reviewed-by: Michael Paquier, Álvaro Herrera  
Discussion: https://postgr.es/m/CA+fd4k5gC9H4uoWMLg9K_QfNrnkkdEw+-AFveob9YX7z8JnKTA@mail.gmail.com  

commit   : e5532f194c18e6c12c3aa9cb07291973dc8adb39    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Dec 2019 13:01:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Dec 2019 13:01:06 +0900    

On Windows, all the hosts spawned by the TAP tests bind to 127.0.0.1.  
Hence, if there is a port conflict, starting a cluster would immediately  
fail.  One of the test scripts of pg_ctl initializes a node without  
PostgresNode.pm, using the default port 5432.  This could cause  
unexpected startup failures in the tests if an independent server was up  
and running on the same host (the reverse is also possible, though more  
unlikely).  Fix this issue by assigning properly a free port to the node  
configured, in the same range used as for the other nodes part of the  
tests.  
  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/20191202031444.GC1696@paquier.xyz  
Backpatch-through: 11  

commit   : 55a1954da16e041f895e5c3a6abff13c5e3a4a2f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2019 19:08:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2019 19:08:10 -0500    

If an inheritance/partitioning parent table is assigned some column  
alias names in the query, EXPLAIN mapped those aliases onto the  
child tables' columns by physical position, resulting in bogus output  
if a child table's columns aren't one-for-one with the parent's.  
  
To fix, make expand_single_inheritance_child() generate a correctly  
re-mapped column alias list, rather than just copying the parent  
RTE's alias node.  (We have to fill the alias field, not just  
adjust the eref field, because ruleutils.c will ignore eref in  
favor of looking at the real column names.)  
  
This means that child tables will now always have alias fields in  
plan rtables, where before they might not have.  That results in  
a rather substantial set of regression test output changes:  
EXPLAIN will now always show child tables with aliases that match  
the parent table (usually with "_N" appended for uniqueness).  
But that seems like a net positive for understandability, since  
the parent alias corresponds to something that actually appeared  
in the original query, while the child table names didn't.  
(Note that this does not change anything for cases where an explicit  
table alias was written in the query for the parent table; it  
just makes cases without such aliases behave similarly to that.)  
Hence, while we could avoid these subsidiary changes if we made  
inherit.c more complicated, we choose not to.  
  
Discussion: https://postgr.es/m/12424.1575168015@sss.pgh.pa.us  

commit   : ce76c0ba53e4bd0daf3db7a703671b27797b7244    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2019 18:05:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2019 18:05:29 -0500    

This provides for cheaper mapping of child columns back to parent  
columns.  The one existing use-case in examine_simple_variable()  
would hardly justify this by itself; but an upcoming bug fix will  
make use of this array in a mainstream code path, and it seems  
likely that we'll find other uses for it as we continue to build  
out the partitioning infrastructure.  
  
Discussion: https://postgr.es/m/12424.1575168015@sss.pgh.pa.us  

commit   : 4526951d564a7eed512b4a0ac3b5893e0a115690    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2019 16:31:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2019 16:31:03 -0500    

The relation aliases shown in the "Relations" line for a foreign scan  
didn't always agree with those used in the rest of EXPLAIN's output.  
The regression test result changes appearing here provide examples.  
  
It's really impossible for postgres_fdw to duplicate EXPLAIN's alias  
assignment logic during postgresGetForeignRelSize(), because of the  
de-duplication that EXPLAIN does on a global basis --- and anyway,  
trying to duplicate that would be unmaintainable.  Instead, just put  
numeric rangetable indexes into the string, and convert those to  
table names/aliases in postgresExplainForeignScan, which does have  
access to the results of ruleutils.c's alias assignment logic.  
Aside from being more reliable, this shifts some work from planning  
to EXPLAIN, which is a good tradeoff for performance.  (I also  
changed from using StringInfo to using psprintf, which makes the  
code slightly simpler and reduces its memory consumption.)  
  
A kluge required by this solution is that we have to reverse-engineer  
the rtoffset applied by setrefs.c.  If that logic ever fails  
(presumably because the member tables of a join got offset by  
different amounts), we'll need some more cooperation with setrefs.c  
to keep things straight.  But for now, there's no need for that.  
  
Arguably this is a back-patchable bug fix, but since this is a mostly  
cosmetic issue and there have been no field complaints, I'll refrain  
for now.  
  
Discussion: https://postgr.es/m/12424.1575168015@sss.pgh.pa.us  

commit   : 1d468b9ad81b9139b4a0b16b416c3597925af4b0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Dec 2019 11:42:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Dec 2019 11:42:28 +0900    

This can be useful to stop data generation happening on the server for  
long-running queries caused by large scale factors.  This cannot happen  
by default as data is generated on the client, but it is possible to  
control the initialization steps of pgbench to do that.  
  
Reported-by: Fujii Masao  
Author: Fabien Coelho  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1910311939430.27369@lancre  
Discussion: https://postgr.es/m/CAHGQGwHWEyTXxZh46qgFY8a2bDF_EYeUdp3+_Hy=qLZSzwVPKg@mail.gmail.com  

commit   : a4fd3aa719e8f97299dfcf1a8f79b3017e2b8d8b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Dec 2019 11:18:56 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Dec 2019 11:18:56 +0900    

Originally, this code was duplicated in src/bin/psql/ and  
src/bin/scripts/, but it can be useful for other frontend applications,  
like pgbench.  This refactoring offers the possibility to setup a custom  
callback which would get called in the signal handler for SIGINT or when  
the interruption console events happen on Windows.  
  
Author: Fabien Coelho, with contributions from Michael Paquier  
Reviewed-by: Álvaro Herrera, Ibrar Ahmed  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1910311939430.27369@lancre  

commit   : c01ac6dcba0aa65ad237c3af4a67bc70da8e4b0e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 1 Dec 2019 17:49:43 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 1 Dec 2019 17:49:43 -0500    

This rectifies an oversight in commit 4dc6355210, which caused certain  
builds to fail, especially on Windows.  

commit   : c35b714caff008c875b484656de7d168a7bc45f9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Dec 2019 13:09:26 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 1 Dec 2019 13:09:26 -0500    

We implement ON COMMIT DELETE ROWS by truncating tables marked that  
way, which requires also truncating/rebuilding their indexes.  But  
RelationTruncateIndexes asks the relcache for up-to-date copies of any  
index expressions, which may cause execution of eval_const_expressions  
on them, which can result in actual execution of subexpressions.  
This is a bad thing to have happening during ON COMMIT.  Manuel Rigger  
reported that use of a SQL function resulted in crashes due to  
expectations that ActiveSnapshot would be set, which it isn't.  
The most obvious fix perhaps would be to push a snapshot during  
PreCommit_on_commit_actions, but I think that would just open the door  
to more problems: CommitTransaction explicitly expects that no  
user-defined code can be running at this point.  
  
Fortunately, since we know that no tuples exist to be indexed, there  
seems no need to use the real index expressions or predicates during  
RelationTruncateIndexes.  We can set up dummy index expressions  
instead (we do need something that will expose the right data type,  
as there are places that build index tupdescs based on this), and  
just ignore predicates and exclusion constraints.  
  
In a green field it'd likely be better to reimplement ON COMMIT DELETE  
ROWS using the same "init fork" infrastructure used for unlogged  
relations.  That seems impractical without catalog changes though,  
and even without that it'd be too big a change to back-patch.  
So for now do it like this.  
  
Per private report from Manuel Rigger.  This has been broken forever,  
so back-patch to all supported branches.  

commit   : 4dc63552109f65cebbe168203bd62c5e4c753162    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 30 Nov 2019 15:27:13 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 30 Nov 2019 15:27:13 -0500    

This patch providies for support for password protected SSL client  
keys in libpq, and for DER format keys, both encrypted and unencrypted.  
There is a new connection parameter sslpassword, which is supplied to  
the OpenSSL libraries via a callback function. The callback function can  
also be set by an application by calling PQgetSSLKeyPassHook(). There is  
also a function to retreive the connection setting, PQsslpassword().  
  
Craig Ringer and Andrew Dunstan  
  
Reviewed by: Greg Nancarrow  
  
Discussion: https://postgr.es/m/f7ee88ed-95c4-95c1-d4bf-7b415363ab62@2ndQuadrant.com  

commit   : 3ff660bbeb96086cb1cf880bfb4e2e350cbd21b2    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 30 Nov 2019 14:51:27 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 30 Nov 2019 14:51:27 +0100    

When using %b or %B patterns to format a date, the code was simply using  
tm_mon as an index into array of month names. But that is wrong, because  
tm_mon is 1-based, while array indexes are 0-based. The result is we  
either use name of the next month, or a segfault (for December).  
  
Fix by subtracting 1 from tm_mon for both patterns, and add a regression  
test triggering the issue. Backpatch to all supported versions (the bug  
is there far longer, since at least 2003).  
  
Reported-by: Paul Spencer  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/16143-0d861eb8688d3fef%40postgresql.org  

commit   : 98a9b37ba70f24b28478360d9cf7f190b0f75f8d    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 30 Nov 2019 07:43:42 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 30 Nov 2019 07:43:42 +0530    

This commit revert the commits to add a test case that tests the 'force'  
option when there is an active backend connected to the database being  
dropped.  
  
This feature internally sends SIGTERM to all the backends connected to the  
database being dropped and then the same is reported to the client.  We  
found that on Windows, the client end of the socket is not able to read  
the data once we close the socket in the server which leads to loss of  
error message which is not what we expect.  We also observed  similar  
behavior in other cases like pg_terminate_backend(),  
pg_ctl kill TERM <pid>.  There are probably a few others like that.  The  
fix for this requires further study.  
  
Discussion: https://postgr.es/m/E1iaD8h-0004us-K9@gemulon.postgresql.org  

commit   : e6c2d17c5367ddcd900450c6a857dac8630da0ca    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 29 Nov 2019 10:55:31 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 29 Nov 2019 10:55:31 +0100    

FLOAT8PASSBYVAL can be used instead of USE_FLOAT8_BYVAL here.  

commit   : 7fc380f83d466b43a8f65bb52c925c1ab19736ea    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 29 Nov 2019 10:04:45 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 29 Nov 2019 10:04:45 +0100    

Add a regression test file that exercises the kinds of commands that  
allow_system_table_mods allows.  
  
This is put in the "unsafe_tests" suite, so it won't accidentally  
create a mess if someone runs the normal regression tests against an  
instance that they care about.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/8b00ea5e-28a7-88ba-e848-21528b632354%402ndquadrant.com  

commit   : c4a7a392ec8f0ff7701d84768080721ff8a7782e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 29 Nov 2019 10:04:45 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 29 Nov 2019 10:04:45 +0100    

Make allow_system_table_mods settable at run time by superusers.  It  
was previously postmaster start only.  
  
We don't want to make system catalog DDL wide-open, but there are  
occasionally useful things to do like setting reloptions or statistics  
on a busy system table, and blocking those doesn't help anyone.  Also,  
this enables the possibility of writing a test suite for this setting.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/8b00ea5e-28a7-88ba-e848-21528b632354%402ndquadrant.com  

commit   : 508bf95b767140ec1a339bcb53538d21deb9d995    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 29 Nov 2019 10:04:45 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 29 Nov 2019 10:04:45 +0100    

Previously, allow_system_table_mods allowed a non-superuser to do DML  
on a system table without further permission checks.  This has been  
removed, as it was quite inconsistent with the rest of the meaning of  
this setting.  (Since allow_system_table_mods was previously only  
accessible with a server restart, it is unlikely that anyone was using  
this possibility.)  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/8b00ea5e-28a7-88ba-e848-21528b632354%402ndquadrant.com  

commit   : d4feadeca1591fd5fe91bdf73a7897553f5366d7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 29 Nov 2019 09:10:17 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 29 Nov 2019 09:10:17 +0100    

Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/6e7aa4a1-be6a-1a75-b1f9-83a678e5184a@2ndquadrant.com  

commit   : c60e520f6e0e8db9618cad042df071a6752f3c06    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 28 Nov 2019 23:29:30 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 28 Nov 2019 23:29:30 +0100    

The byte loop used in pglz_decompress() because of possible overlap may  
be quite inefficient, so this commit replaces it with memcpy. The gains  
do depend on the data (compressibility) and hardware, but seem to be  
quite significant.  
  
Author: Andrey Borodin  
Reviewed-by: Michael Paquier, Konstantin Knizhnik, Tels  
Discussion: https://postgr.es/m/469C9ED9-348C-4FE7-A7A7-B0FA671BEE4C@yandex-team.ru  

commit   : 6d61c3f1cb7134c3ad80d29e216563571cc43de2    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 28 Nov 2019 23:25:14 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 28 Nov 2019 23:25:14 +0100    

Commit c676e659b2 reworked how choose_best_statistics() picks the best  
extended statistics, but failed to remove clauses_attnums which is now  
unnecessary. So get rid of it and backpatch to 12, same as c676e659b2.  
  
Author: Tomas Vondra  
Discussion: https://postgr.es/m/CA+u7OA7H5rcE2=8f263w4NZD6ipO_XOrYB816nuLXbmSTH9pQQ@mail.gmail.com  
Backpatch-through: 12  

commit   : c676e659b246f94d571b57b559f80cb2dc03e73b    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 28 Nov 2019 22:20:28 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 28 Nov 2019 22:20:28 +0100    

When picking the best extended statistics object for a list of clauses,  
it's not enough to look at attnums extracted from the clause list as a  
whole. Consider for example this query with OR clauses:  
  
   SELECT * FROM t WHERE (t.a = 1) OR (t.b = 1) OR (t.c = 1)  
  
with a statistics defined on columns (a,b). Relying on attnums extracted  
from the whole OR clause, we'd consider the statistics usable. That does  
not work, as we see the conditions as a single OR-clause, referencing an  
attribute not covered by the statistic, leading to empty list of clauses  
to be estimated using the statistics and an assert failure.  
  
This changes choose_best_statistics to check which clauses are actually  
covered, and only using attributes from the fully covered ones. For the  
previous example this means the statistics object will not be considered  
as compatible with the OR-clause.  
  
Backpatch to 12, where MCVs were introduced. The issue does not affect  
older versions because functional dependencies don't handle OR clauses.  
  
Author: Tomas Vondra  
Reviewed-by: Dean Rasheed  
Reported-By: Manuel Rigger  
Discussion: https://postgr.es/m/CA+u7OA7H5rcE2=8f263w4NZD6ipO_XOrYB816nuLXbmSTH9pQQ@mail.gmail.com  
Backpatch-through: 12  

commit   : 3974c4a72459fc07acef3ee1369d63a7b8305b62    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 28 Nov 2019 16:48:37 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 28 Nov 2019 16:48:37 -0300    

Discussion: https://postgr.es/m/20191128144653.GA27883@alvherre.pgsql  

commit   : 8a7e9e9dad56419ff987e5f6baaf411a03c1951a    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 28 Nov 2019 11:46:57 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 28 Nov 2019 11:46:57 +0530    

This will test that the force option works when there is an active backend  
connected to the database being dropped.  
  
Author: Pavel Stehule and Vignesh C  
Reviewed-by: Amit Kapila and Vignesh C  
Discussion: https://postgr.es/m/CAP_rwwmLJJbn70vLOZFpxGw3XD7nLB_7+NKz46H5EOO2k5H7OQ@mail.gmail.com  

commit   : 290acac92b1d7bebb4ec68fe8b7a5cb442333eda    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 28 Nov 2019 08:28:17 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 28 Nov 2019 08:28:17 +0530    

The subroutine pump_until provides the functionality to poll until the  
given string is matched, or a timeout occurs.  This can be used from other  
places as well, so moving it to TestLib.pm.  The immediate need is for an  
upcoming regression test patch for dropdb utility.  
  
Author: Vignesh C  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CAP_rwwmLJJbn70vLOZFpxGw3XD7nLB_7+NKz46H5EOO2k5H7OQ@mail.gmail.com  

commit   : 60b35b7f1ea1d5cd17805e30299fd21616855b7d    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 27 Nov 2019 20:36:33 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 27 Nov 2019 20:36:33 -0500    

Previously these error paragraphs were too wide.  
  
Backpatch-through: 13  

commit   : f0b57aec1d41f89611efac4d6938a725b056ed00    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 27 Nov 2019 20:24:57 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 27 Nov 2019 20:24:57 -0500    

This clarifies instructions on how to dump/reload databases that use  
incompatible isn versions.  
  
Reported-by: Alvaro Herrera  
  
Discussion: https://postgr.es/m/20191114190652.GA23586@alvherre.pgsql  
  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
  
Backpatch-through: 13  

commit   : f6f59826f01188aa9603983d00b0cd3496e9359d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 27 Nov 2019 15:45:44 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 27 Nov 2019 15:45:44 -0500    

Commit 114541d58e has upset some buildfarm members running Msys, that  
weren't previously having problems, so the use of native Windows methods  
to open files is restricted by this patch to only MSVC builds.  

commit   : ca266a069a20c32a8f0a1df982a5a67d9483bcb3    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 27 Nov 2019 07:19:22 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 27 Nov 2019 07:19:22 -0500    

This reverts commits 9af34f3c6b and 792dba73c8.  
  
The code has been found not to be portable.  
  
Discussion: https://postgr.es/m/2658c496-f885-02db-13bb-228423782524@2ndQuadrant.com  

commit   : 4513d8b07bf342028ca95250b6e1d759858abdd3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Nov 2019 11:21:02 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 Nov 2019 11:21:02 +0100    

This build option was once useful to maintain compatibility with  
version-0 functions, but those are no longer supported, so this option  
is no longer useful for end users.  We keep the option available to  
developers in pg_config_manual.h so that it is easy to test the  
pass-by-reference code paths without having to fire up a 32-bit  
machine.  
  
Discussion: https://www.postgresql.org/message-id/flat/f3e1e576-2749-bbd7-2d57-3f9dcf75255a@2ndquadrant.com  

commit   : 47a3c7fa06538c181be815db44b5d7e8efe696ef    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 27 Nov 2019 16:00:45 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 27 Nov 2019 16:00:45 +0900    

commit   : 792dba73c8f30528e51c4967d3be8ec4bdc5234b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 26 Nov 2019 16:23:00 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 26 Nov 2019 16:23:00 -0500    

Commit 9af34f3c6b naively assumed that all non-windows platforms would  
have pseudoterminals and that perl would have IO::Pty. Such is not the  
case. Instead of assumung anything, test for the presence of IO::Pty and  
only use code that might depend on it if it's present. The test result is  
exposed in $TestLib::have_io_pty so that it can be conveniently used in  
SKIP tests.  
  
Discussion: https://postgr.es/m/20191126044110.GB5435@paquier.xyz  

commit   : 553d2ec2710be5ae304c40134643c8f6d754af67    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Nov 2019 14:41:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 26 Nov 2019 14:41:48 -0500    

The fix for CVE-2017-7484 disallowed use of pg_statistic data for  
planning purposes if the user would not be able to select the associated  
column and a non-leakproof function is to be applied to the statistics  
values.  That turns out to disable use of pg_statistic data in some  
common cases involving inheritance/partitioning, where the user does  
have permission to select from the parent table that was actually named  
in the query, but not from a child table whose stats are needed.  Since,  
in non-corner cases, the user *can* select the child table's data via  
the parent, this restriction is not actually useful from a security  
standpoint.  Improve the logic so that we also check the permissions of  
the originally-named table, and allow access if select permission exists  
for that.  
  
When checking access to stats for a simple child column, we can map  
the child column number back to the parent, and perform this test  
exactly (including not allowing access if the child column isn't  
exposed by the parent).  For expression indexes, the current logic  
just insists on whole-table select access, and this patch allows  
access if the user can select the whole parent table.  In principle,  
if the child table has extra columns, this might allow access to  
stats on columns the user can't read.  In practice, it's unlikely  
that the planner is going to do any stats calculations involving  
expressions that are not visible to the query, so we'll ignore that  
fine point for now.  Perhaps someday we'll improve that logic to  
detect exactly which columns are used by an expression index ...  
but today is not that day.  
  
Back-patch to v11.  The issue was created in 9.2 and up by the  
CVE-2017-7484 fix, but this patch depends on the append_rel_array[]  
planner data structure which only exists in v11 and up.  In  
practice the issue is most urgent with partitioned tables, so  
fixing v11 and later should satisfy much of the practical need.  
  
Dilip Kumar and Amit Langote, with some kibitzing by me  
  
Discussion: https://postgr.es/m/3876.1531261875@sss.pgh.pa.us  

commit   : 12198239c0a5122e29619d50f76f89adc5bc7ade    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 Nov 2019 13:32:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 26 Nov 2019 13:32:52 +0900    

On some platforms, fsync() returns EBADFD when opening a file descriptor  
with O_RDONLY (read-only), leading ultimately now to a PANIC to prevent  
data corruption.  
  
This commit adds a new sanity check in pg_fsync() based on fcntl() to  
make sure that we don't repeat again mistakes with incorrectly-set file  
descriptors so as problems are detected at an early stage.  Without  
that, such errors could only be detected after running Postgres on a  
specific supported platform for the culprit code path, which could take  
some time before being found.  b8e19b93 was a fix for such a problem,  
which got undetected for more than 5 years, and a586cc4b fixed another  
similar issue.  
  
Note that the new check added works as well when fsync=off is  
configured, so as all regression tests would detect problems as long as  
assertions are enabled.  fcntl() being not available on Windows, the  
new checks do not happen there.  
  
Author: Michael Paquier  
Reviewed-by: Mark Dilger  
Discussion: https://postgr.es/m/20191009062640.GB21379@paquier.xyz  

commit   : 080313f8296fb0bcc74bd70fc8e15cd64f45945e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 18 Nov 2019 14:17:41 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 18 Nov 2019 14:17:41 +0530    

Revert part of commit 19df1702f5.  
  
Early shutdown was added by that commit so that we could collect  
statistics from workers, but unfortunately, it interacted badly with  
rescans.  The problem is that we ended up destroying the parallel context  
which is required for rescans.  This leads to rescans of a Limit node over  
a Gather node to produce unpredictable results as it tries to access  
destroyed parallel context.  By reverting the early shutdown code, we  
might lose statistics in some cases of Limit over Gather [Merge], but that  
will require further study to fix.  
  
Reported-by: Jerry Sievers  
Diagnosed-by: Thomas Munro  
Author: Amit Kapila, testcase by Vignesh C  
Backpatch-through: 9.6  
Discussion: https://postgr.es/m/87ims2amh6.fsf@jsievers.enova.com  

commit   : 0d3c3aae3366891f1c3d6bac326070660be36f76    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 25 Nov 2019 16:08:53 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 25 Nov 2019 16:08:53 -0500    

AuxiliaryProcessMain does ProcSignalInit, so one might expect that  
auxiliary processes would need to respond to SendProcSignal, but none  
of the auxiliary processes do that. Change them to use  
procsignal_sigusr1_handler instead of their own private handlers so  
that they do. Besides seeming more correct, this is also less code. It  
shouldn't make any functional difference right now because, as far as  
we know, there are no current cases where SendProcSignal targets an  
auxiliary process, but there are plans to change that in the future.  
  
Andres Freund  
  
Discussion: http://postgr.es/m/20181030051643.elbxjww5jjgnjaxg@alap3.anarazel.de  

commit   : 9af34f3c6b02779fac6dbb6cd4c5bb225a019f43    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 25 Nov 2019 15:51:51 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 25 Nov 2019 15:51:51 -0500    

Where possible, do this using a pseudoterminal, so that things like  
openssl that want to open /dev/tty if stdin isn't a tty won't.  
Elsewhere, i.e. Windows, just close by providing an empty string using  
the standard IPC::Run pipe mechanism.  
  
Patch by Andrew Dunstan, based on an idea from Craig Ringer.  
  
Reviewed by Mark Dilger.  
  
Discussion: https://postgr.es/m/873ebb57-fc98-340d-949d-691b1810bf66@2ndQuadrant.com  

commit   : 0dc8ead46363fec6f621a12c7e1f889ba73b55a9    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Nov 2019 15:04:54 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 25 Nov 2019 15:04:54 -0300    

XLogReader, walsender and pg_waldump all had their own routines to read  
data from WAL files to memory, with slightly different approaches  
according to the particular conditions of each environment.  There's a  
lot of commonality, so we can refactor that into a single routine  
WALRead in XLogReader, and move the differences to a separate (simpler)  
callback that just opens the next WAL-segment.  This results in a  
clearer (ahem) code flow.  
  
The error reporting needs are covered by filling in a new error-info  
struct, WALReadError, and it's the caller's responsibility to act on it.  
The backend has WALReadRaiseError() to do so.  
  
We no longer ever need to seek in this interface; switch to using  
pg_pread().  
  
Author: Antonin Houska, with contributions from Álvaro Herrera  
Reviewed-by: Michaël Paquier, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/14984.1554998742@spoje.net  

commit   : 5883f5fe27d7b52c812dd0f8cbda67373a14c451    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Nov 2019 10:48:36 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 25 Nov 2019 10:48:36 -0500    

"%ld" is not an acceptable format spec for int64 variables, though  
it accidentally works on most non-Windows 64-bit platforms.  Follow  
the lead of commit 6a1cd8b92, and use "%lld" with an explicit cast  
to long long.  Per buildfarm.  

commit   : e0487223ecac9cbb7f673e4ff6d2e4086e591abf    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 25 Nov 2019 08:08:57 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 25 Nov 2019 08:08:57 +0530    

Similar to commits 14aec03502, 7e735035f2 and dddf4cdc33, this commit  
makes the order of header file inclusion consistent in more places.  
  
Author: Vignesh C  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CALDaNm2Sznv8RR6Ex-iJO6xAdsxgWhCoETkaYX=+9DW3q0QCfA@mail.gmail.com  

commit   : 2aa84520b3508dda273b9bbffab7bf87f0d98bf8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 Nov 2019 09:57:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 Nov 2019 09:57:35 +0900    

Both argument names were reversed in the declaration of the function.  
  
Author: Ranier Vilela  
Discussion: https://postgr.es/m/MN2PR18MB292755AEFF9A9144B220ABEEE34B0@MN2PR18MB2927.namprd18.prod.outlook.com  

commit   : 4cb658af70027c3544fb843d77b2e84028762747    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 Nov 2019 09:40:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 Nov 2019 09:40:53 +0900    

This reworks the reloption parsing and build of a couple of index AMs by  
creating new structures for each index AM's options.  This split was  
already done for BRIN, GIN and GiST (which actually has a fillfactor  
parameter), but not for hash, B-tree and SPGiST which relied on  
StdRdOptions due to an overlap with the default option set.  
  
This saves a couple of bytes for rd_options in each relcache entry with  
indexes making use of relation options, and brings more consistency  
between all index AMs.  While on it, add a couple of AssertMacro() calls  
to make sure that utility macros to grab values of reloptions are used  
with the expected index AM.  
  
Author: Nikolay Shaplov  
Reviewed-by: Amit Langote, Michael Paquier, Álvaro Herrera, Dent John  
Discussion: https://postgr.es/m/4127670.gFlpRb6XCm@x200m  

commit   : 114541d58e5970e51b78b77b65de16210beaab43    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 24 Nov 2019 18:25:22 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 24 Nov 2019 18:25:22 -0500    

It is hoped that this will avoid some errors that we have seen before,  
but lately with greater frequency, in buildfarm animals.  
  
For now apply only to master. If this proves effective it can be  
backpatched.  
  
Discussion: https://postgr.es/m/13900.1572839580@sss.pgh.pa.us  
  
Author: Juan José Santamaría Flecha  

commit   : d3aa114ac4de9ecc558ba77ed5c85e2ad9ad01d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Nov 2019 18:03:39 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Nov 2019 18:03:39 -0500    

The user docs didn't really explain how to use LISTEN safely,  
so clarify that.  Also clean up some fuzzy-headed explanations  
in comments.  No code changes.  
  
Discussion: https://postgr.es/m/3ac7f397-4d5f-be8e-f354-440020675694@gmail.com  

commit   : 6b802cfc7fab0f38001ae465ccd4f7f565b6169d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Nov 2019 15:57:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Nov 2019 15:57:31 -0500    

If LISTEN is the only action in a serializable-mode transaction,  
and the session was not previously listening, and the notify queue  
is not empty, predicate.c reported an assertion failure.  That  
happened because we'd acquire the transaction's initial snapshot  
during PreCommit_Notify, which was called *after* predicate.c  
expects any such snapshot to have been established.  
  
To fix, just swap the order of the PreCommit_Notify and  
PreCommit_CheckForSerializationFailure calls during CommitTransaction.  
This will imply holding the notify-insertion lock slightly longer,  
but the difference could only be meaningful in serializable mode,  
which is an expensive option anyway.  
  
It appears that this is just an assertion failure, with no  
consequences in non-assert builds.  A snapshot used only to scan  
the notify queue could not have been involved in any serialization  
conflicts, so there would be nothing for  
PreCommit_CheckForSerializationFailure to do except assign it a  
prepareSeqNo and set the SXACT_FLAG_PREPARED flag.  And given no  
conflicts, neither of those omissions affect the behavior of  
ReleasePredicateLocks.  This admittedly once-over-lightly analysis  
is backed up by the lack of field reports of trouble.  
  
Per report from Mark Dilger.  The bug is old, so back-patch to all  
supported branches; but the new test case only goes back to 9.6,  
for lack of adequate isolationtester infrastructure before that.  
  
Discussion: https://postgr.es/m/3ac7f397-4d5f-be8e-f354-440020675694@gmail.com  
Discussion: https://postgr.es/m/13881.1574557302@sss.pgh.pa.us  

commit   : 1974853d899db69a72361a9052fd699c9dcd028e    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 25 Nov 2019 09:20:28 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 25 Nov 2019 09:20:28 +1300    

Back-patch to 10.  
  
Author: Andreas Karlsson  
Discussion: https://postgr.es/m/043acae2-a369-b7fa-be48-1933aa2e82d1%40proxel.se  

commit   : 7900269724424b6deca516eba3dd8e4bf6621bea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Nov 2019 14:42:59 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Nov 2019 14:42:59 -0500    

This patch ensures that, if any notify messages were received during  
a just-finished transaction, they get sent to the frontend just before  
not just after the ReadyForQuery message.  With libpq and other client  
libraries that act similarly, this guarantees that the client will see  
the notify messages as available as soon as it thinks the transaction  
is done.  
  
This probably makes no difference in practice, since in realistic  
use-cases the application would have to cope with asynchronous  
arrival of notify events anyhow.  However, it makes it a lot easier  
to build cross-session-notify test cases with stable behavior.  
I'm a bit surprised now that we've not seen any buildfarm instability  
with the test cases added by commit b10f40bf0.  Tests that I intend  
to add in an upcoming bug fix are definitely unstable without this.  
  
Back-patch to 9.6, which is as far back as we can do NOTIFY testing  
with the isolationtester infrastructure.  
  
Discussion: https://postgr.es/m/13881.1574557302@sss.pgh.pa.us  

commit   : 8b7ae5a82d04312672c919ecea3c30b1ec7faaf2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Nov 2019 14:09:33 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Nov 2019 14:09:33 -0500    

This function wasn't touched in commit 51004c717, but that turns out  
to be a bad idea, because its results now include any dead space  
that exists in the NOTIFY queue on account of our being lazy about  
advancing the queue tail.  Notably, the isolation tests now fail  
if run twice without a server restart between, because async-notify's  
first test of the function will already show a positive value.  
It seems likely that end users would be equally unhappy about the  
result's instability.  To fix, just make the function call  
asyncQueueAdvanceTail before computing its result.  That should end  
in producing the same value as before, and it's hard to believe that  
there's any practical use-case where pg_notification_queue_usage()  
is called so often as to create a performance degradation, especially  
compared to what we did before.  
  
Out of paranoia, also mark this function parallel-restricted (it  
was volatile, but parallel-safe by default, before).  Although the  
code seems to work fine when run in a parallel worker, that's outside  
the design scope of async.c, and it's a bit scary to have intentional  
side-effects happening in a parallel worker.  There seems no plausible  
use-case where it'd be important to try to parallelize this, so let's  
not take any risk of introducing new bugs.  
  
In passing, re-pgindent async.c and run reformat-dat-files on  
pg_proc.dat, just because I'm a neatnik.  
  
Discussion: https://postgr.es/m/13881.1574557302@sss.pgh.pa.us  

commit   : 91da65f4ac2837e0792071e42b2e2101059f1b1b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Nov 2019 12:03:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 24 Nov 2019 12:03:16 -0500    

Commit abd9ca377 replaced a couple of while-loops in fmtfloat()  
with calls to dopr_outchmulti, but I (tgl) failed to notice that  
the new if-tests guarding those calls were really unnecessary,  
because they're inside a larger if-block checking the same thing.  
  
Ranier Vilela  
  
Discussion: https://postgr.es/m/MN2PR18MB2927850AB00CF39CC370D107E34B0@MN2PR18MB2927.namprd18.prod.outlook.com  

commit   : 45ff049e288b0fc7d68195b25ba1a78522e7a45b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 23 Nov 2019 13:19:20 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 23 Nov 2019 13:19:20 -0300    

This Assert(false) was not supposed to be in the committed copy.  
  
Reported by: Tom Lane  
Discussion: https://postgr.es/m/26476.1574525468@sss.pgh.pa.us  

commit   : 4f66c93f61439b4db866b21cc1ecd5bf815564ef    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sat, 23 Nov 2019 10:41:52 -0500    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sat, 23 Nov 2019 10:41:52 -0500    

Use SELinux "db_table: { truncate }" to check if permission is granted to  
TRUNCATE. Update example SELinux policy to grant needed permission for  
TRUNCATE. Add new regression test to demonstrate a positive and negative  
cases. Test will only be run if the loaded SELinux policy has the  
"db_table: { truncate }" permission. Makes use of recent commit which added  
object TRUNCATE hook. Patch by Yuli Khodorkovskiy with minor  
editorialization by me. Not back-patched because the object TRUNCATE hook  
was not.  
  
Author: Yuli Khodorkovskiy  
Reviewed-by: Joe Conway  
Discussion: https://postgr.es/m/CAFL5wJcomybj1Xdw7qWmPJRpGuFukKgNrDb6uVBaCMgYS9dkaA%40mail.gmail.com  

commit   : f7a2002e82cfc639d1b6df89012f5d6c623ad545    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sat, 23 Nov 2019 10:39:20 -0500    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sat, 23 Nov 2019 10:39:20 -0500    

All operations with acl permissions checks should have a corresponding hook  
so that, for example, mandatory access control (MAC) may be enforced by an  
extension. The command TRUNCATE is missing this hook, so add it. Patch by  
Yuli Khodorkovskiy with some editorialization by me. Based on the discussion  
not back-patched. A separate patch will exercise the hook in the sepgsql  
extension.  
  
Author: Yuli Khodorkovskiy  
Reviewed-by: Joe Conway  
Discussion: https://postgr.es/m/CAFL5wJcomybj1Xdw7qWmPJRpGuFukKgNrDb6uVBaCMgYS9dkaA%40mail.gmail.com  

commit   : d1c866e57f1156000a51ff7e26590984d32bab53    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2019 17:07:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2019 17:07:54 -0500    

Up to now, whatever you'd edited was put back into the query buffer  
but not redisplayed, which is less than user-friendly.  But we can  
improve that just by printing the text along with a prompt, if we  
enforce that the editing result ends with a newline (which it  
typically would anyway).  You then continue typing more lines if  
you want, or you can type ";" or do \g or \r or another \e.  
  
This is intentionally divorced from readline's processing,  
for simplicity and so that it works the same with or without  
readline enabled.  We discussed possibly integrating things  
more closely with readline; but that seems difficult, uncertainly  
portable across different readline and libedit versions, and  
of limited real benefit anyway.  Let's try the simple way and  
see if it's good enough.  
  
Patch by me, thanks to Fabien Coelho and Laurenz Albe for review  
  
Discussion: https://postgr.es/m/13192.1572318028@sss.pgh.pa.us  

commit   : 73b06cf893c9d3bb38c11878a12cc29407e78b6c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2019 15:02:18 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2019 15:02:18 -0500    

We already used this optimization if the plpgsql function is read-only.  
But it seems okay to do it even in a read-write function, if the  
expression contains only immutable functions/operators.  There would  
only be a change of behavior if an "immutable" called function depends  
on seeing database updates made during the current plpgsql function.  
That's enough of a violation of the promise of immutability that anyone  
who complains won't have much of a case.  
  
The benefits are significant --- for simple cases like  
  
  while i < 10000000  
  loop  
    i := i + 1;  
  end loop;  
  
I see net performance improvements around 45%.  Of course, real-world  
cases won't get that much faster, but it ought to be noticeable.  
At the very least, this removes much of the performance penalty that  
used to exist for forgetting to mark a plpgsql function non-volatile.  
  
Konstantin Knizhnik, reviewed by Pavel Stehule, cosmetic changes by me  
  
Discussion: https://postgr.es/m/ed9da20e-01aa-d04b-d085-e6c16b14b9d7@postgrespro.ru  

commit   : f67b173771a0525ff7f2010d2d57d63d7f546352    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2019 12:52:26 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2019 12:52:26 -0500    

It seems pretty unacceptable to have no regression test coverage  
for this aspect of the logical replication protocol, especially  
given the bugs we've found in related code.  
  
Discussion: https://postgr.es/m/16129-a0c0f48e71741e5f@postgresql.org  

commit   : 4d9ceb0018cc087e267f978c90917b3195542e22    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2019 11:31:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 22 Nov 2019 11:31:19 -0500    

slot_modify_cstrings seriously abused the TupleTableSlot API by relying  
on a slot's underlying data to stay valid across ExecClearTuple.  Since  
this abuse was also quite undocumented, it's little surprise that the  
case got broken during the v12 slot rewrites.  As reported in bug #16129  
from Ondřej Jirman, this could lead to crashes or data corruption when  
a logical replication subscriber processes a row update.  Problems would  
only arise if the subscriber's table contained columns of pass-by-ref  
types that were not being copied from the publisher.  
  
Fix by explicitly copying the datum/isnull arrays from the source slot  
that the old row was in already.  This ends up being about the same  
thing that happened pre-v12, but hopefully in a less opaque and  
fragile way.  
  
We might've caught the problem sooner if there were any test cases  
dealing with updates involving non-replicated or dropped columns.  
Now there are.  
  
Back-patch to v10 where this code came in.  Even though the failure  
does not manifest before v12, IMO this code is too fragile to leave  
as-is.  In any case we certainly want the additional test coverage.  
  
Patch by me; thanks to Tomas Vondra for initial investigation.  
  
Discussion: https://postgr.es/m/16129-a0c0f48e71741e5f@postgresql.org  

commit   : 8959a5e0fa2926b0f99e055e63fb4d81e1dcb3a0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Nov 2019 21:14:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Nov 2019 21:14:54 +0900    

A set of SQL files are generated for the tutorial when compiling the  
code, so let's avoid any risk to have them added in the tree in the  
future.  

commit   : a9d5157ae8a7680b496d56f4edc3a43feff708c4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Nov 2019 21:08:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 22 Nov 2019 21:08:49 +0900    

Support has been removed as of 5ded4bd, but code related to the tutorial  
still used it.  Functions using version-1 are already present for some  
time in the tutorial, and the documentation mentions them, so just  
replace the old version with the new one.  
  
Reported-by: Pavel Stehule  
Analyzed-by: Euler Taveira  
Author: Michael Paquier  
Reviewed-by: Tom Lane, Pavel Stehule  
Discussion: https://postgr.es/m/CAFj8pRCgC2uDzrw-vvanXu6Z3ofyviEOQPEpH6_aL4OCe7JRag@mail.gmail.com  

commit   : 4a0aab14dcb35550b55e623a3c194442c5666084    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Nov 2019 16:21:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 21 Nov 2019 16:21:43 -0500    

While a self-referential view doesn't actually work, it's possible  
to create one, and it turns out that this breaks some of the  
information_schema views.  Those views call relation_is_updatable(),  
which neglected to consider the hazards of being recursive.  In  
older PG versions you get a "stack depth limit exceeded" error,  
but since v10 it'd recurse to the point of stack overrun and crash,  
because commit a4c35ea1c took out the expression_returns_set() call  
that was incidentally checking the stack depth.  
  
Since this function is only used by information_schema views, it  
seems like it'd be better to return "not updatable" than suffer  
an error.  Hence, add tracking of what views we're examining,  
in just the same way that the nearby fireRIRrules() code detects  
self-referential views.  I added a check_stack_depth() call too,  
just to be defensive.  
  
Per private report from Manuel Rigger.  Back-patch to all  
supported versions.  

commit   : 2e4db241bfd3206bad8286f8ffc2db6bbdaefcdf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 21 Nov 2019 18:00:07 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 21 Nov 2019 18:00:07 +0100    

This build option was only useful to maintain compatibility for  
version-0 functions, but those are no longer supported, so this option  
can be removed.  
  
float4 is now always pass-by-value; the pass-by-reference code path is  
completely removed.  
  
Discussion: https://www.postgresql.org/message-id/flat/f3e1e576-2749-bbd7-2d57-3f9dcf75255a@2ndquadrant.com  

commit   : 43a54a3bccd7dc6be798475214d561f3e93b3055    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 21 Nov 2019 22:17:28 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 21 Nov 2019 22:17:28 +0900    

Oversight in commit e6d8069522. Since that commit changed the format of  
XLOG_DBASE_DROP WAL record, XLOG_PAGE_MAGIC needs to be bumped.  
  
Spotted by Michael Paquier  

commit   : e6d8069522c8bde8239dd1fedfb4984efa4b3a1a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 21 Nov 2019 21:10:37 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 21 Nov 2019 21:10:37 +0900    

Previously DROP DATABASE generated as many XLOG_DBASE_DROP WAL records  
as the number of tablespaces that the database to drop uses. This caused  
the scans of shared_buffers as many times as the number of the tablespaces  
during recovery because WAL replay of one XLOG_DBASE_DROP record needs  
that full scan. This could make the recovery time longer especially  
when shared_buffers is large.  
  
This commit changes DROP DATABASE so that it generates only one  
XLOG_DBASE_DROP record, and registers the information of all the tablespaces  
into it. Then, WAL replay of XLOG_DBASE_DROP record needs full scan of  
shared_buffers only once, and which may improve the recovery performance.  
  
Author: Fujii Masao  
Reviewed-by: Kirk Jamison, Simon Riggs  
Discussion: https://postgr.es/m/CAHGQGwF8YwNH0ZaL+2wjZPkj+ji9UhC+Z4ScnG97WKtVY5L9iw@mail.gmail.com  

commit   : 30840c92ac0c4073fb7bc8222317630571b8cf25    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 21 Nov 2019 19:55:13 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 21 Nov 2019 19:55:13 +0900    

ALTER TABLE RENAME COLUMN command always can be used to rename the column  
in the view, but it's reasonable to add that syntax to ALTER VIEW too.  
  
Author: Fujii Masao  
Reviewed-by: Ibrar Ahmed, Yu Kimura  
Discussion: https://postgr.es/m/CAHGQGwHoQMD3b-MqTLcp1MgdhCpOKU7QNRwjFooT4_d+ti5v6g@mail.gmail.com  

commit   : 61a956d9cca3f72acb279c9c00f1d9cd47bbc934    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 21 Nov 2019 19:22:37 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 21 Nov 2019 19:22:37 +0900    

Author: Takao Fujii  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/f9dcdef78c124517edc9e5e5880f651e@oss.nttdata.com  

commit   : 9290ad198b15d6b986b855d2a58d087a54777e87    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 16 Nov 2019 18:24:00 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 16 Nov 2019 18:24:00 +0530    

This adds the statistics about transactions spilled to disk from  
ReorderBuffer.  Users can query the pg_stat_replication view to check  
these stats.  
  
Author: Tomas Vondra, with bug-fixes and minor changes by Dilip Kumar  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com  

commit   : 168d2064001f704965899bb2057591271c44e57a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Nov 2019 10:23:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 Nov 2019 10:23:28 +0900    

Trying to use hypothetical indexes with BRIN currently fails when trying  
to access a relation that does not exist when looking for the  
statistics.  With the current API, it is not possible to easily pass  
a value for pages_per_range down to the hypothetical index, so this  
makes use of the default value of BRIN_DEFAULT_PAGES_PER_RANGE, which  
should be fine enough in most cases.  
  
Being able to refine or enforce the hypothetical costs in more  
optimistic ways would require more refactoring by filling in the  
statistics when building IndexOptInfo in plancat.c.  This would involve  
ABI breakages around the costing routines, something not fit for stable  
branches.  
  
This is broken since 7e534ad, so backpatch down to v10.  
  
Author: Julien Rouhaud, Heikki Linnakangas  
Reviewed-by: Álvaro Herrera, Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/CAOBaU_ZH0LKEA8VFCocr6Lpte1ab0b6FpvgS0y4way+RPSXfYg@mail.gmail.com  
Backpatch-through: 10  

commit   : 9ff5b699ed3e2d922ff6f5660e53b51bb5db983c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Nov 2019 15:00:11 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Nov 2019 15:00:11 -0500    

Make patternsel_common() select the comparison operators to use with  
hardwired logic that matches pattern_prefix()'s new logic, eliminating  
its dependencies on particular index opfamilies.  
  
This shouldn't change any behavior, as it's just replacing runtime  
operator lookups with the same values hard-wired.  But it makes these  
closely-related functions look more alike, and saving some runtime  
syscache lookups is worth something.  
  
Actually, it's not quite true that this is zero behavioral change:  
when estimating for a column of type "name", the comparison constant  
will be kept as "text" not coerced to "name".  But that's more correct  
anyway, and it allows additional simplification of the coercion logic,  
again syncing this more closely with pattern_prefix().  
  
Per consideration of a report from Manuel Rigger.  
  
Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com  

commit   : 9f0f12ac57023653ad870a33a2e0337e6f3bf512    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 20 Nov 2019 11:36:54 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 20 Nov 2019 11:36:54 -0800    

Oversight in commit 63746189b23.  

commit   : 2ddedcafca116c99e08c777ab2ab3a4de6f00c7e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Nov 2019 14:13:04 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Nov 2019 14:13:04 -0500    

Historically, the planner's LIKE/regex index optimizations were only  
carried out for specific index opfamilies.  That's never been a great  
idea from the standpoint of extensibility, but it didn't matter so  
much as long as we had no practical way to extend such behaviors anyway.  
With the addition of planner support functions, and in view of ongoing  
work to support additional table and index AMs, it seems like a good  
time to relax this.  
  
Hence, recast the decisions in match_pattern_prefix() so that rather  
than decide which operators to generate by looking at what the index  
opfamily contains, we decide which operators to generate a-priori  
and then see if the opfamily supports them.  This is much more  
defensible from a semantic standpoint anyway, since we know the  
semantics of the chosen operators precisely, and we only need to  
assume that the opfamily correctly implements operators it claims  
to support.  
  
The existing "pattern" opfamilies put a crimp in this approach, since  
we need to select the pattern operators if we want those to work.  
So we still have to special-case those opfamilies.  But that seems  
all right, since in view of the addition of collations, the pattern  
opfamilies seem like a legacy hack that nobody will be building on.  
  
The only immediate effect of this change, so far as the core code is  
concerned, is that anchored LIKE/regex patterns can be mapped onto  
BRIN index searches, and exact-match patterns can be mapped onto hash  
indexes, not only btree and spgist indexes as before.  That's not a  
terribly exciting result, but it does fix an omission mentioned in  
the ancient comments here.  
  
Note: no catversion bump, even though this touches pg_operator.dat,  
because it's only adding OID macros not changing the contents of  
postgres.bki.  
  
Per consideration of a report from Manuel Rigger.  
  
Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com  

commit   : 86be6453ba295c3af222ee1e27a243d378070e92    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Nov 2019 12:27:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 20 Nov 2019 12:27:00 -0500    

In particular, clarify that the role membership mechanism allows  
members to inherit the ownership privileges of an object's owning  
role.  
  
Laurenz Albe, with some kibitzing by me  
  
Discussion: https://postgr.es/m/504497aca66bf34bdcdd90bd0bcebdc3a33f577b.camel@cybertec.at  

commit   : a28704af42c68e659cdeeec5b5b2fc84054ae02c    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Nov 2019 17:03:07 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 20 Nov 2019 17:03:07 +0100    

Author: Daniel Gustafsson <daniel@yesql.se>  

commit   : f9cb8bd3f21719589e09bda33974d994551a63b7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Nov 2019 17:48:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 Nov 2019 17:48:31 +0900    

xl_xact_relfilenodes refers to a number of relations, not XIDs, whose  
relfilenodes are processed.  
  
Author: Yu Kimura  
Discussion: https://postgr.es/m/a6ba6cf6bd0c990e019f008bae83437f@oss.nttdata.com  

commit   : 6969deeb8d3991cc533a5bcf451ae5eecaa9a517    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 20 Nov 2019 17:52:15 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 20 Nov 2019 17:52:15 +1300    

When ReadFile() encounters the end of a file while reading from  
a synchronous handle with an offset provided via OVERLAPPED, it  
reports an error instead of returning 0.  By not handling that  
(undocumented) result correctly, we caused some noisy LOG  
messages about an unknown error code.  Repair.  
  
Back-patch to 12, where we started using pread()/ReadFile() with  
an offset.  
  
Reported-by: ZhenHua Cai, Amit Kapila  
Diagnosed-by: Juan Jose Santamaria Flecha  
Tested-by: Amit Kapila  
Discussion: https://postgr.es/m/CAA4eK1LK3%2BWRtpz68TiRdpHwxxWm%3D%2Bt1BMf-G68hhQsAQ41PZg%40mail.gmail.com  

commit   : 80e05a088e4edd421c9c0374d54d787c8a4c0d86    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 18 Nov 2019 10:28:32 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 18 Nov 2019 10:28:32 +0530    

Specifying '-f' will add the 'force' option to the DROP DATABASE command  
sent to the server.  This will try to terminate all existing connections  
to the target database before dropping it.  
  
Author: Pavel Stehule  
Reviewed-by: Vignesh C and Amit Kapila  
Discussion: https://postgr.es/m/CAP_rwwmLJJbn70vLOZFpxGw3XD7nLB_7+NKz46H5EOO2k5H7OQ@mail.gmail.com  

commit   : eecf963269648d4309cc54f8e94508ad42bbb88b    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Wed, 20 Nov 2019 09:08:43 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Wed, 20 Nov 2019 09:08:43 +0900    

Discussion: https://postgr.es/m/20191119.222048.49467220816510881.t-ishii%40sraoss.co.jp  

commit   : b3c265d7be42484bd0ab4a9c0a920289e8f5c995    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Nov 2019 17:03:26 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Nov 2019 17:03:26 -0500    

The planner's optimization code for LIKE and regex operators could  
error out with a complaint like "no = operator for opfamily NNN"  
if someone created a binary-compatible index (for example, a  
bpchar_ops index on a text column) on the LIKE's left argument.  
  
This is a consequence of careless refactoring in commit 74dfe58a5.  
The old code in match_special_index_operator only accepted specific  
combinations of the pattern operator and the index opclass, thereby  
indirectly guaranteeing that the opclass would have a comparison  
operator with the same LHS input type as the pattern operator.  
While moving the logic out to a planner support function, I simplified  
that test in a way that no longer guarantees that.  Really though we'd  
like an altogether weaker dependency on the opclass, so rather than  
put back exactly the old code, just allow lookup failure.  I have in  
mind now to rewrite this logic completely, but this is the minimum  
change needed to fix the bug in v12.  
  
Per report from Manuel Rigger.  Back-patch to v12 where the mistake  
came in.  
  
Discussion: https://postgr.es/m/CA+u7OA7nnGYy8rY0vdTe811NuA+Frr9nbcBO9u2Z+JxqNaud+g@mail.gmail.com  

commit   : b107140804817cc30a4069b1bb5545aa3ea0ce6c    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 20 Nov 2019 00:12:33 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 20 Nov 2019 00:12:33 +0300    

By oversight 52ac6cd2d0 makes ginDeletePage() sets pd_prune_xid of page to be  
deleted before entering the critical section.  It appears that only versions 11  
and later were affected by this oversight.  
  
Backpatch-through: 11  

commit   : 32ca32d0bed4b95e5cd63998478a7816a89cd43d    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 19 Nov 2019 23:11:24 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 19 Nov 2019 23:11:24 +0300    

We find GIN concurrency bugs from time to time.  One of the problems here is  
that concurrency of GIN isn't well-documented in README.  So, it might be even  
hard to distinguish design bugs from implementation bugs.  
  
This commit revised concurrency section in GIN README providing more details.  
Some examples are illustrated in ASCII art.  
  
Also, this commit add the explanation of how is tuple layout in internal GIN  
B-tree page different in comparison with nbtree.  
  
Discussion: https://postgr.es/m/CAPpHfduXR_ywyaVN4%2BOYEGaw%3DcPLzWX6RxYLBncKw8de9vOkqw%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Peter Geoghegan  
Backpatch-through: 9.4  

commit   : d5ad7a09afd066dce423f282bb2b338f48614d32    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 19 Nov 2019 23:08:14 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 19 Nov 2019 23:08:14 +0300    

Current GIN code appears to don't handle traversing to the deleted page via  
downlink.  This commit fixes that by stepping right from the delete page like  
we do in nbtree.  
  
This commit also fixes setting 'deleted' flag to the GIN pages.  Now other page  
flags are not erased once page is deleted.  That helps to keep our assertions  
true if we arrive deleted page via downlink.  
  
Discussion: https://postgr.es/m/CAPpHfdvMvsw-NcE5bRS7R1BbvA4BxoDnVVjkXC5W0Czvy9LVrg%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Peter Geoghegan  
Backpatch-through: 9.4  

commit   : e14641197a5690d92cc48446d0d40f1aec07bac7    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 19 Nov 2019 23:07:36 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 19 Nov 2019 23:07:36 +0300    

When ginDeletePage() is about to delete page it locks its left sibling to revise  
the rightlink.  So, it locks pages in right to left manner.  Int he same time  
ginStepRight() locks pages in left to right manner, and that could cause a  
deadlock.  
  
This commit makes ginScanToDelete() keep exclusive lock on left siblings of  
currently investigated path.  That elimites need to relock left sibling in  
ginDeletePage().  Thus, deadlock with ginStepRight() can't happen anymore.  
  
Reported-by: Chen Huajun  
Discussion: https://postgr.es/m/5c332bd1.87b6.16d7c17aa98.Coremail.chjischj%40163.com  
Author: Alexander Korotkov  
Reviewed-by: Peter Geoghegan  
Backpatch-through: 10  

commit   : 5b805886ca11d5d74217ab1f12395ad54507d4d5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Nov 2019 14:43:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Nov 2019 14:43:37 -0500    

Apparently some people misinterpreted the syntax as being that  
RECURSIVE is a prefix of individual WITH queries.  It's a modifier  
for the WITH clause as a whole, so state that more clearly.  
  
Discussion: https://postgr.es/m/ca53c6ce-a0c6-b14a-a8e3-162f0b2cc119@a-kretschmer.de  

commit   : 787b3fd33fb3089bf80d49ef9948a6ec85005d04    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Nov 2019 14:21:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 Nov 2019 14:21:41 -0500    

The existing text stated that "Default privileges that are specified  
per-schema are added to whatever the global default privileges are for  
the particular object type".  However, that bare-bones observation is  
not quite clear enough, as demonstrated by the complaint in bug #16124.  
Flesh it out by stating explicitly that you can't revoke built-in  
default privileges this way, and by providing an example to drive  
the point home.  
  
Back-patch to all supported branches, since it's been like this  
from the beginning.  
  
Discussion: https://postgr.es/m/16124-423d8ee4358421bc@postgresql.org  

commit   : 7f338369ca624ca6c2e4f579623274c88d325bce    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 19 Nov 2019 15:17:15 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 19 Nov 2019 15:17:15 +1300    

Keep track of the visible width of PROMPT1, and provide %w as a way  
for PROMPT2 to generate the same number of spaces.  
  
Author: Thomas Munro, with ideas from others  
Reviewed-by: Tom Lane (earlier version)  
Discussion: https://postgr.es/m/CA%2BhUKG%2BzGd7RigjWbxwhzGW59gUpf76ydQECeGdEdodH6nd__A%40mail.gmail.com  

commit   : cec2edfa7859279f36d2374770ca920c59c73dd8    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 16 Nov 2019 17:49:33 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 16 Nov 2019 17:49:33 +0530    

Instead of deciding to serialize a transaction merely based on the  
number of changes in that xact (toplevel or subxact), this makes  
the decisions based on amount of memory consumed by the changes.  
  
The memory limit is defined by a new logical_decoding_work_mem GUC,  
so for example we can do this  
  
    SET logical_decoding_work_mem = '128kB'  
  
to reduce the memory usage of walsenders or set the higher value to  
reduce disk writes. The minimum value is 64kB.  
  
When adding a change to a transaction, we account for the size in  
two places. Firstly, in the ReorderBuffer, which is then used to  
decide if we reached the total memory limit. And secondly in the  
transaction the change belongs to, so that we can pick the largest  
transaction to evict (and serialize to disk).  
  
We still use max_changes_in_memory when loading changes serialized  
to disk. The trouble is we can't use the memory limit directly as  
there might be multiple subxact serialized, we need to read all of  
them but we don't know how many are there (and which subxact to  
read first).  
  
We do not serialize the ReorderBufferTXN entries, so if there is a  
transaction with many subxacts, most memory may be in this type of  
objects. Those records are not included in the memory accounting.  
  
We also do not account for INTERNAL_TUPLECID changes, which are  
kept in a separate list and not evicted from memory. Transactions  
with many CTID changes may consume significant amounts of memory,  
but we can't really do much about that.  
  
The current eviction algorithm is very simple - the transaction is  
picked merely by size, while it might be useful to also consider age  
(LSN) of the changes for example. With the new Generational memory  
allocator, evicting the oldest changes would make it more likely  
the memory gets actually pfreed.  
  
The logical_decoding_work_mem can be set in postgresql.conf, in which  
case it serves as the default for all publishers on that instance.  
  
Author: Tomas Vondra, with changes by Dilip Kumar and Amit Kapila  
Reviewed-by: Dilip Kumar and Amit Kapila  
Tested-By: Vignesh C  
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com  

commit   : 2110f716965fe1ac5af83380aa108541b1457e0d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 18 Nov 2019 13:04:53 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 18 Nov 2019 13:04:53 -0800    

Make it clear that _bt_pgaddtup() truncates the first data item on an  
internal page because its key is supposed to be treated as minus  
infinity within _bt_compare().  

commit   : bf2efc55da9a1a33da32fa383db9db2f2c49b2cb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Nov 2019 20:00:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 Nov 2019 20:00:19 -0500    

It turns out that commit e9f1c01b7 missed a case: we must print a  
VALUES clause in long format if get_query_def is given a resultDesc  
that would require the query's output column name(s) to be different  
from what the bare VALUES clause would produce.  
  
This applies in case an ALTER ... RENAME COLUMN has been done to  
a view that formerly could be printed in simple format, as shown  
in the added regression test case.  It also explains bug #16119  
from Dmitry Telpt, because it turns out that (unlike CREATE VIEW)  
CREATE MATERIALIZED VIEW fails to apply any column aliases it's  
given to the stored ON SELECT rule.  So to get them to be printed,  
we have to account for the resultDesc renaming.  It might be worth  
changing the matview code so that it creates the ON SELECT rule  
with the correct aliases; but we'd still need these messy checks in  
get_simple_values_rte to handle the case of a subsequent column  
rename, so any such change would be just neatnik-ism not a bug fix.  
  
Like the previous patch, back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16119-e64823f30a45a754@postgresql.org  

commit   : 815bd578076672a2325d026a2c48b6075454be9b    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 16 Nov 2019 10:51:03 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 16 Nov 2019 10:51:03 -0800    

Oversight in commit 4a252996.  

commit   : 3db0598d908f22435ab8138d1c76b971f17a5633    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 16 Nov 2019 15:23:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 16 Nov 2019 15:23:12 +0900    

Concurrent autovacuums running with the main regression test suite  
could cause the tests with VACUUM (SKIP_LOCKED) to generate randomly  
WARNING messages.  For these tests, set client_min_messages to ERROR to  
get rid of those random failures, as disabling autovacuum for the  
relations operated would not completely close the failure window.  
  
For isolation tests, disable autovacuum for the relations vacuumed with  
SKIP_LOCKED.  The tests are designed so as LOCK commands are taken  
in a first session before running a concurrent VACUUM (SKIP_LOCKED) in a  
second to generate WARNING messages, but a concurrent autovacuum could  
cause the tests to be slower.  
  
Reported-by: Tom Lane  
Author: Michael Paquier  
Reviewed-by: Andres Freund, Tom Lane  
Discussion: https://postgr.es/m/25294.1573077278@sss.pgh.pa.us  
Backpatch-through: 12  

commit   : 2dc08bd6179d8cf480c93701010c19ad7a9891d8    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 16 Nov 2019 02:40:02 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 16 Nov 2019 02:40:02 +0100    

In detoast_attr_slice, VARSIZE_ANY was used to compute compressed length  
of on-disk TOAST values. That's incorrect, because the varlena value may  
be just a TOAST pointer, producing either bogus value or crashing.  
  
This is likely why the code was crashing on big-endian machines before  
540f31680913 replaced the VARSIZE with VARSIZE_ANY, which however only  
masked the issue.  
  
Reported-by: Rushabh Lathia  
Discussion: https://postgr.es/m/CAL-OGkthU9Gs7TZchf5OWaL-Gsi=hXqufTxKv9qpNG73d5na_g@mail.gmail.com  

commit   : d482f7f867b58bbd29f65a4471eca8c5b57a7da0    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 16 Nov 2019 01:17:15 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 16 Nov 2019 01:17:15 +0100    

When estimating number of distinct groups, we failed to ignore system  
attributes when matching the group expressions to mvdistinct stats,  
causing failures like  
  
  ERROR: negative bitmapset member not allowed  
  
Fix that by simply skipping anything that is not a regular attribute.  
Backpatch to PostgreSQL 10, where the extended stats were introduced.  
  
Bug: #16111  
Reported-by: Tuomas Leikola  
Author: Tomas Vondra  
Backpatch-through: 10  
Discussion: https://postgr.es/m/16111-687799584c3a7e73@postgresql.org  

commit   : 76cbfcdf3a0dff3f029ca079701418b861ce86c8    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 16 Nov 2019 10:04:52 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sat, 16 Nov 2019 10:04:52 +1300    

Call ExecShutdownNode() after ExecutePlan()'s loop, rather than at each  
break.  We had forgotten to do that in one case.  The omission caused  
intermittent "temporary file leak" warnings from multi-batch parallel  
hash joins with a LIMIT clause.  
  
Back-patch to 11.  Though the problem exists in theory in earlier  
parallel query releases, nothing really depended on it.  
  
Author: Kyotaro Horiguchi  
Reviewed-by: Thomas Munro, Amit Kapila  
Discussion: https://postgr.es/m/20191111.212418.2222262873417235945.horikyota.ntt%40gmail.com  

commit   : 6ae4d271879b62c4325df3ddf75bff3f2b911086    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 14 Nov 2019 17:33:26 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 14 Nov 2019 17:33:26 -0300    

Apparently, it's no longer welcome.  Therefore replace it with "pristine",  
and add some explanatory text while at it.  
  
Reported by Brian Williams  
Discussion: https://postgr.es/m/157313712259.14261.16141263269989647311@wrigleys.postgresql.org  

commit   : 50d22de9325f41a32faeb0d1055f50b43d0507b3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 14 Nov 2019 13:59:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 14 Nov 2019 13:59:59 +0900    

reloptions.h includes since ba748f7 a set of macros to handle reloption  
types in a way similar to how parseRelOptions() works.  They have never  
been used in the core code, and we have more simple methods now to parse  
and fill in rd_options for a given relation depending on its relkind, so  
remove this interface to simplify things.  
  
Per discussion between Amit Langote, Álvaro Herrera and me.  
  
Discussion: https://postgr.es/m/CA+HiwqE6zbNO92az6pp5GiTw4tr-9rfCE0t84whQSP+YwSKjMQ@mail.gmail.com  

commit   : 1bbd608fdae7af314d8e2229e369a45a3da83cd8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 14 Nov 2019 12:34:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 14 Nov 2019 12:34:28 +0900    

Partitioned tables do not have relation options yet, but, similarly to  
what's done for views which have their own parsing table, it could make  
sense to introduce new parameters for some of the existing default ones  
like fillfactor, autovacuum, etc.  Splitting things has the advantage to  
make the information stored in rd_options include only the necessary  
information, reducing the amount of memory used for a relcache entry  
with partitioned tables if new reloptions are introduced at this level.  
  
Author:  Nikolay Shaplov  
Reviewed-by: Amit Langote, Michael Paquier  
Discussion: https://postgr.es/m/1627387.Qykg9O6zpu@x200m  

commit   : 80ef34fc7075b37fc23f4ab714a5ce60f82400de    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Nov 2019 16:36:31 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Nov 2019 16:36:31 -0800    

At least buildfarm member florican doesn't use a material node above a  
sort in the mark/restore case. As material is not intended to be  
tested with that query, disallow.  

commit   : 7d962eaf50c093b4bb1d35a7b495d416a67b40e2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Nov 2019 15:57:01 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 13 Nov 2019 15:57:01 -0800    

copytup_index() is unused, as tuplesort_putindextuplevalues() doesn't  
use COPYTUP(). Replace function body with an elog(ERROR), as already  
done e.g. for copytup_datum().  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20191013144153.ooxrfglvnaocsrx2@alap3.anarazel.de  

commit   : 4a252996d5fda7662b2afdf329a5c95be0fe3b01    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 24 Oct 2019 13:58:40 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 24 Oct 2019 13:58:40 -0700    

Previously significant parts of tuplesort.c were untested. This  
commit, while not testing every path, significantly increases  
coverage.  In particular, this adds tests for abbreviated key logic,  
forward/backward scans & scrolling and mark/restore.  
  
I tried to keep the table sizes reasonable, and stress the on-disk  
paths by setting work_mem to low values for specific tests. The  
buildfarm will tell whether more attention to test time is needed.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20191013144153.ooxrfglvnaocsrx2@alap3.anarazel.de  

commit   : d57d61533a2b5b27b60cc9024c54688390871bf6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2019 15:53:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2019 15:53:53 -0500    

We should throw an error for indeterminate collation, but bpcharne()  
was missing that logic, resulting in a much less user-friendly error  
(either an assertion failure or "cache lookup failed for collation 0").  
  
Per report from Manuel Rigger.  Back-patch to v12 where the mistake  
came in, evidently in commit 5e1963fb7.  (Before non-deterministic  
collations, this function wasn't collation sensitive.)  
  
Discussion: https://postgr.es/m/CA+u7OA4HOjtymxAbuGNh4-X_2R0Lw5n01tzvP8E5-i-2gQXYWA@mail.gmail.com  

commit   : 0cafdd03a850265006c0ada1b0bf4f83e087a409    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2019 15:26:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2019 15:26:54 -0500    

Initializing a pointer to "false" isn't per project style,  
and reportedly some compilers warn about it (though I've  
not seen any such warnings in the buildfarm).  
  
Seems to have come in with commit ff11e7f4b, so back-patch  
to v12 where that was added.  
  
Didier Gautheron  
  
Discussion: https://postgr.es/m/CAJRYxu+XQuM0qnSqt1Ujztu6fBPzMMAT3VEn6W32rgKG6A2Fsw@mail.gmail.com  

commit   : 7bf40ea0d028e6dc49c152e5820a65d69b74b409    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2019 13:51:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2019 13:51:58 -0500    

This gets rid of our former behavior of forcibly downcasing  
the postmaster's hostname list and truncating the elements to  
NAMEDATALEN.  In principle, DNS hostnames are case-insensitive  
so the first behavior should be harmless, and server hostnames  
are seldom long enough for the second behavior to be an issue.  
But it's still dubious, and an easy fix is available: just use  
SplitGUCList instead.  
  
AFAICT, all other SplitIdentifierString calls in the backend are  
OK: either the items actually are SQL identifiers, or they are  
keywords that are short and case-insensitive.  
  
Per thinking about bug #16106.  While this has been wrong for  
a very long time, the lack of field complaints means there's  
little reason to back-patch.  
  
Discussion: https://postgr.es/m/16106-7d319e4295d08e70@postgresql.org  

commit   : 7618eaf5f315f53619b718e571cd2a2020fb0226    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2019 13:41:04 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2019 13:41:04 -0500    

Commit 6b76f1bb5 changed all the RADIUS auth parameters to be lists  
rather than single values.  But its use of SplitIdentifierString  
to parse the list format was not very carefully thought through,  
because that function thinks it's parsing SQL identifiers, which  
means it will (a) downcase the strings and (b) truncate them to  
be shorter than NAMEDATALEN.  While downcasing should be harmless  
for the server names and ports, it's just wrong for the shared  
secrets, and probably for the NAS Identifier strings as well.  
The truncation aspect is at least potentially a problem too,  
though typical values for these parameters would fit in 63 bytes.  
  
Fortunately, we now have a function SplitGUCList that is exactly  
the same except for not doing the two unwanted things, so fixing  
this is a trivial matter of calling that function instead.  
  
While here, improve the documentation to show how to double-quote  
the parameter values.  I failed to resist the temptation to do  
some copy-editing as well.  
  
Report and patch from Marcos David (bug #16106); doc changes by me.  
Back-patch to v10 where the aforesaid commit came in, since this is  
arguably a regression from our previous behavior with RADIUS auth.  
  
Discussion: https://postgr.es/m/16106-7d319e4295d08e70@postgresql.org  

commit   : 2c7b5dad6eb1602839e5961b4d4eb6494fe4a1ee    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2019 12:11:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2019 12:11:49 -0500    

The TableFunc node (i.e., XMLTABLE) includes type and collation OIDs  
that might not be referenced anywhere else in the expression tree,  
so they need to be accounted for when extracting dependencies.  
  
Fortunately, the practical effects of this are limited, since  
(a) it's somewhat unlikely that people would be extracting  
columns of non-builtin types from an XML document, and (b)  
in many scenarios, the query would contain other references  
to such types, or functions depending on them.  However, it's  
not hard to construct examples wherein the existing code lets  
one drop a type used in XMLTABLE and thereby break a view.  
  
This is evidently an original oversight in the XMLTABLE patch,  
so back-patch to v10 where that came in.  
  
Discussion: https://postgr.es/m/18427.1573508501@sss.pgh.pa.us  

commit   : 29aeda6e4e609b66b6f1c3c73b4def6fb34d90ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2019 11:35:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 Nov 2019 11:35:37 -0500    

pg_upgrade needs to check whether certain non-upgradable data types  
appear anywhere on-disk in the source cluster.  It knew that it has  
to check for these types being contained inside domains and composite  
types; but it somehow overlooked that they could be contained in  
arrays and ranges, too.  Extend the existing recursive-containment  
query to handle those cases.  
  
We probably should have noticed this oversight while working on  
commit 0ccfc2822 and follow-ups, but we failed to :-(.  The whole  
thing's possibly a bit overdesigned, since we don't really expect  
that any of these types will appear on disk; but if we're going to  
the effort of doing a recursive search then it's silly not to cover  
all the possibilities.  
  
While at it, refactor so that we have only one copy of the search  
logic, not three-and-counting.  Also, to keep the branches looking  
more alike, back-patch the output wording change of commit 1634d3615.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/31473.1573412838@sss.pgh.pa.us  

commit   : 7b8a899bdeb638f46e102d1714c079a0874e9fa0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 Nov 2019 16:59:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 Nov 2019 16:59:17 +0900    

This commit changes xact_desc() so that it reports the detail information about  
PREPARE TRANSACTION record, like GID (global transaction identifier),  
timestamp at prepare transaction, delete-on-abort/commit relations,  
XID of subtransactions, and invalidation messages. These are helpful  
when diagnosing 2PC-related troubles.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier, Andrey Lepikhov, Kyotaro Horiguchi, Julien Rouhaud, Alvaro Herrera  
Discussion: https://postgr.es/m/CAHGQGwEvhASad4JJnCv=0dW2TJypZgW_Vpb-oZik2a3utCqcrA@mail.gmail.com  

commit   : 94fec48516a77f219ab94890219d724b973e4674    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 13 Nov 2019 13:30:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 13 Nov 2019 13:30:14 +0900    

postgres_fdw does not support two-phase transactions, so let's add a  
small negative test case to check after it.  Note that this is checked  
using an end-of-xact callback to ensure a proper connection cleanup with  
the foreign server, which is called before checking if a server is able  
to handle 2PC with max_prepared_xacts, so this test does not need an  
alternate output file.  
  
Author: Gilles Darold  
Discussion: https://postgr.es/m/20191108090507.GC1768@paquier.xyz  

commit   : 1379fd537f9fc7941c8acff8c879ce3636dbdb77    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 12 Nov 2019 11:06:13 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 12 Nov 2019 11:06:13 +0530    

This new option terminates the other sessions connected to the target  
database and then drop it.  To terminate other sessions, the current user  
must have desired permissions (same as pg_terminate_backend()).  We don't  
allow to terminate the sessions if prepared transactions, active logical  
replication slots or subscriptions are present in the target database.  
  
Author: Pavel Stehule with changes by me  
Reviewed-by: Dilip Kumar, Vignesh C, Ibrar Ahmed, Anthony Nowocien,  
Ryan Lambert and Amit Kapila  
Discussion: https://postgr.es/m/CAP_rwwmLJJbn70vLOZFpxGw3XD7nLB_7+NKz46H5EOO2k5H7OQ@mail.gmail.com  

commit   : 112caf9039f4c8fb286bb610461ced8253313e9f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Nov 2019 16:58:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Nov 2019 16:58:00 -0500    

Apply the solution adopted in commit dcb7d3caf (ie, explicitly  
don't call memcmp for a zero-length comparison) to func_get_detail()  
as well, removing one other place where we were passing an  
uninitialized array to a parse_func.c entry point.  
  
Discussion: https://postgr.es/m/MN2PR18MB2927F24692485D754794F01BE3740@MN2PR18MB2927.namprd18.prod.outlook.com  
Discussion: https://postgr.es/m/MN2PR18MB2927F6873DF2774A505AC298E3740@MN2PR18MB2927.namprd18.prod.outlook.com  

commit   : c5e8ea978d88ea4aa731516836e14d54c50cc957    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 Nov 2019 18:34:20 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 Nov 2019 18:34:20 -0300    

As suggested by Stephen Frost.  
Discussion: https://postgr.es/m/20191104160605.GC6962@tamriel.snowman.net  

commit   : 5c46e7d82e88859395c2688c37bb643ae7dbbfa1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 Nov 2019 17:19:41 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 Nov 2019 17:19:41 -0300    

It is pointless to show in those views auxiliary processes that don't  
open network connections.  
  
A small incompatibility is that anybody joining pg_stat_activity and  
pg_stat_ssl/pg_stat_gssapi will have to use a left join if they want to  
see such auxiliary processes.  
  
Author: Euler Taveira  
Discussion: https://postgr.es/m/20190904151535.GA29108@alvherre.pgsql  

commit   : 1f55ebae27225111d0a5c4d89d7e77d917357ff4    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 12 Nov 2019 13:08:41 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 12 Nov 2019 13:08:41 -0800    

An upcoming patch that adds deduplication to the nbtree AM will rely on  
_bt_keep_natts_fast() understanding that differences in TOAST input  
state can never affect its answer.  In particular, two opclass-equal  
datums (with opclasses deemed safe for deduplication) should never be  
treated as unequal by _bt_keep_natts_fast() due to TOAST input  
differences.  
  
This also seems like a good idea on general principle.  nbtsplitloc.c  
will now occasionally make better decisions about where to split a leaf  
page.  The behavior of _bt_keep_natts_fast() is now somewhat closer to  
the behavior of _bt_keep_natts().  
  
Discussion: https://postgr.es/m/CAH2-Wzn3Ee49Gmxb7V1VJ3-AC8fWn-Fr8pfWQebHe8rYRxt5OQ@mail.gmail.com  

commit   : dcb7d3cafa3197c5425c129ba0dc5eddd23c0532    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 Nov 2019 17:04:46 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 Nov 2019 17:04:46 -0300    

Prior to this change, it requires to be passed a valid pointer just to  
be able to pass it to a zero-byte memcmp, per 0a52d378b03b.  Given the  
strange resulting code in callsites, it seems better to test for the  
case specifically and remove the requirement.  
  
Reported-by: Ranier Vilela  
Discussion: https://postgr.es/m/MN2PR18MB2927F24692485D754794F01BE3740@MN2PR18MB2927.namprd18.prod.outlook.com  
Discussion: https://postgr.es/m/MN2PR18MB2927F6873DF2774A505AC298E3740@MN2PR18MB2927.namprd18.prod.outlook.com  

commit   : 8c951687f58ad604be13e6addfd56446afb36e13    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 12 Nov 2019 11:25:34 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 12 Nov 2019 11:25:34 -0800    

Bring datum_image_eq() in line with datumIsEqual() by adding support for  
comparing cstring datums.  
  
An upcoming patch that adds deduplication to the nbtree AM will use  
datum_image_eq().  datum_image_eq() will need to work with all datatypes  
that can be used as the storage type of a B-Tree index column, including  
cstring.  (cstring is used as the storage type for columns of type  
"name" as a space-saving optimization.)  
  
Discussion: https://postgr.es/m/CAH2-Wzn3Ee49Gmxb7V1VJ3-AC8fWn-Fr8pfWQebHe8rYRxt5OQ@mail.gmail.com  

commit   : 7a0574b50ee9c2b96ce94c29e031c103285c0b1d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Nov 2019 13:00:04 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 Nov 2019 13:00:04 -0500    

This completes the task begun in commit 1408d5d86, to synchronize  
ECPG's exported definitions with the definition of bool used by  
c.h (and, therefore, the one actually in use in the ECPG library).  
On practically all modern platforms, ecpglib.h will now just  
include <stdbool.h>, which should surprise nobody anymore.  
That removes a header-inclusion-order hazard for ECPG clients,  
who previously might get build failures or unexpected behavior  
depending on whether they'd included <stdbool.h> themselves,  
and if so, whether before or after ecpglib.h.  
  
On platforms where sizeof(_Bool) is not 1 (only old PPC-based  
Mac systems, as far as I know), things are still messy, as  
inclusion of <stdbool.h> could still break ECPG client code.  
There doesn't seem to be any clean fix for that, and given the  
probably-negligible population of users who would care anymore,  
it's not clear we should go far out of our way to cope with it.  
This change at least fixes some header-inclusion-order hazards  
for our own code, since c.h and ecpglib.h previously disagreed  
on whether bool should be char or unsigned char.  
  
To implement this with minimal invasion of ECPG client namespace,  
move the choice of whether to rely on <stdbool.h> into configure,  
and have it export a configuration symbol PG_USE_STDBOOL.  
  
ecpglib.h no longer exports definitions for TRUE and FALSE,  
only their lowercase brethren.  We could undo that if we get  
push-back about it.  
  
Ideally we'd back-patch this as far as v11, which is where c.h  
started to rely on <stdbool.h>.  But the odds of creating problems  
for formerly-working ECPG client code seem about as large as the  
odds of fixing any non-working cases, so we'll just do this in HEAD.  
  
Discussion: https://postgr.es/m/CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com  

commit   : de7c2d30b6dc2544b181cf074e942fff54d7999d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 12 Nov 2019 08:13:55 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 12 Nov 2019 08:13:55 +0100    

commit   : 14aec03502302eff6c67981d8fd121175c436ce9    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 12 Nov 2019 08:30:16 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 12 Nov 2019 08:30:16 +0530    

Similar to commits 7e735035f2 and dddf4cdc33, this commit makes the order  
of header file inclusion consistent for backend modules.  
  
In the passing, removed a couple of duplicate inclusions.  
  
Author: Vignesh C  
Reviewed-by: Kuntal Ghosh and Amit Kapila  
Discussion: https://postgr.es/m/CALDaNm2Sznv8RR6Ex-iJO6xAdsxgWhCoETkaYX=+9DW3q0QCfA@mail.gmail.com  

commit   : b6423e92abfadaa1ed9642319872aa1654403cd6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Nov 2019 14:39:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Nov 2019 14:39:54 -0500    

The example of expansion of multiple views claimed that the resulting  
subquery nest would not get fully flattened because of an aggregate  
function.  There's no aggregate in the example, though, only a user  
defined function confusingly named MIN().  In a modern server, the  
reason for the non-flattening is that MIN() is volatile, but I'm  
unsure whether that was true back when this text was written.  
  
Let's reduce the confusion level by using LEAST() instead (which  
we didn't have at the time this example was created).  And then  
we can just say that the planner will flatten the sub-queries, so  
the rewrite system doesn't have to.  
  
Noted by Paul Jungwirth.  This text is old enough to vote, so  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CA+renyXZFnmp9PcvX1EVR2dR=XG5e6E-AELr8AHCNZ8RYrpnPw@mail.gmail.com  

commit   : 13e8b2ee896d76dfcd02dddee40919fd6f2cd937    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Nov 2019 10:33:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 Nov 2019 10:33:00 -0500    

Commits 4ea03f3f4 et al arranged to filter out row counts in parallel  
plans, because those are dependent on the number of workers actually  
obtained.  Somehow I missed that the 'Rows Removed by Filter' counts  
can also vary, so fix that too.  Per buildfarm.  
  
This seems worth a last-minute patch because unreliable regression  
tests are a serious pain in the rear for packagers.  
  
Like the previous patch, back-patch to v11 where this test was  
introduced.  

commit   : 2cd75e4e795bea110c1d32e8cbfdf1e33a109e80    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Nov 2019 11:54:12 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Nov 2019 11:54:12 +0100    

commit   : d0c92527cc77a8f6b235c2a5abba95e01367f825    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Nov 2019 09:51:10 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Nov 2019 09:51:10 +0100    

commit   : bbaa8232729f2aa1b1061503a3d9f7db503d2788    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Nov 2019 09:50:07 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 Nov 2019 09:50:07 +0100    

This puts pg_config.h.in content back into the "correct" order.  

commit   : db2687d1f3787aa8113b3dbb358153feee30c64c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 11 Nov 2019 16:34:01 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 11 Nov 2019 16:34:01 +1300    

PredicateLockTuple() has a fast exit if tuple was written by the current  
transaction, as in that case it already has a lock.  This check can be  
performed using TransactionIdIsCurrentTransactionId() instead of  
SubTransGetTopmostTransaction(), to avoid any chance of having to hit the  
disk.  
  
Author: Ashwin Agrawal, based on a suggestion from Andres Freund  
Reviewed-by: Thomas Munro  
Discussion: https://postgr.es/m/CALfoeiv0k3hkEb3Oqk%3DziWqtyk2Jys1UOK5hwRBNeANT_yX%2Bng%40mail.gmail.com  

commit   : 695c5977c8bc115029a85dcc1821d7b0136b4e4c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 11 Nov 2019 16:33:04 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 11 Nov 2019 16:33:04 +1300    

If the passed in xid is the current top transaction, we can do a fast  
check and exit early.  This should work well for the current heap but  
also works very well for proposed AMs that don't use a separate xid  
for subtransactions.  
  
Author: Ashwin Agrawal, based on a suggestion from Andres Freund  
Reviewed-by: Thomas Munro  
Discussion: https://postgr.es/m/CALfoeiv0k3hkEb3Oqk%3DziWqtyk2Jys1UOK5hwRBNeANT_yX%2Bng%40mail.gmail.com  

commit   : 9fab25c6cd1f943284b8e0014007cd5750d54308    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 9 Nov 2019 17:28:27 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 9 Nov 2019 17:28:27 +0530    

During Drop Database, it is better to error out before allowing other  
sessions to exit and forcefully terminating autovacuum workers.  All the  
other errors except for checking subscriptions are already done before.  
  
Author: Amit Kapila  
Discussion: https://postgr.es/m/CAA4eK1+qhLkCYG2oy9xug9ur_j=G2wQNRYAyd+-kZfZ1z42pLw@mail.gmail.com  

commit   : ef8fcbff56e8904ba83b2659e9d0290e6106928e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 9 Nov 2019 13:19:27 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 9 Nov 2019 13:19:27 +0100    

After altering a subscription, we should wait until the updated table  
sync data has been fetched by the subscriber.  

commit   : d2d4c35080026ba3da49583e30c1fd53c9fb22dd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 9 Nov 2019 10:13:14 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 9 Nov 2019 10:13:14 +0100    

The previous statement that using a passphrase disables the ability to  
change the server's SSL configuration without a server restart was no  
longer completely true since the introduction of  
ssl_passphrase_command_supports_reload.  

commit   : 27b59d619ddfb512e3f158a87f557a46f2d5794f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 9 Nov 2019 09:35:21 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 9 Nov 2019 09:35:21 +0100    

Remove one sentence that was deemed misleading.  
  
Discussion: https://www.postgresql.org/message-id/flat/E1iEgSp-0004R5-2E%40gemulon.postgresql.org  

commit   : 1c60e40ad54b18685436443da3c56a7018a35475    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 7 Nov 2019 13:48:59 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 7 Nov 2019 13:48:59 +0100    

This happens when we add a replica identity column on a subscriber  
that does not yet exist on the publisher, according to the mapping  
maintained by the subscriber.  Code that checks whether the target  
relation on the subscriber is updatable would check the replica  
identity attribute bitmap with a column number -1, which would result  
in an error.  To fix, skip such columns in the bitmap lookup and  
consider the relation not updatable.  The result is consistent with  
the rule that the replica identity columns on the subscriber must be a  
subset of those on the publisher, since if the column doesn't exist on  
the publisher, the column set on the subscriber can't be a subset.  
  
Reported-by: Tim Clarke <tim.clarke@minerva.info>  
Analyzed-by: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
Discussion: https://www.postgresql.org/message-id/flat/a9139c29-7ddd-973b-aa7f-71fed9c38d75%40minerva.info  

commit   : 943b447d303e6d0a7635d39ac552550b77b96cef    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 9 Nov 2019 15:41:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 9 Nov 2019 15:41:34 +0900    

The buildfarm has turned red after 1858b10 because VPATH builds need to  
use "@abs_srcdir@" and not "@abs_builddir@" for paths coming directly  
from the source tree.  The input file of the new test got that right,  
but not the output file.  
  
Per complaints from several buildfarm animals, including desmoxytes and  
culicidae.  I have also reproduced the error by myself.  

commit   : 1858b105b05fcded43e9f2b767dec7268431043b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 9 Nov 2019 14:50:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 9 Nov 2019 14:50:20 +0900    

This stresses the error handling of COPY inside SPI which does not  
support the operation using stdin or stdout, and these scenarios were  
not tested up to now.  
  
Author: Mark Dilger  
Discussion: https://postgr.es/m/a6e9b130-7fd5-387b-4ec5-89bda24373ab@gmail.com  

commit   : aae50236e4ce95c05a3962be0814c74c5a22206d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 8 Nov 2019 00:44:52 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 8 Nov 2019 00:44:52 -0800    

Not all AMs use HeapTuples internally, making it inconvenient to pass  
a HeapTuple. As the index callbacks really only need the TID, not the  
full tuple, modify callback to only take ItemPointer.  
  
Author: Ashwin Agrawal  
Reviewed-By: Andres Freund  
Discussion: https://postgr.es/m/CALfoeis6=8ehuR=VNtHvj3z16cYfCwPdTcpaxU+sfSUJ5QgR3g@mail.gmail.com  

commit   : 71a8a4f6e36547bb060dbcc961ea9b57420f7190    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 Nov 2019 15:44:20 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 Nov 2019 15:44:20 -0300    

Add some support for automatically showing backtraces in certain error  
situations in the server.  Backtraces are shown on assertion failure;  
also, a new setting backtrace_functions can be set to a list of C  
function names, and all ereport()s and elog()s from the mentioned  
functions will have backtraces generated.  Finally, the function  
errbacktrace() can be manually added to an ereport() call to generate a  
backtrace for that call.  
  
Authors: Peter Eisentraut, Álvaro Herrera  
Discussion: https://postgr.es/m//5f48cb47-bf1e-05b6-7aae-3bf2cd01586d@2ndquadrant.com  
Discussion: https://postgr.es/m/CAMsr+YGL+yfWE=JvbUbnpWtrRZNey7hJ07+zT4bYJdVp4Szdrg@mail.gmail.com  

commit   : 3dcffb381c81c9c8f8254100feacac256b9e75a6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Nov 2019 18:12:51 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Nov 2019 18:12:51 +0100    

commit   : 879c1176157175e0a83742b810f137aebccef4a4    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Nov 2019 17:00:30 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 8 Nov 2019 17:00:30 +0900    

Currently, postgres_fdw does not support preparing a remote transaction  
for two-phase commit even in the case where the remote transaction is  
read-only, but the old error message appeared to imply that that was not  
supported only if the remote transaction modified remote tables.  Change  
the message so as to include the case where the remote transaction is  
read-only.  
  
Also fix a comment above the message.  
  
Also add a note about the lack of supporting PREPARE TRANSACTION to the  
postgres_fdw documentation.  
  
Reported-by: Gilles Darold  
Author: Gilles Darold and Etsuro Fujita  
Reviewed-by: Michael Paquier and Kyotaro Horiguchi  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/08600ed3-3084-be70-65ba-279ab19618a5%40darold.net  

commit   : b85e43feb3e837699239aba6b8e0f280a59417be    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Nov 2019 08:03:16 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 Nov 2019 08:03:16 +0100    

Use a separate error message for invalid checkpoint location and  
invalid state instead of just "invalid data" for both.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/20191107041630.GK1768@paquier.xyz  

commit   : e86c8ef243aad4570f66a406c81211f75774ced1    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 7 Nov 2019 17:12:09 -0800    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 7 Nov 2019 17:12:09 -0800    

nbtree index builds once stashed the "minimum key" for a page, which was  
used as the basis of the pivot tuple that gets placed in the next level  
up (i.e. the tuple that stores the downlink to the page in question).  
It doesn't quite work that way anymore, so the "minimum key" terminology  
now seems misleading (these days the minimum key is actually a straight  
copy of the high key from the left sibling, which is a distinct thing in  
subtle but important ways).  Rename this concept to "low key".  This  
name is a lot clearer given that there is now a sharp distinction  
between pivot and non-pivot tuples.  Also remove comments that describe  
obsolete details about how the minimum key concept used to work.  
  
Rather than generating the minus infinity item for the leftmost page on  
a level by copying the new item and truncating that copy, simply  
allocate a small buffer.  The old approach confusingly created the  
impression that the new item had some kind of significance.  This was  
another artifact of how things used to work before commits 8224de4f and  
dd299df8.  

commit   : c10fae21428fe926568e67b7662ed8577faf9235    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 Nov 2019 15:50:00 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 Nov 2019 15:50:00 -0500    

The point is that DELETE triggers cannot modify any values.  
  
Reported-by: Eugen Konkov  
  
Discussion: https://postgr.es/m/919823407.20191029175436@yandex.ru  
  
Backpatch-through: 9.4  

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

Declaring this in the client-visible header ecpglib.h was a pretty  
poor decision.  It's not meant to be application-callable (and if  
it was, putting it outside the extern "C" { ... } wrapper means  
that C++ clients would fail to call it).  And the declaration would  
not even compile for a client, anyway, since it would not have the  
macro pg_attribute_format_arg().  Fortunately, it seems that no  
clients have tried to include this header with ENABLE_NLS defined,  
or we'd have gotten complaints about that.  But we have no business  
putting such a restriction on client code.  
  
Move the declaration to ecpglib_extern.h, since in fact nothing  
outside src/interfaces/ecpg/ecpglib/ needs to call it.  
  
The practical effect of this is just that clients can now safely  
#include ecpglib.h while having ENABLE_NLS defined, but that seems  
like enough of a reason to back-patch it.  
  
Discussion: https://postgr.es/m/20590.1573069709@sss.pgh.pa.us  

commit   : b4bcc6bfdfa2b564b0171d437f9988a3159fd58d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 7 Nov 2019 13:59:24 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 7 Nov 2019 13:59:24 -0300    

SET CONSTRAINTS ... DEFERRED failed on partitioned tables, because of a  
sanity check that ensures that the affected constraints have triggers.  
On partitioned tables, the triggers are in the leaf partitions, not in  
the partitioned relations themselves, so the sanity check fails.  
Removing the sanity check solves the problem, because the code needed to  
support the case is already there.  
  
Backpatch to 11.  
  
Note: deferred unique constraints are not affected by this bug, because  
they do have triggers in the parent partitioned table.  I did not add a  
test for this scenario.  
  
Discussion: https://postgr.es/m/20191105212915.GA11324@alvherre.pgsql  

commit   : a7145f6bc8b7774a29f3841552a463fb20ea98d7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Nov 2019 11:22:52 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 Nov 2019 11:22:52 -0500    

This patch adopts the overflow check logic introduced by commit cbdb8b4c0  
into two more places.  interval_mul() failed to notice if it computed a  
new microseconds value that was one more than INT64_MAX, and pgbench's  
double-to-int64 logic had the same sorts of edge-case problems that  
cbdb8b4c0 fixed in the core code.  
  
To make this easier to get right in future, put the guts of the checks  
into new macros in c.h, and add commentary about how to use the macros  
correctly.  
  
Back-patch to all supported branches, as we did with the previous fix.  
  
Yuya Watari  
  
Discussion: https://postgr.es/m/CAJ2pMkbkkFw2hb9Qb1Zj8d06EhWAQXFLy73St4qWv6aX=vqnjw@mail.gmail.com  

commit   : effa40281bb1f6c71e81c980f86852ab3be603c3    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 7 Nov 2019 13:30:04 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 7 Nov 2019 13:30:04 +0100    

The presence of long long int is now implied in the requirement for  
C99 and the configure check for the same.  
  
We keep the define hard-coded in ecpg_config.h for backward  
compatibility with ecpg-using user code.  
  
Discussion: https://www.postgresql.org/message-id/flat/5cdd6a2b-b2c7-c6f6-344c-a406d5c1a254%402ndquadrant.com  

commit   : 581a55889ba7f76dd87a270e37e5137f684bfdb7    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 7 Nov 2019 09:54:09 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 7 Nov 2019 09:54:09 +0100    

We need to pop the error stack before running the user-supplied  
PG_FINALLY code.  Otherwise an error in the cleanup code would end up  
at the same sigsetjmp() invocation and result in an infinite error  
handling loop.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/95a822c3-728b-af0e-d7e5-71890507ae0c%402ndquadrant.com  

commit   : a0c96856e8b38a102daac76e3d385d9f8876744e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 7 Nov 2019 16:31:36 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 7 Nov 2019 16:31:36 +0900    

If there is the WAL page that the continuation WAL record just fits within  
(i.e., the continuation record ends just at the end of the page) and  
the LSN in such page is specified with -s option, previously pg_waldump  
caused an assertion failure. The cause of this assertion failure was that  
XLogFindNextRecord() that pg_waldump -s calls mistakenly handled  
such special WAL page.  
  
This commit changes XLogFindNextRecord() so that it can handle  
such WAL page correctly.  
  
Back-patch to all supported versions.  
  
Author: Andrey Lepikhov  
Reviewed-by: Fujii Masao, Michael Paquier  
Discussion: https://postgr.es/m/99303554-5dd5-06e6-f943-b3005ccd6edd@postgrespro.ru  

commit   : 7815e7efdb4ce9575b5d8460beb0dd2569d7ca3a    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 7 Nov 2019 16:51:04 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 7 Nov 2019 16:51:04 +1300    

Introduce qunique() and qunique_arg(), which can be used after qsort()  
and qsort_arg() respectively to remove duplicate values.  Use it where  
appropriate.  
  
Author: Thomas Munro  
Reviewed-by: Tom Lane (in an earlier version)  
Discussion: https://postgr.es/m/CAEepm%3D2vmFTNpAmwbGGD2WaryM6T3hSDVKQPfUwjdD_5XY6vAA%40mail.gmail.com  

commit   : 3feb6ace7cfe8edbf6db702de06dc9295f307a8e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 7 Nov 2019 11:13:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 7 Nov 2019 11:13:31 +0900    

SPI gets used to build a list of relation OIDs for XML object  
generation, and one code path building a list uses SPI_execute() without  
looking at errors it produces.  So fix that.  
  
Author: Mark Dilger  
Reviewed-by: Michael Paquier, Pavel Stehule  
Discussion: https://postgr.es/m/17d30445-4862-7917-170f-84328dcd292d@gmail.com  

commit   : 6e3e6cc0e884a6091e1094dff29db430af08fb93    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 4 Nov 2019 01:57:45 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 4 Nov 2019 01:57:45 +0100    

This allows logging a sample of statements, without incurring excessive  
log traffic (which may impact performance).  This can be useful when  
analyzing workloads with lots of short queries.  
  
The sampling is configured using two new GUC parameters:  
  
 * log_min_duration_sample - minimum required statement duration  
  
 * log_statement_sample_rate - sample rate (0.0 - 1.0)  
  
Only statements with duration exceeding log_min_duration_sample are  
considered for sampling. To enable sampling, both those GUCs have to  
be set correctly.  
  
The existing log_min_duration_statement GUC has a higher priority, i.e.  
statements with duration exceeding log_min_duration_statement will be  
always logged, irrespectedly of how the sampling is configured. This  
means only configurations  
  
  log_min_duration_sample < log_min_duration_statement  
  
do actually sample the statements, instead of logging everything.  
  
Author: Adrien Nayrat  
Reviewed-by: David Rowley, Vik Fearing, Tomas Vondra  
Discussion: https://postgr.es/m/bbe0a1a8-a8f7-3be2-155a-888e661cc06c@anayrat.info  

commit   : 11d9ac28e5e0077d8f23761c2962a30423f44cee    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 4 Nov 2019 02:00:26 +0100    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 4 Nov 2019 02:00:26 +0100    

The docs do say which GUCs can be changed only by superusers, but we  
forgot to mention this for the new log_transaction_sample_rate. This  
GUC was introduced in PostgreSQL 12, so backpatch accordingly.  
  
Author: Adrien Nayrat  
Backpatch-through: 12  

commit   : 22e44e8dbcfe4b9f3c4189f07a2361c951d72514    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Nov 2019 12:00:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Nov 2019 12:00:17 -0500    

Avoid creating transiently-inconsistent slot states where possible,  
by not setting TTS_FLAG_SHOULDFREE until after the slot actually has  
a free'able tuple pointer, and by making sure that we reset tts_nvalid  
and related derived state before we replace the tuple contents.  This  
would only matter if something were to examine the slot after we'd  
suffered some kind of error (e.g. out of memory) while manipulating  
the slot.  We typically don't do that, so these changes might just be  
cosmetic --- but even if so, it seems like good future-proofing.  
  
Also remove some redundant Asserts, and add a couple for consistency.  
  
Back-patch to v12 where all this code was rewritten.  
  
Discussion: https://postgr.es/m/16095-c3ff2e5283b8dba5@postgresql.org  

commit   : ff43b3e88eceb94b3a2b2579e8510e4f3aedbe09    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Nov 2019 11:11:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 Nov 2019 11:11:40 -0500    

Since commit d26a810eb, we've defined bool as being either _Bool from  
<stdbool.h>, or "unsigned char"; but that commit overlooked the fact  
that probes.d has "#define bool char".  For consistency, make it say  
"unsigned char" instead.  This should be strictly a cosmetic change,  
but it seems best to be in sync.  
  
Formally, in the now-normal case where we're using <stdbool.h>, it'd  
be better to write "#define bool _Bool".  However, then we'd need  
some build infrastructure to inject that configuration choice into  
probes.d, and it doesn't seem worth the trouble.  We only use  
<stdbool.h> if sizeof(_Bool) is 1, so having DTrace think that  
bool parameters are "unsigned char" should be close enough.  
  
Back-patch to v12 where d26a810eb came in.  
  
Discussion: https://postgr.es/m/CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com  

commit   : d40abd5fcfb25d764419f8e9bffa5cdbdb247c1b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 6 Nov 2019 14:20:29 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 6 Nov 2019 14:20:29 +0100    

The previous code was allocating more memory than necessary because  
the formula used the wrong data type.  
  
Reported-by: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
Discussion: https://www.postgresql.org/message-id/20191105172918.3e32a446@firost  

commit   : 5b7ba75f7ff854003231e8099e3038c7e2eba875    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 6 Nov 2019 08:07:04 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 6 Nov 2019 08:07:04 +0100    

The cache_plan argument to ri_PlanCheck has not been used since  
e8c9fd5fdf768323911f7088e8287f63b513c3c6.  
  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/ec8a8b45-a30b-9193-cd4b-985d60d1497e%402ndquadrant.com  

commit   : 5f6b1eb0cf4b0fb101478da51c294a63fd4726ef    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 6 Nov 2019 16:12:21 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 6 Nov 2019 16:12:21 +0900    

When sending data for logical decoding using the streaming replication  
protocol via a WAL sender, the timestamp of the sent write message is  
allocated at the beginning of the message when preparing for the write,  
and actually computed when the write message is ready to be sent.  
  
The timestamp was getting computed after sending the message.  This  
impacts anything using logical decoding, causing for example logical  
replication to report mostly NULL for last_msg_send_time in  
pg_stat_subscription.  
  
This commit makes sure that the timestamp is computed before sending the  
message.  This is wrong since 5a991ef, so backpatch down to 9.4.  
  
Author: Jeff Janes  
Discussion: https://postgr.es/m/CAMkU=1z=WMn8jt7iEdC5sYNaPgAgOASb_OW5JYv-vMdYaJSL-w@mail.gmail.com  
Backpatch-through: 9.4  

commit   : a9056cc637f2d183eefa165ebbd0308d9a89abb9    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 6 Nov 2019 04:13:30 +0000    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Wed, 6 Nov 2019 04:13:30 +0000    

WindowAgg will potentially store large numbers of input rows into  
tuplestores to allow access to other rows in the frame. If the input  
is coming via an explicit Sort node, then unneeded columns will  
already have been discarded (since Sort requests a small tlist); but  
there are idioms like COUNT(*) OVER () that result in the input not  
being sorted at all, and cases where the input is being sorted by some  
means other than a Sort; if we don't request a small tlist, then  
WindowAgg's storage requirement is inflated by the unneeded columns.  
  
Backpatch back to 9.6, where the current tlist handling was added.  
(Prior to that, WindowAgg would always use a small tlist.)  
  
Discussion: https://postgr.es/m/87a7ator8n.fsf@news-spur.riddles.org.uk  

commit   : 979766c0afceb95c4b96323b57a0f6edf8472612    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Nov 2019 12:54:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Nov 2019 12:54:17 +0900    

Previously ALTER MATERIALIZED VIEW / FOREIGN TABLE ... RENAME COLUMN ...  
returned "ALTER TABLE" as a command tag. This commit fixes them so that  
they return "ALTER MATERIALIZED VIEW" and "ALTER FOREIGN TABLE" as  
command tags, respectively.  
  
This issue exists in all supported versions, but we don't back-patch this  
because it's not enough of a bug to justify taking any compatibility risks for.  
Otherwise, the back-patch would cause minor version update to break,  
for example, the existing event trigger functions using TG_TAG.  
  
Author: Fujii Masao  
Reviewed-by: Ibrar Ahmed  
Discussion: https://postgr.es/m/CAHGQGwGUaC03FFdTFoHsCuDrrNvFvNVQ6xyd40==P25WvuBJjg@mail.gmail.com  

commit   : a386942bd29b0ef0c9df061392659880d22cdf43    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Nov 2019 11:02:30 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 6 Nov 2019 11:02:30 +0900    

This commit allows --init-steps option in pgbench to accept "G" character  
meaning server-side data generation as an initialization step.  
With "G", only limited queries are sent from pgbench client and  
then data is actually generated in the server. This might make  
the initialization phase faster if the bandwidth between pgbench client  
and the server is low.  
  
Author: Fabien Coelho  
Reviewed-by: Anna Endo, Ibrar Ahmed, Fujii Masao  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1904061826420.3678@lancre  

commit   : 4b5e58b86e3b09daa7384dbbd0bb4cacbd9bd7c6    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 Nov 2019 20:54:04 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 Nov 2019 20:54:04 -0500    

Reported-by: matthew.alton@gmail.com  
  
Discussion: https://postgr.es/m/157204060717.1042.8194076510523669244@wrigleys.postgresql.org  
  
Backpatch-through: 9.4  

commit   : 26aaf97b683d6258c098859e6b1268e1f5da242f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 5 Nov 2019 14:56:40 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 5 Nov 2019 14:56:40 -0800    

There's plenty places in frontend code that could benefit from a  
string buffer implementation. Some because it yields simpler and  
faster code, and some others because of the desire to share code  
between backend and frontend.  
  
While there is a string buffer implementation available to frontend  
code, libpq's PQExpBuffer, it is clunkier than stringinfo, it  
introduces a libpq dependency, doesn't allow for sharing between  
frontend and backend code, and has a higher API/ABI stability  
requirement due to being exposed via libpq.  
  
Therefore it seems best to just making StringInfo being usable by  
frontend code. There's not much to do for that, except for rewriting  
two subsequent elog/ereport calls into others types of error  
reporting, and deciding on a maximum string length.  
  
For the maximum string size I decided to privately define MaxAllocSize  
to the same value as used in the backend. It seems likely that we'll  
want to reconsider this for both backend and frontend code in the not  
too far away future.  
  
For now I've left stringinfo.h in lib/, rather than common/, to reduce  
the likelihood of unnecessary breakage. We could alternatively decide  
to provide a redirecting stringinfo.h in lib/, or just not provide  
compatibility.  
  
Author: Andres Freund  
Reviewed-By: Kyotaro Horiguchi, Daniel Gustafsson  
Discussion: https://postgr.es/m/20190920051857.2fhnvhvx4qdddviz@alap3.anarazel.de  

commit   : 01368e5d9da77099b38aac527b01b85cc7869b25    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 5 Nov 2019 14:41:07 -0800    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 5 Nov 2019 14:41:07 -0800    

When maintaining or merging patches, one of the most common sources  
for conflicts are the list of objects in makefiles. Especially when  
the split across lines has been changed on both sides, which is  
somewhat common due to attempting to stay below 80 columns, those  
conflicts are unnecessarily laborious to resolve.  
  
By splitting, and alphabetically sorting, OBJS style lines into one  
object per line, conflicts should be less frequent, and easier to  
resolve when they still occur.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20191029200901.vww4idgcxv74cwes@alap3.anarazel.de  

commit   : 66c61c81b90c68db84d422092fbbf8a1a82ee09a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Nov 2019 14:29:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Nov 2019 14:29:08 -0500    

Avoid initial capital, since that's not how we do it.  
  
Discussion: https://postgr.es/m/CACP=ajbrFFYUrLyJBLV8=q+eNCapa1xDEyvXhMoYrNphs-xqPw@mail.gmail.com  

commit   : 3affe76ef8227dad85b61cec769235f682132651    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Nov 2019 14:27:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Nov 2019 14:27:37 -0500    

For a long time (since commit aed378e8d) we have had a policy to log  
nothing about a connection if the client disconnects when challenged  
for a password.  This is because libpq-using clients will typically  
do that, and then come back for a new connection attempt once they've  
collected a password from their user, so that logging the abandoned  
connection attempt will just result in log spam.  However, this did  
not work well for PAM authentication: the bottom-level function  
pam_passwd_conv_proc() was on board with it, but we logged messages  
at higher levels anyway, for lack of any reporting mechanism.  
Add a flag and tweak the logic so that the case is silent, as it is  
for other password-using auth mechanisms.  
  
Per complaint from Yoann La Cancellera.  It's been like this for awhile,  
so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CACP=ajbrFFYUrLyJBLV8=q+eNCapa1xDEyvXhMoYrNphs-xqPw@mail.gmail.com  

commit   : a30531c5c8a384363d410d4027e1c1eeed76e550    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Nov 2019 13:40:37 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Nov 2019 13:40:37 -0500    

get_relkind_objtype, and hence get_object_type, failed when applied to a  
toast table.  This is not a good thing, because it prevents reporting of  
perfectly legitimate permissions errors.  (At present, these functions  
are in fact *only* used to determine the ObjectType argument for  
acl_error() calls.)  It seems best to have them fall back to returning  
OBJECT_TABLE in every case where they can't determine an object type  
for a pg_class entry, so do that.  
  
In passing, make some edits to alter.c to make it more obvious that  
those calls of get_object_type() are used only for error reporting.  
This might save a few cycles in the non-error code path, too.  
  
Back-patch to v11 where this issue originated.  
  
John Hsu, Michael Paquier, Tom Lane  
  
Discussion: https://postgr.es/m/C652D3DF-2B0C-4128-9420-FB5379F6B1E4@amazon.com  

commit   : 529ebb20aaa5eb68e4fb7a656271bbb83efe9529    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Nov 2019 11:42:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 Nov 2019 11:42:24 -0500    

Commit d25ea0127 got rid of what I thought were entirely unnecessary  
derived child expressions in EquivalenceClasses for EC members that  
mention multiple baserels.  But it turns out that some of the child  
expressions that code created are necessary for partitionwise joins,  
else we fail to find matching pathkeys for Sort nodes.  (This happens  
only for certain shapes of the resulting plan; it may be that  
partitionwise aggregation is also necessary to show the failure,  
though I'm not sure of that.)  
  
Reverting that commit entirely would be quite painful performance-wise  
for large partition sets.  So instead, add code that explicitly  
generates child expressions that match only partitionwise child join  
rels we have actually generated.  
  
Per report from Justin Pryzby.  (Amit Langote noticed the problem  
earlier, though it's not clear if he recognized then that it could  
result in a planner error, not merely failure to exploit partitionwise  
join, in the code as-committed.)  Back-patch to v12 where commit  
d25ea0127 came in.  
  
Amit Langote, with lots of kibitzing from me  
  
Discussion: https://postgr.es/m/CA+HiwqG2WVUGmLJqtR0tPFhniO=H=9qQ+Z3L_ZC+Y3-EVQHFGg@mail.gmail.com  
Discussion: https://postgr.es/m/20191011143703.GN10470@telsasoft.com  

commit   : 2a4d96ebbd65be9aa421a8a4550a51ff12bc6d2d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 5 Nov 2019 10:32:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 5 Nov 2019 10:32:38 +0900    

Since 898e5e32, this command uses partially ShareUpdateExclusiveLock,  
but the docs did not get the call.  
  
Author: Justin Pryzby  
Reviewed-by: Amit Langote, Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/20191028001207.GB23808@telsasoft.com  
Backpatch-through: 12  

commit   : ea881338014fd5c7d864d78d2eb441d784d1cc39    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 5 Nov 2019 10:17:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 5 Nov 2019 10:17:33 +0900    

This clarifies more how to use and how to take advantage of constraints  
when attaching a new partition.  
  
Author: Justin Pryzby  
Reviewed-by: Amit Langote, Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/20191028001207.GB23808@telsasoft.com  
Backpatch-through: 10  

commit   : 3534fa2233285c1fab1e668871aabf05e5541213    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 5 Nov 2019 09:17:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 5 Nov 2019 09:17:05 +0900    

Historically, the code to build relation options has been shaped the  
same way in multiple code paths by using a set of datums in input with  
the options parsed with a static table which is then filled with the  
option values.  This introduces a new common routine in reloptions.c to  
do most of the legwork for the in-core code paths.  
  
Author: Amit Langote  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CA+HiwqGsoSn_uTPPYT19WrtR7oYpYtv4CdS0xuedTKiHHWuk_g@mail.gmail.com  

commit   : 5102f39440f758ea53c2e1cdea7d8411df1805d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Nov 2019 16:25:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Nov 2019 16:25:05 -0500    

The code only compared two triggers' names and namespaces (the latter  
being the owning table's schema).  This could result in falling back  
to an OID-based sort of similarly-named triggers on different tables.  
We prefer to avoid that, so add a comparison of the table names too.  
(The sort order is thus table namespace, trigger name, table name,  
which is a bit odd, but it doesn't seem worth contorting the code  
to work around that.)  
  
Likewise for policy objects, in 9.5 and up.  
  
Complaint and fix by Benjie Gillam.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/CAMThMzEEt2mvBbPgCaZ1Ap1N-moGn=Edxmadddjq89WG4NpPtQ@mail.gmail.com  

commit   : ec28808ba85853fa14b090199236ca555273607e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Nov 2019 14:16:42 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 Nov 2019 14:16:42 -0500    

As the code stands, nEntries counts the number of ginEntryInsert()  
calls, so that's what you end up with at the end of a GIN index build.  
However, ginvacuumcleanup() recomputes nEntries as the number of  
surviving leaf tuples, and that's generally consistent with the way that  
gincostestimate() uses the value.  So let's clearly define nEntries  
as the number of leaf tuples, and therefore adjust ginEntryInsert() to  
increment it only when we make a new one, not when we add TIDs into an  
existing tuple or posting tree.  
  
In practice this inconsistency probably has little impact, so I don't  
feel a need to back-patch.  
  
Insung Moon and Keisuke Kuroda  
  
Discussion: https://postgr.es/m/CAEMmqBuH_O-oXL+3_ArQ6F5cJ7kXVow2SGQB3HRacku_T+xkmA@mail.gmail.com  

commit   : a63c84e59acf9f5e2b54aad4974a80e5075af646    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 4 Nov 2019 11:07:32 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 4 Nov 2019 11:07:32 +0100    

Some older compilers appear to not understand the recently introduced  
PG_FINALLY code structure that well in some circumstances and complain  
about possibly uninitialized variables.  So to fix, initialize the  
variables explicitly in the cases complained about.  
  
Discussion: https://www.postgresql.org/message-id/flat/95a822c3-728b-af0e-d7e5-71890507ae0c%402ndquadrant.com  

commit   : 8557a6f10ca6f01f4b2f2f25e197292f3f46bb5c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 4 Nov 2019 08:30:00 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 4 Nov 2019 08:30:00 +0100    

Rearrange the logic in record_image_cmp() and datum_image_eq() to  
error out on unexpected typlens (either not supported there or  
completely invalid due to corruption).  Barring corruption, this is  
not possible today but it seems more future-proof and robust to fix  
this.  
  
Reported-by: Peter Geoghegan <pg@bowt.ie>  

commit   : db27b60f07a039e236738fe90bd4215cafd35cf2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Nov 2019 16:10:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Nov 2019 16:10:23 -0500    

Commit 8af1624e3 introduced a warning about possibly returning  
without a value, on compilers that don't realize that ereport(ERROR)  
doesn't return.  Tweak the code to avoid that.  
  
Per buildfarm.  Back-patch to 9.6, like the aforesaid commit.  

commit   : 741b1aaf61a3da10250555f827c0a7a2f9bc2822    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Nov 2019 10:57:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 3 Nov 2019 10:57:49 -0500    

DatumGetPointer() takes a Datum argument, not a pointer.  
This is cosmetic given the current definitions of the  
underlying macros, but it's still formally a type violation.  
  
Bug was introduced in commit 389bb2818, but there seems  
no need to back-patch.  
  
Dagfinn Ilmari Mannsåker  
  
Discussion: https://postgr.es/m/d8jlfsxq3a0.fsf@dalvik.ping.uio.no  

commit   : 8af1624e3f0efd2d029217a91d07bd3795f080a6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Nov 2019 16:45:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 2 Nov 2019 16:45:32 -0400    

Using incorrect, or just mismatched, dictionary and affix files  
could result in a crash, due to failure to cross-check offsets  
obtained from the file.  Add necessary validation, as well as  
some Asserts for future-proofing.  
  
Per bug #16050 from Alexander Lakhin.  Back-patch to 9.6 where the  
problem was introduced.  
  
Arthur Zakirov, per initial investigation by Tomas Vondra  
  
Discussion: https://postgr.es/m/16050-024ae722464ab604@postgresql.org  
Discussion: https://postgr.es/m/20191013012610.2p2fp3zzpoav7jzf@development  

commit   : dc816e5815913e2b2ae2327a4d3e4d4416ed6898    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 2 Nov 2019 14:16:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 2 Nov 2019 14:16:04 +0900    

When using CREATE TABLE for a new partition, the partitioned indexes of  
the parent are created automatically in a fashion similar to LIKE  
INDEXES.  The new partition and its parent use a mapping for attribute  
numbers for this operation, and while the mapping was correctly built,  
its length was defined as the number of attributes of the newly-created  
child, and not the parent.  If the parent includes dropped columns, this  
could cause failures.  
  
This is wrong since 8b08f7d which has introduced the concept of  
partitioned indexes, so backpatch down to 11.  
  
Reported-by: Wyatt Alt  
Author: Michael Paquier  
Reviewed-by: Amit Langote  
Discussion: https://postgr.es/m/CAGem3qCcRmhbs4jYMkenYNfP2kEusDXvTfw-q+eOhM0zTceG-g@mail.gmail.com  
Backpatch-through: 11  

commit   : e174f699c476a4cc01875211a5f43e57c3190a37    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 Nov 2019 22:51:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 Nov 2019 22:51:05 +0900    

A couple of routines assume that the LWLock SyncRepLock needs to be  
taken, so add a couple of assertions to be sure of that.  Also, when  
waiting for a given LSN at transaction commit, the code implied that the  
syncrep queue cleanup happens while holding interrupts, but the code  
never checked after that.  
  
Author: Michael Paquier  
Reviewed-by: Fujii Masao, Kyotaro Horiguchi, Dongming Liu  
Discussion: https://postgr.es/m/a0806273-8bbb-43b3-bbe1-c45a58f6ae21.lingce.ldm@alibaba-inc.com  

commit   : 20345197ff48c99a8a20dd3cd191d2aad5c7271c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 Nov 2019 22:38:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 Nov 2019 22:38:32 +0900    

When a backend exits, it gets deleted from the syncrep queue if present.  
The queue was checked without SyncRepLock taken in exclusive mode, so it  
would have been possible for a backend to remove itself after a WAL  
sender already did the job.  Fix this issue based on a suggestion from  
Fujii Masao, by first checking the queue without the lock.  Then, if the  
backend is present in the queue, take the lock and perform an additional  
lookup check before doing the element deletion.  
  
Author: Dongming Liu  
Reviewed-by: Kyotaro Horiguchi, Fujii Masao, Michael Paquier  
Discussion: https://postgr.es/m/a0806273-8bbb-43b3-bbe1-c45a58f6ae21.lingce.ldm@alibaba-inc.com  
Backpatch-through: 9.4  

commit   : 396773762425126a85243fc85a267d401496beb8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 1 Nov 2019 13:16:21 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 1 Nov 2019 13:16:21 +0100    

In these macros, the rd_options pointer is cast to ViewOption *.  Add  
some assertions that the passed-in relation is actually a view before  
doing that.  
  
Author: Nikolay Shaplov <dhyan@nataraj.su>  
Discussion: https://www.postgresql.org/message-id/flat/3634983.eHpMQ1mJnI@x200m  

commit   : 604bd3671121b51f977de146ed95484c2297fb3e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 1 Nov 2019 11:09:52 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 1 Nov 2019 11:09:52 +0100    

This gives an alternative way of catching exceptions, for the common  
case where the cleanup code is the same in the error and non-error  
cases.  So instead of  
  
    PG_TRY();  
    {  
        ... code that might throw ereport(ERROR) ...  
    }  
    PG_CATCH();  
    {  
        cleanup();  
	PG_RE_THROW();  
    }  
    PG_END_TRY();  
    cleanup();  
  
one can write  
  
    PG_TRY();  
    {  
        ... code that might throw ereport(ERROR) ...  
    }  
    PG_FINALLY();  
    {  
        cleanup();  
    }  
    PG_END_TRY();  
  
Discussion: https://www.postgresql.org/message-id/flat/95a822c3-728b-af0e-d7e5-71890507ae0c%402ndquadrant.com  

commit   : 73025140885c889410b9bfc4a30a3866396fc5db    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 31 Oct 2019 07:41:41 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 31 Oct 2019 07:41:41 +0100    

Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://www.postgresql.org/message-id/flat/dc9b45fa-b950-fadc-4751-85d6f729df55%402ndquadrant.com