PostgreSQL 13.0 (upcoming) commit log

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  

commit   : f921ea624eb8695c6ccaaf3410b9f9d9926d71c7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 31 Oct 2019 10:22:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 31 Oct 2019 10:22:24 +0900    

Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20191030.123428.18823202335157111.horikyota.ntt@gmail.com  

commit   : c5e1df951d9d70ab7d53ce47caaf73f3b2d6b1e1    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 30 Oct 2019 11:01:44 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 30 Oct 2019 11:01:44 +0100    

IDENT_USERNAME_MAX is the maximum length of the information returned  
by an ident server, per RFC 1413.  Using it as the buffer size in peer  
authentication is inappropriate.  It was done here because of the  
historical relationship between peer and ident authentication.  To  
reduce confusion between the two authenticaton methods and disentangle  
their code, use a dynamically allocated buffer instead.  
  
Discussion: https://www.postgresql.org/message-id/flat/c798fba5-8b71-4f27-c78e-37714037ea31%402ndquadrant.com  

commit   : 5cc1e64fb6f59aa8621caae03be36400807e3575    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 30 Oct 2019 09:13:39 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 30 Oct 2019 09:13:39 +0100    

For historical reasons, the functions for peer authentication were  
grouped under ident authentication.  But they are really completely  
separate, so give them their own section headings.  

commit   : e4d92126fda1defd9be201b97b162d1568122064    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 29 Oct 2019 22:46:40 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 29 Oct 2019 22:46:40 -0700    

The additional newline seems to have accidentally been introduced in  
2c03216d831, in 9.5. The newline is only issued when an FPW is  
present for the block reference.  
  
While there could be an argument that removing the newlines in the  
back branches could cause a problem for somebody parsing the  
pg_waldump output, the likelihood of that seems small enough. It seems  
at least equally likely that the randomness of when newlines are  
issued causes problems.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20191029233341.4gnyau7e5v2lh5sc@alap3.anarazel.de  
Backpatch: 9.5, like 2c03216d831.  

commit   : e0f76f204ccb870fc207546eaeae65abeacb7dad    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 29 Oct 2019 19:18:07 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 29 Oct 2019 19:18:07 -0700    

This got broken in 604f7956b94, shortly after rm_identify's  
introduction.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20191029233341.4gnyau7e5v2lh5sc@alap3.anarazel.de  
Backpatch: 9.5, where rm_identify was introduced  

commit   : 6ca86bb7e9c72f428c7f4e3f2b48dd6c4084429c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Oct 2019 10:03:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 30 Oct 2019 10:03:00 +0900    

Author: Vignesh C  
Reviewed-by: Dilip Kumar, Michael Paquier  
Discussion: https://postgr.es/m/CALDaNm0ni+GAOe4+fbXiOxNrVudajMYmhJFtXGX-zBPoN8ixhw@mail.gmail.com  

commit   : 517bf2d9107f0d45c5fea2e3904e8d3b10ce6bb2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Oct 2019 09:14:43 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 29 Oct 2019 09:14:43 +0100    

Under MinGW, when compiling the ecpg test files, you get compiler  
warnings about the use of %lld in printf().  
  
These files don't use our printf replacement or the c.h porting layer,  
so determine the appropriate format conversion the hard way.  
  
Reviewed-by: Michael Meskes <meskes@postgresql.org>  
Discussion: https://www.postgresql.org/message-id/flat/760c9dd1-2d80-c223-3f90-609b615f7918%402ndquadrant.com  

commit   : d80be6f2f6c9793b92fc87c61d9ae2bcea3db560    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Oct 2019 11:08:09 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 29 Oct 2019 11:08:09 +0900    

When cancelling REINDEX CONCURRENTLY after swapping the old and new  
indexes (for example interruption at step 5), the old index remains  
around and is marked as invalid.  The old index should also be manually  
droppable to clean up the parent relation from any invalid indexes still  
remaining.  For a partition index reindexed, pg_class.relispartition was  
not getting updated, causing the index to not be droppable as DROP INDEX  
would look for dependencies in a partition tree, which do not exist  
anymore after the swap phase is done.  
  
The fix here is simple: when swapping the old and new indexes, make sure  
that pg_class.relispartition is correctly switched, similarly to what is  
done for the index name.  
  
Reported-by: Justin Pryzby  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20191015164047.GA22729@telsasoft.com  
Backpatch-through: 12  

commit   : 8b7a0f1d118282f612e5b9686d820edcddedd081    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Oct 2019 15:08:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Oct 2019 15:08:24 -0400    

Teach get_expr_result_type() to manufacture a tuple descriptor directly  
from a RowExpr node.  If the RowExpr has type RECORD, this is the only  
way to get a tupdesc for its result, since even if the rowtype has been  
blessed, we don't have its typmod available at this point.  (If the  
RowExpr has some named composite type, we continue to let the existing  
code handle it, since the RowExpr might well not have the correct column  
names embedded in it.)  
  
This fixes assorted corner cases illustrated by the added regression  
tests.  
  
Discussion: https://postgr.es/m/10872.1572202006@sss.pgh.pa.us  

commit   : f88544904e4b57b1a8e969a5d594288554417c88    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Oct 2019 14:15:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Oct 2019 14:15:03 -0400    

Historically, psql consulted COMSPEC to spawn a shell in its \! command,  
but we just invoked "cmd" when spawning shells in pg_ctl and pg_regress.  
It seems better to rely on the environment variable, if it's set,  
in all cases.  
  
It's debatable whether this is a bug fix or just a behavioral change,  
so no back-patch.  
  
Juan José Santamaría Flecha  
  
Discussion: https://postgr.es/m/16080-5d7f03222469f717@postgresql.org  

commit   : bd1ef5799b04168d8a869197dd9b85935d5d5da9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Oct 2019 12:21:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 28 Oct 2019 12:21:13 -0400    

Commit 9556aa01c rearranged the innards of text_position() in a way  
that would make it not work for empty search strings.  Which is fine,  
because all callers of that code special-case an empty pattern in  
some way.  However, the primary use-case (text_position itself) got  
special-cased incorrectly: historically it's returned 1 not 0 for  
an empty search string.  Restore the historical behavior.  
  
Per complaint from Austin Drenski (via Shay Rojansky).  
Back-patch to v12 where it got broken.  
  
Discussion: https://postgr.es/m/CADT4RqAz7oN4vkPir86Kg1_mQBmBxCp-L_=9vRpgSNPJf0KRkw@mail.gmail.com  

commit   : 61ecea45e50bcd3b87d4e905719e63e41d6321ce    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Oct 2019 14:23:42 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Oct 2019 14:23:42 +0900    

There is a step to track when the new heap is written, but this was  
missing in the documentation.  
  
Author: Noriyoshi Shinoda  
Discussion: https://postgr.es/m/AT5PR8401MB06447FAE88E1592754E958B8EE640@AT5PR8401MB0644.NAMPRD84.PROD.OUTLOOK.COM  
Backpatch-through: 12  

commit   : 68ac9cf2499236996f3d4bf31f7f16d5bd3c77af    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Oct 2019 11:57:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 28 Oct 2019 11:57:31 +0900    

When swapping the dependencies of the old and new indexes, the code has  
been correctly switching all links in pg_depend from the old to the new  
index for both referencing and referenced entries.  However it forgot  
the fact that the new index may itself have existing entries in  
pg_depend, like references to the parent table attributes.  This  
resulted in duplicated entries in pg_depend after running REINDEX  
CONCURRENTLY.  
  
Fix this problem by removing any existing entries in pg_depend on the  
new index before switching the dependencies of the old index to the new  
one.  More regression tests are added to check the consistency of  
entries in pg_depend for indexes, including partition indexes.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20191025064318.GF8671@paquier.xyz  
Backpatch-through: 12  

commit   : 51970fa8df9b32b5501ca1cb9d5b805894c1e064    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 27 Oct 2019 13:54:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 27 Oct 2019 13:54:12 +0900    

9155580 has changed the value of the first fake LSN for unlogged  
relations from 1 to FirstNormalUnloggedLSN (aka 1000), GiST requiring a  
non-zero LSN on some pages to allow an interlocking logic to work, but  
its value was still initialized to 1 at the beginning of recovery or  
after running pg_resetwal.  This fixes the initialization for both code  
paths.  
  
Author: Takayuki Tsunakawa  
Reviewed-by: Dilip Kumar, Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/OSBPR01MB2503CE851940C17DE44AE3D9FE6F0@OSBPR01MB2503.jpnprd01.prod.outlook.com  
Backpatch-through: 12  

commit   : b804521344fb366215900ac3f01314a1710bc6d8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 26 Oct 2019 12:55:16 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 26 Oct 2019 12:55:16 -0700    

Commit a7471bd85c05f849e88d6cfe9da3c795008e8f2e introduced it.  

commit   : e653c714c25bb8bde0b80b3bf3a220704b71a106    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 26 Oct 2019 12:55:06 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 26 Oct 2019 12:55:06 -0700    

State the earliest known fixed version, so we can someday judge the  
workaround to be obsolete.  

commit   : cfb7559083436b802e7ecc5e3fa235057890265c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Oct 2019 12:30:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 26 Oct 2019 12:30:41 -0400    

When we added the GUC units feature, we didn't make any great effort  
to adjust the documentation of individual GUCs; they tended to still  
say things like "this is the number of milliseconds that ...", even  
though users might prefer to write some other units, and SHOW might  
even show the value in other units.  Commit 6c9fb69f2 made an effort  
to improve this situation, but I thought it made things less readable  
by injecting units information in mid-sentence.  It also wasn't very  
consistent, and did not touch all the GUCs that have units.  
  
To improve matters, standardize on the phrasing "If this value is  
specified without units, it is taken as <units>".  Also, try to  
standardize where this is mentioned, right before the specification  
of the default.  (In a couple of places, doing that would've required  
more rewriting than seemed justified, so I wasn't 100% consistent  
about that.)  I also tried to use the phrases "amount of time",  
"amount of memory", etc rather than describing the contents of GUCs  
in other ways, as those were the majority usage in places that weren't  
overcommitting to a particular unit.  (I left "length of time" alone  
in a couple of places, though.)  
  
I failed to resist the temptation to copy-edit some awkward text, too.  
  
Backpatch to v12, like 6c9fb69f2, mainly because v12 hasn't diverged  
much from HEAD yet.  
  
Discussion: https://postgr.es/m/15882.1571942223@sss.pgh.pa.us  

commit   : 2fc2a88e6722df40245d3ae2ec7f8fc1c6bf0596    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Oct 2019 21:11:48 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Oct 2019 21:11:48 +0200    

Remove SQL_LANGUAGES, which was eliminated in SQL:2008, and  
SQL_PACKAGES and SQL_SIZING_PROFILES, which were eliminated in  
SQL:2011.  Since they were dropped by the SQL standard, the  
information in them was no longer updated and therefore no longer  
useful.  
  
This also removes the feature-package association information in  
sql_feature_packages.txt, but for the time begin we are keeping the  
information which features are in the Core package (that is, mandatory  
SQL features).  Maybe at some point someone wants to invent a way to  
store that that does not involve using the "package" mechanism  
anymore.  
  
Discussion https://www.postgresql.org/message-id/flat/91334220-7900-071b-9327-0c6ecd012017%402ndquadrant.com  

commit   : 592a16321bd760d21220d0b2648bf151065816a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Oct 2019 15:22:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Oct 2019 15:22:40 -0400    

It appears that libxml2 doesn't bother to set the "children" field of  
an XML_NAMESPACE_DECL node to null; that field just contains garbage.  
In v10 and v11, this can result in a crash in XMLTABLE().  The rewrite  
done in commit 251cf2e27 fixed this, somewhat accidentally, in v12.  
We're not going to back-patch 251cf2e27, however.  The case apparently  
doesn't have wide use, so rather than risk introducing other problems,  
just add a safety check to throw an error.  
  
Even though no bug manifests in v12/HEAD, add the relevant test case  
there too, to prevent future regressions.  
  
Chapman Flack (per private report)  

commit   : cbe63d02d0f7d85ecbae7d8998f5edfe56d50b9d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Oct 2019 20:23:44 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 25 Oct 2019 20:23:44 +0200    

commit   : ee201520707596b058e6bbfab0a5e2006f3834c5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Oct 2019 12:18:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Oct 2019 12:18:11 -0400    

This reverts commit c114229ca2519620703a4be4e38181290cad8c0a.  
Commit 1408d5d869925c8ea7ca01c2644e8903fbab23de should make it  
safe to include these headers in the natural order.  

commit   : 1408d5d869925c8ea7ca01c2644e8903fbab23de    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Oct 2019 12:17:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Oct 2019 12:17:41 -0400    

pgtypeslib_extern.h contained fallback definitions of "bool", "FALSE",  
and "TRUE".  The latter two are just plain unused, and have been for  
awhile.  The former came into play only if there wasn't a macro  
definition of "bool", which is true only if we aren't using <stdbool.h>.  
However, it then defined bool as "char"; since commit d26a810eb that  
conflicts with c.h's desire to use "unsigned char".  We'd missed seeing  
any bad effects of that due to accidental header inclusion order choices,  
but dddf4cdc3 exposed that it was problematic.  
  
To fix, let's just get rid of these definitions.  They should not be  
needed because everyplace in Postgres should be relying on c.h to  
provide a definition for type bool.  (Note that despite its name,  
pgtypeslib_extern.h isn't exposed to any outside code; we don't  
install it.)  
  
This doesn't fully resolve the issue, because ecpglib.h is doing  
similar things, but that seems to require more thought to fix.  
  
Back-patch to v12 where d26a810eb came in, to forestall any unpleasant  
surprises from future back-patched bug fixes.  
  
Discussion: https://postgr.es/m/CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com  

commit   : 22f6f2c1ccb56e0d6a159d4562418587e4b10e01    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Oct 2019 11:41:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Oct 2019 11:41:16 -0400    

Commit f8e5f156b added private state in postgres.c to track whether  
a statement timeout is running.  This seems like bad design to me;  
timeout.c's private state should be the single source of truth about  
that.  We already fixed one bug associated with failure to keep those  
states in sync (cf. be42015fc), and I've got little faith that we  
won't find more in future.  So get rid of postgres.c's local variable  
by exposing a way to ask timeout.c whether a timeout is running.  
(Obviously, such an inquiry is subject to race conditions, but it  
seems fine for the purpose at hand.)  
  
To make get_timeout_active() as cheap as possible, add a flag in  
the per-timeout struct showing whether that timeout is active.  
This allows some small savings elsewhere in timeout.c, mainly  
elimination of unnecessary searches of the active_timeouts array.  
  
While at it, fix enable_statement_timeout to not call disable_timeout  
when statement_timeout is 0 and the timeout is not running.  This  
avoids a useless deschedule-and-reschedule-timeouts cycle, which  
represents a significant savings (at least one kernel call) when  
there is any other active timeout.  Right now, there usually isn't,  
but there are proposals around to change that.  
  
Discussion: https://postgr.es/m/16035-456e6e69ebfd4374@postgresql.org  

commit   : 2b2bacdca0100f50ba4f79cda53514b6e5114e8f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Oct 2019 11:15:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 25 Oct 2019 11:15:50 -0400    

Historically, we started the timer (if StatementTimeout > 0) at the  
beginning of a simple-Query message and usually let it run until the  
end, so that the timeout limit applied to the entire query string,  
and intra-string changes of the statement_timeout GUC had no effect.  
But, confusingly, a COMMIT within the string would reset the state  
and allow a fresh timeout cycle to start with the current setting.  
  
Commit f8e5f156b changed the behavior of statement_timeout for extended  
query protocol, and as an apparently-unintended side effect, a change in  
the statement_timeout GUC during a multi-statement simple-Query message  
might have an effect immediately --- but only if it was going from  
"disabled" to "enabled".  
  
This is all pretty confusing, not to mention completely undocumented.  
Let's change things so that the timeout is always reset between queries  
of a multi-query string, whether they're transaction control commands  
or not.  Thus the active timeout setting is applied to each query in  
the string, separately.  This costs a few more cycles if statement_timeout  
is active, but it provides much more intuitive behavior, especially if one  
changes statement_timeout in one of the queries of the string.  
  
Also, add something to the documentation to explain all this.  
  
Per bug #16035 from Raj Mohite.  Although this is a bug fix, I'm hesitant  
to back-patch it; conceivably somebody has worked out the old behavior  
and is depending on it.  (But note that this change should make the  
behavior less restrictive in most cases, since the timeout will now  
be applied to shorter segments of code.)  
  
Discussion: https://postgr.es/m/16035-456e6e69ebfd4374@postgresql.org  

commit   : c114229ca2519620703a4be4e38181290cad8c0a    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Oct 2019 10:04:20 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 25 Oct 2019 10:04:20 +0530    

The commit dddf4cdc3 tries to ensure that the Postgres header file  
inclusions are in order based on their ASCII value.  However, in one of  
the case there is a header file dependency due to which we can't maintain  
such order.  
  
Author: Amit Kapila  
Discussion: https://postgr.es/m/E1iNpHW-000855-1u@gemulon.postgresql.org  

commit   : dddf4cdc3300073ec04b2c3e482a4c1fa4b8191b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 23 Oct 2019 09:38:53 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 23 Oct 2019 09:38:53 +0530    

Similar to commit 7e735035f2, this commit makes the order of header file  
inclusion consistent for non-backend modules.  
  
In passing, fix the case where we were using angle brackets (<>) for the  
local module includes instead of quotes ("").  
  
Author: Vignesh C  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CALDaNm2Sznv8RR6Ex-iJO6xAdsxgWhCoETkaYX=+9DW3q0QCfA@mail.gmail.com  

commit   : 8270a0d9a948944871dd35d9ff0d5c0d8d78623f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Oct 2019 10:20:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 25 Oct 2019 10:20:08 +0900    

Phases 2 (building the new index) and 3 (validating the new index)  
checked for interrupts outside a transaction context, having as  
consequence to not release session-level locks taken on the parent  
relation and the old and new indexes processed.  This could for example  
be triggered with statement_timeout and a bad timing, and would issue  
confusing error messages when shutting down the session still holding  
the locks (note that an assertion failure would be triggered first), on  
top of more issues with concurrent sessions trying to take a lock that  
would interfere with the SHARE UPDATE EXCLUSIVE locks hold here.  
  
This moves all the interruption checks inside a transaction context.  
Note that I have manually tested all interruptions to make sure that  
invalid indexes can be cleaned up properly.  Partition indexes still  
have issues on their own with some missing dependency handling, which  
will be dealt with in a follow-up patch.  
  
Reported-by: Justin Pryzby  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20191013025145.GC4475@telsasoft.com  
Backpatch-through: 12  

commit   : 3b0c59ac1c7d480821ed009b998dd6be7d2d851c    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 24 Oct 2019 14:13:36 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 24 Oct 2019 14:13:36 +0900    

Author: Fujii Masao  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CAHGQGwH7dtYvOZZ8c0AG5AJwH5pfiRdKaCptY1_RdHy0HYeRfQ@mail.gmail.com  

commit   : 7e735035f208418f31b91846ae3e8a381edb3af3    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 23 Oct 2019 09:26:22 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 23 Oct 2019 09:26:22 +0530    

The basic rule we follow here is to always first include 'postgres.h' or  
'postgres_fe.h' whichever is applicable, then system header includes and  
then Postgres header includes.  In this, we also follow that all the  
Postgres header includes are in order based on their ASCII value.  We  
generally follow these rules, but the code has deviated in many places.  
This commit makes it consistent just for contrib modules.  The later  
commits will enforce similar rules in other parts of code.  
  
Author: Vignesh C  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CALDaNm2Sznv8RR6Ex-iJO6xAdsxgWhCoETkaYX=+9DW3q0QCfA@mail.gmail.com  

commit   : 59c2617af35f064e5d3ef39cfe94531f7459f3de    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 23 Oct 2019 20:29:02 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 23 Oct 2019 20:29:02 -0400    

Reported-by: Asim / apraveen@pivotal.io  
  
Discussion: https://postgr.es/m/157076828181.26165.15231292023740913543@wrigleys.postgresql.org  
  
Backpatch-through: 9.4  

commit   : 0c089d36e2bb07a8ccd575d456265e83b6697d00    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 23 Oct 2019 18:06:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 23 Oct 2019 18:06:38 -0400    

Commit a524f50d0f added  
old_11_check_for_sql_identifier_data_type_usage(), but it did not use  
the clearer database error list format added to the master branch in  
commit 1634d36157.  This commit fixes that.  
  
Backpatch-through: master  

commit   : 5d3500da72611018f2280d6a31e58ccdb4b16152    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Oct 2019 15:04:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Oct 2019 15:04:48 +0900    

In the first transaction run for REINDEX CONCURRENTLY, a thinko in the  
existing logic caused two session locks to be taken on the old index,  
causing the session lock on the newly-created index to be missed.  This  
made possible concurrent DDL commands (like ALTER INDEX) on the new  
index while REINDEX CONCURRENTLY was processing from the point where the  
first internal transaction committed.  
  
This issue has been discovered while digging into another bug.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20191021074323.GB1869@paquier.xyz  
Backpatch-through: 12  

commit   : 508e84d79910cdb3b61fc410a245fd46e4fad30f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 23 Oct 2019 07:10:09 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 23 Oct 2019 07:10:09 +0200    

The use of this was removed by  
6da56f3f84d430671d5edd8f9336bd744c089e31.  
  
Discussion: https://www.postgresql.org/message-id/87d95052-3780-b833-9953-27eab80186cf%402ndquadrant.com  

commit   : 4fa5edcd1a45cb11bc52b612e12bb29ab39cb895    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Oct 2019 12:27:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Oct 2019 12:27:03 +0900    

8ae0d47 marked those options as obsolete back in 2005, with the options  
removed from the documentation.  This removes the last references to  
both options in the code which were kept around for compatibility  
purposes with past commands.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/5da284a2-62d9-e338-88d1-26ee5009d93e@gmail.com  

commit   : 57379cd5ac56e575630a5fee5777a1035d0a764a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Oct 2019 11:34:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Oct 2019 11:34:18 +0900    

A check was redundant.  While on it, add an assertion to make sure that  
the parsing routine is never called with a NULL input.  All the code  
paths currently calling the parsing routine are careful with NULL inputs  
already, but future callers may forget that.  
  
Reported-by: Peter Eisentraut, Lars Kanis  
Discussion: https://postgr.es/m/ec64956b-4597-56b6-c3db-457d15250fe4@2ndquadrant.com  
Backpatch-through: 12  

commit   : e3db3f829f605edc0675e5d308de97f444b53d4b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Oct 2019 10:25:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 23 Oct 2019 10:25:06 +0900    

Any callback set would have no meaning in the context of an exception.  
As an autovacuum worker exits quickly in this context, this could be  
only an issue within EmitErrorReport(), where the elog hook is for  
example called.  That's unlikely to going to be a problem, but let's be  
clean and consistent with other code paths handling exceptions.  This is  
present since 2909419, which introduced autovacuum.  
  
Author: Ashwin Agrawal  
Reviewed-by: Tom Lane, Michael Paquier  
Discussion: https://postgr.es/m/CALfoeisM+_+dgmAdAOHAu0k-ZpEHHqSSG=GRf3pKJGm8OqWX0w@mail.gmail.com  
Backpatch-through: 9.4  

commit   : ad4b7aeb84434c958e2df76fa69b68493a889e4a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 22 Oct 2019 10:35:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 22 Oct 2019 10:35:54 +0200    

Through several updates, the CREATE USER command has been separated  
from where the user is actually used in the test.  

commit   : f86f46d091a6876fbf28e0a4a87ca72b560cf77f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 22 Oct 2019 09:58:20 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 22 Oct 2019 09:58:20 +0200    

The last argument of smgrextend() was renamed from isTemp to skipFsync  
in debcec7dc31a992703911a9953e299c8d730c778, but the comments at two  
call sites were not updated.  

commit   : 52ad1e659967896ed153185328ffe806d69abcb6    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 21 Oct 2019 23:04:14 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 21 Oct 2019 23:04:14 +0300    

This commit refactors come ridiculous coding in compareDatetime().  Also, it  
provides correct cross-datatype comparison even when one of values overflows  
during cast.  That eliminates dilemma on whether we should suppress overflow  
errors during cast.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/32308.1569455803%40sss.pgh.pa.us  
Discussion: https://postgr.es/m/a5629d0c-8162-7559-16aa-0c8390d6ba5f%40postgrespro.ru  
Author: Nikita Glukhov, Alexander Korotkov  

commit   : a6888fde7f0dbe865559b31ba2ce01ac1150debe    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 21 Oct 2019 23:03:55 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 21 Oct 2019 23:03:55 +0300    

While casting from timestamp to timestamptz we do timestamp2tm() then  
tm2timestamp().  This commit eliminates call to tm2timestamp().  Instead, it  
directly applies timezone offset to the original timestamp value.  That makes  
upcoming datetime overflow handling in jsonpath easier.  That should also save  
us some CPU cycles.  
  
Discussion: https://postgr.es/m/CAPpHfdvRPRh_mTGar5WmDeRZ%3DU5dOXHdxspYYD%3D76m3knNGjXA%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Tom Lane  

commit   : db477b691dc4e80bc8379d976ef53a0aa0afe4c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Oct 2019 14:18:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Oct 2019 14:18:01 -0400    

It emerges that recent versions of Windows (at least 2016 Standard)  
spell this locale name as "Norwegian Bokmål_Norway.1252", defeating  
our mapping code that translates "Norwegian (Bokmål)_Norway" to  
something that's all-ASCII (cf commits db29620d4 and aa1d2fc5e).  
Add another mapping entry to handle this spelling.  
  
Per bug #16068 from Robert Ford.  Like the previous patches,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16068-4cb6eeaa7eb46d93@postgresql.org  

commit   : d995fd667f6d22307864afe18ae91950b23b5b53    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Oct 2019 13:52:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Oct 2019 13:52:25 -0400    

On recent Red Hat platforms (at least RHEL 8 and Fedora 30, maybe older),  
configure's probe for libperl failed if the user forces CFLAGS to be -O0.  
This is because some code in perl's inline.h fails to be optimized away  
at -O0, and said code doesn't work if compiled without -fPIC.  
  
To fix, add CFLAGS_SL to the compile flags used during the libperl probe.  
This is a better simulation of the way that plperl is built, anyway,  
so it might forestall other issues in future.  
  
Per gripe from Kyotaro Horiguchi.  Back-patch to all supported branches,  
since people might want to build older branches on these platforms.  
  
Discussion: https://postgr.es/m/20191010.144533.263180400.horikyota.ntt@gmail.com  

commit   : 44273ce4f664a1bb34ef8ea9359237344cd6aaec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Oct 2019 12:32:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 21 Oct 2019 12:32:35 -0400    

Move the platform-dependent logic that sets CFLAGS_SL from  
src/makefiles/Makefile.foo to src/template/foo, so that the value  
is determined at configure time and thus is available while running  
configure's tests.  
  
On a couple of platforms this might save a few microseconds of build  
time by eliminating a test that make otherwise has to do over and over.  
Otherwise it's pretty much a wash for build purposes; in particular,  
this makes no difference to anyone who might be overriding CFLAGS_SL  
via a make option.  
  
This patch in itself does nothing with the value and thus should not  
change any behavior, though you'll probably have to re-run configure  
to get a correctly updated Makefile.global.  We'll use the new  
configure variable in a follow-on patch.  
  
Per gripe from Kyotaro Horiguchi.  Back-patch to all supported branches,  
because the follow-on patch is a portability bug fix.  
  
Discussion: https://postgr.es/m/20191010.144533.263180400.horikyota.ntt@gmail.com  

commit   : 80831bcdbe80a6ca7f22105e32c2cbb54e125c4c    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 21 Oct 2019 17:30:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Mon, 21 Oct 2019 17:30:00 +0900    

Commit b52b7dc25, which moved code creating PartitionBoundInfo in  
RelationBuildPartitionDesc() in partcache.c (relocated to partdesc.c  
afterwards) to partbounds.c, should have updated this, but didn't.  
  
Author: Etsuro Fujita  
Reviewed-by: Alvaro Herrera  
Backpatch-through: 12  
Discussion: https://postgr.es/m/CAPmGK16Uxr%3DPatiGyaRwiQVLB7Y-GqbkK3AxRLVYzU0Czv%3DsEw%40mail.gmail.com  

commit   : 70a6c37d524cc2c29712424785be3d9e2e62f484    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 17 Oct 2019 08:45:43 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 17 Oct 2019 08:45:43 +0530    

We memorize all internal and empty leaf pages in the 1st vacuum stage for  
gist indexes.  They are used in the 2nd stage, to delete all the empty  
pages.  There was a memory context page_set_context for this purpose, but  
we never used it.  
  
Reported-by: Amit Kapila  
Author: Dilip Kumar  
Reviewed-by: Amit Kapila  
Backpatch-through: 12, where it got introduced  
Discussion: https://postgr.es/m/CAA4eK1LGr+MN0xHZpJ2dfS8QNQ1a_aROKowZB+MPNep8FVtwAA@mail.gmail.com  

commit   : ba19a6b73c5bd771d8864171ede03503a9ff564e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 21 Oct 2019 11:39:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 21 Oct 2019 11:39:15 +0900    

The logic was correctly detecting a parsing failure, but the parsing  
error did not get reported back to the client properly.  
  
Reported-by: Ed Morley  
Author: Lars Kanis  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/a9b4cbd7-4ecb-06b2-ebd7-1739bbff3217@greiz-reinsdorf.de  
Backpatch-through: 12  

commit   : 4f4061b2dde178d2ab79d1ee3b1ae3c62c117926    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 21 Oct 2019 11:17:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 21 Oct 2019 11:17:13 +0900    

Commit e7a2217 has introduced stricter checks for integer values in  
connection parameters for libpq.  However this failed to correctly check  
after trailing whitespaces, while leading whitespaces were discarded per  
the use of strtol(3).  This fixes and refactors the parsing logic to  
handle both cases consistently.  Note that trying to restrict the use of  
trailing whitespaces can easily break connection strings like in ECPG  
regression tests (these have allowed me to catch the parsing bug with  
connect_timeout).  
  
Author: Michael Paquier  
Reviewed-by: Lars Kanis  
Discussion: https://postgr.es/m/a9b4cbd7-4ecb-06b2-ebd7-1739bbff3217@greiz-reinsdorf.de  
Backpatch-through: 12  

commit   : ea9e06ac66d3e9584950f52878c8e4b71f963610    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 20 Oct 2019 10:19:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 20 Oct 2019 10:19:13 +0200    

There were some leftovers from ancient ad-hoc ways to build on  
Windows, prior to the standardization on MSVC and MinGW.  We don't  
need to build a lib$(NAME)ddll.def (debug build, as opposed to  
lib$(NAME)dll.def) for MinGW, since nothing uses that.  We also don't  
need to build the regular .def file during distprep, since the MinGW  
build environment is perfectly capable of creating that normally at  
build time.  
  
Discussion: https://www.postgresql.org/message-id/flat/0f9db9f8-47b8-a48b-6ccc-15b22b412316%402ndquadrant.com  

commit   : 5d3587d14b753cb25b0ebcd549d95e1b6ceebce4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 19 Oct 2019 18:21:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 19 Oct 2019 18:21:58 +0200    

In some cases #if was used instead of #ifdef in an inconsistent style.  
Cleaning this up also helps when analyzing cases like  
38d8dce61fff09daae0edb6bcdd42b0c7f10ebcd where this makes a  
difference.  
  
There are no behavior changes here, but the change in pg_bswap.h would  
prevent possible accidental misuse by third-party code.  
  
Discussion: https://www.postgresql.org/message-id/flat/3b615ca5-c595-3f1d-fdf7-a429e564f614%402ndquadrant.com  

commit   : 48cc59ed24f95fa171b12ba1b461e6dc72d62b2b    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 18 Oct 2019 20:21:10 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 18 Oct 2019 20:21:10 -0700    

Besides style, this might improve performance in the contended case.  
  
Reviewed by Amit Kapila.  
  
Discussion: https://postgr.es/m/20191015035348.GA4166224@rfd.leadboat.com  

commit   : 30ee5d17c20dbb282a9952b3048d6ad52d56c371    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 18 Oct 2019 20:20:52 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 18 Oct 2019 20:20:52 -0700    

This is more like how we handle s_lock.h and arch-x86.h.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/20191005173400.GA3979129@rfd.leadboat.com  

commit   : 89b4d7744c80ecb3f6bdf8a07ca711a043718db3    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 18 Oct 2019 20:20:28 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 18 Oct 2019 20:20:28 -0700    

Without "b", a variant of the tas() code miscompiles on macOS 10.4.  
This may also fix a compilation failure involving macOS 10.1.  Today's  
compilers have been allocating acceptable registers with or without this  
change, but this future-proofs the code by precisely conveying the  
acceptable registers.  Back-patch to 9.4 (all supported versions).  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/20191009063900.GA4066266@rfd.leadboat.com  

commit   : f25968c49697db673f6cd2a07b3f7626779f1827    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 19 Oct 2019 11:18:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 19 Oct 2019 11:18:15 +0900    

Since pluggable storage has been introduced, those two routines have  
been replaced by table_open/close, with some compatibility macros still  
present to allow extensions to compile correctly with v12.  
  
Some code paths using the old routines still remained, so replace them.  
Based on the discussion done, the consensus reached is that it is better  
to remove those compatibility macros so as nothing new uses the old  
routines, so remove also the compatibility macros.  
  
Discussion: https://postgr.es/m/20191017014706.GF5605@paquier.xyz  

commit   : ec1259e880dd0738a0b111e47d1b7153d3da20fd    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 18 Oct 2019 22:32:18 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 18 Oct 2019 22:32:18 +0900    

recovery_min_apply_delay parameter is intended for use with streaming  
replication deployments. However, the document clearly explains that  
the parameter will be honored in all cases if it's specified. So it should  
take effect even if in archive recovery. But, previously, archive recovery  
with recovery_min_apply_delay enabled always failed, and caused assertion  
failure if --enable-caasert is enabled.  
  
The cause of this problem is that; the ownership of recoveryWakeupLatch  
that recovery_min_apply_delay uses was taken only when standby mode  
is requested. So unowned latch could be used in archive recovery, and  
which caused the failure.  
  
This commit changes recovery code so that the ownership of  
recoveryWakeupLatch is taken even in archive recovery. Which prevents  
archive recovery with recovery_min_apply_delay from failing.  
  
Back-patch to v9.4 where recovery_min_apply_delay was added.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CAHGQGwEyD6HdZLfdWc+95g=VQFPR4zQL4n+yHxQgGEGjaSVheQ@mail.gmail.com  

commit   : 9b95a36be8be6c3a78b303bbe709c622dc312e87    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 18 Oct 2019 22:24:18 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 18 Oct 2019 22:24:18 +0900    

In v11 or before, this setting could not take effect in crash recovery  
because it's specified in recovery.conf and crash recovery always  
starts without recovery.conf. But commit 2dedf4d9a8 integrated  
recovery.conf into postgresql.conf and which unexpectedly allowed  
this setting to take effect even in crash recovery. This is definitely  
not good behavior.  
  
To fix the issue, this commit makes crash recovery always ignore  
recovery_min_apply_delay setting.  
  
Back-patch to v12 where the issue was added.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CAHGQGwEyD6HdZLfdWc+95g=VQFPR4zQL4n+yHxQgGEGjaSVheQ@mail.gmail.com  
Discussion: https://postgr.es/m/e445616d-023e-a268-8aa1-67b8b335340c@pgmasters.net  

commit   : 89403ed228583c80c608310e68020229818836e6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 18 Oct 2019 14:49:39 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 18 Oct 2019 14:49:39 +0200    

Apparently while this code was being developed,  
ReindexRelationConcurrently operated on multiple relations.  The version  
that was ultimately pushed doesn't, so this comment's use of plural is  
inaccurate.  

commit   : d2efb90dbad97828838ab356c03927b3dda65070    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 18 Oct 2019 07:18:50 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 18 Oct 2019 07:18:50 -0300    

Michaël Paquier complained that index_drop is requesting progress  
reporting for non-obvious reasons, so let's add a comment to explain  
why.  
  
Discussion: https://postgr.es/m/20191017010412.GH2602@paquier.xyz  

commit   : 3f60f690fac1bf375b92cf2f8682e8fe8f690981    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 18 Oct 2019 14:26:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 18 Oct 2019 14:26:29 +0900    

The timestamp tracking the last moment a message is received in a  
logical replication worker was initialized in each loop checking if a  
message was received or not, causing wal_receiver_timeout to be ignored  
in basically any logical replication deployments.  This also broke the  
ping sent to the server when reaching half of wal_receiver_timeout.  
  
This simply moves the initialization of the timestamp out of the apply  
loop to the beginning of LogicalRepApplyLoop().  
  
Reported-by: Jehan-Guillaume De Rorthais  
Author: Julien Rouhaud  
Discussion: https://postgr.es/m/CAOBaU_ZHESFcWva8jLjtZdCLspMj7vqaB2k++rjHLY897ZxbYw@mail.gmail.com  
Backpatch-through: 10  

commit   : 38ddeab13b4b86161799c097dea4bdf9be60924a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 17 Oct 2019 15:06:06 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 17 Oct 2019 15:06:06 +0200    

Logical walsender should exit when it catches up with sending WAL during  
shutdown; but there was a rare corner case when it failed to because of  
a race condition that puts it back to wait for more WAL instead -- but  
since there wasn't any, it'd not shut down immediately.  It would only  
continue the shutdown when wal_sender_timeout terminates the sleep,  
which causes annoying waits during shutdown procedure.  Restructure the  
code so that we no longer forget to set WalSndCaughtUp in that case.  
  
This was an oversight in commit c6c333436.  
  
Backpatch all the way down to 9.4.  
  
Author: Craig Ringer, Álvaro Herrera  
Discussion: https://postgr.es/m/CAMsr+YEuz4XwZX_QmnX_-2530XhyAmnK=zCmicEnq1vLr0aZ-g@mail.gmail.com  

commit   : 1752e351639dcc68ea289cf91428246ed316d9b2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 17 Oct 2019 09:58:01 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 17 Oct 2019 09:58:01 +0200    

When an FK constraint is created, it needs the index on the referenced  
table to exist and be valid.  When doing parallel pg_restore and the  
referenced table was partitioned, this condition can sometimes not be  
met, because pg_dump didn't emit sufficient object dependencies to  
ensure so; this means that parallel pg_restore would fail in certain  
conditions.  Fix by having pg_dump make the FK constraint object  
dependent on the partition attachment objects for the constraint's  
referenced index.  
  
This has been broken since f56f8f8da6af, so backpatch to Postgres 12.  
  
Discussion: https://postgr.es/m/20191005224333.GA9738@alvherre.pgsql  

commit   : 3c8c55dd5445370c5cad3ae04de02caba7be7073    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 17 Oct 2019 13:24:50 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 17 Oct 2019 13:24:50 +1300    

Otherwise it can be hard to see where an error is coming from, when  
the parallel worker sets all the GUCs that it received from the  
leader.  Bug #15726.  Back-patch to 9.5, where RestoreGUCState()  
appeared.  
  
Reported-by: Tiago Anastacio  
Reviewed-by: Daniel Gustafsson, Tom Lane  
Discussion: https://postgr.es/m/15726-6d67e4fa14f027b3%40postgresql.org  

commit   : 6bda2af039d45d9a136ddc04e2242163177ab5ad    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 17 Oct 2019 09:59:21 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 17 Oct 2019 09:59:21 +1300    

Commits 801c2dc7 and 801c2dc7 made it possible for vacuum to  
try to freeze a multixact that is still running.  That was  
prevented by a check, but raised an error.  Repair.  
  
Back-patch all the way.  
  
Author: Nathan Bossart, Jeremy Schneider  
Reported-by: Jeremy Schneider  
Reviewed-by: Jim Nasby, Thomas Munro  
Discussion: https://postgr.es/m/DAFB8AFF-2F05-4E33-AD7F-FF8B0F760C17%40amazon.com  

commit   : 0d21f919eb86cd3baa267844d111c6a5af480696    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 16 Oct 2019 14:51:34 +0200    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 16 Oct 2019 14:51:34 +0200    

A race condition can make us try to dereference a NULL pointer to the  
PGPROC struct of a process that's already finished.  That results in  
crashes during REINDEX CONCURRENTLY and CREATE INDEX CONCURRENTLY.  
  
This was introduced in ab0dfc961b6a, so backpatch to pg12.  
  
Reported by: Justin Pryzby  
Reviewed-by: Michaël Paquier  
Discussion: https://postgr.es/m/20191012004446.GT10470@telsasoft.com  

commit   : a524f50d0fc6fe6f2146ce708c2c9576d3734da4    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 16 Oct 2019 13:23:18 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 16 Oct 2019 13:23:18 +0200    

The pg_upgrade check for pg_catalog.unknown type when upgrading from 9.6  
had a couple of issues with domains and composite types - it detected  
even composite types unused in objects with storage. So for example this  
was enough to trigger an unnecessary pg_upgrade failure:  
  
  CREATE TYPE unknown_composite AS (u pg_catalog.unknown)  
  
On the other hand, this only happened with composite types directly on  
the pg_catalog.unknown data type, but not with a domain. So this was not  
detected  
  
  CREATE DOMAIN unknown_domain AS pg_catalog.unknown;  
  CREATE TYPE unknown_composite_2 AS (u unknown_domain);  
  
unlike the first example. These false positives and inconsistencies are  
unfortunate, but what's worse we've failed to detected objects using the  
pg_catalog.unknown type through a domain. So we missed cases like this  
  
  CREATE TABLE t (u unknown_composite_2);  
  
The consequence is clusters broken after a pg_upgrade.  
  
This fixes these false positives and false negatives by using the same  
recursive CTE introduced by eaf900e842 for sql_identifier. Backpatch all  
the way to 10, where the of pg_catalog.unknown data type was restricted.  
  
Author: Tomas Vondra  
Backpatch-to: 10-  
Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org  

commit   : 8d48e6a7240cb0542577860e1bac768cd86fc633    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 16 Oct 2019 13:23:14 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 16 Oct 2019 13:23:14 +0200    

The pg_upgrade check for pg_catalog.line data type when upgrading from  
9.3 had a couple of issues with domains and composite types. Firstly, it  
triggered false positives for composite types unused in objects with  
storage. This was enough to trigger an unnecessary pg_upgrade failure:  
  
  CREATE TYPE line_composite AS (l pg_catalog.line)  
  
On the other hand, this only happened with composite types directly on  
the pg_catalog.line data type, but not with a domain. So this was not  
detected  
  
  CREATE DOMAIN line_domain AS pg_catalog.line;  
  CREATE TYPE line_composite_2 AS (l line_domain);  
  
unlike the first example. These false positives and inconsistencies are  
unfortunate, but what's worse we've failed to detected objects using the  
pg_catalog.line data type through a domain. So we missed cases like this  
  
  CREATE TABLE t (l line_composite_2);  
  
The consequence is clusters broken after a pg_upgrade.  
  
This fixes these false positives and false negatives by using the same  
recursive CTE introduced by eaf900e842 for sql_identifier. 9.3 did not  
support domains on composite types, but we can still have multi-level  
composite types.  
  
Backpatch all the way to 9.4, where the format for pg_catalog.line data  
type changed.  
  
Author: Tomas Vondra  
Backpatch-to: 9.4-  
Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org  

commit   : ae5cae54ca6b1949829026b9fbb744c7f5a28bd5    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 16 Oct 2019 02:37:34 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 16 Oct 2019 02:37:34 -0700    

The test in 93765bd956b added an event trigger to ensure that the  
tested table rewrites do not get optimized away (as happened in the  
past). But doing so would require running the tests in isolation, as  
otherwise the trigger might also fire in concurrent sessions, causing  
test failures there.  
  
Reported-By: Tom Lane  
Discussion: https://postgr.es/m/3328.1570740683@sss.pgh.pa.us  
Backpatch: 12, just as 93765bd956b  

commit   : 1de4fd10922b96b6d90838181c59c1a45f8a95f6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 16 Oct 2019 15:10:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 16 Oct 2019 15:10:14 +0900    

Author: Vignesh C  
Discussion: https://postgr.es/m/CALDaNm0LPk9vTGTBPBRv0=fX=94o4r6-DuBbHNeCN2AH5bufLw@mail.gmail.com  

commit   : cce95a2f029e546dc461d7ec1760e2c3a247b0e7    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 16 Oct 2019 17:55:51 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 16 Oct 2019 17:55:51 +1300    

The previous commit forgot to remove this test, which no longer  
holds on all systems.  

commit   : d5ac14f9ccdda036358c9059d4a29836ebc0c440    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 16 Oct 2019 16:51:40 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 16 Oct 2019 16:51:40 +1300    

Using glibc's version string to detect potential collation definition  
changes is not 100% reliable, but it's better than nothing.  Currently  
this affects only collations explicitly provided by "libc".  More work  
will be needed to handle the default collation.  
  
Author: Thomas Munro, based on a suggestion from Christoph Berg  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/4b76c6d4-ae5e-0dc6-7d0d-b5c796a07e34%402ndquadrant.com  

commit   : 4351142e5843dc9fcb080a51aa082d63be59a5ab    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 16 Oct 2019 13:09:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 16 Oct 2019 13:09:52 +0900    

This fixes multiple areas of the documentation:  
- COPY for its past compatibility section.  
- SET ROLE mentioning INHERITS instead of INHERIT  
- PREPARE referring to stmt_name, that is not present.  
- Extension documentation about format name with upgrade scripts.  
  
Backpatch down to 9.4 for the relevant parts.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/bf95233a-9943-b341-e2ff-a860c28af481@gmail.com  
Backpatch-through: 9.4  

commit   : cef82eda1464193ab84a58610a388572d456c8c5    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 15 Oct 2019 10:40:13 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 15 Oct 2019 10:40:13 -0700    

Since the introduction of different slot types, in 1a0586de3657, we  
create a virtual slot in tuplesort_begin_cluster(). While that looks  
right, it unfortunately doesn't actually work, as ExecStoreHeapTuple()  
is used to store tuples in the slot. Unfortunately no regression tests  
for CLUSTER on expression indexes existed so far.  
  
Fix the slot type, and add bare bones tests for CLUSTER on expression  
indexes.  
  
Reported-By: Justin Pryzby  
Author: Andres Freund  
Discussion: https://postgr.es/m/20191011210320.GS10470@telsasoft.com  
Backpatch: 12, like 1a0586de3657  

commit   : 3a0e85739490e5cd50e5eba382ae3c9cc3bc2fca    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 15 Oct 2019 00:25:04 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 15 Oct 2019 00:25:04 +0200    

The recursive CTE added in 0ccfc28223 referenced pg_catalog.regtype,  
without the schema part, unlike all other queries in pg_upgrade.  
  
Backpatch-to: 12  

commit   : 0ccfc2822366f92c61cba96541d1c64d2b8b2086    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 14 Oct 2019 22:31:56 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 14 Oct 2019 22:31:56 +0200    

Commit 7c15cef86d changed sql_identifier data type to be based on name  
instead of varchar.  Unfortunately, this breaks on-disk format for this  
data type.  Luckily, that should be a very rare problem, as this data  
type is used only in information_schema views, so this only affects user  
objects (tables, materialized views and indexes).  One way to end in  
such situation is to do CTAS with a query on those system views.  
  
There are two options to deal with this - we can either abort pg_upgrade  
if there are user objects with sql_identifier columns in pg_upgrade, or  
we could replace the sql_identifier type with varchar.  Considering how  
rare the issue is expected to be, and the complexity of replacing the  
data type (e.g. in matviews), we've decided to go with the simple check.  
  
The query is somewhat complex - the sql_identifier data type may be used  
indirectly - through a domain, a composite type or both, possibly in  
multiple levels.  Detecting this requires a recursive CTE.  
  
Backpatch to 12, where the sql_identifier definition changed.  
  
Reported-by: Hans Buschmann  
Author: Tomas Vondra  
Reviewed-by: Tom Lane  
Backpatch-to: 12  
Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org  

commit   : 14ac4237cba02f2766a7e6379468e71050de6fd2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 14 Oct 2019 08:58:38 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 14 Oct 2019 08:58:38 +0900    

1df5875 has changed the way dependencies are dropped for this command  
with inheritance trees, which impacts sepgsql.  This just updates the  
regression test output to take care of the failures and adapt to the new  
code.  
  
Reported by buildfarm member rhinoceros.  
  
Author: Michael Paquier  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/20191013101331.GC1434@paquier.xyz  
Backpatch-through: 12  

commit   : bdb839cbdebe851c200b2c7c03aec7483573d631    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 13 Oct 2019 22:10:38 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 13 Oct 2019 22:10:38 +0200    

Use https, consistent host name, remove references to ftp.  Also  
update the URLs for CLDR, which has moved from Trac to GitHub.  

commit   : 9abb2bfc046070b22e3be28173a0736da31cab5a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Oct 2019 15:48:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Oct 2019 15:48:26 -0400    

POSIX sigaction(2) can be told to block a set of signals while a  
signal handler executes.  Make use of that instead of manually  
blocking and unblocking signals in the postmaster's signal handlers.  
This should save a few cycles, and it also prevents recursive  
invocation of signal handlers when many signals arrive in close  
succession.  We have seen buildfarm failures that seem to be due to  
postmaster stack overflow caused by such recursion (exacerbated by  
a Linux PPC64 kernel bug).  
  
This doesn't change anything about the way that it works on Windows.  
Somebody might consider adjusting port/win32/signal.c to let it work  
similarly, but I'm not in a position to do that.  
  
For the moment, just apply to HEAD.  Possibly we should consider  
back-patching this, but it'd be good to let it age awhile first.  
  
Discussion: https://postgr.es/m/14878.1570820201@sss.pgh.pa.us  

commit   : f38291e927fa8c04eb772e6a17a3dd44da2b69e8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Oct 2019 12:56:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 13 Oct 2019 12:56:16 -0400    

This reverts commit 6a5084eed49552bfc8859c438c8d74ad09fc5d3f.  
We learned what we needed to know from that.  

commit   : 1df5875d39383b3981b804666ee1f4b0ff65943f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 13 Oct 2019 17:51:55 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 13 Oct 2019 17:51:55 +0900    

When dropping a column on a partitioned table which has one or more  
partitioned indexes, the operation was failing as dependencies with  
partitioned indexes using the column dropped were not getting removed in  
a way consistent with the columns involved across all the relations part  
of an inheritance tree.  
  
This commit refactors the code executing column drop so as all the  
columns from an inheritance tree to remove are gathered first, and  
dropped all at the end.  This way, we let the dependency machinery sort  
out by itself the deletion of all the columns with the partitioned  
indexes across a partition tree.  
  
This issue has been introduced by 1d92a0c, so backpatch down to  
REL_12_STABLE.  
  
Author: Amit Langote, Michael Paquier  
Reviewed-by: Álvaro Herrera, Ashutosh Sharma  
Discussion: https://postgr.es/m/CA+HiwqE9kuBsZ3b5pob2-cvE8ofzPWs-og+g8bKKGnu6b4-yTQ@mail.gmail.com  
Backpatch-through: 12  

commit   : b4675a8ae2d0aaafeb136c46c92bb56eaf018d32    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 12 Oct 2019 21:17:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 12 Oct 2019 21:17:34 +0200    

Within the context of SCRAM, "verifier" has a specific meaning in the  
protocol, per RFCs.  The existing code used "verifier" differently, to  
mean whatever is or would be stored in pg_auth.rolpassword.  
  
Fix this by using the term "secret" for this, following RFC 5803.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/be397b06-6e4b-ba71-c7fb-54cae84a7e18%402ndquadrant.com  

commit   : 5f3d271d03b249f5c80e3d3ca946f62a33d7862f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 12 Oct 2019 00:21:47 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 12 Oct 2019 00:21:47 -0700    

With xlc v16.1.0, it causes internal compiler errors.  With xlc versions  
not exhibiting that bug, removing -qsrcmsg merely changes the compiler  
error reporting format.  Back-patch to 9.4 (all supported versions).  
  
Discussion: https://postgr.es/m/20191003064105.GA3955242@rfd.leadboat.com  

commit   : 20961ceaf0426c6fba40bb422cf111f704a00058    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 11 Oct 2019 15:47:59 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 11 Oct 2019 15:47:59 +0900    

In v11 or before, those settings could not take effect in crash recovery  
because they are specified in recovery.conf and crash recovery always  
starts without recovery.conf. But commit 2dedf4d9a8 integrated  
recovery.conf into postgresql.conf and which unexpectedly allowed  
those settings to take effect even in crash recovery. This is definitely  
not good behavior.  
  
To fix the issue, this commit makes crash recovery always ignore  
restore_command and recovery_end_command settings.  
  
Back-patch to v12 where the issue was added.  
  
Author: Fujii Masao  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/e445616d-023e-a268-8aa1-67b8b335340c@pgmasters.net  

commit   : 06a367c382d0a3595238eff2e777222dbc91911b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Oct 2019 14:24:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 10 Oct 2019 14:24:56 -0400    

This reverts commit f7ab80285.  Per discussion, we can't remove an  
exported symbol without a SONAME bump, which we don't want to do.  
In particular that breaks usage of current libpq.so with pre-9.3  
versions of psql etc, which need libpq to export pqsignal().  
  
As noted in that commit message, exporting the symbol from libpgport.a  
won't work reliably; but actually we don't want to export src/port's  
implementation anyway.  Any pre-9.3 client is going to be expecting the  
definition that pqsignal() had before 9.3, which was that it didn't  
set SA_RESTART for SIGALRM.  Hence, put back pqsignal() in a separate  
source file in src/interfaces/libpq, and give it the old semantics.  
  
Back-patch to v12.  
  
Discussion: https://postgr.es/m/E1g5vmT-0003K1-6S@gemulon.postgresql.org  

commit   : 3b5d3721c25ed1270832265c5475649c3baa0e26    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 10 Oct 2019 10:51:11 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 10 Oct 2019 10:51:11 +0200    

No need to call exit() after pg_fatal().  Clean up a few stragglers  
for consistency.  

commit   : 93765bd956bea26206043de8cbb0ae4b67e4df15    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 9 Oct 2019 22:00:50 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 9 Oct 2019 22:00:50 -0700    

In c2fe139c201c I made ATRewriteTable() use tuple slots. Unfortunately  
I did not notice that columns can be added in a rewrite that do not  
have a default, when another column is added/altered requiring one.  
  
Initialize columns to NULL again, and add tests.  
  
Bug: #16038  
Reported-By: anonymous  
Author: Andres Freund  
Discussion: https://postgr.es/m/16038-5c974541f2bf6749@postgresql.org  
Backpatch: 12, where the bug was introduced in c2fe139c201c  

commit   : 50518ec296aea3af3e00c43c2ccef74c96cb5762    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 9 Oct 2019 21:36:01 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 9 Oct 2019 21:36:01 +0200    

This reverts commit 9f90b1d08d796a925808b24f77f624a0ff682c77.  
  
This needs some refinements in the pg_dump and pg_upgrade tests.  

commit   : 9f90b1d08d796a925808b24f77f624a0ff682c77    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 9 Oct 2019 21:17:47 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 9 Oct 2019 21:17:47 +0200    

Using glibc's version number to detect potential collation definition  
changes is not 100% reliable, but it's better than nothing.  
  
Author: Thomas Munro  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/4b76c6d4-ae5e-0dc6-7d0d-b5c796a07e34%402ndquadrant.com  

commit   : b8e19b932a99a7eb5a3bce84e74b0b7c093d0981    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Oct 2019 13:30:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Oct 2019 13:30:43 +0900    

The file descriptor was opened with read-only to fsync a regular file,  
which would cause EBADFD errors on some platforms.  
  
This is similar to the recent fix done by a586cc4b (which was broken by  
me with 82a5649), except that I noticed this issue while monitoring the  
backend code for similar mistakes.  Backpatch to 9.4, as this has been  
introduced since logical decoding exists as of b89e151.  
  
Author: Michael Paquier  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/20191006045548.GA14532@paquier.xyz  
Backpatch-through: 9.4  

commit   : 1634d361577aab30c7d90336c96b969a2f5e5811    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 8 Oct 2019 22:16:48 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 8 Oct 2019 22:16:48 -0400    

Previously, the "Database:" label in the error file was unclear if the  
label was a status report or the problem was _in_ the database.  New  
text is "In database:".  
  
Reported-by: Justin Pryzby  
  
Discussion: https://postgr.es/m/20191002172337.GC9680@telsasoft.com  
  
Backpatch-through: head  

commit   : 6c9fb69f2bb589c210a114162e67c86476460453    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 8 Oct 2019 21:49:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 8 Oct 2019 21:49:08 -0400    

Previously, our docs would say "Specifies the number of milliseconds"  
but it wasn't clear that "milliseconds" was merely the default unit.  
New text says "Specifies duration (defaults to milliseconds)", which is  
clearer.  
  
Reported-by: basil.bourque@gmail.com  
  
Discussion: https://postgr.es/m/15912-2e35e9026f61230b@postgresql.org  
  
Backpatch-through: 12  

commit   : 38d8dce61fff09daae0edb6bcdd42b0c7f10ebcd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 8 Oct 2019 10:27:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 8 Oct 2019 10:27:30 +0200    

As of d9dd406fe281d22d5238d3c26a7182543c711e74, we require MSVC 2013,  
which means _MSC_VER >= 1800.  This means that conditionals about  
older versions of _MSC_VER can be removed or simplified.  
  
Previous code was also in some cases handling MinGW, where _MSC_VER is  
not defined at all, incorrectly, such as in pg_ctl.c and win32_port.h,  
leading to some compiler warnings.  This should now be handled better.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  

commit   : a7471bd85c05f849e88d6cfe9da3c795008e8f2e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Oct 2019 14:31:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Oct 2019 14:31:30 +0900    

Author: Vignesh C  
Discussion: https://postgr.es/m/CALDaNm3Dy=dTdx8UCVw=DWbzLzmRUC1dkq45=heOZDUg3U_PtA@mail.gmail.com  

commit   : 491bb81fb803b0477062bb0a51edb752fa2cb396    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Oct 2019 13:59:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Oct 2019 13:59:53 +0900    

Some comments in this file referred to outdated links.  This simplifies  
the outdated comment blocks and refreshes the links.  
  
Reported-by: Vignesh C  
Author: Juan José Santamaría Flecha  
Discussion: https://postgr.es/m/46C03E17-16F7-4C38-B148-029AC7448E96@gmail.com  

commit   : 55ba56415bae6ac1f43c12d54537bd60eaa2153b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Oct 2019 11:46:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 8 Oct 2019 11:46:30 +0900    

This includes new TAP tests for a couple of areas not covered yet and  
some improvements:  
- More coverage for --no-ensure-shutdown, the enforced recovery step and  
--dry-run.  
- Failures with option combinations and basic option checks.  
- Removal of a duplicated comment.  
  
Author: Alexey Kondratov, Michael Paquier  
Discussion: https://postgr.es/m/20191007010651.GD14532@paquier.xyz  

commit   : 47eec34e4674e327ba7c2c57dda19241c889859e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 7 Oct 2019 18:06:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 7 Oct 2019 18:06:08 -0400    

The docs for sync and async multimaster replication were unclear about  
when to use it, and when it has benefits;  this change clarifies that.  
  
Reported-by: juha-pekka.eloranta@reaktor.fi  
  
Discussion: https://postgr.es/m/156856543824.1274.12180817186798859836@wrigleys.postgresql.org  
  
Backpatch-through: 9.4  

commit   : cae078f3f98fa3614b12719d276db376df95d473    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 7 Oct 2019 17:26:46 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 7 Oct 2019 17:26:46 -0400    

This should help people clearly know that these days start at midnight.  
  
Reported-by: David Harper  
  
Discussion: https://postgr.es/m/156258047907.1181.11324468080514061996@wrigleys.postgresql.org  
  
Backpatch-through: 9.4  

commit   : 47571ec1e46994265961b9ddfb83cccb340e4aec    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 7 Oct 2019 14:33:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 7 Oct 2019 14:33:31 -0400    

Previously it was mentioned in the lock_timeout docs in a confusing  
location.  
  
Reported-by: ivaylo.zlatanov@gmail.com  
  
Discussion: https://postgr.es/m/157019615723.25307.15449102262106437404@wrigleys.postgresql.org  
  
Backpatch-through: 9.4  

commit   : 3887e9455f812035473eee1cba0cf9c237969998    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Oct 2019 12:39:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Oct 2019 12:39:09 -0400    

The postmaster's code path for spawning a bgworker neglected to check  
whether we already have the max number of live child processes.  That's  
a bit hard to hit, since it would necessarily be a transient condition;  
but if we do, AssignPostmasterChildSlot() fails causing a postmaster  
crash, as seen in a report from Bhargav Kamineni.  
  
To fix, invoke canAcceptConnections() in the bgworker code path, as we  
do in the other code paths that spawn children.  Since we don't want  
the same pmState tests in this case, add a child-process-type parameter  
to canAcceptConnections() so that it can know what to do.  
  
Back-patch to 9.5.  In principle the same hazard exists in 9.4, but the  
code is enough different that this patch wouldn't quite fix it there.  
Given the tiny usage of bgworkers in that branch it doesn't seem worth  
creating a variant patch for it.  
  
Discussion: https://postgr.es/m/18733.1570382257@sss.pgh.pa.us  

commit   : 400d5ffcafa65e0f742dd29de83b035b8ea27c4a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Oct 2019 16:28:56 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Oct 2019 16:28:56 +0200    

Since 63bd0db12199c5df043e1dea0f2b574f622b3a4c we don't use tzname  
anymore, so we don't need to check for it.  Instead, just keep the  
part of PGAC_STRUCT_TIMEZONE that we need, which is the check for  
struct tm.tm_zone.  
  
Discussion: https://www.postgresql.org/message-id/flat/5eb11a37-f3ca-5fb7-308f-4485dec25a2e%402ndquadrant.com  

commit   : 4d7e5a5db01edaff749555220aa41eb35be06799    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Oct 2019 16:27:31 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Oct 2019 16:27:31 +0200    

Change from HAVE_TM_ZONE to HAVE_STRUCT_TM_TM_ZONE.  

commit   : 6a5084eed49552bfc8859c438c8d74ad09fc5d3f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Oct 2019 10:39:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 7 Oct 2019 10:39:07 -0400    

Temporarily change pg_ctl so that the postmaster's exit status will  
be printed (to the postmaster's stdout).  This is to help identify  
the cause of intermittent "postmaster exited during a parallel  
transaction" failures seen on a couple of buildfarm members.  This  
change degrades pg_ctl's functionality in a couple of minor ways,  
so we'll revert it once we've obtained the desired info.  
  
Discussion: https://postgr.es/m/18537.1570421268@sss.pgh.pa.us  

commit   : cc4ec2d29ac4f3b8335d1851627a9735b81beb50    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Oct 2019 09:44:17 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 7 Oct 2019 09:44:17 +0200    

HEAD as used here was CVS terminology.  Now we mean master.  

commit   : caa078353ecd1f3b3681c0d4fa95ad4bb8c2308a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Oct 2019 09:07:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 7 Oct 2019 09:07:22 +0900    

This includes a couple of changes around the new behavior of pg_rewind  
which enforces recovery to happen once on a cluster not shut down  
cleanly:  
- Some comments and documentation improvements.  
- Shutdown the cluster to rewind with immediate mode in all the tests,  
this allows to check after the forced recovery behavior which is wanted  
as new default.  
- Use -F for the forced recovery step, so as postgres does not use  
fsync.  This was useless as a final sync is done once the tool is done.  
  
Author: Michael Paquier  
Reviewed-by: Alexey Kondratov  
Discussion: https://postgr.es/m/20191004083721.GA1829@paquier.xyz  

commit   : 732457b5d2521c6ccd6b3b096d7aba73fca2a38a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Oct 2019 14:14:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Oct 2019 14:14:45 -0400    

Commit aa087ec64 was a bit over-hasty about the doc changes needed  
while splitting pg_statistic_ext_data off from pg_statistic_ext.  
It duplicated one para and inserted another in what seems to me  
to be the wrong section.  Fix that up, and in passing do some minor  
copy-editing.  
  
Per report from noborusai.  
  
Discussion: https://postgr.es/m/CAAM3qnLXLUz4mOBkqa8jxigpKhKNxzSuvwpjvCRPvO5EqWjxSg@mail.gmail.com  

commit   : ac12ab06a96179d44046494bc76ec53f30b5d30a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Oct 2019 12:06:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 6 Oct 2019 12:06:30 -0400    

Commit 1cff1b95a included some code that supposed it could repalloc()  
a memory chunk to a smaller size without risk of the chunk moving.  
That was not a great idea, because it depended on undocumented behavior  
of AllocSetRealloc, which commit c477f3e44 changed thereby breaking it.  
(Not to mention that this code ought to work with other memory context  
types, which might not work the same...)  So get rid of the repalloc  
calls, and instead just wipe the now-unused ListCell array and/or tell  
Valgrind it's NOACCESS, as if we'd freed it.  
  
In cases where the initial list allocation had been quite large, this  
could represent an annoying waste of space.  In principle we could  
ameliorate that by allocating the initial cell array separately when  
it exceeds some threshold.  But that would complicate new_list() which  
is hot code, and the returns would materialize only in narrow cases.  
On balance I don't think it'd be worth it.  
  
Discussion: https://postgr.es/m/17059.1570208426@sss.pgh.pa.us  

commit   : 36425ece5d6c78177cdc1453a9925a0bb85da59f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 5 Oct 2019 20:49:39 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 5 Oct 2019 20:49:39 +0200    

Commit f2369bc610 switched most of the memory accounting from int64 to  
Size, but it forgot to change the MemoryContextMemAllocated return type.  
So this fixes that omission.  
  
Discussion: https://www.postgresql.org/message-id/11238.1570200198%40sss.pgh.pa.us  

commit   : e800bd7414df3ce8170761e5b75b13e83f576988    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 5 Oct 2019 10:05:05 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 5 Oct 2019 10:05:05 -0700    

This prints the unexpected value in more failure cases, and it removes  
forty-eight hand-maintained error messages.  Back-patch to 9.5, which  
introduced these tests.  
  
Reviewed (in an earlier version) by Andres Freund.  
  
Discussion: https://postgr.es/m/20190915160021.GA24376@alvherre.pgsql  

commit   : d82f3909da11f9732fbc488333de0fdeb4d91ff5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Oct 2019 12:26:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 5 Oct 2019 12:26:55 -0400    

This would be all right, maybe, if it didn't also match a file that  
definitely should not be ignored.  We don't add rmgrs so often that  
manual maintenance of this file list is impractical, so just write  
out the list.  
  
(I find the equivalent wildcard use in the Makefile pretty lazy and  
unsafe as well, but will leave that alone until it actually causes a  
problem.)  
  
Per bug #16042 from Denis Stuchalin.  
  
Discussion: https://postgr.es/m/16042-c174ee692ac21cbd@postgresql.org  

commit   : 3a68105154c3a35e4b107b41e2f54ec85fbe29f5    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 5 Oct 2019 08:05:11 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 5 Oct 2019 08:05:11 -0700    

Discussion: https://postgr.es/m/20191004222437.45qmglpto43pd3jb@alap3.anarazel.de  
Backpatch: 9.6-, just like c8841199509 and 6e61d75f525  

commit   : 6e61d75f5258dc395c131ad5edd712852e29939e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 4 Oct 2019 21:11:23 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 4 Oct 2019 21:11:23 -0700    

One of the upsert related tests is unstable (sometimes even hanging  
until isolationtester's step timeout is reached). Based on preliminary  
analysis that might be a problem outside of just that test, but not  
really related to EPQ and triggers.  Disable for now, to get the  
buildfarm greener again.  
  
Discussion: https://postgr.es/m/20191004222437.45qmglpto43pd3jb@alap3.anarazel.de  
Backpatch: 9.6-, just like c8841199509.  

commit   : c88411995098800e19e8507d4db19e86b09d73e4    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 4 Oct 2019 13:56:04 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 4 Oct 2019 13:56:04 -0700    

As evidenced by bug #16036 this area is woefully under-tested. Add  
fairly extensive tests for the combination.  
  
Backpatch back to 9.6 - before that isolationtester was not capable  
enough. While we don't backpatch tests all the time, future fixes to  
trigger.c would potentially look different enough in 12+ from the  
earlier branches that introducing bugs during backpatching is more  
likely than normal. Also, it's just a crucial and undertested area of  
the code.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/16036-28184c90d952fb7f@postgresql.org  
Backpatch: 9.6-, the earliest these tests work  

commit   : d986d4e87f61c68f52c68ebc274960dc664b7b4e    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 4 Oct 2019 11:59:34 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 4 Oct 2019 11:59:34 -0700    

When ExecBRUpdateTriggers()'s GetTupleForTrigger() follows an EPQ  
chain the former needs to run the result tuple through the junkfilter  
again, and update the slot containing the new version of the tuple to  
contain that new version. The input tuple may already be in the  
junkfilter's output slot, which used to be OK - we don't need the  
previous version anymore. Unfortunately ff11e7f4b9ae started to use  
ExecCopySlot() to update newslot, and ExecCopySlot() doesn't support  
copying a slot into itself, leading to a slot in a corrupt  
state, which then can cause crashes or other symptoms.  
  
Fix this by skipping the ExecCopySlot() when copying into itself.  
  
While we could have easily made ExecCopySlot() handle that case, it  
seems better to add an assert forbidding doing so instead. As the goal  
of copying might be to make the contents of one slot independent from  
another, it seems failure prone to handle doing so silently.  
  
A follow-up commit will add tests for the obviously under-covered  
combination of EPQ and triggers. Done as a separate commit as it might  
make sense to backpatch them further than this bug.  
  
Also remove confusion with confusing variable names for slots in  
ExecBRDeleteTriggers() and ExecBRUpdateTriggers().  
  
Bug: #16036  
Reported-By: Антон Власов  
Author: Andres Freund  
Discussion: https://postgr.es/m/16036-28184c90d952fb7f@postgresql.org  
Backpatch: 12-, where ff11e7f4b9ae was merged  

commit   : a586cc4b6c568e88a459f1a69ac82aa42af7e5ba    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 4 Oct 2019 13:08:51 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 4 Oct 2019 13:08:51 -0700    

Cribbing from dfbaed45975:  
    Some operating systems, including the reporter's windows, return EBADFD  
    or similar when fsync() is invoked on a O_RDONLY file descriptor.  
    Unfortunately RestoreSlotFromDisk() does exactly that; which causes  
    failures after restarts in at least some scenarios.  
  
    If you hit the bug the error message will be something like  
    ERROR: could not fsync file "pg_replslot/$name/state": Bad file descriptor  
  
    Simply use O_RDWR instead of O_RDONLY when opening the relevant file  
    descriptor to fix the bug.  
  
Unfortunately this fix was undone in 82a5649fb9db. Re-apply, and add a  
comment.  
  
Bug: 16039  
Reported-By: Hans Buschmann  
Author: Andres Freund  
Discussion: https://postgr.es/m/16039-196fc97cc05e141c@postgresql.org  
Backpatch: 12-, as 82a5649fb9db  

commit   : ad7595b890dbc26284bb0d784c2aaf1b9d6f903a    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 4 Oct 2019 15:34:40 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 4 Oct 2019 15:34:40 -0400    

First, make sure that the .exe name is quoted when trying to get the  
version number. Also, don't quote the lib name for using in the project  
files if it's already been quoted. This second change applies to all  
libraries, not just OpenSSL.  
  
This has clearly been broken forever, so backpatch to all live branches.  

commit   : 2e8b6bfa90b252b1e1758364de7deff067d6058a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Oct 2019 14:24:46 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Oct 2019 14:24:46 -0400    

The old names for the attribute-detoasting functions names included  
the word "heap," which seems outdated now that the heap is only one of  
potentially many table access methods.  
  
On the other hand, toast_insert_or_update and toast_delete are  
heap-specific, so rename them by adding "heap_" as a prefix.  
  
Not all of the work of making the TOAST system fully accessible to AMs  
other than the heap is done yet, but there seems to be little harm in  
getting this renaming out of the way now. Commit  
8b94dab06617ef80a0901ab103ebd8754427ef5a already divided up the  
functions among various files partially according to whether it was  
intended that they should be heap-specific or AM-agnostic, so this is  
just clarifying the division contemplated by that commit.  
  
Patch by me, reviewed and tested by Prabhat Sabu, Thomas Munro,  
Andres Freund, and Álvaro Herrera.  
  
Discussion: http://postgr.es/m/CA+TgmoZv-=2iWM4jcw5ZhJeL18HF96+W1yJeYrnGMYdkFFnEpQ@mail.gmail.com  

commit   : 61aa9f544a91f2908e4c7cd549907cdc5b6f1c82    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Oct 2019 10:34:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 4 Oct 2019 10:34:21 -0400    

Commit 5ac0d9360 failed to entirely fix bitshiftright's habit of  
leaving one-bits in the pad space that should be all zeroes,  
because in a moment of sheer brain fade I'd concluded that only  
the code path used for not-a-multiple-of-8 shift distances needed  
to be fixed.  Of course, a multiple-of-8 shift distance can also  
cause the problem, so we need to forcibly zero the extra bits  
in both cases.  
  
Per bug #16037 from Alexander Lakhin.  As before, back-patch to all  
supported branches.  
  
Discussion: https://postgr.es/m/16037-1d1ebca564db54f4@postgresql.org  

commit   : f2369bc610a19563cc00054ccfe9089fac469641    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 4 Oct 2019 16:10:56 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 4 Oct 2019 16:10:56 +0200    

Commit 5dd7fc1519 added block-level memory accounting, but used int64 variable to  
track the amount of allocated memory. That is incorrect, because we have Size for  
exactly these purposes, but it was mostly harmless until c477f3e449 which changed  
how we handle with repalloc() when downsizing the chunk. Previously we've ignored  
these cases and just kept using the original chunk, but now we need to update the  
accounting, and the code was doing this:  
  
    context->mem_allocated += blksize - oldblksize;  
  
Both blksize and oldblksize are Size (so unsigned) which means the subtraction  
underflows, producing a very high positive value. On 64-bit platforms (where Size  
has the same size as mem_alllocated) this happens to work because the result wraps  
to the right value, but on (some) 32-bit platforms this fails.  
  
This fixes two things - it changes mem_allocated (and related variables) to Size,  
and it splits the update to two separate steps, to prevent any underflows.  
  
Discussion: https://www.postgresql.org/message-id/15151.1570163761%40sss.pgh.pa.us  

commit   : 967e276e9f6b485c8577371713a323bf277b6902    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Oct 2019 08:19:25 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 4 Oct 2019 08:19:25 -0400    

Allocate notify-related state lazily instead. This makes trivial  
subtransactions noticeably faster.  
  
Patch by me, reviewed and tested by Dilip Kumar, Kyotaro Horiguchi,  
and Jeevan Ladhe.  
  
Discussion: https://postgr.es/m/CA+TgmobE1J22S1eC-6N-je9LgrcwZypkwp+zH6JXo9mc=4Nk3A@mail.gmail.com  

commit   : 6837632b758e0470a2692d9f8303e8aebd6fbd8f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Oct 2019 16:18:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Oct 2019 16:18:29 +0900    

This fixes two issues with recent features added in pg_rewind:  
- --dry-run should do nothing on the target directory, but 927474c  
forgot to consider that for --write-recovery-conf.  
- --no-ensure-shutdown was not actually working.  There is no test  
coverage for this option yet, but a subsequent patch will add that.  
  
Author: Alexey Kondratov  
Discussion: https://postgr.es/m/7ca88204-3e0b-2f4c-c8af-acadc4b266e5@postgrespro.ru  

commit   : 6f3823b03560589157d9dbdab623f603ef393d7c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Oct 2019 09:14:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 4 Oct 2019 09:14:51 +0900    

Even if --dry-run mode was specified, the control file was getting  
updated, preventing follow-up runs of pg_rewind to work properly on the  
target data folder.  The origin of the problem came from the refactoring  
done by ce6afc6.  
  
Author: Alexey Kondratov  
Discussion: https://postgr.es/m/7ca88204-3e0b-2f4c-c8af-acadc4b266e5@postgrespro.ru  
Backpatch-through: 12  

commit   : 8e10405c745003c5c16acb2da847db9bed1a169e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Oct 2019 17:34:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Oct 2019 17:34:25 -0400    

Encoding conversion uses the very simplistic rule that the output  
can't be more than 4X longer than the input, and palloc's a buffer  
of that size.  This results in failure to convert any string longer  
than 1/4 GB, which is becoming an annoying limitation.  
  
As a band-aid to improve matters, allow the allocated output buffer  
size to exceed 1GB.  We still insist that the final result fit into  
MaxAllocSize (1GB), though.  Perhaps it'd be safe to relax that  
restriction, but it'd require close analysis of all callers, which  
is daunting (not least because external modules might call these  
functions).  For the moment, this should allow a 2X to 4X improvement  
in the longest string we can convert, which is a useful gain in  
return for quite a simple patch.  
  
Also, once we have successfully converted a long string, repalloc  
the output down to the actual string length, returning the excess  
to the malloc pool.  This seems worth doing since we can usually  
expect to give back several MB if we take this path at all.  
  
This still leaves much to be desired, most notably that the assumption  
that MAX_CONVERSION_GROWTH == 4 is very fragile, and yet we have no  
guard code verifying that the output buffer isn't overrun.  Fixing  
that would require significant changes in the encoding conversion  
APIs, so it'll have to wait for some other day.  
  
The present patch seems safely back-patchable, so patch all supported  
branches.  
  
Alvaro Herrera and Tom Lane  
  
Discussion: https://postgr.es/m/20190816181418.GA898@alvherre.pgsql  
Discussion: https://postgr.es/m/3614.1569359690@sss.pgh.pa.us  

commit   : c477f3e449d1a7322c2453e9cd9d6b710ae91577    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Oct 2019 13:56:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 3 Oct 2019 13:56:26 -0400    

Up to now, if you resized a large (>8K) palloc chunk down to a smaller  
size, aset.c made no attempt to return any space to the malloc pool.  
That's unpleasant if a really large allocation is resized to a  
significantly smaller size.  I think no such cases existed when this  
code was designed, and I'm not sure whether they're common even yet,  
but an upcoming fix to encoding conversion will certainly create such  
cases.  Therefore, fix AllocSetRealloc so that it gives realloc()  
a chance to do something with the block.  This doesn't noticeably  
increase complexity, we mostly just have to change the order in which  
the cases are considered.  
  
Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/20190816181418.GA898@alvherre.pgsql  
Discussion: https://postgr.es/m/3614.1569359690@sss.pgh.pa.us  

commit   : b7a1c5539ad34d7357e04cc58f9c02a101482737    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 3 Oct 2019 10:54:52 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Thu, 3 Oct 2019 10:54:52 +0100    

query_tree_walker and query_tree_mutator were skipping the  
windowClause of the query, without regard for the fact that the  
startOffset and endOffset in a WindowClause node are expression trees  
that need to be processed. This was an oversight in commit ec4be2ee6  
from 2010 which added the expression fields; the main symptom is that  
function parameters in window frame clauses don't work in inlined  
functions.  
  
Fix (as conservatively as possible since this needs to not break  
existing out-of-tree callers) and add tests.  
  
Backpatch all the way, since this has been broken since 9.0.  
  
Per report from Alastair McKinley; fix by me with kibitzing and review  
from Tom Lane.  
  
Discussion: https://postgr.es/m/DB6PR0202MB2904E7FDDA9D81504D1E8C68E3800@DB6PR0202MB2904.eurprd02.prod.outlook.com  

commit   : b1c1aa53182372e907f3f7f090e7eb5f432a4c9a    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 1 Oct 2019 09:50:26 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 1 Oct 2019 09:50:26 +0530    

These new options allow users to partition the pgbench_accounts table by  
specifying the number of partitions and partitioning method.  The values  
allowed for partitioning method are range and hash.  
  
This feature allows users to measure the overhead of partitioning if any.  
  
Author: Fabien COELHO  
Reviewed-by: Amit Kapila, Amit Langote, Dilip Kumar, Asif Rehman, and  
Alvaro Herrera  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1907230826190.7008@lancre  

commit   : df86e52cace2c4134db51de6665682fb985f3195    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Oct 2019 15:53:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Oct 2019 15:53:07 +0900    

cbc55da has reworked the order of some actions at the end of archive  
recovery.  Unfortunately this overlooked the fact that the startup  
process needs to remove RECOVERYXLOG (for temporary WAL segment newly  
recovered from archives) and RECOVERYHISTORY (for temporary history  
file) at this step, leaving the files around even after recovery ended.  
  
Backpatch to 9.5, like the previous commit.  
  
Author: Sawada Masahiko  
Reviewed-by: Fujii Masao, Michael Paquier  
Discussion: https://postgr.es/m/CAD21AoBO_eDQub6zojFnWtnmutRBWvYf7=cW4Hsqj+U_R26w3Q@mail.gmail.com  
Backpatch-through: 9.5  

commit   : 9555cc8d2b02c4191d67ba39f589b39b01735518    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Oct 2019 09:55:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Oct 2019 09:55:27 +0900    

The location of the session end hook has been chosen so as it is  
possible to allow modules to do their own transactions, however any  
trying to any any subsystem which went through before_shmem_exit()  
would cause issues, limiting the pluggability of the hook.  
  
Per discussion with Tom Lane and Andres Freund.  
  
Discussion: https://postgr.es/m/18722.1569906636@sss.pgh.pa.us  

commit   : 540f31680913b4e11f2caa40cafeca269cfcb22f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Oct 2019 16:53:04 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Oct 2019 16:53:04 +0200    

Commit 11a078cf87 triggered failures on big-endian machines, and the  
only plausible place for an issue seems to be that TOAST_COMPRESS_SIZE  
calls VARSIZE instead of VARSIZE_ANY. So try fixing that blindly.  
  
Discussion: https://www.postgresql.org/message-id/20191001131803.j6uin7nho7t6vxzy%40development  

commit   : fa2fe04bf1d4d31e099808745974964f84eb4521    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Oct 2019 14:39:06 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Oct 2019 14:39:06 +0200    

This fixes two compiler warnings about unused variables in non-assert builds,  
introduced by 5dd7fc1519461548eebf26c33eac6878ea3e8788.  

commit   : 11a078cf87ffb611d19c7dec6df68b41084ad9c9    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Oct 2019 14:13:44 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Oct 2019 14:13:44 +0200    

Commit 4d0e994eed added support for partial TOAST decompression, so the  
decompression is interrupted after producing the requested prefix. For  
prefix and slices near the beginning of the entry, this may saves a lot  
of decompression work.  
  
That however only deals with decompression - the whole compressed entry  
was still fetched and re-assembled, even though the compression used  
only a small fraction of it. This commit improves that by computing how  
much compressed data may be needed to decompress the requested prefix,  
and then fetches only the necessary part.  
  
We always need to fetch a bit more compressed data than the requested  
(uncompressed) prefix, because the prefix may not be compressible at all  
and pglz itself adds a bit of overhead. That means this optimization is  
most effective when the requested prefix is much smaller than the whole  
compressed entry.  
  
Author: Binguo Bao  
Reviewed-by: Andrey Borodin, Tomas Vondra, Paul Ramsey  
Discussion: https://www.postgresql.org/message-id/flat/CAL-OGkthU9Gs7TZchf5OWaL-Gsi=hXqufTxKv9qpNG73d5na_g@mail.gmail.com  

commit   : 002962dc7293043126561b0d0df79d6c76251804    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Oct 2019 15:19:32 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Oct 2019 15:19:32 +0900    

Several buildfarm machines have been complaining about the new module  
test_session_hooks to be unstable, like crake and thorntail.  The issue  
was that the module was trying to log some start and end session  
activity for parallel workers, which makes little sense as they don't  
support DML, so just prevent this pattern to happen in the module.  
  
This could be reproduced by enforcing force_parallel_mode=regress, which  
is the value used by some of the buildfarm members.  
  
Discussion: https://postgr.es/m/20191001045246.GF2781@paquier.xyz  

commit   : e788bd924c19e296bd34316e30e3ba1b68354e64    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Oct 2019 12:15:25 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Oct 2019 12:15:25 +0900    

These hooks can be used in loadable modules.  A simple test module is  
included.  
  
The first attempt was done with cd8ce3a but we lacked handling for  
NO_INSTALLCHECK in the MSVC scripts (problem solved afterwards by  
431f1599) so the buildfarm got angry.  This also fixes a couple of  
issues noticed upon review compared to the first attempt, so the code  
has slightly changed, resulting in a more simple test module.  
  
Author: Fabrízio de Royes Mello, Yugo Nagata  
Reviewed-by: Andrew Dunstan, Michael Paquier, Aleksandr Parfenov  
Discussion: https://postgr.es/m/20170720204733.40f2b7eb.nagata@sraoss.co.jp  
Discussion: https://postgr.es/m/20190823042602.GB5275@paquier.xyz  

commit   : 41a6de41ed697df5d84f3144c6c60b4a9725381f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Oct 2019 10:56:27 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 1 Oct 2019 10:56:27 +0900    

When using a client compiled without channel binding support (linking to  
OpenSSL 1.0.1 or older) to connect to a server which supports channel  
binding (linking to OpenSSL 1.0.2 or newer), libpq would generate a  
confusing error message with channel_binding=require for an SSL  
connection, where the server sends back SCRAM-SHA-256-PLUS:  
"channel binding is required, but server did not offer an authentication  
method that supports channel binding."  
  
This is confusing because the server did send a SASL mechanism able to  
support channel binding, but libpq was not able to detect that  
properly.  
  
The situation can be summarized as followed for the case described in  
the previous paragraph for the SASL mechanisms used with the various  
modes of channel_binding:  
1) Client supports channel binding.  
1-1) channel_binding = disable => OK, with SCRAM-SHA-256.  
1-2) channel_binding = prefer => OK, with SCRAM-SHA-256-PLUS.  
1-3) channel_binding = require => OK, with SCRAM-SHA-256-PLUS.  
2) Client does not support channel binding.  
2-1) channel_binding = disable => OK, with SCRAM-SHA-256.  
2-2) channel_binding = prefer => OK, with SCRAM-SHA-256.  
2-3) channel_binding = require => failure with new error message,  
instead of the confusing one.  
This commit updates case 2-3 to generate a better error message.  Note  
that the SSL TAP tests are not impacted as it is not possible to test  
with mixed versions of OpenSSL for the backend and libpq.  
  
Reported-by: Tom Lane  
Author: Michael Paquier  
Reviewed-by: Jeff Davis, Tom Lane  
Discussion: https://postgr.es/m/24857.1569775891@sss.pgh.pa.us  

commit   : 5dd7fc1519461548eebf26c33eac6878ea3e8788    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Oct 2019 03:13:39 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 1 Oct 2019 03:13:39 +0200    

Adds accounting of memory allocated in a memory context. Compared to  
various ad hoc solutions, the main advantage is that the accounting is  
transparent and does not require direct control over allocations (this  
matters for use cases where the allocations happen in user code, like  
for example aggregate states allocated in a transition functions).  
  
To reduce overhead, the accounting happens at the block level (not for  
individual chunks) and only the context immediately owning the block is  
updated. When inquiring about amount of memory allocated in a context,  
we have to recursively walk all children contexts.  
  
This "lazy" accounting works well for cases with relatively small number  
of contexts in the relevant subtree and/or with infrequent inquiries.  
  
Author: Jeff Davis  
Reivewed-by: Tomas Vondra, Melanie Plageman, Soumyadeep Chakraborty  
Discussion: https://www.postgresql.org/message-id/flat/027a129b8525601c6a680d27ce3a7172dab61aab.camel@j-davis.com  

commit   : 36d22dd95bc87ca68e742da91f47f8826f8758c9    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 30 Sep 2019 16:06:16 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 30 Sep 2019 16:06:16 -0700    

That avoids unnecessary work during both interpreted execution, and  
JIT compiled expression evaluation. Both benefit from fewer expression  
steps needing be processed, and for interpreted execution there now is  
a fastpath dedicated to just fetching a value from a virtual  
slot. That's e.g. beneficial for hashjoins over nodes that perform  
projections, as the hashed columns are currently fetched individually.  
  
Author: Soumyadeep Chakraborty, Andres Freund  
Discussion: https://postgr.es/m/CAE-ML+9OKSN71+mHtfMD-L24oDp8dGTfaVjDU6U+j+FNAW5kRQ@mail.gmail.com  

commit   : 34c9c53bb035ba92491006eb80f7a60527db367d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 30 Sep 2019 15:00:21 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 30 Sep 2019 15:00:21 -0700    

This is mainly in preparation for adding further fastpath evaluation  
routines.  
  
Also reorder ExecJust*Var functions to be consistent with the order in  
which they're used.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/CAE-ML+9OKSN71+mHtfMD-L24oDp8dGTfaVjDU6U+j+FNAW5kRQ@mail.gmail.com  

commit   : d52eaa094847d395f942827a6f413904e516994c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Sep 2019 17:14:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Sep 2019 17:14:00 -0400    

This file had a very weird mix of tests that did "set plan_cache_mode =  
force_generic_plan" to get a generic plan, and tests that relied on  
using five dummy executions of a prepared statement.  Converting them  
all to rely on plan_cache_mode is more consistent and shaves off a  
noticeable fraction of the test script's runtime.  
  
Discussion: https://postgr.es/m/11952.1569536725@sss.pgh.pa.us  

commit   : 863fa43e32b02963f240864245c6c922f619459f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Sep 2019 15:48:54 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 30 Sep 2019 15:48:54 -0400    

This one was exposed by a12c75a10.  
  
Backpatch to release 11 where check_pg_config was introduced.  

commit   : 5daf682cfc974bf9095be527603c6410921892a9    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 30 Sep 2019 12:43:09 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 30 Sep 2019 12:43:09 -0700    

The aforementioned commit orders the link to pgfeutils after libpq,  
which can fail because pgfeutils uses symbols from libpq.  
  
Per buildfarm animal jacana.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190930192013.r3wievljua2n3tbb@alap3.anarazel.de  

commit   : ce734aaec1891ca2180c269b4c9adbfb13ca4052    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Sep 2019 14:31:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Sep 2019 14:31:12 -0400    

The behavior described in the PREPARE man page applies only for the  
default plan_cache_mode setting, so explain that properly.  Rewrite  
some of the text while I'm here.  Per suggestion from Bruce.  
  
Discussion: https://postgr.es/m/20190930155505.GA21095@momjian.us  

commit   : 7e0fb165dd2447f83464833e63e646d2771edb15    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 30 Sep 2019 13:44:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 30 Sep 2019 13:44:22 -0400    

This commit adds a mention that the order of columns specified during  
multi-column most-common-value statistics is insignificant, and tries to  
simplify examples.  
  
Discussion: https://postgr.es/m/20190828162238.GA8360@momjian.us  
  
Backpatch-through: 12  

commit   : 7524c788743f387c20bd4719c7a0ef0887602930    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Sep 2019 14:04:00 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Sep 2019 14:04:00 -0300    

Author: Alexey Kondratov  
Reviewed-by: Paul Guo  
Discussion: https://postgr.es/m/2f726102-3f1e-bf16-061e-501919473ace@postgrespro.ru  

commit   : 927474ce1a2498ddb617c6113a88ca61fbba161d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Sep 2019 12:57:35 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 30 Sep 2019 12:57:35 -0300    

This is provided with a new switch --write-recovery-conf and reuses the  
pg_basebackup code.  
  
Author: Paul Guo, Jimmy Yih, Ashwin Agrawal  
Reviewed-by: Alexey Kondratov, Michaël Paquier, Álvaro Herrera  
Discussion: https://postgr.es/m/CAEET0ZEffUkXc48pg2iqARQgGRYDiiVxDu+yYek_bTwJF+q=Uw@mail.gmail.com  

commit   : a12c75a1048295f03cf85533d6dcab5072ba262b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Sep 2019 13:11:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 30 Sep 2019 13:11:31 +0900    

When compiling Postgres with OpenSSL 1.0.1 or older versions, SCRAM's  
channel binding cannot be supported as X509_get_signature_nid() is  
needed, which causes a regression test with channel_binding='require' to  
fail as the server cannot publish SCRAM-SHA-256-PLUS as SASL mechanism  
over an SSL connection.  
  
Fix the issue by using a method similar to c3d41cc, making the test  
result conditional.  The test passes if X509_get_signature_nid() is  
present, and when missing we test for a connection failure.  Testing a  
connection failure is more useful than skipping the test as we should  
fail the connection if channel binding is required by the client but the  
server does not support it.  
  
Reported-by: Tom Lane, Michael Paquier  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20190927024457.GA8485@paquier.xyz  
Discussion: https://postgr.es/m/24857.1569775891@sss.pgh.pa.us  

commit   : 7acf8a876b7704ae162fc4f48ff97f4290fb0a61    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Sep 2019 10:18:15 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Sep 2019 10:18:15 +0900    

In v11 or before, recovery target settings could not take effect in  
crash recovery because they are specified in recovery.conf and  
crash recovery always starts without recovery.conf. But commit  
2dedf4d9a8 integrated recovery.conf into postgresql.conf and  
which unexpectedly allowed recovery target settings to take effect  
even in crash recovery. This is definitely not good behavior.  
  
To fix the issue, this commit makes crash recovery always ignore  
recovery target settings.  
  
Back-patch to v12.  
  
Author: Peter Eisentraut  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/e445616d-023e-a268-8aa1-67b8b335340c@pgmasters.net  

commit   : ac88807f9b227ddcd92b8be9a053094837c1b99a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 29 Sep 2019 16:24:32 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 29 Sep 2019 16:24:32 -0700    

In the course of 5567d12ce03, 356687bd8 and 317ffdfeaac, I changed  
BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass  
in the parent node, but NULL. Which in turn prevents the tuple  
equality comparator from being JIT compiled.  While that fixes  
bug #15486, it is not actually necessary after all of the above commits,  
as we don't re-build the comparator when using the new  
BuildTupleHashTableExt() interface (as the content of the hashtable  
are reset, but the TupleHashTable itself is not).  
  
Therefore re-allow jit compilation for callers that use  
BuildTupleHashTableExt with a separate context for "metadata" and  
content.  
  
As in the previous commit, there's ongoing work to make this easier to  
test to prevent such regressions in the future, but that  
infrastructure is not going to be backpatchable.  
  
The performance impact of not JIT compiling hashtable equality  
comparators can be substantial e.g. for aggregation queries that  
aggregate a lot of input rows to few output rows (when there are a lot  
of output groups, there will be fewer comparisons).  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de  
Backpatch: 11, just as 5567d12ce03  

commit   : 97e971ee05d5a0f6361ea34abf27059d762045a7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 29 Sep 2019 15:24:54 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 29 Sep 2019 15:24:54 -0700    

For many queries the fact that the tuple descriptor from the lower  
node was not taken into account when determining whether the type of a  
slot is fixed, lead to tuple deforming for such upper nodes not to be  
JIT accelerated.  
  
I broke this in 675af5c01e297.  
  
There is ongoing work to enable writing regression tests for related  
behavior (including a patch that would have detected this  
regression), by optionally showing such details in EXPLAIN. But as it  
seems unlikely that that will be suitable for stable branches, just  
merge the fix for now.  
  
While it's fairly close to the 12 release window, the fact that 11  
continues to perform JITed tuple deforming in these cases, that  
there's still cases where we do so in 12, and the fact that the  
performance regression can be sizable, weigh in favor of fixing it  
now.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de  
Backpatch: 12-, where 675af5c01e297 was merged.  

commit   : 258bf86a9aec05b531c206a6e661ec8c0754e10f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 29 Sep 2019 17:32:46 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 29 Sep 2019 17:32:46 -0400    

Windows does not enforce key file permissions checks in libpq, and psql  
can produce CRLF line endings on Windows.  
  
Backpatch to Release 12 (CRLF) and Release 11 (permissions check)  

commit   : e04a53a6071d13ef4a13a41c6419d8e14c30b95c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 23:07:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 23:07:22 +0200    

Recovery target parameters are all applied even in standby mode.  The  
previous documentation mostly wished they were not but this was never  
the case.  
  
Discussion: https://www.postgresql.org/message-id/flat/e445616d-023e-a268-8aa1-67b8b335340c%40pgmasters.net  

commit   : 2c97f73468419672f2340afb24f1321695ee3002    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Sep 2019 12:35:53 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Sep 2019 12:35:53 -0400    

Coverity pointed out that it's pretty silly to check for a null pointer  
after we've already dereferenced the pointer.  To fix, just swap the  
order of the two error checks.  Oversight in commit d6e612f83.  

commit   : 92f1545d6ea9fbfe4b47108028ccaae351a1480c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 09:50:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Sep 2019 09:50:36 +0200    

Forward-patched from PostgreSQL 12 release notes patch, for  
consistency.  

commit   : 4e6f101e921c9a7ff4e7fff847966b9cdd390753    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Sep 2019 15:54:02 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Sep 2019 15:54:02 +0200    

Some older OpenSSL versions (0.9.8 branch) define TLS*_VERSION macros  
but not the corresponding SSL_OP_NO_* macro, which causes the code for  
handling ssl_min_protocol_version/ssl_max_protocol_version to fail to  
compile.  To fix, add more #ifdefs and error handling.  
  
Reported-by: Victor Wagner <vitus@wagner.pp.ru>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/20190924101859.09383b4f%40fafnir.local.vm  

commit   : 4ea03f3f4eba3c76abae2e69bf48c921799a68a3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Sep 2019 13:33:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Sep 2019 13:33:34 -0400    

This test already knew that, to get stable test output, it had to hide  
"loops" counts in EXPLAIN ANALYZE results.  But that's not nearly enough:  
if we get a smaller number of workers than we planned for, then the  
"Workers Launched" number will change, and so will all the rows and loops  
counts up to the Gather node.  This has resulted in repeated failures in  
the buildfarm, so adjust the test to filter out all these counts.  
  
(Really, we wouldn't bother with EXPLAIN ANALYZE at all here, except  
that currently the only way to verify that executor-time pruning has  
happened is to look for '(never executed)' annotations.  Those are  
stable and needn't be filtered out.)  
  
Back-patch to v11 where the test was introduced.  
  
Discussion: https://postgr.es/m/11952.1569536725@sss.pgh.pa.us  

commit   : 55282fa20f46c193bd4a89ad5bcd048048a8734d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 28 Sep 2019 15:22:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 28 Sep 2019 15:22:49 +0900    

HEAD supports OpenSSL 0.9.8 and newer versions, and this code likely got  
forgotten as its surrounding comments mention an incorrect version  
number.  
  
Author: Michael Paquier  
Reviewed-by: Peter Eisentraut  
Discussion: https://postgr.es/m/20190927032311.GB8485@paquier.xyz  

commit   : 5ee96b3e2221d154ffcb719bd2dee1179c53f821    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Sep 2019 18:19:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Sep 2019 18:19:37 -0400    

For the most part, we leave libpq-controlling environment variables  
alone during "make installcheck", reasoning that connecting to the  
server the user expects us to connect to may depend on those variables.  
But that argument doesn't apply to PGDATABASE, since we always want  
to connect to a specific database name within the server.  And failing  
to unset it causes certain ECPG tests to fail, as various people have  
complained of in the past.  So let's unset it.  
  
Possibly this should be back-patched, but I'm disinclined to do that  
right before 12.0 release.  Maybe later.  
  
Discussion: https://postgr.es/m/20180318205548.2akxjqvo7hrk5wbc@alap3.anarazel.de  
Discussion: https://postgr.es/m/E1bOum4-0002EA-2y@gemulon.postgresql.org  

commit   : 3f6b3be39ca91a62b88051a6b4fdf428a05c6b0d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 27 Sep 2019 14:10:16 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 27 Sep 2019 14:10:16 -0700    

When compiling postgres using gcc -O3, there are false-positive  
warnings about the now initialized variables. Silence them.  
  
Author: Peter Eisentraut, Andres Freund  
Discussion: https://postgr.es/m/15fb2350-b8b8-e188-278f-0b34fdee5210@2ndquadrant.com  

commit   : 5adafaf176d09ba5ea11ae128416fc5211469bc0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Sep 2019 16:40:01 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Sep 2019 16:40:01 -0300    

If we don't do this, the rewind fails if the server wasn't cleanly shut  
down, which seems unhelpful serving no purpose.  
  
Also provide a new option --no-ensure-shutdown to suppress this  
behavior, for alleged advanced usage that prefers to avoid the crash  
recovery.  
  
Authors: Paul Guo, Jimmy Yih, Ashwin Agrawal  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/CAEET0ZEffUkXc48pg2iqARQgGRYDiiVxDu+yYek_bTwJF+q=Uw@mail.gmail.com  

commit   : c967e13f4047ef6f3d91bcb1cff6d746322aff6d    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 27 Sep 2019 10:25:08 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 27 Sep 2019 10:25:08 -0700    

For some reason at least gcc-9 warns about the fallthrough, even  
though it otherwise recognizes that elog(ERROR, ...) doesn't return.  
  
Author: Andres Freund  

commit   : b9bffa004a9980ac235b6ff541ee2fe0e9800372    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Sep 2019 11:28:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Sep 2019 11:28:24 -0400    

We've noted certain EXPLAIN queries on these tables occasionally showing  
unexpected plan choices.  This seems to happen because VACUUM sometimes  
fails to update relpages/reltuples for one of these single-page tables,  
due to bgwriter or checkpointer holding a pin on the lone page at just  
the wrong time.  To ensure those values get set, insert explicit ANALYZE  
operations on these tables after we finish populating them.  This  
doesn't seem to affect any other test cases, so it's a usable fix.  
  
Back-patch to v12.  In principle the issue exists further back, but  
we have not seen it before v12, so I won't risk back-patching further.  
  
Discussion: https://postgr.es/m/24480.1569518042@sss.pgh.pa.us  

commit   : d9cacca2d139d9e0792544f773d2361d8478c131    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Sep 2019 11:20:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Sep 2019 11:20:09 -0400    

This removes the last of the temporary debugging queries added to the  
regression tests by commit f03a9ca43.  We've pretty much convinced  
ourselves that the plan instability we were seeing is due to VACUUM  
sometimes failing to update relpages/reltuples for a single-page table,  
due to bgwriter or checkpointer holding a pin on that page at just the  
wrong time.  I'll push a workaround for that separately.  
  
Discussion: https://postgr.es/m/CA+hUKG+0CxrKRWRMf5ymN3gm+BECHna2B-q1w8onKBep4HasUw@mail.gmail.com  

commit   : 4fa1d89cba0f1feb5120e99eb01c152ba276c4e9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Sep 2019 11:01:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Sep 2019 11:01:36 -0400    

The markup for optional parameters was neither correct nor consistent.  
In passing, fix a spelling mistake.  
  
Per report from Alex Macy.  Some of these mistakes are old, so  
back-patch as appropriate.  
  
Discussion: https://postgr.es/m/156953522258.1204.12736099368284950578@wrigleys.postgresql.org  

commit   : 775578a445bbbbfc43b1dcc1c3e2d3b4bdb35962    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 27 Sep 2019 16:21:47 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 27 Sep 2019 16:21:47 +0200    

The documentation states that no target settings will be used when  
standby.signal is present, but this is not quite the case since  
recovery_target_timeline is a valid recovery target for a standby.  
  
Update the documentation with this exception.  
  
Author: David Steele <david@pgmasters.net>  
Discussion: https://www.postgresql.org/message-id/flat/e445616d-023e-a268-8aa1-67b8b335340c%40pgmasters.net  

commit   : 4b011cad272e997935eb8d80ab741a40b395fdf5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Sep 2019 12:53:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Sep 2019 12:53:43 +0900    

Author: Justin Pryzby  
Reviewed-by: Tatsuro Yamada  
Discussion: https://postgr.es/m/20190927022051.GC24334@telsasoft.com  
Backpatch-through: 12  

commit   : bb0e3ce8eb074cef7a88c20bfc34f7e0346312b1    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 18 Sep 2019 09:14:26 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 18 Sep 2019 09:14:26 +0530    

The test name and the following test cases suggest the index created  
should be hash index, but it forgot to add 'using hash' in the test case.  
This in itself won't improve code coverage as there were some other tests  
which were covering the corresponding code.  However, it is better if the  
added tests serve their actual purpose.  
  
Reported-by: Paul A Jungwirth  
Author: Paul A Jungwirth  
Reviewed-by: Mahendra Singh  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/CA+renyV=Us-5XfMC25bNp-uWSj39XgHHmGE9Rh2cQKMegSj52g@mail.gmail.com  

commit   : fbfa5664882c9b61428266e6fb0d48b0147c421a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Sep 2019 09:31:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 27 Sep 2019 09:31:20 +0900    

The code was enforcing AccessExclusiveLock for all custom relation  
options, which is incorrect as the APIs allow a custom lock level to be  
set.  
  
While on it, fix a couple of inconsistencies in the tests and the README  
of dummy_index_am.  
  
Oversights in commit 773df88.  
  
Discussion: https://postgr.es/m/20190925234152.GA2115@paquier.xyz  

commit   : 8190164e82ae03bde80864ab0941794a90e70483    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 21:29:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 21:29:14 +0200    

commit   : 6c3ef7482f2bdedc68146a4ffcba4b8b241b91a9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 21:27:34 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 21:27:34 +0200    

commit   : a4a5c0cf9cec3df2d1662a799c539c2cc84aa463    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 16:35:10 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 16:35:10 +0200    

Author: Liudmila Mantrova <l.mantrova@postgrespro.ru>  
Reported-by: Jeff Janes <jeff.janes@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAMkU%3D1wP-SO4KpiLxHJuPezTJCmK%3DJqefLXrr3eXFO7Qku%2BtMg%40mail.gmail.com  

commit   : 49e36e7901c691fd7e80ba56465b649a211290cf    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 10:51:39 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 10:51:39 +0200    

Update the note about why not to use // comments, even though it's now  
technically supported.  
  
The note about variable declarations was dropped here because it's  
addressed more properly later in the chapter.  
  
Discussion: https://www.postgresql.org/message-id/flat/156924954640.1117.6309209869705522549%40wrigleys.postgresql.org  

commit   : a083657896c739909a25190ebd0032c01f6c8109    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 09:44:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Sep 2019 09:44:22 +0200    

Put the description of the SQL/JSON path language after the  
description of the general JSON functions and operators, instead of  
before.  
  
Discussion: https://www.postgresql.org/message-id/16968.1569189812@sss.pgh.pa.us  

commit   : 6e22813b2d6083afa2b5af1612a834b3ffae3389    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 26 Sep 2019 11:53:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 26 Sep 2019 11:53:37 +0900    

This has been introduced by 709d003, that has moved readSegNo, readOff  
and readPageTLI into a new structure called WALOpenSegment initialized  
separately.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20190926.110809.248342687.horikyota.ntt@gmail.com  

commit   : 7881bb14f4b23e8dc8671938cfb3f34117c12d8b    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 26 Sep 2019 02:06:45 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 26 Sep 2019 02:06:45 +0300    

Discussion: https://postgr.es/m/CAPpHfdteFKW6MLpXM4md99m55YAuXs0n9_P2wiTq_EmG09doUA%40mail.gmail.com  

commit   : b81a9c2fc52509025c635fa08ecaec1bad21441b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Sep 2019 17:30:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Sep 2019 17:30:42 -0400    

LIKE INCLUDING DEFAULTS tried to copy the attrdef expression without  
copying the state of the attgenerated column.  This is in fact wrong,  
because GENERATED and DEFAULT expressions are not the same kind of animal;  
one can contain Vars and the other not.  We *must* copy attgenerated  
when we're copying the attrdef expression.  Rearrange the if-tests  
so that the expression is copied only when the correct one of  
INCLUDING DEFAULTS and INCLUDING GENERATED has been specified.  
  
Per private report from Manuel Rigger.  
  
Tom Lane and Peter Eisentraut  

commit   : bffe1bd68457e43925c362d8728ce3b25bdf1c94    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 21:54:14 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 21:54:14 +0300    

This commit implements jsonpath .datetime() method as it's specified in  
SQL/JSON standard.  There are no-argument and single-argument versions of  
this method.  No-argument version selects first of ISO datetime formats  
matching input string.  Single-argument version accepts template string as  
its argument.  
  
Additionally to .datetime() method itself this commit also implements  
comparison ability of resulting date and time values.  There is some difficulty  
because exising jsonb_path_*() functions are immutable, while comparison of  
timezoned and non-timezoned types involves current timezone.  At first, current  
timezone could be changes in session.  Moreover, timezones themselves are not  
immutable and could be updated.  This is why we let existing immutable functions  
throw errors on such non-immutable comparison.  In the same time this commit  
provides jsonb_path_*_tz() functions which are stable and support operations  
involving timezones.  As new functions are added to the system catalog,  
catversion is bumped.  
  
Support of .datetime() method was the only blocker prevents T832 from being  
marked as supported.  sql_features.txt is updated correspondingly.  
  
Extracted from original patch by Nikita Glukhov, Teodor Sigaev, Oleg Bartunov.  
Heavily revised by me.  Comments were adjusted by Liudmila Mantrova.  
  
Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com  
Discussion: https://postgr.es/m/CAPpHfdsZgYEra_PeCLGNoXOWYx6iU-S3wF8aX0ObQUcZU%2B4XTw%40mail.gmail.com  
Author: Alexander Korotkov, Nikita Glukhov, Teodor Sigaev, Oleg Bartunov, Liudmila Mantrova  
Reviewed-by: Anastasia Lubennikova, Peter Eisentraut  

commit   : 6dda292d4df82a9158d1acc93feecf3b84637b59    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 21:53:41 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 21:53:41 +0300    

SQL/JSON standard allows manipulation with datetime values.  So, it appears to  
be convinient to allow datetime values to be represented in JsonbValue struct.  
These datetime values are allowed for temporary representation only.  During  
serialization datetime values are converted into strings.  
  
SQL/JSON requires writing timestamps with timezone in the same timezone offset  
as they were parsed.  This is why we allow storage of timezone offset in  
JsonbValue struct.  For the same reason timezone offset argument is added to  
JsonEncodeDateTime() function.  
  
Extracted from original patch by Nikita Glukhov, Teodor Sigaev, Oleg Bartunov.  
Revised by me.  Comments were adjusted by Liudmila Mantrova.  
  
Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com  
Discussion: https://postgr.es/m/CAPpHfdsZgYEra_PeCLGNoXOWYx6iU-S3wF8aX0ObQUcZU%2B4XTw%40mail.gmail.com  
Author: Nikita Glukhov, Teodor Sigaev, Oleg Bartunov, Alexander Korotkov, Liudmila Mantrova  
Reviewed-by: Anastasia Lubennikova, Peter Eisentraut  

commit   : 5bc450629b31a0b6986e668056d5bd36792412d2    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 21:51:47 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 21:51:47 +0300    

Add support of error suppression in some date and time manipulation functions  
as it's required for jsonpath .datetime() method support.  This commit doesn't  
use PG_TRY()/PG_CATCH() in order to implement that.  Instead, it provides  
internal versions of date and time functions used, which support error  
suppression.  
  
Discussion: https://postgr.es/m/CAPpHfdsZgYEra_PeCLGNoXOWYx6iU-S3wF8aX0ObQUcZU%2B4XTw%40mail.gmail.com  
Author: Alexander Korotkov, Nikita Glukhov  
Reviewed-by: Anastasia Lubennikova, Peter Eisentraut  

commit   : 66c74f8b6e347ba5830bf06468bef8081601c187    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 21:50:55 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 21:50:55 +0300    

This commit adds parse_datetime() function, which implements datetime  
parsing with extended features demanded by upcoming jsonpath .datetime()  
method:  
  
 * Dynamic type identification based on template string,  
 * Support for standard-conforming 'strict' mode,  
 * Timezone offset is returned as separate value.  
  
Extracted from original patch by Nikita Glukhov, Teodor Sigaev, Oleg Bartunov.  
Revised by me.  
  
Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com  
Discussion: https://postgr.es/m/CAPpHfdsZgYEra_PeCLGNoXOWYx6iU-S3wF8aX0ObQUcZU%2B4XTw%40mail.gmail.com  
Author: Nikita Glukhov, Teodor Sigaev, Oleg Bartunov, Alexander Korotkov  
Reviewed-by: Anastasia Lubennikova, Peter Eisentraut  

commit   : 1a950f37d0a283f2a76bec63c05530ed6eb16de1    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 21:44:48 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 21:44:48 +0300    

SQL Standard 2016 defines rules for handling separators in datetime template  
strings, which are different to to_date()/to_timestamp() rules.  Standard  
allows only small set of separators and requires strict matching for them.  
  
Standard applies to jsonpath .datetime() method and CAST (... FORMAT ...) SQL  
clause.  We're not going to change handling of separators in existing  
to_date()/to_timestamp() functions, because their current behavior is familiar  
for users.  Standard behavior now available by special flag, which will be used  
in upcoming .datetime() jsonpath method.  
  
Discussion: https://postgr.es/m/CAPpHfdsZgYEra_PeCLGNoXOWYx6iU-S3wF8aX0ObQUcZU%2B4XTw%40mail.gmail.com  
Author: Alexander Korotkov  

commit   : bd29cc1992df9a1b786ca36c05e8f590d3795d10    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Sep 2019 16:17:19 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Sep 2019 16:17:19 -0300    

Forgot to add the file in the previous commit.  

commit   : 773df883e8f7543958d0d719c025b5f47c5a67f0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Sep 2019 15:56:52 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Sep 2019 15:56:52 -0300    

All our current in core relation options of type string (not many,  
admittedly) behave in reality like enums.  But after seeing an  
implementation for enum reloptions, it's clear that strings are messier,  
so introduce the new reloption type.  Switch all string options to be  
enums instead.  
  
Fortunately we have a recently introduced test module for reloptions, so  
we don't lose coverage of string reloptions, which may still be used by  
third-party modules.  
  
Authors: Nikolay Shaplov, Álvaro Herrera  
Reviewed-by: Nikita Glukhov, Aleksandr Parfenov  
Discussion: https://postgr.es/m/43332102.S2V5pIjXRx@x200m  

commit   : caba97a9d9f4d4fa2531985fd12d3cd823da06f3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Sep 2019 14:35:24 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Sep 2019 14:35:24 -0300    

... into a new file, fe_utils/recovery_gen.c.  
  
This can later be used by pg_rewind.  
  
Authors: Paul Guo, Jimmy Yih, Ashwin Agrawal.  A few tweaks by Álvaro Herrera  
Reviewed-by: Michaël Paquier  
Discussion: https://postgr.es/m/CAEET0ZEffUkXc48pg2iqARQgGRYDiiVxDu+yYek_bTwJF+q=Uw@mail.gmail.com  

commit   : f5daf7f3266ff5a92f1bf8d386bd5ac3d7d042d6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 13:44:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 13:44:30 +0900    

Append node has been removed in v12 when there would be only one subnode  
under it.  
  
Author: Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqHhS62w8zUFXF4NBjvMboCXYnD-jWoWp-tfo2aHvP3Gxg@mail.gmail.com  
Backpatch-through: 12  

commit   : e0afac124ec7026a49909436ebcfc2bd999852a8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 12:48:26 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 12:48:26 +0900    

Several buildfarm members (crake, loach and spurfowl) are complaining  
about two queries looking up at pg_class.reloptions which trigger the  
validation routines for string reloptions with default values.  This  
commit limits the routines to be triggered only when building an index  
with all custom options set in CREATE INDEX, which is sufficient for the  
coverage.  
  
Introduced by 640c198.  

commit   : 640c19869f8c4b5c34d3982b5e1cd40e62abbb85    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 12:11:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 12:11:12 +0900    

This includes more tests dedicated to relation options, bringing the  
coverage of this code close to 100%, and the module can be used for  
other purposes, like a base template for an index AM implementation.  
  
Author: Nikolay Sharplov, Michael Paquier  
Reviewed-by: Álvaro Herrera, Dent John  
Discussion: https://postgr.es/m/17071942.m9zZutALE6@x200m  

commit   : 69f94108079d70093b59096a3ae0ad82c842b4c0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 10:13:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 10:13:52 +0900    

Relation options can define a lock mode other than AccessExclusiveMode  
since 47167b7, but modules defining custom relation options did not  
really have a way to enforce that.  Correct that by extending the  
current API set so as modules can define a custom lock mode.  
  
Author: Michael Paquier  
Reviewed-by: Kuntal Ghosh  
Discussion: https://postgr.es/m/20190920013831.GD1844@paquier.xyz  

commit   : 736b84eede6cfdadf1114cf5a0e950d7f4986d82    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 10:07:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 10:07:23 +0900    

In-core relation options can use a custom lock mode since 47167b7, that  
has lowered the lock available for some autovacuum parameters.  However  
it forgot to consider custom relation options.  This causes failures  
with ALTER TABLE SET when changing a custom relation option, as its lock  
is not defined.  The existing APIs to define a custom reloption does not  
allow to define a custom lock mode, so enforce its initialization to  
AccessExclusiveMode which should be safe enough in all cases.  An  
upcoming patch will extend the existing APIs to allow a custom lock mode  
to be defined.  
  
The problem can be reproduced with bloom indexes, so add a test there.  
  
Reported-by: Nikolay Sharplov  
Analyzed-by: Thomas Munro, Michael Paquier  
Author: Michael Paquier  
Reviewed-by: Kuntal Ghosh  
Discussion: https://postgr.es/m/20190920013831.GD1844@paquier.xyz  
Backpatch-through: 9.6  

commit   : 90c0987258264de07780f0329db2fce83098fba8    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 01:47:36 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 25 Sep 2019 01:47:36 +0300    

Our item contains only so->numberOfNonNullOrderBys of distances.  Reflect that  
in the loop upper bound.  
  
Discussion: https://postgr.es/m/53536807-784c-e029-6e92-6da802ab8d60%40postgrespro.ru  
Author: Nikita Glukhov  
Backpatch-through: 12  

commit   : 709d003fbd98b975a4fbcb4c5750fa6efaf9ad87    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 24 Sep 2019 16:08:31 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 24 Sep 2019 16:08:31 -0300    

The state-tracking of WAL reading in various places was pretty messy,  
mostly because the ancient physical-replication WAL reading code wasn't  
using the XLogReader abstraction.  This led to some untidy code.  Make  
it prettier by creating two additional supporting structs,  
WALSegmentContext and WALOpenSegment which keep track of WAL-reading  
state.  This makes code cleaner, as well as supports more future  
cleanup.  
  
Author: Antonin Houska  
Reviewed-by: Álvaro Herrera and (older versions) Robert Haas  
Discussion: https://postgr.es/m/14984.1554998742@spoje.net  

commit   : a9ae99d0190960ce2d3dd3e5f10e7f4adc3cf203    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Sep 2019 12:11:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Sep 2019 12:11:32 -0400    

Fix an oversight in commit 7266d0997: as it stood, the code failed  
when a function-in-FROM returns composite and can be simplified  
to a composite constant.  
  
For the moment, just test for composite result and abandon pullup  
if we see one.  To make it actually work, we'd have to decompose  
the composite constant into per-column constants; which is surely  
do-able, but I'm not convinced it's worth the code space.  
  
Per report from Raúl Marín Rodríguez.  
  
Discussion: https://postgr.es/m/CAM6_UM4isP+buRA5sWodO_MUEgutms-KDfnkwGmryc5DGj9XuQ@mail.gmail.com  

commit   : 6d05086c0a79e50d8e91ed953626ec7280cd2481    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Sep 2019 17:31:26 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Sep 2019 17:31:26 +0900    

When a relation is truncated, shared_buffers needs to be scanned  
so that any buffers for the relation forks are invalidated in it.  
Previously, shared_buffers was scanned for each relation forks, i.e.,  
MAIN, FSM and VM, when VACUUM truncated off any empty pages  
at the end of relation or TRUNCATE truncated the relation in place.  
Since shared_buffers needed to be scanned multiple times,  
it could take a long time to finish those commands especially  
when shared_buffers was large.  
  
This commit changes the logic so that shared_buffers is scanned only  
one time for those three relation forks.  
  
Author: Kirk Jamison  
Reviewed-by: Masahiko Sawada, Thomas Munro, Alvaro Herrera, Takayuki Tsunakawa and Fujii Masao  
Discussion: https://postgr.es/m/D09B13F772D2274BB348A310EE3027C64E2067@g01jpexmbkw24  

commit   : 2e5c83acbb7b3916037b3e3a2f81ced10d413a3e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Sep 2019 10:00:56 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Sep 2019 10:00:56 +0200    

This was working around a bug in ccache that was fixed in ccache  
3.2.2 (released 2015-05-10).  (Users of older ccache versions can  
continue to set CCACHE_DISABLE themselves.)  
  
Discussion: https://www.postgresql.org/message-id/20190530191130.GA24528@alvherre.pgsql  

commit   : 30d13796582fe13df0cbea1a8605d926a454d32f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Sep 2019 15:28:13 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Sep 2019 15:28:13 -0700    

This appears to have been an oversight in b8d7f053c5c2. As it's  
effectively harmless, though confusing, only fix in master.  
  
Author: Andres Freund  

commit   : d6e612f837e235db0411e8b67558c9a6b3e9f41f    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 23 Sep 2019 13:45:23 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 23 Sep 2019 13:45:23 -0700    

Allow clients to require channel binding to enhance security against  
untrusted servers.  
  
Author: Jeff Davis  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel%40j-davis.com  

commit   : 13cd97e6c8c9679a9b2384c22a4f0333b1a5cc55    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Sep 2019 12:37:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Sep 2019 12:37:04 -0400    

The array <@ and @> operators do not worry about duplicates: if every  
member of array X matches some element of array Y, then X is contained  
in Y, even if several members of X get matched to the same Y member.  
This was not explicitly stated in the docs though, so improve matters.  
  
Discussion: https://postgr.es/m/156614120484.1310.310161642239149585@wrigleys.postgresql.org  

commit   : 887248e97e2da6f602ddf22aaaaf8cb41d0d010d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 23 Sep 2019 13:37:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 23 Sep 2019 13:37:33 +0200    

commit   : 467c1d9107e15a44a0ca3c46f0c7ebeeb7cfa208    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 23 Sep 2019 09:04:20 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 23 Sep 2019 09:04:20 +0200    

The backend also needs to pull in translations from the frontend  
pg_log_*() functions, since some files in src/common/ use those.  

commit   : 5ac0d93600c1a21db1c2a8fa29a253edca38415f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Sep 2019 17:45:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Sep 2019 17:45:59 -0400    

If the bitstring length is not a multiple of 8, we'd shift the  
rightmost bits into the pad space, which must be zeroes --- bit_cmp,  
for one, depends on that.  This'd lead to the result failing to  
compare equal to what it should compare equal to, as reported in  
bug #16013 from Daryl Waycott.  
  
This is, if memory serves, not the first such bug in the bitstring  
functions.  In hopes of making it the last one, do a bit more work  
than minimally necessary to fix the bug:  
  
* Add assertion checks to bit_out() and varbit_out() to complain if  
they are given incorrectly-padded input.  This will improve the  
odds that manual testing of any new patch finds problems.  
  
* Encapsulate the padding-related logic in macros to make it  
easier to use.  
  
Also, remove unnecessary padding logic from bit_or() and bitxor().  
Somebody had already noted that we need not re-pad the result of  
bit_and() since the inputs are required to be the same length,  
but failed to extrapolate that to the other two.  
  
Also, move a comment block that once was near the head of varbit.c  
(but people kept putting other stuff in front of it), to put it in  
the header block.  
  
Note for the release notes: if anyone has inconsistent data as a  
result of saving the output of bitshiftright() in a table, it's  
possible to fix it with something like  
UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol);  
  
This has been broken since day one, so back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/16013-c2765b6996aacae9@postgresql.org  

commit   : 0a2f894c3c88e4693d7cd36cba1b136474c7ff89    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Sep 2019 14:21:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Sep 2019 14:21:07 -0400    

The code used the destination slot's natts where it intended to  
use the source slot's natts.  Adding an Assert shows that there  
is no case in "make check-world" where these counts are different,  
so maybe this is a harmless bug, but it's still a bug.  
  
Takayuki Tsunakawa  
  
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1FD34C0E@G01JPEXMBYT05  

commit   : 51004c7172b5c35afac050f4d5849839a06e8d3b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Sep 2019 11:46:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Sep 2019 11:46:29 -0400    

Move the responsibility for advancing the NOTIFY queue tail pointer  
from the listener(s) to the notification sender, and only have the  
sender do it once every few queue pages, rather than after every batch  
of notifications as at present.  This reduces the number of times we  
execute asyncQueueAdvanceTail, and reduces contention when there are  
multiple listeners (since that function requires exclusive lock).  
This change relies on the observation that we don't really need the tail  
pointer to be exactly up-to-date.  It's certainly not necessary to  
attempt to release disk space more often than once per SLRU segment.  
The only other usage of the tail pointer is that an incoming listener,  
if it's the only listener in its database, will need to scan the queue  
forward from the tail; but that's surely a less performance-critical  
path than routine sending and receiving of notifies.  We compromise by  
advancing the tail pointer after every 4 pages of output, so that it  
shouldn't get more than a few pages behind.  
  
Also, when sending signals to other backends after adding notify  
message(s) to the queue, recognize that only backends in our own  
database are going to care about those messages, so only such  
backends really need to be awakened promptly.  Backends in other  
databases should get kicked if they're well behind on reading the  
queue, else they'll hold back the global tail pointer; but wakening  
them for every single message is pointless.  This change can  
substantially reduce signal traffic if listeners are spread among  
many databases.  It won't help for the common case of only a single  
active database, but the extra check costs very little.  
  
Martijn van Oosterhout, with some adjustments by me  
  
Discussion: https://postgr.es/m/CADWG95vtRBFDdrx1JdT1_9nhOFw48KaeTev6F_LtDQAFVpSPhA@mail.gmail.com  
Discussion: https://postgr.es/m/CADWG95uFj8rLM52Er80JnhRsTbb_AqPP1ANHS8XQRGbqLrU+jA@mail.gmail.com  

commit   : 72c48c3fc31e3be090b1f70eb6d8222634ba4bde    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 21 Sep 2019 23:22:15 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 21 Sep 2019 23:22:15 +0200    

part of revert "Add DECLARE STATEMENT support to ECPG."  

commit   : c160b8928c77cb52f52d7509465b6c7d8026bd27    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Sep 2019 16:56:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Sep 2019 16:56:30 -0400    

Since we introduced the idea of leakproof functions, texteq and textne  
were marked leakproof but their sibling text comparison functions were  
not.  This inconsistency seemed justified because texteq/textne just  
relied on memcmp() and so could easily be seen to be leakproof, while  
the other comparison functions are far more complex and indeed can  
throw input-dependent errors.  
  
However, that argument crashed and burned with the addition of  
nondeterministic collations, because now texteq/textne may invoke  
the exact same varstr_cmp() infrastructure as the rest.  It makes no  
sense whatever to give them different leakproofness markings.  
  
After a certain amount of angst we've concluded that it's all right  
to consider varstr_cmp() to be leakproof, mostly because the other  
choice would be disastrous for performance of many queries where  
leakproofness matters.  The input-dependent errors should only be  
reachable for corrupt input data, or so we hope anyway; certainly,  
if they are reachable in practice, we've got problems with requirements  
as basic as maintaining a btree index on a text column.  
  
Hence, run around to all the SQL functions that derive from varstr_cmp()  
and mark them leakproof.  This should result in a useful gain in  
flexibility/performance for queries in which non-leakproofness degrades  
the efficiency of the query plan.  
  
Back-patch to v12 where nondeterministic collations were added.  
While this isn't an essential bug fix given the determination  
that varstr_cmp() is leakproof, we might as well apply it now that  
we've been forced into a post-beta4 catversion bump.  
  
Discussion: https://postgr.es/m/31481.1568303470@sss.pgh.pa.us  

commit   : 2810396312664bdb941e549df7dfa75218d73a1c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Sep 2019 16:29:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Sep 2019 16:29:17 -0400    

text_pattern_ops and its siblings can't be used with nondeterministic  
collations, because they use the text_eq operator which will not behave  
as bitwise equality if applied with a nondeterministic collation.  The  
initial implementation of that restriction was to insert a run-time test  
in the related comparison functions, but that is inefficient, may throw  
misleading errors, and will throw errors in some cases that would work.  
It seems sufficient to just prevent the combination during CREATE INDEX,  
so do that instead.  
  
Lacking any better way to identify the opclasses involved, we need to  
hard-wire tests for them, which requires hand-assigned values for their  
OIDs, which forces a catversion bump because they previously had OIDs  
that would be assigned automatically.  That's slightly annoying in the  
v12 branch, but fortunately we're not at rc1 yet, so just do it.  
  
Back-patch to v12 where nondeterministic collations were added.  
  
In passing, run make reformat-dat-files, which found some unrelated  
whitespace issues (slightly different ones in HEAD and v12).  
  
Peter Eisentraut, with small corrections by me  
  
Discussion: https://postgr.es/m/22566.1568675619@sss.pgh.pa.us  

commit   : df4fbcd8990e025d6701d0993f401d315cb619a2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Sep 2019 19:53:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Sep 2019 19:53:33 -0400    

DST law changes in Fiji and Norfolk Island.  Historical corrections  
for Alberta, Austria, Belgium, British Columbia, Cambodia, Hong Kong,  
Indiana (Perry County), Kaliningrad, Kentucky, Michigan, Norfolk  
Island, South Korea, and Turkey.  

commit   : 1a2983231d9080bfa06cfbf38d5415b5d71eea91    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Sep 2019 20:18:11 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Sep 2019 20:18:11 -0300    

The new function stashes its output value in a JsonbValue that can be  
passed in by the caller, which enables some of them to pass  
stack-allocated structs -- saving palloc cycles.  It also allows some  
callers that know they are handling a jsonb object to use this new jsonb  
object-specific API, instead of going through generic container  
findJsonbValueFromContainer.  
  
Author: Nikita Glukhov  
Discussion: https://postgr.es/m/7c417f90-f95f-247e-ba63-d95e39c0ad14@postgrespro.ru  

commit   : dbb9aeda9959d8a8f463e841b69dfa04afc67a3a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Sep 2019 19:18:24 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Sep 2019 19:18:24 -0300    

Instead of creating an iterator object at each step down the JSONB  
object/array, we can just just examine its object/array flags, which is  
faster.  Also, use the recently introduced JsonbValueAsText instead of  
open-coding the same thing, for code simplicity.  
  
Author: Nikita Glukhov  
Discussion: https://postgr.es/m/7c417f90-f95f-247e-ba63-d95e39c0ad14@postgrespro.ru  

commit   : abb014a63106653f2872a3b1662a79ab80d4dcbb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Sep 2019 18:34:31 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Sep 2019 18:34:31 -0300    

jsonb_object_field_text and jsonb_array_element_text both contained  
identical copies of this code, so extract that into new routine  
JsonbValueAsText.  This can also be used in other places, to measurable  
performance benefit: the jsonb_each() and jsonb_array_elements()  
functions can use it for outputting text forms instead of their less  
efficient current implementation (because we no longer need to build  
intermediate a jsonb representation of each value).  
  
Author: Nikita Glukhov  
Discussion: https://postgr.es/m/7c417f90-f95f-247e-ba63-d95e39c0ad14@postgrespro.ru  

commit   : e56cad84d542a8cc2056390a9c651118cfa6c89c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Sep 2019 14:22:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Sep 2019 14:22:58 -0400    

Although the SQL/JSON tech report makes reference to ECMAScript which  
allows both single- and double-quoted strings, all the rest of the  
report speaks only of double-quoted string literals in jsonpaths.  
That's more compatible with JSON itself; moreover single-quoted strings  
are hard to use inside a jsonpath that is itself a single-quoted SQL  
literal.  So guess that the intent is to allow only double-quoted  
literals, and remove lexer support for single-quoted literals.  
It'll be less painful to add this again later if we're wrong, than to  
remove a shipped feature.  
  
Also, adjust the lexer so that unrecognized backslash sequences are  
treated as just meaning the escaped character, not as errors.  This  
change has much better support in the standards, as JSON, JavaScript  
and ECMAScript all make it plain that that's what's supposed to  
happen.  
  
Back-patch to v12.  
  
Discussion: https://postgr.es/m/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg@mail.gmail.com  

commit   : 96b6c82c9dd4a6a91c7e54bf42d36da111959ec6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Sep 2019 12:47:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 20 Sep 2019 12:47:21 -0400    

This reverts commit bd7c95f0c1a38becffceb3ea7234d57167f6d4bf,  
along with assorted follow-on fixes.  There are some questions  
about the definition and implementation of that statement, and  
we don't have time to resolve them before v13 release.  Rather  
than ship the feature and then have backwards-compatibility  
concerns constraining any redesign, let's remove it for now  
and try again later.  
  
Discussion: https://postgr.es/m/TY2PR01MB2443EC8286995378AEB7D9F8F5B10@TY2PR01MB2443.jpnprd01.prod.outlook.com  

commit   : d1b0007639a1cefb5dcecf44999a4461f4c34089    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Sep 2019 12:53:58 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Sep 2019 12:53:58 -0300    

I (Álvaro) broke that in commit 6212276e4343 -- forgot to set the  
necessary flag.  Repair.  
  
Author: Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqEaM2tV5awKhP1vSbgjQe_uXVU15Oi4sTgwgempwMiT8g@mail.gmail.com  

commit   : 5033e9580869fec514d787dc9d3b0b63cce0bcfb    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Sep 2019 15:31:12 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Sep 2019 15:31:12 +0300    

f5f084fc3e has removed test because of its instability.  This commit provides  
alternative test with determined ordering using extra ORDER BY expression.  
  
Backpatch-through: 12  

commit   : c53e40a132dca2ea8db73ce705a9019197ec338b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 20 Sep 2019 07:38:06 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 20 Sep 2019 07:38:06 +0530    

Reported-By: Kuntal Ghosh (off-list)  
Backpatch-through: 9.4, like 82fa3ff8672  

commit   : f5f084fc3ec516545d826e1e9b7ab4aabf612698    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Sep 2019 01:46:49 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Sep 2019 01:46:49 +0300    

6cae9d2c10 introduced test for NULL values in KNN SP-GiST.  This test relies on  
undetermined ordering showing different results on various platforms.  This  
commit removes that test.  Will be replaced with better test later.  
  
Discussion: https://postgr.es/m/6d51305e1159241cabee132f7efc7eff%40xs4all.nl  
Backpatch-through: 12  

commit   : 8c8a267201bebb0edeaab2a76b7d3bcc9739924f    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Sep 2019 01:10:56 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 20 Sep 2019 01:10:56 +0300    

6cae9d2c10 has added an error in freeing old values in  
index_store_float8_orderby_distances() function.  It looks for old value in  
scan->xs_orderbynulls[i] after setting a new value there.  
This commit fixes that.  Also it removes short-circuit in handling  
distances == NULL situation.  Now distances == NULL will be treated the same  
way as array with all null distances.  That is, previous values will be freed  
if any.  
  
Reported-by: Tom Lane, Nikita Glukhov  
Discussion: https://postgr.es/m/CAPpHfdu2wcoAVAm3Ek66rP%3Duo_C-D84%2B%2Buf1VEcbyi_caBXWCA%40mail.gmail.com  
Discussion: https://postgr.es/m/426580d3-a668-b9d1-7b8e-f74d1a6524e0%40postgrespro.ru  
Backpatch-through: 12  

commit   : 6cae9d2c10e151f741e7bc64a8b70bb2615c367c    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 19 Sep 2019 21:30:19 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 19 Sep 2019 21:30:19 +0300    

This commit improves subject in two ways:  
  
 * It removes ugliness of 02f90879e7, which stores distance values and null  
   flags in two separate arrays after GISTSearchItem struct.  Instead we pack  
   both distance value and null flag in IndexOrderByDistance struct.  Alignment  
   overhead should be negligible, because we typically deal with at most few  
   "col op const" expressions in ORDER BY clause.  
 * It fixes handling of "col op NULL" expression in KNN-SP-GiST.  Now, these  
   expression are not passed to support functions, which can't deal with them.  
   Instead, NULL result is implicitly assumed.  It future we may decide to  
   teach support functions to deal with NULL arguments, but current solution is  
   bugfix suitable for backpatch.  
  
Reported-by: Nikita Glukhov  
Discussion: https://postgr.es/m/826f57ee-afc7-8977-c44c-6111d18b02ec%40postgrespro.ru  
Author: Nikita Glukhov  
Reviewed-by: Alexander Korotkov  
Backpatch-through: 9.4  

commit   : 0a97edb12ec44f8d2d8828cbca6dd7639408ac88    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Sep 2019 11:22:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 19 Sep 2019 11:22:21 -0400    

Provide some documentation about the differences between XQuery  
regular expressions and those supported by Spencer's regex engine.  
Since SQL now exposes XQuery regexps with the LIKE_REGEX operator,  
I made this a standalone section designed to help somebody who  
has to translate a LIKE_REGEX query to Postgres.  (Eventually we might  
extend Spencer's engine to allow precise implementation of XQuery,  
but not today.)  
  
Reference that in the jsonpath docs, provide definitions of the  
XQuery flag letters, and add a description of the JavaScript-inspired  
string literal syntax used within jsonpath.  Also point out explicitly  
that backslashes used within like_regex patterns will need to be doubled.  
  
This also syncs the docs with the decision implemented in commit  
d5b90cd64 to desupport XQuery's 'x' flag for now.  
  
Jonathan Katz and Tom Lane  
  
Discussion: https://postgr.es/m/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg@mail.gmail.com  

commit   : e1c8743e6ccd262df84fa2d80bf21d72115ac0d6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Sep 2019 15:03:23 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Sep 2019 15:03:23 +0200    

Make the error messages around GSSAPI encryption a bit clearer.  Tweak  
some messages to avoid plural problems.  
  
Also make a code change for clarity.  Using "conf" for "confidential"  
is quite confusing.  Using "conf_state" is perhaps not much better but  
that's what the GSSAPI documentation uses, so there is at least some  
hope of understanding it.  

commit   : 70377cf4c6bf4eb4b2d1209752a300d5f3571145    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Sep 2019 14:40:09 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Sep 2019 14:40:09 +0530    

Reported-by: Filip Rembiałkowski  
Author: Filip Rembiałkowski  
Backpatch-through: 12, where it was introduced  
Discussion: https://postgr.es/m/CAP_rwwmSNy1=_82rwGe3-X4PjWqPSFXtzNf43DCtGzD7SazdXA@mail.gmail.com  

commit   : 74f2a8aa27cb7bd2dbab3ed58e6b5c239a6b4a31    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Sep 2019 09:02:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 19 Sep 2019 09:02:41 +0200    

The major version of ecpglib was changed in  
bd7c95f0c1a38becffceb3ea7234d57167f6d4bf, apparently without  
justification.  Revert this, since nothing has changed in this library  
except some added functions.  
  
Discussion: https://www.postgresql.org/message-id/flat/48ee4c56-e1df-b39d-2cad-c7d80b120eb5%402ndquadrant.com  

commit   : bec847d9e946ab6e05a2884e524c3cc8c52feebb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Sep 2019 13:18:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Sep 2019 13:18:53 +0900    

This fixes an inconsistency with this parameter name not listed in the  
command synopsis, and connection_name is the parameter name more  
commonly used in the docs for ECPG commands.  
  
Reported-by: Yusuke Egashita  
Discussion: https://postgr.es/m/156870956796.1259.11456186889345212399@wrigleys.postgresql.org  
Backpatch-through: 9.4  

commit   : 82fa3ff867219a212a467317a77011df29cb5903    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Sep 2019 08:02:12 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Sep 2019 08:02:12 +0530    

It's important users be able to know (without looking at the source code)  
that running DDL or DDL-like commands can interrupt autovacuum which can  
lead to a lot of dead tuples and hence slower database operations.  
  
Reported-by: James Coleman  
Author: James Coleman  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/CAAaqYe-XYyNwML1=f=gnd0qWg46PnvD=BDrCZ5-L94B887XVxQ@mail.gmail.com  

commit   : 58b4cb30a5bf52d71a4d0e5f9f7e1da3e64f67cc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Sep 2019 11:01:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 19 Sep 2019 11:01:52 +0900    

After more discussion, the new function added by ddbd5d8 could have been  
designed in a better way.  Based on an idea from Álvaro, instead of  
returning one column which includes both the raw and combined flags, use  
two columns, with one for the raw flags and one for the combined flags.  
  
This also takes care of some issues with HEAP_LOCKED_UPGRADED and  
HEAP_XMAX_IS_LOCKED_ONLY which are not really combined flags as they  
depend on conditions defined by other raw bits, as mentioned by Amit.  
  
While on it, fix an extra issue with combined flags.  A combined flag  
was returned if at least one of its bits was set, but all its bits need  
to be set to include it in the result.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera, Amit Kapila  
Discussion: https://postgr.es/m/20190913114950.GA3824@alvherre.pgsql  

commit   : 59354ccef5d7671bb11982628d6ddd6fffbad2c4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Sep 2019 16:50:20 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Sep 2019 16:50:20 -0300    

Fixup for previous commit: actually, the complete source for  
testlibpq3.c appears in SGML docs, so we need to patch that also.  
Go figure.  

commit   : 9b8e99e905097e104c295bff1c47b6c0d652efdb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Sep 2019 16:29:55 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Sep 2019 16:29:55 -0300    

The sample output assumes non-standard-conforming interpretation of  
backslashes in input literals, so the actual output didn't match.  
  
Noticed while perusing another patch that touches this file.  
  
Evidently this code is seldom checked, so I'm not going to bother  
backpatching this fix.  

commit   : 32200c19dd8f084956d90e3c2cb5c2b8a8b90dfa    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Sep 2019 11:24:12 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Sep 2019 11:24:12 -0300    

Lack of quotes results in failure to run the test under older Solaris.  
  
Author: Marina Polyakova, Victor Wagner  
Discussion: https://postgr.es/m/feba89f89e8925b3535cb7d72b9e05e1@postgrespro.ru  

commit   : 33a94bae605edf3ceda6751916f0b1af3e88630a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 18 Sep 2019 21:05:33 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 18 Sep 2019 21:05:33 +0900    

smgrdounlinkfork() became dead code as the result of commit ece01aae47,  
but it was left in place just in case we want it someday. However no users  
have appeared in 7 years, so it's time to remove this unused function.  
  
Author: Kirk Jamison  
Discussion: https://www.postgresql.org/message-id/D09B13F772D2274BB348A310EE3027C64E2067@g01jpexmbkw24  

commit   : f9f2fda79658cc8f898c6fa7ba6da9a1f394cdee    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 18 Sep 2019 18:50:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 18 Sep 2019 18:50:00 +0900    

1. Commit 7086be6e3 should have documented the limitation that the direct  
   modification is disabled when WCO constraints are present, but didn't,  
   which is definitely my fault.  Update the documentation (Postgres 9.6  
   onwards).  
  
2. Commit fc22b6623 should have documented the limitation that the direct  
   modification is disabled when generated columns are defined, but  
   didn't.  Update the documentation (Postgres 12 onwards).  
  
Author: Etsuro Fujita  
Discussion: https://postgr.es/m/CAPmGK14AYCPunLb6TRz1CQsW5Le01Z2ox8LSOKH0P-cOVDcQRA%40mail.gmail.com  

commit   : 48770492c3b796b251112fa9b74534f087c9f471    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 17 Sep 2019 22:03:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 17 Sep 2019 22:03:00 +0200    

Author: Mark G <markg735@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/CAEeOP_YFVeFjq4zDZLDQbLSRFxBiTpwBQHxCNgGd%2Bp5VztTXyQ%40mail.gmail.com  

commit   : d5b90cd648558a4fd714b1396176ddb028ec28fc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Sep 2019 15:39:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 17 Sep 2019 15:39:51 -0400    

The SQL spec defers to XQuery to define what the option flags are  
for LIKE_REGEX patterns.  XQuery says that:  
* 's' allows the dot character to match newlines, which by  
  default it will not;  
* 'm' allows ^ and $ to match at newlines, not only at the  
  start/end of the whole string.  
Thus, these are *not* inverses as they are for the similarly-named  
POSIX options, and neither one corresponds to the POSIX 'n' option.  
Fortunately, Spencer's library does expose these two behaviors as  
separately twiddlable flags, so we just have to fix the mapping from  
JSP flag bits to REG flag bits.  I also chose to rename the symbol  
for 's' to DOTALL, to make it clearer that it's not the inverse  
of MLINE.  
  
Also, XQuery says that if the 'q' flag "is used together with the m, s,  
or x flag, that flag has no effect".  I read this as saying that 'q'  
overrides the other flags; whoever wrote our code seems to have read  
it backwards.  
  
Lastly, while XQuery's 'x' flag is related to what Spencer's code  
does for REG_EXPANDED, it's not the same or a subset.  It seems best  
to treat XQuery's 'x' as unimplemented for now.  Maybe later we can  
expand our regex code to offer 'x'-style parsing as a separate option.  
  
While at it, refactor the jsonpath code so that (a) there's only  
one copy of the flag transformation logic not two, and (b) the  
processing of flags is independent of the order in which the flags  
are written.  
  
We need some documentation updates to go with this, but I'll  
tackle that separately.  
  
Back-patch to v12 where this code originated.  
  
Discussion: https://postgr.es/m/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg@mail.gmail.com  
Reference: https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/#flags  

commit   : a25221f53c7960e00484c801f10d2e989b75a7f2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 17 Sep 2019 11:32:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 17 Sep 2019 11:32:33 +0200    

We believe that the issues that this was working around have been  
fixed in MinGW more than 5 years ago, so this isn't necessary anymore.  
  
Discussion: https://www.postgresql.org/message-id/flat/20190719050830.GK1859%40paquier.xyz  

commit   : b64b857f50fb51da1588c54a56f8fc1c0d491058    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 16 Sep 2019 21:02:32 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 16 Sep 2019 21:02:32 +0300    

SQL Standard 2016 defines SSSSS format pattern for seconds past midnight in  
jsonpath .datetime() method and CAST (... FORMAT ...) SQL clause.  In our  
datetime parsing engine we currently support it with SSSS name.  
  
This commit adds SSSSS as an alias for SSSS.  Alias is added in favor of  
upcoming jsonpath .datetime() method.  But it's also supported in to_date()/  
to_timestamp() as positive side effect.  
  
Discussion: https://postgr.es/m/CAPpHfdsZgYEra_PeCLGNoXOWYx6iU-S3wF8aX0ObQUcZU%2B4XTw%40mail.gmail.com  
Author: Nikita Glukhov, Alexander Korotkov  
Reviewed-by: Anastasia Lubennikova, Peter Eisentraut  

commit   : d589f94460c24d9b7ac21887d031818d6e3f354d    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 16 Sep 2019 21:02:14 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 16 Sep 2019 21:02:14 +0300    

SQL Standard 2016 defines FF1-FF9 format patters for fractions of seconds in  
jsonpath .datetime() method and CAST (... FORMAT ...) SQL clause.  Parsing  
engine of upcoming .datetime() method will be shared with to_date()/  
to_timestamp().  
  
This patch implements FF1-FF6 format patterns for upcoming jsonpath .datetime()  
method.  to_date()/to_timestamp() functions will also get support of this  
format patterns as positive side effect.  FF7-FF9 are not supported due to  
lack of precision in our internal timestamp representation.  
  
Extracted from original patch by Nikita Glukhov, Teodor Sigaev, Oleg Bartunov.  
Heavily revised by me.  
  
Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com  
Discussion: https://postgr.es/m/CAPpHfdsZgYEra_PeCLGNoXOWYx6iU-S3wF8aX0ObQUcZU%2B4XTw%40mail.gmail.com  
Author: Nikita Glukhov, Teodor Sigaev, Oleg Bartunov, Alexander Korotkov  
Reviewed-by: Anastasia Lubennikova, Peter Eisentraut  

commit   : d8122578098d3ff20a9a12d25807e56cecac673c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Sep 2019 11:51:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 15 Sep 2019 11:51:57 -0400    

Noted by Coverity.  Typo in 27cc7cd2b, so back-patch to v12  
as that was.  

commit   : 3d9a3ef5cbfc70bd2802c3f0da3fbc4e5abdf377    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 15 Sep 2019 13:13:59 +0100    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sun, 15 Sep 2019 13:13:59 +0100    

Commit d7f8d26d9 added new tests to the stats_ext regression test that  
included creating a view in the public schema, without realising that  
the stats_ext test runs in the same parallel group as the rules test,  
which makes doing that unsafe.  
  
This led to intermittent failures of the rules test on the buildfarm,  
although I wasn't able to reproduce that locally. Fix by creating the  
view in a different schema.  
  
Tomas Vondra and Dean Rasheed, report and diagnosis by Thomas Munro.  
  
Discussion: https://postgr.es/m/CA+hUKGKX9hFZrYA7rQzAMRE07L4hziCc-nO_b3taJpiuKyLLxg@mail.gmail.com  

commit   : 87e9fae0696d9e3ff70a1438775ad9f786b854a5    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Sep 2019 19:38:41 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 14 Sep 2019 19:38:41 -0700    

This reverts commit e7ff59686eacf5021fb84be921116986c3828d8a.  It  
defined pg_atomic_fetch_add_u32_impl() without defining  
pg_atomic_compare_exchange_u32_impl(), which is incompatible with  
src/include/port/atomics/fallback.h.  Per buildfarm member prairiedog.  
  
Discussion: https://postgr.es/m/7517.1568470247@sss.pgh.pa.us  

commit   : e7ff59686eacf5021fb84be921116986c3828d8a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Sep 2019 19:34:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Sep 2019 19:34:30 -0700    

This is more like how we handle s_lock.h and arch-x86.h.  This does not  
materially affect code generation for gcc 7.2.0 or xlc 13.1.3.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/20190831071157.GA3251746@rfd.leadboat.com  

commit   : dd50f1a43290bb3c67e24e808d4d8656e9532c9a    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Sep 2019 19:34:06 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Sep 2019 19:34:06 -0700    

PostgreSQL has been unusable when built with xlc 13 and newer, which are  
incompatible with our use of __fetch_and_add().  Back-patch to 9.5,  
which introduced pg_atomic_fetch_add_u32().  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/20190831071157.GA3251746@rfd.leadboat.com  

commit   : f380c5190134a4e928bf30a4ff9fec775cdcc692    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Sep 2019 19:33:30 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Fri, 13 Sep 2019 19:33:30 -0700    

Back-patch to 9.5, which introduced these functions.  
  
Reviewed by Tom Lane.  
  
Discussion: https://postgr.es/m/20190831071157.GA3251746@rfd.leadboat.com  

commit   : b360e0fcd7dcffe3238187209911a6f523057b0c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Sep 2019 16:56:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Sep 2019 16:56:58 -0400    

Add the comments that I griped were missing.  Also re-order tests  
so that parallelism-related tests aren't randomly separated from  
each other.  
  
Discussion: https://postgr.es/m/CAAaqYe9GD__4Crm=ddz+-XXcNhfY_V5gFYdLdmkFNq=2VHO56Q@mail.gmail.com  

commit   : bac2fae05c7737530a6fe8276cd27d210d25c6ac    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Sep 2019 16:36:28 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Sep 2019 16:36:28 -0300    

Most WAL records are ignored in early SnapBuild snapshot build phases.  
But it's critical to process some of them, so that later messages have  
the correct transaction state after the snapshot is completely built; in  
particular, XLOG_XACT_ASSIGNMENT messages are critical in order for  
sub-transactions to be correctly assigned to their parent transactions,  
or at least one assert misbehaves, as reported by Ildar Musin.  
  
Diagnosed-by: Masahiko Sawada  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAONYFtOv+Er1p3WAuwUsy1zsCFrSYvpHLhapC_fMD-zNaRWxYg@mail.gmail.com  

commit   : ce5d04b6463d9f642e30d1f6abf45846e1255be0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Sep 2019 16:26:55 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Sep 2019 16:26:55 -0300    

Lack of parens in the definitions could cause a statement using these  
macros to have unexpected semantics.  In current code no bug is  
apparent, but best to fix the definitions to avoid problems down the  
line.  
  
Reported-by: Tom Lane  
Discussion: https://postgr.es/m/19795.1568400476@sss.pgh.pa.us  

commit   : 6212276e4343f729b0152e81824f850d1a21d57e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Sep 2019 14:51:13 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Sep 2019 14:51:13 -0300    

The progress state was being clobbered once the first index completed  
being rebuilt, causing the final phases of the operation not show  
anything in the progress view.  This was inadvertently broken in  
03f9e5cba0ee, which added progress tracking for REINDEX.  
  
(The reason this bugfix is this small is that I had already noticed this  
problem when writing monitoring for CREATE INDEX, and had already worked  
around it, as can be seen in discussion starting at  
https://postgr.es/m/20190329150218.GA25010@alvherre.pgsql Fixing the  
problem is just a matter of fixing one place touched by the REINDEX  
monitoring.)  
  
Reported by: Álvaro Herrera  
Author: Álvaro Herrera  
Discussion: https://postgr.es/m/20190801184333.GA21369@alvherre.pgsql  

commit   : eb57bd9c1d83a20eaff559a53b2f584dcd0668a8    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 13 Sep 2019 17:21:20 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 13 Sep 2019 17:21:20 +0300    

Discussion: https://postgr.es/m/CAEkD-mDUZrRE%3Dk-FznEg4Ed2VdjpZCyHoyo%2Bp0%2B8KvHqR%3DpNVQ%40mail.gmail.com  
Author: Liudmila Mantrova, Alexander Lakhin  
Reviewed-by: Alexander Korotkov, Alvaro Herrera  
Backpatch-through: 12  

commit   : c30fc9ddd596f7981555318d1c236fc55279cac8    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 13 Sep 2019 17:12:20 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Fri, 13 Sep 2019 17:12:20 +0300    

Besides cosmetic improvements it removes statement that operators necessary  
need to be separated from operands with spaces, which is not really true.  
  
Discussion: https://postgr.es/m/CAEkD-mDUZrRE%3Dk-FznEg4Ed2VdjpZCyHoyo%2Bp0%2B8KvHqR%3DpNVQ%40mail.gmail.com  
Author: Liudmila Mantrova, Alexander Lakhin  
Reviewed-by: Alexander Korotkov, Alvaro Herrera  
Backpatch-through: 12  

commit   : fc16778873d081b07930d642622ee0cf22c3f9b7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 13 Sep 2019 18:16:40 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 13 Sep 2019 18:16:40 +0900    

Author: Shenhao Wang  
Discussion: https://postgr.es/m/63580B24E208E3429D94153A03C68E0901AA8002D5@G08CNEXMBPEKD02.g08.fujitsu.local  

commit   : 3b6b54f178d7539354064727cca9b4ff2eca0fce    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 15:45:08 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 15:45:08 -0700    

Include newitemoff in rmgr desc output for nbtree page split records.  
In passing, correct an obsolete comment that claimed that newitemoff is  
only logged for _L variant nbtree page split WAL records.  
  
Both issues were oversights in commit 2c03216d831, which revamped the  
WAL format.  
  
Author: Peter Geoghegan  
Backpatch: 9.5-, where the WAL format was revamped.  

commit   : 7f1f72c44400e6fef3436b05f1ad0f6bacd03d96    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Sep 2019 18:29:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Sep 2019 18:29:17 -0400    

Since WITH CHECK OPTION was introduced, ExecInitModifyTable has  
initialized WCO expressions with the wrong plan node as parent -- that is,  
it passed its input subplan not the ModifyTable node itself.  Up to now  
we thought this was harmless, but bug #16006 from Vinay Banakar shows it's  
not: if the input node is a SubqueryScan then ExecInitWholeRowVar can get  
confused into doing the wrong thing.  (The fact that ExecInitWholeRowVar  
contains such logic is certainly a horrid kluge that doesn't deserve to  
live, but figuring out another way to do that is a task for some other day.)  
  
Andres had already noticed the wrong-parent mistake and fixed it in commit  
148e632c0, but not being aware of any user-visible consequences, he quite  
reasonably didn't back-patch.  This patch is simply a back-patch of  
148e632c0, plus addition of a test case based on bug #16006.  I also added  
the test case to v12/HEAD, even though the bug is already fixed there.  
  
Back-patch to all supported branches.  9.4 lacks RLS policies so the  
new test case doesn't work there, but I'm pretty sure a test could be  
devised based on using a whole-row Var in a plain WITH CHECK OPTION  
condition.  (I lack the cycles to do so myself, though.)  
  
Andres Freund and Tom Lane  
  
Discussion: https://postgr.es/m/16006-99290d2e4642cbd5@postgresql.org  
Discussion: https://postgr.es/m/20181205225213.hiwa3kgoxeybqcqv@alap3.anarazel.de  

commit   : 614cdeaa8908f69ab0b97b688e9785147575c01f    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 09:59:16 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 09:59:16 -0700    

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

commit   : 1b9becd43ccb7d48243882c021738c60d32c55aa    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 09:51:27 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 09:51:27 -0700    

commit   : bc98e1ea64627183746ecffcb957db147038134e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Sep 2019 10:34:50 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Sep 2019 10:34:50 -0300    

Authored by Tom Lane, after a gripe from James Coleman.  
  
Discussion: https://postgr.es/m/CAAaqYe9GD__4Crm=ddz+-XXcNhfY_V5gFYdLdmkFNq=2VHO56Q@mail.gmail.com  

commit   : 9b3c8f07ff3f7938696723405dc9c7b43dde4252    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 11 Sep 2019 10:25:49 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 11 Sep 2019 10:25:49 +0530    

The example used to explain 'Looping Through Query Results' uses  
pseudo-materialized views.  Replace it with a more up-to-date example  
which does the same thing with actual materialized views, which have  
been available since PostgreSQL 9.3.  
  
In the passing, change '%' as format specifier instead of '%s' as is used  
in other examples in plpgsql.sgml.  
  
Reported-by: Ian Barwick  
Author: Ian Barwick  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.4  
Discussion: https://postgr.es/m/9a70d393-7904-4918-c97c-649f6d114b6a@2ndquadrant.com  

commit   : ddbd5d8731619ad3ab47ce325e8605422297a613    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Sep 2019 15:06:00 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Sep 2019 15:06:00 +0900    

Flags of t_infomask and t_infomask2 for each tuple are already included  
in the information returned by heap_page_items as integers, and we  
lacked a way to make that information human-readable.  
  
Per discussion, the function includes an option which controls if  
combined flags should be decomposed or not.  The default is false, to  
not decompose combined flags.  
  
The module is bumped to version 1.8.  
  
Author: Craig Ringer, Sawada Masahiko  
Reviewed-by: Peter Geoghegan, Robert Haas, Álvaro Herrera, Moon Insung,  
Amit Kapila, Michael Paquier, Tomas Vondra  
Discussion: https://postgr.es/m/CAMsr+YEY7jeaXOb+oX+RhDyOFuTMdmHjGsBxL=igCm03J0go9Q@mail.gmail.com  

commit   : aafe2762b152ffd4cb839d2a01df6cfcc3c6df6c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Sep 2019 10:35:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 12 Sep 2019 10:35:13 +0900    

This adds tests to cover more code paths to ignore backslash commands in  
false branches when using \if|\elif|\else, and improves the coverage of  
\elif.  
  
Author: Fabien Coelho  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1908281618520.28828@lancre  

commit   : 9a86f03b4e8c8f16eca7faebcb4a46330e431102    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Sep 2019 11:43:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Sep 2019 11:43:01 -0400    

This is a second try at what commit 57431a911 tried to do, namely,  
launch the syslogger before we open postmaster sockets so that our  
messages about the sockets end up in the syslogger files.  That  
commit fell foul of a bunch of subtle issues caused by trying to  
launch a postmaster child process before creating shared memory.  
Rather than messing with that interaction, let's postpone opening  
the sockets till after we launch the syslogger.  
  
This would not have been terribly safe before commit 7de19fbc0,  
because we relied on socket opening to detect whether any competing  
postmasters were using the same port number.  But now that we choose  
IPC keys without regard to the port number, there's no interaction  
to worry about.  
  
Also delay creation of the external PID file (if requested) till after  
the sockets are open, since external code could plausibly be relying  
on that ordering of events.  And postpone most of the work of  
RemovePgTempFiles() so that that potentially-slow processing still  
happens after we make the external PID file.  We have to be a bit  
careful about that last though: as noted in the discussion subsequent to  
bug #15804, EXEC_BACKEND builds still have to clear the parameter-file  
temp dir before launching the syslogger.  
  
Patch by me; thanks to Michael Paquier for review/testing.  
  
Discussion: https://postgr.es/m/15804-3721117bf40fb654@postgresql.org  

commit   : 75f46eaee20c38b2a04f569e8a5fed4f63091bd3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 11 Sep 2019 10:15:23 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 11 Sep 2019 10:15:23 -0300    

The previous wording was a bit too terse, too vague on the subject of  
'host' and 'hostaddr' in connection specifications, which has caused  
people to waste time trying to conform to rules because of  
misunderstanding the whole thing; this small change should make things  
clearer.  
  
Author: Robert Haas, stemming from Fabien Coelho's complaints  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1808201323020.13832@lancre  

commit   : 8a0deae8d9b6861265cf4ebf25a9e4385f4c7672    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Sep 2019 15:17:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Sep 2019 15:17:35 +0900    

Procedures are supported since v11 and \dfp can be used since this  
version, but it was not mentioned as a supported option in the  
description of describeFunctions() which handles \df in psql.  
  
Extracted from a larger patch.  
  
Author: Fabien Coelho  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1908281618520.28828@lancre  

commit   : 9d6e1ec5ceed1b7871fc2afd68898f0e876b60b9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Sep 2019 11:07:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 11 Sep 2019 11:07:18 +0900    

Depending on the system used, t/*.pl may not be expanded into a list of  
tests which can be consumed by prove when attempting to run TAP tests on  
a given path.  Fix that by using glob() directly in the script, to make  
sure that a complete list of tests is provided.  This has not proved to  
be an issue with MSVC as the list was properly expanded, but it is on  
Linux with perl's system().  
  
This is extracted from a larger patch.  
  
Author: Tom Lane  
Discussion: https://postgr.es/m/6628.1567958876@sss.pgh.pa.us  
Backpatch-through: 9.4  

commit   : d06215d03b50c264a0f31e335b895ee1b6753e68    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 10 Sep 2019 20:09:27 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 10 Sep 2019 20:09:27 +0200    

When building statistics, we need to decide how many rows to sample and  
how accurate the resulting statistics should be. Until now, it was not  
possible to explicitly define statistics target for extended statistics  
objects, the value was always computed from the per-attribute targets  
with a fallback to the system-wide default statistics target.  
  
That's a bit inconvenient, as it ties together the statistics target set  
for per-column and extended statistics. In some cases it may be useful  
to require larger sample / higher accuracy for extended statics (or the  
other way around), but with this approach that's not possible.  
  
So this commit introduces a new command, allowing to specify statistics  
target for individual extended statistics objects, overriding the value  
derived from per-attribute targets (and the system default).  
  
  ALTER STATISTICS stat_name SET STATISTICS target_value;  
  
When determining statistics target for an extended statistics object we  
first look at this explicitly set value. When this value is -1, we fall  
back to the old formula, looking at the per-attribute targets first and  
then the system default. This means the behavior is backwards compatible  
with older PostgreSQL releases.  
  
Author: Tomas Vondra  
Discussion: https://postgr.es/m/20190618213357.vli3i23vpkset2xd@development  
Reviewed-by: Kirk Jamison, Dean Rasheed  

commit   : bca6e64354a2b8ed56751eb12bbf9429490c0811    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Sep 2019 18:15:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Sep 2019 18:15:17 -0400    

Up to now, async.c scanned its whole array of per-backend state  
whenever it needed to find listening backends.  That's expensive  
if MaxBackends is large, so extend the data structure with list  
links that thread the active entries together.  
  
A downside of this change is that asyncQueueUnregister (unregister  
a listening backend at backend exit) now requires exclusive not shared  
lock, and it can take awhile if there are many other listening  
backends.  We could improve the latter issue by using a doubly- not  
singly-linked list, but it's probably not worth the storage space;  
typical usage patterns for LISTEN/NOTIFY have fairly long-lived  
listeners.  
  
In return for that, Exec_ListenPreCommit (initially register a  
listening backend), SignalBackends, and asyncQueueAdvanceTail  
get significantly faster when MaxBackends is much larger than  
the number of listening backends.  If most of the potential  
backend slots are listening, we don't win, but that's a case  
where the actual interprocess-signal overhead is going to swamp  
these considerations anyway.  
  
Martijn van Oosterhout, hacked a bit more by me  
  
Discussion: https://postgr.es/m/CADWG95vtRBFDdrx1JdT1_9nhOFw48KaeTev6F_LtDQAFVpSPhA@mail.gmail.com  

commit   : 0afc0a7841889c6221fd47430e72f4fe570833f4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Sep 2019 17:56:11 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Sep 2019 17:56:11 -0300    

As originally coded, the script would fail on Windows 10 and Python 3  
because stdout would not be switched to UTF-8 only for Python 2.  This  
patch makes that apply to both versions.  
  
Also add python 2 compatibility markers so that we know what to remove  
once we drop support for that.  Also use a "with" clause to ensure file  
descriptor is closed promptly.  
  
Author: Hugh Ranalli, Ramanarayana  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/CAKm4Xs7_61XMyOWmHs3n0mmkS0O4S0pvfWk=7cQ5P0gs177f7A@mail.gmail.com  
Discussion: https://postgr.es/m/15548-cef1b3f8de190d4f@postgresql.org  

commit   : b438e7e7a1c58e0c20b5f46e73cbd713e8033c69    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Sep 2019 12:13:29 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 10 Sep 2019 12:13:29 -0300    

There was some duplicate code to run SHOW transaction_read_only to  
determine whether the server is read-write or read-only.  Reduce it by  
adding another state to the state machine.  
  
Author: Hari Babu Kommi  
Reviewed-by: Takayuki Tsunakawa, Álvaro Herrera  
Discussion: https://postgr.es/m/CAJrrPGe_qgdbbN+yBgEVpd+YLHXXjTruzk6RmTMhqrFig+32ag@mail.gmail.com  

commit   : 55d015bde05311cbaaf16424e3aa05c37946cd8a    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Sep 2019 11:41:19 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 9 Sep 2019 11:41:19 -0700    

Assert that _bt_binsrch() binary searches with scantid set in insertion  
scankey cannot be performed on leaf pages.  Leaf-level binary searches  
where scantid is set must use _bt_binsrch_insert() instead.  
  
_bt_binsrch_insert() is likely to have additional responsibilities in  
the future, such as searching within GIN-style posting lists using  
scantid.  It seems like a good idea to tighten things up now.  

commit   : 3146f5257f16d34c95163974f42a13d99141b977    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Sep 2019 14:21:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 9 Sep 2019 14:21:40 -0400    

Don't just assume that the next port is free; it might not be, or  
if we're really unlucky it might even be out of the TCP range.  
Do it honestly with two get_free_port() calls instead.  
  
This is surely a pretty low-probability problem, but I think it  
explains a buildfarm failure seen today, so let's fix it.  
  
Back-patch to v11 where this script was added.  
  
Discussion: https://postgr.es/m/25124.1568052346@sss.pgh.pa.us  

commit   : 73ff3a0abbbcb2c623731b88f2d1334bc67e5820    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Sep 2019 08:56:33 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Sep 2019 08:56:33 -0400    

Modern versions of msys2 have changed the treatment of "cmd /c" so that  
the runtime will try to convert the switch to a native file path. This  
patch adds a setting to inhibit that behaviour.  
  
Discussion: https://postgr.es/m/3227042f-cfcc-745a-57dd-fb8c471f8ddf@2ndQuadrant.com  
  
Backpatch to all live branches.  

commit   : 27cc7cd2bc8a5e8efc8279bc5d2a8ae42fd8ad33    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 5 Sep 2019 13:00:20 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 5 Sep 2019 13:00:20 -0700    

In ad0bda5d24ea I changed the EvalPlanQual machinery to store  
substitution tuples in slot, instead of using plain HeapTuples. The  
main motivation for that was that using HeapTuples will be inefficient  
for future tableams.  But it turns out that that conversion was buggy  
for non-locking rowmarks - the wrong tuple descriptor was used to  
create the slot.  
  
As a secondary issue 5db6df0c0 changed ExecLockRows() to begin EPQ  
earlier, to allow to fetch the locked rows directly into the EPQ  
slots, instead of having to copy tuples around. Unfortunately, as Tom  
complained, that forces some expensive initialization to happen  
earlier.  
  
As a third issue, the test coverage for EPQ was clearly insufficient.  
  
Fixing the first issue is unfortunately not trivial: Non-locked row  
marks were fetched at the start of EPQ, and we don't have the type  
information for the rowmarks available at that point. While we could  
change that, it's not easy. It might be worthwhile to change that at  
some point, but to fix this bug, it seems better to delay fetching  
non-locking rowmarks when they're actually needed, rather than  
eagerly. They're referenced at most once, and in cases where EPQ  
fails, might never be referenced. Fetching them when needed also  
increases locality a bit.  
  
To be able to fetch rowmarks during execution, rather than  
initialization, we need to be able to access the active EPQState, as  
that contains necessary data. To do so move EPQ related data from  
EState to EPQState, and, only for EStates creates as part of EPQ,  
reference the associated EPQState from EState.  
  
To fix the second issue, change EPQ initialization to allow use of  
EvalPlanQualSlot() to be used before EvalPlanQualBegin() (but  
obviously still requiring EvalPlanQualInit() to have been done).  
  
As these changes made struct EState harder to understand, e.g. by  
adding multiple EStates, significantly reorder the members, and add a  
lot more comments.  
  
Also add a few more EPQ tests, including one that fails for the first  
issue above. More is needed.  
  
Reported-By: yi huang  
Author: Andres Freund  
Reviewed-By: Tom Lane  
Discussion:  
    https://postgr.es/m/CAHU7rYZo_C4ULsAx_LAj8az9zqgrD8WDd4hTegDTMM1LMqrBsg@mail.gmail.com  
    https://postgr.es/m/24530.1562686693@sss.pgh.pa.us  
Backpatch: 12-, where the EPQ changes were introduced  

commit   : 7e04160390464cd39690d36054e0ac5e4f1bf227    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 9 Sep 2019 13:50:12 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 9 Sep 2019 13:50:12 +0300    

f2e40380 introduces support of non-key attributes in GiST indexes.  Then if  
get_index_column_opclass() is asked by gistproperty() to get an opclass of  
non-key column, it returns garbage past oidvector value.  This commit fixes  
that by making get_index_column_opclass() return InvalidOid in this case.  
  
Discussion: https://postgr.es/m/20190902231948.GA5343%40alvherre.pgsql  
Author: Nikita Glukhov, Alexander Korotkov  
Backpatch-through: 12  

commit   : 89b160c32045dd85cc6f9ae6248e34a72931ac67    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Sep 2019 10:30:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 9 Sep 2019 10:30:22 +0200    

Tweak the tests so that we're not just testing the default setting of  
transaction_read_only.  
  
Reported-by: fn ln <emuser20140816@gmail.com>  

commit   : 1192e3fb54ce57f57399490d70af617ebc12605c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Sep 2019 17:00:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 8 Sep 2019 17:00:29 -0400    

Some of these are quite old, but that doesn't make them not bugs.  
We'd rather report a failure via elog than SIGSEGV.  
  
While at it, uniformly spell the error check as !RelationIsValid(rel)  
rather than a bare rel == NULL test.  The machine code is the same  
but it seems better to be consistent.  
  
Coverity complained about this today, not sure why, because the  
mistake is in fact old.  

commit   : 02f90879e75b3d4ccdba1ec7c3cad6af08dff77d    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Sep 2019 21:13:40 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Sep 2019 21:13:40 +0300    

In order to implement NULL LAST semantic GiST previously assumed distance to  
the NULL value to be Inf.  However, our distance functions can return Inf and  
NaN for non-null values.  In such cases, NULL LAST semantic appears to be  
broken.  This commit fixes that by introducing separate array of null flags for  
distances.  
  
Backpatch to all supported versions.  
  
Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com  
Author: Alexander Korotkov  
Backpatch-through: 9.4  

commit   : e5d8f3596100da0d38a38513c69e803b7fe7041a    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Sep 2019 21:07:30 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 8 Sep 2019 21:07:30 +0300    

Previously plain float comparison was used in GiST pairing heap.  Such  
comparison doesn't provide proper ordering for value sets containing Inf and Nan  
values.  This commit fixes that by usage of float8_cmp_internal().  Note, there  
is remaining problem with NULL distances, which are represented as Inf in  
pairing heap.  It would be fixes in subsequent commit.  
  
Backpatch to all supported versions.  
  
Reported-by: Andrey Borodin  
Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Heikki Linnakangas  
Backpatch-through: 9.4  

commit   : 862ef372d6b23629f93d4afc123ddd7d172501ac    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 16:11:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 16:11:21 +0200    

When using COMMIT AND CHAIN or ROLLBACK AND CHAIN not in an explicit  
transaction block, the previous implementation would leave a  
transaction block active in the ROLLBACK case but not the COMMIT case.  
To fix for now, error out when using these commands not in an explicit  
transaction block.  This restriction could be lifted if a sensible  
definition and implementation is found.  
  
Bug: #15977  
Author: fn ln <emuser20140816@gmail.com>  
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>  

commit   : 0e777462121bd5b892c1621903d1953a49437290    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 11:10:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 11:10:49 +0200    

commit   : 8e929a4667a1f4f97c5447f54b8176b0ee15aa7d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 10:26:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 8 Sep 2019 10:26:35 +0200    

Note: Following existing practice, titles of formalpara and step are  
not titlecased.  

commit   : db438318997b75f4b40c61258da56384039fa43f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Sep 2019 19:03:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Sep 2019 19:03:11 -0400    

Commit 6f6b99d13 stuck an INFO message into the fast path for  
checking partition constraints, for no very good reason except  
that it made it easy for the regression tests to verify that  
that path was taken.  Assorted later patches did likewise,  
increasing the unsuppressable-chatter level from ALTER TABLE  
even more.  This isn't good for the user experience, so let's  
drop these messages down to DEBUG1 where they belong.  So as  
not to have a loss of test coverage, create a TAP test that  
runs the relevant queries with client_min_messages = DEBUG1  
and greps for the expected messages.  
  
This testing method is a bit brute-force --- in particular,  
it duplicates the execution of a fair amount of the core  
create_table and alter_table tests.  We experimented with  
other solutions, but running any significant amount of  
standard testing with client_min_messages = DEBUG1 seems  
to have a lot of output-stability pitfalls, cf commits  
bbb96c370 and 5655565c0.  Possibly at some point we'll look  
into whether we can reduce the amount of test duplication.  
  
Backpatch into v12, because some of these messages are new  
in v12 and we don't really want to ship it that way.  
  
Sergei Kornilov  
  
Discussion: https://postgr.es/m/81911511895540@web58j.yandex.ru  
Discussion: https://postgr.es/m/4859321552643736@myt5-02b80404fd9e.qloud-c.yandex.net  

commit   : ca70bdaefea5188066b3c2a6eaaaa1cb8cb8ce06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Sep 2019 14:21:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 7 Sep 2019 14:21:59 -0400    

As a result of some long-ago quick hacks, the SIMILAR TO operator  
and the corresponding flavor of substring() interpreted "ESCAPE NULL"  
as selecting the default escape character '\'.  This is both  
surprising and not per spec: the standard is clear that these  
functions should return NULL for NULL input.  
  
Additionally, because of inconsistency of the strictness markings  
of 3-argument substring() and similar_escape(), the planner could not  
inline the SQL definition of substring(), resulting in a substantial  
performance penalty compared to the underlying POSIX substring()  
function.  
  
The simplest fix for this would be to change the strictness marking  
of similar_escape(), but if we do that we risk breaking existing views  
that depend on that function.  Hence, leave similar_escape() as-is  
as a compatibility function, and instead invent a new function  
similar_to_escape() that comes in two strict variants.  
  
There are a couple of other behaviors in this area that are also  
not per spec, but they are documented and seem generally at least  
as sane as the spec's definition, so leave them alone.  But improve  
the documentation to describe them fully.  
  
Patch by me; thanks to Álvaro Herrera and Andrew Gierth for review  
and discussion.  
  
Discussion: https://postgr.es/m/14047.1557708214@sss.pgh.pa.us  

commit   : c5bc7050aff1d1bba6532377fe37b351581661a8    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 16:12:28 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 16:12:28 +0200    

commit   : 021da890bcc129a9a1a4d996304cf437553f0937    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 22:19:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 22:19:53 +0200    

commit   : c57dbc19896cb5a15e53099765c64517afdbab14    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 22:16:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 22:16:58 +0200    

commit   : 8e5ce1c3f837a8b9a5210b7224cb5e5ac3bfc751    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 6 Sep 2019 15:47:23 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 6 Sep 2019 15:47:23 -0400    

The test for SysV support currently involves looking for the perl  
modules IPC::SharedMem and IPC::SysV. However, the perl on msys2 has  
these modules but the tests fail. Therefore, force skipping the tests on  
Windows platforms unconditionally.  
  
Discussion: https://postgr.es/m/176e86ba-1a46-9d8c-5ae4-9865a463b411@2ndQuadrant.com  

commit   : 71a01086603cc3a27c0d6ae60228aeb13c32d359    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Sep 2019 11:24:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 6 Sep 2019 11:24:36 -0400    

We don't consider that building with MinGW is deprecated,  
so adjust some places that gave that impression.  
Per discussion with Peter Eisentraut.  
  
Discussion: https://postgr.es/m/4a023388-8652-fea0-a0b4-35ad5e734e9a@2ndquadrant.com  

commit   : bd124996ef0d655f96a7d4df79611707091f1585    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Sep 2019 10:38:51 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Sep 2019 10:38:51 -0400    

This moves much of the non-heap-specific logic from toast_delete and  
toast_insert_or_update into a helper functions accessible via a new  
header, toast_helper.h.  Using the functions in this module, a table  
AM can implement creation and deletion of TOAST table rows with  
much less code duplication than was possible heretofore.  Some  
table AMs won't want to use the TOAST logic at all, but for those  
that do this will make that easier.  
  
Patch by me, reviewed and tested by Prabhat Sabu, Thomas Munro,  
Andres Freund, and Álvaro Herrera.  
  
Discussion: http://postgr.es/m/CA+TgmoZv-=2iWM4jcw5ZhJeL18HF96+W1yJeYrnGMYdkFFnEpQ@mail.gmail.com  

commit   : 286af0ce12117bc673b97df6228d1a666594d247    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Sep 2019 08:22:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 6 Sep 2019 08:22:32 -0400    

The old code didn't differentiate between a read error and a  
concurrent truncation. fread reports both of these by returning 0;  
you have to use feof() or ferror() to distinguish between them,  
which this code did not do.  
  
It might be a better idea to use read() rather than fread() here,  
so that we can display a less-generic error message, but I'm not  
sure that would qualify as a back-patchable bug fix, so just do  
this much for now.  
  
Jeevan Chalke, reviewed by Jeevan Ladhe and by me.  
  
Discussion: http://postgr.es/m/CA+TgmobG4ywMzL5oQq2a8YKp8x2p3p1LOMMcGqpS7aekT9+ETA@mail.gmail.com  

commit   : 5599f40d259a275d3202b10aa6ffb9a36fd8a940    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 09:15:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 6 Sep 2019 09:15:35 +0200    

The term "ccache" is overloaded.  Let's be more clear, in case someone  
other than a Kerberos wizard has to read this code.  

commit   : 946647f845d0b0762656a8e07055f501c4b29688    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Sep 2019 14:27:25 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 6 Sep 2019 14:27:25 +0900    

Previously even if postmaster died and WaitLatch() woke up with that event  
while pg_promote() was waiting for the standby promotion to finish,  
pg_promote() did nothing special and kept waiting until timeout occurred.  
This could cause a busy loop.  
  
This patch make pg_promote() return false immediately when postmaster  
dies, to avoid such a busy loop.  
  
Back-patch to v12 where pg_promote() was added.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/CAHGQGwEs9ROgSp+QF+YdDU+xP8W=CY1k-_Ov-d_Z3JY+to3eXA@mail.gmail.com  

commit   : fc8cb94bf451cd810ae5b1c1f90b977277247625    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Sep 2019 14:00:13 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 6 Sep 2019 14:00:13 +0900    

Doing the switch reduces the footprint of "progname" in both utilities  
for the messages produced.  This also cleans up a couple of  
inconsistencies in the message formats.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera, Peter Eisentraut  
Discussion: https://postgr.es/m/20190820012819.GA8326@paquier.xyz  

commit   : 7de19fbc0b1a9172d0907017302b32846b2887b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Sep 2019 13:31:41 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Sep 2019 13:31:41 -0400    

This approach provides a much tighter binding between a data directory  
and the associated SysV shared memory block (and SysV or named-POSIX  
semaphores, if we're using those).  Key collisions are still possible,  
but only between data directories stored on different filesystems,  
so the situation should be negligible in practice.  More importantly,  
restarting the postmaster with a different port number no longer  
risks failing to identify a relevant shared memory block, even when  
postmaster.pid has been removed.  A standalone backend is likewise  
much more certain to detect conflicting leftover backends.  
  
(In the longer term, we might now think about deprecating the port as  
a cluster-wide value, so that one postmaster could support sockets  
with varying port numbers.  But that's for another day.)  
  
The hazards fixed here apply only on Unix systems; our Windows code  
paths already use identifiers derived from the data directory path  
name rather than the port.  
  
src/test/recovery/t/017_shm.pl, which intends to test key-collision  
cases, has been substantially rewritten since it can no longer use  
two postmasters with identical port numbers to trigger the case.  
Instead, use Perl's IPC::SharedMem module to create a conflicting  
shmem segment directly.  The test script will be skipped if that  
module is not available.  (This means that some older buildfarm  
members won't run it, but I don't think that that results in any  
meaningful coverage loss.)  
  
Patch by me; thanks to Noah Misch and Peter Eisentraut for discussion  
and review.  
  
Discussion: https://postgr.es/m/16908.1557521200@sss.pgh.pa.us  

commit   : 8b94dab06617ef80a0901ab103ebd8754427ef5a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 8 Jul 2019 11:58:05 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 8 Jul 2019 11:58:05 -0400    

detoast.c/h contain functions required to detoast a datum, partially  
or completely, plus a few other utility functions for examining the  
size of toasted datums.  
  
toast_internals.c/h contain functions that are used internally to the  
TOAST subsystem but which (mostly) do not need to be accessed from  
outside.  
  
heaptoast.c/h contains code that is intrinsically specific to the  
heap AM, either because it operates on HeapTuples or is based on the  
layout of a heap page.  
  
detoast.c and toast_internals.c are placed in  
src/backend/access/common rather than src/backend/access/heap.  At  
present, both files still have dependencies on the heap, but that will  
be improved in a future commit.  
  
Patch by me, reviewed and tested by Prabhat Sabu, Thomas Munro,  
Andres Freund, and Álvaro Herrera.  
  
Discussion: http://postgr.es/m/CA+TgmoZv-=2iWM4jcw5ZhJeL18HF96+W1yJeYrnGMYdkFFnEpQ@mail.gmail.com  

commit   : 74a308cf5221f491776fcdb4dc36eb61678dbc6f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 5 Sep 2019 08:15:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 5 Sep 2019 08:15:58 +0200    

Use the explicit_bzero() function in places where it is important that  
security information such as passwords is cleared from memory.  There  
might be other places where it could be useful; this is just an  
initial collection.  
  
For platforms that don't have explicit_bzero(), provide various  
fallback implementations.  (explicit_bzero() itself isn't standard,  
but as Linux/glibc, FreeBSD, and OpenBSD have it, it's the most common  
spelling, so it makes sense to make that the invocation point.)  
  
Discussion: https://www.postgresql.org/message-id/flat/42d26bde-5d5b-c90d-87ae-6cab875f73be%402ndquadrant.com  

commit   : ae060a52b2881ea842f596fa78b8d09f9a91b149    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 15:46:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 15:46:37 +0900    

The logic ending progress reporting for a backend entry introduced by  
b6fb647 causes callers of pgstat_progress_end_command() to do some extra  
work when track_activities is enabled as the process fields are reset in  
the backend entry even if no command were started for reporting.  
  
This resets the fields only if a command is registered for progress  
reporting, and only if track_activities is enabled.  
  
Author: Masahiho Sawada  
Discussion: https://postgr.es/m/CAD21AoCry_vJ0E-m5oxJXGL3pnos-xYGCzF95rK5Bbi3Uf-rpA@mail.gmail.com  
Backpatch-through: 9.6  

commit   : 522baf14847a7e4cc97c49c7b1c28d21bc33921f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 13:21:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 13:21:11 +0900    

Since the addition of fsync requests in bc34223 to make base backup data  
consistent on disk once pg_basebackup finishes, each tablespace tar file  
is individually flushed once completed, with an additional flush of the  
parent directory when the base backup finishes.  While holding a  
connection to the server, a fsync request taking a long time may cause a  
failure of the base backup, which is annoying for any integration.  A  
recent example of breakage can involve tcp_user_timeout, but  
wal_sender_timeout can cause similar problems.  
  
While reviewing the code, there was a second issue causing too many  
fsync requests to be done for the same WAL data.  As recursive fsyncs  
are done at the end of the backup for both the plain and tar formats  
from the base target directory where everything is written, it is fine  
to disable fsyncs when fetching or streaming WAL.  
  
Reported-by: Ryohei Takahashi  
Author: Michael Paquier  
Reviewed-by: Ryohei Takahashi  
Discussion: https://postgr.es/m/OSBPR01MB4550DAE2F8C9502894A45AAB82BE0@OSBPR01MB4550.jpnprd01.prod.outlook.com  
Backpatch-through: 10  

commit   : 25dcc9d35dfeb027047ebaea9b27cda1eaa9b393    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 3 Sep 2019 17:41:43 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 3 Sep 2019 17:41:43 -0400    

This function is only used by xlogreader.c itself, so there's no need to  
export it.  It was introduced by commit 3b02ea4f0780 with the apparent  
intention that it could be used externally, but I couldn't find any  
external code calling it.  
  
I (Álvaro) couldn't resist the urge to sort nearby function prototypes  
properly while at it.  
  
Author: Antonin Houska  
Discussion: https://postgr.es/m/14984.1554998742@spoje.net  

commit   : fe66125974c58cc749ba441ff53e72216c819da0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 3 Sep 2019 14:47:29 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 3 Sep 2019 14:47:29 -0400    

The message was included as a parameter when this function was added in  
dcb2bda9b704, but I don't think it has ever served any useful purpose.  
Let's stop spreading it pointlessly.  
  
Reviewed by Amit Langote and Peter Eisentraut.  
  
Discussion: https://postgr.es/m/20190806224728.GA17233@alvherre.pgsql  

commit   : 10f55448965f9af3a62070dce840c5c701561630    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 14:25:26 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 14:25:26 +0200    

Clarify in the help output and documentation that -n, -t etc. take a  
"pattern" rather than a "schema" or "table" etc.  This was especially  
confusing now that the new pg_dumpall --exclude-database option was  
documented with "pattern" and the others not, even though they all  
behave the same.  
  
Discussion: https://www.postgresql.org/message-id/flat/b85f3fa1-b350-38d1-1893-4f7911bd7310%402ndquadrant.com  

commit   : bde8c2d319ab3ebaf9f07e5511e1142a38bab0e0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 11:59:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 11:59:36 +0200    

Document that the tablespace sizes are in units of kilobytes.  Make  
the pg_basebackup source code a bit clearer about this, too.  
  
Reviewed-by: Magnus Hagander <magnus@hagander.net>  

commit   : 1d7a6e3eb45946db86d6d1776c55323740d955b0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    

The read() return was not checking for errors, the write() return was  
not checking for short writes.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/5de61b6b-8be9-7771-0048-860328efe027%402ndquadrant.com  

commit   : 396e4afdbcbfd3398415f1a0a29668d6a24a2ddd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 3 Sep 2019 08:26:55 +0200    

This avoids getting a  
  
    Could not read from file ...: Success.  
  
for a short read or write (since errno is not set in that case).  
Instead, report a more specific error messages.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/5de61b6b-8be9-7771-0048-860328efe027%402ndquadrant.com  

commit   : 4e72a8e11e3440b10a10c8de4be2f6664ec41115    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Sep 2019 13:03:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Sep 2019 13:03:29 +0900    

"kB" or "kilobyte" is used in the documentation.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/32BA3AF7-37E9-4334-A226-98B844ADCC4E@yesql.se  

commit   : 3a54eb1a383411765deb66e6081568ae6f8d9132    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Sep 2019 12:30:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Sep 2019 12:30:53 +0900    

The leak happens in str_tolower, str_toupper and str_initcap, which are  
used in several places including their equivalent SQL-level functions,  
and can only be triggered when using an ICU-provided collation when  
converting the input string.  
  
b615920 fixed a similar leak.  Backpatch down 10 where ICU collations  
have been introduced.  
  
Author: Konstantin Knizhnik  
Discussion: https://postgr.es/m/94c0ad0a-cbc2-e4a3-7829-2bdeaf9146db@postgrespro.ru  
Backpatch-through: 10  

commit   : f63a5ead9d04467e1c1847bd5e3d87c4dca6cd35    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2019 16:10:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2019 16:10:37 -0400    

In what seems like a fit of misplaced optimization,  
ExtractReplicaIdentity() accessed the relation's replica-identity  
index without taking any lock on it.  Usually, the surrounding query  
already holds some lock so this is safe enough ... but in the case  
of a previously-planned delete, there might be no existing lock.  
Given a suitable test case, this is exposed in v12 and HEAD by an  
assertion added by commit b04aeb0a0.  
  
The whole thing's rather poorly thought out anyway; rather than  
looking directly at the index, we should use the index-attributes  
bitmap that's held by the parent table's relcache entry, as the  
caller functions do.  This is more consistent and likely a bit  
faster, since it avoids a cache lookup.  Hence, change to doing it  
that way.  
  
While at it, rather than blithely assuming that the identity  
columns are non-null (with catastrophic results if that's wrong),  
add assertion checks that they aren't null.  Possibly those should  
be actual test-and-elog, but I'll leave it like this for now.  
  
In principle, this is a bug that's been there since this code was  
introduced (in 9.4).  In practice, the risk seems quite low, since  
we do have a lock on the index's parent table, so concurrent  
changes to the index's catalog entries seem unlikely.  Given the  
precedent that commit 9c703c169 wasn't back-patched, I won't risk  
back-patching this further than v12.  
  
Per report from Hadi Moshayedi.  
  
Discussion: https://postgr.es/m/CAK=1=Wrek44Ese1V7LjKiQS-Nd-5LgLi_5_CskGbpggKEf3tKQ@mail.gmail.com  

commit   : aef36238587c95934185d29ec94e970796f477d8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2019 14:02:45 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Sep 2019 14:02:45 -0400    

After an unexpected connection loss and successful reconnection,  
psql neglected to resynchronize its internal state about the server,  
such as server version.  Ordinarily we'd be reconnecting to the same  
server and so this isn't really necessary, but there are scenarios  
where we do need to update --- one example is where we have a list  
of possible connection targets and they're not all alike.  
  
Define "resynchronize" as including connection_warnings(), so that  
this case acts the same as \connect.  This seems useful; for example,  
if the server version did change, the user might wish to know that.  
An attuned user might also notice that the new connection isn't  
SSL-encrypted, for example, though this approach isn't especially  
in-your-face about such changes.  Although this part is a behavioral  
change, it only affects interactive sessions, so it should not break  
any applications.  
  
Also, in do_connect, make sure that we desynchronize correctly when  
abandoning an old connection in non-interactive mode.  
  
These problems evidently are the result of people patching only one  
of the two places where psql deals with connection changes, so insert  
some cross-referencing comments in hopes of forestalling future bugs  
of the same ilk.  
  
Lastly, in Windows builds, issue codepage mismatch warnings only at  
startup, not during reconnections.  psql's codepage can't change  
during a reconnect, so complaining about it again seems like useless  
noise.  
  
Peter Billen and Tom Lane.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAMTXbE8e6U=EBQfNSe01Ej17CBStGiudMAGSOPaw-ALxM-5jXg@mail.gmail.com  

commit   : 6fcc40b1d4b91471f667fdf3ebe9665fbab95849    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 Sep 2019 13:37:57 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 2 Sep 2019 13:37:57 -0400    

This module was pretty much undocumented.  Fix that.  
  
Inspired by a preliminary patch sent by Ramanarayana, heavily updated by  
Andrew Dunstan, and reviewed by Michael Paquier.  
  
Discussion: https://postgr.es/m/CAF6A77G_WJTwBV9SBxCnQfZB09hm1p1O3stZ6eE5QiYd=X84Jg@mail.gmail.com  

commit   : 7dedfd22b79822b7f4210e6255b672ea82db6678    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Sep 2019 09:38:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 2 Sep 2019 09:38:23 +0900    

Similarly to the signed versions added in 4d6ad31, this adds a set of  
inline functions for overflow checks with unsigned integers, including  
uint16, uint32 and uint64.  This relies on compiler built-in overflow  
checks by default if available.  The behavior of unsigned integers is  
well-defined so the fallback implementations checks are simple for  
additions and subtractions.  Multiplications avoid division-based checks  
which are expensive if possible, still this can happen for uint64 if  
128-bit integers are not available.  
  
While on it, the code in common/int.h is reorganized to avoid too many  
duplicated comments.  The new macros will be used in a follow-up patch.  
  
All thanks to Andres Freund for the input provided.  
  
Author: Fabien Coelho, Michael Paquier  
Discussion: https://postgr.es/m/20190830073423.GB2354@paquier.xyz  

commit   : 36515e4f14fc1b22787a54d5de45b1e6b5e6cd9c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 1 Sep 2019 23:19:51 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 1 Sep 2019 23:19:51 +0200    

Fix a warning about unused variable on Windows when using OpenSSL.  

commit   : 756349c87b853f83c21726c2029f840643485f7f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Aug 2019 14:05:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Aug 2019 14:05:32 -0400    

These have been there a long time, but their format was never explained  
in the docs.  Per complaint from Yusuke Egashira.  
  
Discussion: https://postgr.es/m/848B1649C8A6274AA527C4472CA11EDD5FC70CBE@G01JPEXMBYT02  

commit   : b61a5e6a1f8d4d9e0bfe5d26bebfbb0687353c08    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Aug 2019 13:37:10 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 31 Aug 2019 13:37:10 -0400    

The comment describing the string format was a lie.  Make it agree with  
reality, add/improve some other comments, fix coding style for loops with  
empty bodies.  Also add an Assert that we counted parameters correctly,  
because the spread-out logic for that looks pretty fragile.  
  
No actual bugs fixed here, so no need to back-patch.  
  
Discussion: https://postgr.es/m/848B1649C8A6274AA527C4472CA11EDD5FC70CBE@G01JPEXMBYT02  

commit   : 137b03b862c21b90a86732120d0c98480daf22de    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Aug 2019 15:44:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Aug 2019 15:44:00 -0400    

The list of configure options has grown long, and there was next  
to no organization to it, never mind any indication of which options  
were interesting to most people.  Break it into several sub-sections  
to provide a bit of structure, and add some introductory text where  
it seems helpful to point people to particular options.  
  
I failed to resist the temptation to do a small amount of  
word-smithing on some of the option descriptions, too.  
But mostly this is reorganization and addition of intro text.  
  
Discussion: https://postgr.es/m/6384.1559917369@sss.pgh.pa.us  

commit   : 76c2af92666ea46bf893680e96079ecdc4e0e45d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Aug 2019 13:02:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 30 Aug 2019 13:02:35 -0400    

Section 16.2 pointed to platform-specific FAQ files that we removed  
way back in 8.4.  Section 16.7 contained a bunch of information about  
AIX and HPUX bugs that were squashed decades ago, plus discussions of  
old compiler versions that are certainly moot now that we require C99  
support.  Since we're obviously not maintaining this stuff carefully,  
just remove it.  The HPUX sub-section seems like it can go away  
entirely, since everything it said that was still applicable was  
redundant with material elsewhere in the chapter.  
  
In passing, I couldn't resist the temptation to do a small amount  
of copy-editing on nearby text.  
  
Back-patch to v12, since this stuff is surely obsolete in any  
branch that requires C99.  
  
Discussion: https://postgr.es/m/15538.1567042743@sss.pgh.pa.us  

commit   : 9684e426954921e8b2bfa367f9e6a4cbbf4ce5ff    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 29 Aug 2019 16:19:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 29 Aug 2019 16:19:35 +0200    

Fix up oid2name, pg_upgrade, and pgbench to error out on too many  
command-line arguments.  This makes it match the behavior of other  
PostgreSQL programs.  
  
Author: Peter Eisentraut, Ibrar Ahmed  
Discussion: https://www.postgresql.org/message-id/flat/f2554627-04e7-383a-ef01-ab99bb6a291c%402ndquadrant.com  

commit   : 317b3d7ae271eca64d49c9c0fddccc3b1e2cb1f6    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 29 Aug 2019 18:45:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Thu, 29 Aug 2019 18:45:00 +0900    

commit   : 744c848dce64fd55970fcf7e9039008cbff2627e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Aug 2019 12:59:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 28 Aug 2019 12:59:47 -0400    

commit   : bde7493d10898831100a0c6c233a5f3030bfcecd    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 28 Aug 2019 12:55:33 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 28 Aug 2019 12:55:33 +0300    

The comment did not match what the code actually did for integers with  
the 43rd bit set. You get an integer like that, if you have a posting  
list with two adjacent TIDs that are more than 2^31 blocks apart.  
According to the comment, we would store that in 6 bytes, with no  
continuation bit on the 6th byte, but in reality, the code encodes it  
using 7 bytes, with a continuation bit on the 6th byte as normal.  
  
The decoding routine also handled these 7-byte integers correctly, except  
for an overflow check that assumed that one integer needs at most 6 bytes.  
Fix the overflow check, and fix the comment to match what the code  
actually does. Also fix the comment that claimed that there are 17 unused  
bits in the 64-bit representation of an item pointer. In reality, there  
are 64-32-11=21.  
  
Fitting any item pointer into max 6 bytes was an important property when  
this was written, because in the old pre-9.4 format, item pointers were  
stored as plain arrays, with 6 bytes for every item pointer. The maximum  
of 6 bytes per integer in the new format guaranteed that we could convert  
any page from the old format to the new format after upgrade, so that the  
new format was never larger than the old format. But we hardly need to  
worry about that anymore, and running into that problem during upgrade,  
where an item pointer is expanded from 6 to 7 bytes such that the data  
doesn't fit on a page anymore, is implausible in practice anyway.  
  
Backpatch to all supported versions.  
  
This also includes a little test module to test these large distances  
between item pointers, without requiring a 16 TB table. It is not  
backpatched, I'm including it more for the benefit of future development  
of new posting list formats.  
  
Discussion: https://www.postgresql.org/message-id/33bfc20a-5c86-f50c-f5a5-58e9925d05ff%40iki.fi  
Reviewed-by: Masahiko Sawada, Alexander Korotkov  

commit   : 720b59b55b84c8a346098cdbf3d34c7e554b0bf5    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 28 Aug 2019 13:37:03 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 28 Aug 2019 13:37:03 +1200    

RelationAllowsEarlyPruning() performed a catalog scan, but is used  
in two contexts where that was a bad idea:  
  
1.  In heap_page_prune_opt(), which runs very frequently in some large  
    scans.  This caused major performance problems in a field report  
    that was easy to reproduce.  
  
2.  In TestForOldSnapshot(), which runs while we hold a buffer content  
    lock.  It's not clear if this was guaranteed to be free of buffer  
    deadlock risk.  
  
The check was introduced in commit 2cc41acd8 and defended against a  
real problem: 9.6's hash indexes have no page LSN and so we can't  
allow early pruning (ie the snapshot-too-old feature).  We can remove  
the check from all later releases though: hash indexes are now logged,  
and there is no way to create UNLOGGED indexes on regular logged  
tables.  
  
If a future release allows such a combination, it might need to put  
a similar check in place, but it'll need some more thought.  
  
Back-patch to 10.  
  
Author: Thomas Munro  
Reviewed-by: Tom Lane, who spotted the second problem  
Discussion: https://postgr.es/m/CA%2BhUKGKT8oTkp5jw_U4p0S-7UG9zsvtw_M47Y285bER6a2gD%2Bg%40mail.gmail.com  
Discussion: https://postgr.es/m/CAA4eK1%2BWy%2BN4eE5zPm765h68LrkWc3Biu_8rzzi%2BOYX4j%2BiHRw%40mail.gmail.com  

commit   : 80d0e5ba3fe03890831b425e85d10150e226239e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Aug 2019 12:28:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Aug 2019 12:28:16 +0900    

check_float4_val() checks after underflow and overflow of values  
converted from float8 to float4, but there has never been any regression  
tests for that.  This brings the coverage of float.h to 100%.  
  
Author: Movead Li  
Discussion: https://postgr.es/m/20190822174636998766188@highgo.ca  

commit   : be182e4f9e899a531094bee83b14fd434e52f7cb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Aug 2019 11:47:35 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Aug 2019 11:47:35 +0900    

In this case, the transfer uses a libpq connection, which is subject to  
the timeout parameters set at system level, and this can make the rewind  
operation suddenly canceled which is not good for automation.  One  
workaround to such issues would be to use PGOPTIONS to enforce the  
wanted timeout parameters, but that's annoying, and for example pg_dump,  
which can run potentially long-running queries disables all types of  
timeouts.  
  
lock_timeout and statement_timeout are the ones which can cause problems  
now.  Note that pg_rewind does not use transactions, so disabling  
idle_in_transaction_session_timeout is optional, but it feels safer to  
do so for the future.  
  
This is back-patched down to 9.5.  idle_in_transaction_session_timeout  
is only present since 9.6.  
  
Author: Alexander Kukushkin  
Discussion: https://postgr.es/m/CAFh8B=krcVXksxiwVQh1SoY+ziJ-JC=6FcuoBL3yce_40Es5_g@mail.gmail.com  
Backpatch-through: 9.5  

commit   : b1907d6882205319822c7452ce6b5e71ee2867be    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 19:49:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 19:49:09 -0400    

Commit a4327296d taught pg_regress proper to do this, but  
missed the opportunity to do likewise in the isolationtester  
and ecpg variants of pg_regress.  Seems like this might be  
helpful for tracking down issues exposed by those tests.  

commit   : 458f01e254e0f0b1ccab8e4589aa8495781a933a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 18:03:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 18:03:09 -0400    

Give it an explanatory para like the other default roles have.  
Don't imply that it can send any signal whatever.  
  
In passing, reorder the table entries and explanatory paras  
for the default roles into some semblance of consistency.  
  
Ian Barwick, tweaked a bit by me.  
  
Discussion: https://postgr.es/m/89907e32-76f3-7282-a89c-ea19c722fe5d@2ndquadrant.com  

commit   : c9bd7f4f2b0fc3b8291914a45cbf2a5270877ee6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 17:24:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 17:24:13 -0400    

Turns out that returning "unrecognized signal" is confusing.  
Make it explicit that the platform lacks any support for signal names.  
(At least of the machines in the buildfarm, only HPUX lacks it.)  
  
Back-patch to v12 where we invented this function.  
  
Discussion: https://postgr.es/m/3067.1566870481@sss.pgh.pa.us  

commit   : b8b3a276d453f5d561341021c93ec05b158f4c65    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 27 Aug 2019 14:01:43 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 27 Aug 2019 14:01:43 -0700    

Commit efada2b8e92, which made the nbtree page deletion algorithm more  
robust, removed the concept of a half-dead internal page.  Remove a  
comment about half dead parent pages that was overlooked.  

commit   : da1b51ecc52ffdb3f8fb1cda1e15dc60ff00cd11    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 16:37:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 16:37:21 -0400    

Section 4.2.7 says that unless otherwise specified, built-in  
aggregates ignore rows in which any input is null.  This is  
not true of the JSON aggregates, but it wasn't documented.  
Fix that.  
  
Of the other entries in table 9.55, some were explicit about  
ignoring nulls, and some weren't; for consistency and  
self-contained-ness, make them all say it explicitly.  
  
Per bug #15884 from Tim Möhlmann.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/15884-c32d848f787fcae3@postgresql.org  

commit   : d4b2425441b7ab298300142d64bb8020d38b290f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 15:14:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 15:14:55 -0400    

Daniel Gustafsson  
  
Discussion: https://postgr.es/m/F2FB03F2-B112-4E51-842E-12C50DCA2F4A@yesql.se  

commit   : 6e42130568ad28bed857948f5a3192dbf01624dc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 14:44:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 27 Aug 2019 14:44:26 -0400    

An empty file name or subdirectory name leads join_path_components() to  
just produce the parent directory name, which leads to weird failures or  
recursive inclusions.  Let's throw a specific error for that.  It takes  
only slightly more code to detect all-blank names, so do so.  
  
Also, detect direct recursion, ie a file calling itself.  As coded  
this will also detect recursion via "include_dir '.'", which is  
perhaps more likely than explicitly including the file itself.  
  
Detecting indirect recursion would require API changes for guc-file.l  
functions, which seems not worth it since extensions might call them.  
The nesting depth limit will catch such cases eventually, just not  
with such an on-point error message.  
  
In passing, adjust the example usages in postgresql.conf.sample  
to perhaps eliminate the problem at the source: there's no reason  
for the examples to suggest that an empty value is valid.  
  
Per a trouble report from Brent Bates.  Back-patch to 9.5; the  
issue is old, but the code in 9.4 is enough different that the  
patch doesn't apply easily, and it doesn't seem worth the trouble  
to fix there.  
  
Ian Barwick and Tom Lane  
  
Discussion: https://postgr.es/m/8c8bcbca-3bd9-dc6e-8986-04a5abdef142@2ndquadrant.com  

commit   : 9acda731184c1ebdf99172cbb19d0404b7eebc37    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 27 Aug 2019 09:11:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 27 Aug 2019 09:11:31 +0900    

FD_SETSIZE needs to be declared before winsock2.h, or it is possible to  
run into buffer overflow issues when using --jobs.  This is similar to  
pgbench's solution done in a23c641.  
  
This has been introduced by 71d84ef, and older versions have been using  
the default value of FD_SETSIZE, defined at 64.  
  
Per buildfarm member jacana, but this impacts all Windows animals  
running the TAP tests.  I have reproduced the failure locally to check  
the patch.  
  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/20190826054000.GE7005@paquier.xyz  
Backpatch-through: 9.5  

commit   : fb57f40eec503d637bf01c298f5cb2472f0d4fdb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Aug 2019 17:02:52 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Aug 2019 17:02:52 -0400    

If a test case tried to set an invalid value of synchronous_standby_names,  
the test script didn't detect that, which seems like a bad idea.  
Noticed while testing a proposed patch that broke some of these  
test cases.  

commit   : ee3278239550ff0ec9df72dd798a480c82c2b723    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Aug 2019 15:59:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Aug 2019 15:59:44 -0400    

A report from Alvaro Herrera shows that if we're in PM_STARTUP  
state, and we spawn a dead_end child to reject some incoming  
connection request, and that child dies with an unexpected exit  
code, the postmaster does not respond well.  We correctly send  
SIGQUIT to the startup process, but then:  
  
* if the startup process exits with nonzero exit code, as expected,  
we thought that that indicated a crash and aborted startup.  
  
* if the startup process exits with zero exit code, which is possible  
due to the inherent race condition, we'd advance to PM_RUN state  
which is fine --- but the code forgot that AbortStartTime would be  
nonzero in this situation.  We'd either die on the Asserts saying  
that it was zero, or perhaps misbehave later on.  (A quick look  
suggests that the only misbehavior might be busy-waiting due to  
DetermineSleepTime doing the wrong thing.)  
  
To fix the first point, adjust the state-machine logic to recognize  
that a nonzero exit code is expected after sending SIGQUIT, and have  
it transition to a state where we can restart the startup process.  
To fix the second point, change the Asserts to clear the variable  
rather than just claiming it should be clear already.  
  
Perhaps we could improve this further by not treating a crash of  
a dead_end child as a reason for panic'ing the database.  However,  
since those child processes are connected to shared memory, that  
seems a bit risky.  There are few good reasons for a dead_end child  
to report failure anyway (the cause of this in Alvaro's report is  
quite unclear).  On balance, therefore, a minimal fix seems best.  
  
This is an oversight in commit 45811be94.  While that was back-patched,  
I'm hesitant to back-patch this change.  The lack of reasons for a  
dead_end child to fail suggests that the case should be very rare in  
the field, which squares with the lack of reports; so it seems like  
this might not be worth the risk of introducing new issues.  In any  
case we can let it bake awhile in HEAD before considering a back-patch.  
  
Discussion: https://postgr.es/m/20190615160950.GA31378@alvherre.pgsql  

commit   : 348778ddbc75eddaa7f9c7ce5b6adad8ada564e4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Aug 2019 14:32:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 26 Aug 2019 14:32:40 -0400    

Incompletely quoting an API spec does nobody any good.  Noted by  
Paul Jungwirth.  Looks like the discrepancy was my fault originally :-(  
  
Discussion: https://postgr.es/m/CA+renyU_J8TU_d3Kr0PkuOgFbpypextendu7a+_d5NOfVdvDeA@mail.gmail.com  

commit   : f2690338814738967d75cc1e35cc1cfac1a40710    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Aug 2019 19:04:35 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 26 Aug 2019 19:04:35 +0200    

In cc8d41511721d25d557fc02a46c053c0a602fed0, the arguments of  
warn_or_exit_horribly() were changed but this was not updated.  

commit   : c62b84437f52f0e23924268938916e90b8e5b9e6    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2019 08:11:27 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2019 08:11:27 -0400    

Previously 'uname -r' on Msys2 reported a kernele release starting with  
2. The latest version starts with 3. In commit 1638623f we specifically  
looked for one starting with 2. This is now changed to look for any  
digit between 2 and 9.  
  
backpatch to release 10.  

commit   : acb96eb7d294a003a9392cdd445630ef137d9918    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2019 07:44:34 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 26 Aug 2019 07:44:34 -0400    

On msys2, 'uname -s' reports a string starting MSYS instead on MINGW  
as happens on msys1. Treat these both the same way. This reverts  
608a710195a4b in favor of a more general solution.  
  
Backpatch to all live branches.  

commit   : 71d84efba714db3b8a330a54be15c4d385719ad6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Aug 2019 11:14:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Aug 2019 11:14:18 +0900    

When trying to use a high number of jobs, vacuumdb (and more recently  
reindexdb) has only checked for a maximum number of jobs used, causing  
confusing failures when running out of file descriptors when the jobs  
open connections to Postgres.  This commit changes the error handling so  
as we do not check anymore for a maximum number of allowed jobs when  
parsing the option value with FD_SETSIZE, but check instead if a file  
descriptor is within the supported range when opening the connections  
for the jobs so as this is detected at the earliest time possible.  
  
Also, improve the error message to give a hint about the number of jobs  
recommended, using a wording given by the reviewers of the patch.  
  
Reported-by: Andres Freund  
Author: Michael Paquier  
Reviewed-by: Andres Freund, Álvaro Herrera, Tom Lane  
Discussion: https://postgr.es/m/20190818001858.ho3ev4z57fqhs7a5@alap3.anarazel.de  
Backpatch-through: 9.5  

commit   : 6338fa3e715ad1cb12e0760bf73ffc2a906098ea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Aug 2019 15:04:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Aug 2019 15:04:04 -0400    

POSIX permits getopt() to advance optind beyond argc when the last  
argv entry is an option that requires an argument and hasn't got one.  
It seems that no major platforms actually do that, but musl does,  
so that something like "psql -f" would crash with that libc.  
Add a check that optind is in range before trying to look at the  
possibly-bogus option.  
  
Report and fix by Quentin Rameau.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/20190825100617.GA6087@fifth.space  

commit   : faee5a12ecf13190d7ca11d6dcc7078e494f46ca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Aug 2019 12:14:50 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 25 Aug 2019 12:14:50 -0400    

We were setting extra_float_digits = 0 to avoid platform-dependent  
output in this test, but that's still able to expose platform-specific  
roundoff behavior in some new test cases added by commit a3d284485,  
as reported by Peter Eisentraut.  Reduce it to -1 to hide that.  
  
(Over in geometry.sql, we're using -3, which is an ancient decision  
dating to 337f73b1b.  I wonder whether that's overkill now.  But  
there's probably little value in trying to change it.)  
  
Back-patch to v12 where a3d284485 came in; there's no evidence that  
we have any platform-dependent issues here before that.  
  
Discussion: https://postgr.es/m/15551268-e224-aa46-084a-124b64095ee3@2ndquadrant.com  

commit   : f493d98c167321e5d5c17dd7d795721045a81c97    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 25 Aug 2019 13:54:48 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 25 Aug 2019 13:54:48 +1200    

Bleeding-edge LLVM has stopped supplying replacements for various  
C++14 library features, for people on older C++ versions.  Since we're  
not ready to require C++14 yet, just use plain old new instead of  
make_unique.  As revealed by buildfarm animal seawasp.  
  
Back-patch to 11.  
  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/CA%2BhUKGJWG7unNqmkxg7nC5o3o-0p2XP6co4r%3D9epqYMm8UY4Mw%40mail.gmail.com  

commit   : 06fdc4e4d33c40dbf886565336574da5566878f4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Aug 2019 12:34:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Aug 2019 12:34:37 +0900    

989d23b has caused its tests to be broken as the module defines unused  
steps, turning the buildfarm red.  

commit   : 867d25ccb4c7f290d08c720622ecaae4afd1dc3f    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 23 Aug 2019 20:24:49 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 23 Aug 2019 20:24:49 -0700    

The Postgres approach to coupling locks during an ascent of the tree is  
slightly different to the approach taken by Lehman and Yao.  Add a new  
paragraph to the "Differences to the Lehman & Yao algorithm" section of  
the nbtree README that explains the similarities and differences.  

commit   : 989d23b04beac0c26f44c379b04ac781eaa4265e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Aug 2019 11:45:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Aug 2019 11:45:05 +0900    

This is useful for developers to find out if an isolation spec is  
over-engineered or if it needs more work by warning at the end of a  
test run if a step is not used, generating a failure with extra diffs.  
  
While on it, clean up all the specs which include steps not used in any  
permutations to simplify them.  
  
Author: Michael Paquier  
Reviewed-by: Asim Praveen, Melanie Plageman  
Discussion: https://postgr.es/m/20190819080820.GG18166@paquier.xyz  

commit   : 9903338b5ea59093d77cfe50ec0b1c22d4a7d843    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Aug 2019 11:35:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 24 Aug 2019 11:35:43 +0900    

The original purpose of the dry-run mode is to be able to print all the  
possible permutations from a spec file, but it has become less useful  
since isolation tests has improved regarding deadlock detection as one  
step not wanted by the author could block indefinitely now (originally  
the step blocked would have been detected rather quickly).  Per  
discussion, let's remove it.  
  
Author: Michael Paquier  
Reviewed-by: Asim Praveen, Melanie Plageman  
Discussion: https://postgr.es/m/20190819080820.GG18166@paquier.xyz  

commit   : 292ae8af79b4f1b09a327d39e80ef70943a28194    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Aug 2019 20:41:06 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Aug 2019 20:41:06 +0900    

This adds a section for heap-related functions.  These were previously  
mixed with functions having a more general purpose, leading to  
confusion.  While on it, add a query example for fsm_page_contents.  
  
Backpatch down to 10, where b5e3942 introduced the subsections for  
function types in pageinspect documentation.  
  
Author: Masahiko Sawada  
Discussion: https://postgr.es/m/CAD21AoDyM7E1+cK3-aWejxKTGC-wVVP2B+RnJhN6inXyeRmqzw@mail.gmail.com  
Backpatch-through: 10  

commit   : 21e60fa8fe296355dca96c451fb13119cc0e6bd2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 15:36:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 15:36:30 +0200    

T612 has been fully supported since the major window function  
enhancements in PostgreSQL 11, but it wasn't updated at the time.  

commit   : a00c53b0cbf06dd6c01f5a1d55ebe21310a250af    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 10:17:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 22 Aug 2019 10:17:30 +0200    

There were some minor differences that didn't seem necessary.  
  
Discussion: https://www.postgresql.org/message-id/flat/86b67eef-bb26-c97d-3e35-64f1fbd4f9fe%402ndquadrant.com  

commit   : 37093766b2f489128564774995f02d4e7d00dccd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Aug 2019 09:58:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Aug 2019 09:58:45 +0900    

The "Express" flavor of Visual Studio exists up to 2017, and the  
documentation referred to "Express" for Visual Studio 2019.  
  
Author: Takuma Hoshiai  
Discussion: https://postgr.es/m/20190820120231.f905542e685140258ca73d82@sraoss.co.jp  
Backpatch-through: 9.4  

commit   : 091bd6befcb71feb58b1478e1b976c85ae504822    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 21 Aug 2019 13:50:27 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 21 Aug 2019 13:50:27 -0700    

Adjust the struct comment that describes how page splits use their  
descent stack to cascade up the tree from the leaf level.  
  
In passing, fix up some unrelated nbtree comments that had typos or were  
obsolete.  

commit   : c45643d618e35ec2fe91438df15abd4f3c0d85ca    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Aug 2019 21:33:05 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Aug 2019 21:33:05 +0200    

crypt() hasn't been needed since crypt detection was removed from  
PostgreSQL, so these configure checks are not necessary.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/21f88934-f00c-27f6-a9d8-7ea06d317781%402ndquadrant.com  

commit   : 8f75e8e44609335e6bdd73123284682235f242a2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Aug 2019 11:12:44 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 21 Aug 2019 11:12:44 -0400    

In early development patches, "replication origins" were called "identifiers";  
almost everything was renamed, but these references to the old terminology  
went unnoticed.  
  
Reported-by: Craig Ringer  

commit   : bbd93667bde56d3900add55479759f33d20ece1e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Aug 2019 10:43:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 21 Aug 2019 10:43:23 -0400    

Using pg_pltemplate as test data was probably not very forward-looking,  
considering we've had many discussions around removing that catalog  
altogether.  Use a nearby temp table instead, to make these two test  
scripts more self-contained.  This is a better test case anyway, since  
it exercises the scenario where the entries in the anyarray column  
actually vary in type intra-query.  

commit   : 3f0f99125e5c0fd704de3c07abe691ebefc51a50    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Aug 2019 11:46:37 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 21 Aug 2019 11:46:37 +0200    

Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>  
Discussion: https://www.postgresql.org/message-id/flat/E393EC88-377F-4C59-A67A-69F2A38D17C7@yesql.se  

commit   : db1f28917bac5e008dcb2653a54e73d2d0571e06    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 20 Aug 2019 22:25:58 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 20 Aug 2019 22:25:58 +0200    

Correct the comment for read_any_attr().  Give a clearer error message  
when parsing at the end of the string, when the client-final-message  
does not contain a "p" attribute (for some reason).  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Discussion: https://www.postgresql.org/message-id/flat/2fb8a15b-de35-682d-a77b-edcc9c52fa12%402ndquadrant.com  

commit   : f8cf524da15ec4d8fad26aeff44af9928d30eb3d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Aug 2019 16:04:09 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 20 Aug 2019 16:04:09 -0400    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/20190819072244.GE18166@paquier.xyz  

commit   : 56f8f9624ba050c7c47dd97547b7fafb866f2bdd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 16:10:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 16:10:20 +0900    

FD_SETSIZE is included in sys/select.h per POSIX, and this header  
inclusion has been moved to scripts_parallel.c as of 5f38403 without  
moving the variable, causing a compilation failure on recent versions of  
OpenBSD (6.6 was the version used in the report).  
  
In order to take care of the failure, move FD_SETSIZE directly to  
scripts_parallel.c with a wrapper controlling the maximum number of  
parallel slots supported, based on a suggestion by Andres Freund.  
  
While on it, reduce the maximum number to be less than FD_SETSIZE,  
leaving some room for stdin, stdout and such as they consume some file  
descriptors.  
  
The buildfarm did not complain about that, as it happens to only be  
an issue on recent versions of OpenBSD and there is no coverage in this  
area.  51c3e9f fixed a similar set of issues.  
  
Bug: #15964  
Reported-by: Sean Farrell  
Discussion: https://postgr.es/m/15964-c1753bdfed722e04@postgresql.org  

commit   : 0431a787469265776eeb9a472beb3457d2990edb    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 12:36:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 12:36:31 +0900    

This has been found during its translation.  
  
Author: Liudmila Mantrova  
Discussion: https://postgr.es/m/CAEkD-mDJHV3bhgezu3MUafJLoAKsOOT86+wHukKU8_NeiJYhLQ@mail.gmail.com  
Backpatch-through: 12  

commit   : e136a0d8ca31d1c94b3f2868ae0e735b8d9ff12f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 18:00:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 18:00:57 -0400    

If the record argument is NULL and has no declared type more concrete  
than RECORD, we can't extract useful information about the desired  
rowtype from it.  In this case, see if we're in FROM with an AS clause,  
and if so extract the needed rowtype info from AS.  
  
It worked like this before v11, but commit 37a795a60 removed the  
behavior, reasoning that it was undocumented, inefficient, and utterly  
not self-consistent.  If you want to take type info from an AS clause,  
you should be using the json_to_record() family of functions not the  
json_populate_record() family.  Also, it was already the case that  
the "populate" functions would fail for a null-valued RECORD input  
(with an unfriendly "record type has not been registered" error)  
when there wasn't an AS clause at hand, and it wasn't obvious that  
that behavior wasn't OK when there was one.  However, it emerges  
that some people were depending on this to work, and indeed the  
rather off-point error message you got if you left off AS encouraged  
slapping on AS without switching to the json_to_record() family.  
  
Hence, put back the fallback behavior of looking for AS.  While at it,  
improve the run-time error you get when there's no place to obtain type  
info; we can do a lot better than "record type has not been registered".  
(We can't, unfortunately, easily improve the parse-time error message  
that leads people down this path in the first place.)  
  
While at it, I refactored the code a bit to avoid duplicating the  
same logic in several different places.  
  
Per bug #15940 from Jaroslav Sivy.  Back-patch to v11 where the  
current coding came in.  (The pre-v11 deficiencies in this area  
aren't regressions, so we'll leave those branches alone.)  
  
Patch by me, based on preliminary analysis by Dmitry Dolgov.  
  
Discussion: https://postgr.es/m/15940-2ab76dc58ffb85b6@postgresql.org  

commit   : 4c01a1110388661d8752fee35e9c5614aa4a2d32    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 19 Aug 2019 12:51:38 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 19 Aug 2019 12:51:38 -0700    

Necessary after fb3b098f. That previously escaped notice, because all  
including sites already include fmgr.h some other way.  
  
Reported-By: Tom Lane  
Author: Andres Freund  
Discussion: https://postgr.es/m/17463.1566153454@sss.pgh.pa.us  

commit   : 55ea109188474dae22d90f743d7189a8bdf94d49    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 14:22:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 14:22:56 -0400    

We already had "cpluspluscheck", which served the dual purposes of  
verifying that headers compile standalone and that they compile as C++.  
However, C++ compilers don't have the exact same set of error conditions  
as C compilers, so this doesn't really prove that a header will compile  
standalone as C.  
  
Hence, add a second script that's largely similar but runs the C  
compiler not C++.  
  
Also add a bit more documentation than the none-at-all we had before.  
  
Discussion: https://postgr.es/m/14803.1566175851@sss.pgh.pa.us  

commit   : a12079109686e75c833b0b04925af8cb2fa011c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 13:17:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 19 Aug 2019 13:17:02 -0400    

IANA tzcode release 2019b adds an option that tells zic not to emit  
the old 32-bit section of the timezone files, and to skip some other  
space-wasting hacks needed for compatibility with old timezone client  
libraries.  Since we only expect our own code to use the timezone data  
we install, and our code is up-to-date with 2019b, there's no apparent  
reason not to generate the smallest possible files.  
  
Unfortunately, while the individual zone files do get significantly  
smaller in many cases, they were not that big to begin with; which  
means that no real space savings ensues on filesystems that don't  
optimize small files.  (For instance, on ext4 with 4K block size,  
"du" says the installed timezone tree is the same size as before.)  
Still, it seems worth making the change, if only because this is  
presumably the wave of the future.  At the very least, we'll save  
some cycles while reading a zone file.  
  
But given the marginal value and the fact that this is a new code  
path, it doesn't seem worth the risk of back-patching this change  
into stable branches.  Hence, unlike most of our timezone-related  
changes, apply to HEAD only.  
  
Discussion: https://postgr.es/m/24998.1563403327@sss.pgh.pa.us  

commit   : 28b6ec1df64775db6d6eb47655141cda1240d901    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 19 Aug 2019 12:05:38 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 19 Aug 2019 12:05:38 -0400    

Author: Jürgen Purtz  
Discussion: https://postgr.es/m/c6027f7a-78ea-8453-0837-09903ba5fd9b@purtz.de  

commit   : a407012c07844b5d81012d6960c4b2ec11d6af9c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Aug 2019 10:30:47 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 19 Aug 2019 10:30:47 +0200    

In a vpath build, we need to point to the source directory to allow  
FOP to find the images.  

commit   : 71851e9ab7ac8409fabc6f64273149aa71fa29f5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Aug 2019 16:33:24 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Aug 2019 16:33:24 +0900    

Oversight in 7bdc655.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/5da8e325-c665-da95-21e0-c8a99ea61fbf@gmail.com  

commit   : c96581abe418a3bf64b643aa4e27091d1eaea1c1    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Aug 2019 16:21:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 19 Aug 2019 16:21:39 +0900    

This fixes various typos in docs and comments, and removes some orphaned  
definitions.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/5da8e325-c665-da95-21e0-c8a99ea61fbf@gmail.com  

commit   : 927f34ce8a215c8b254136f710cca9ca4da1352c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 19:27:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 19:27:23 -0400    

Prefix inet_net_ntop and sibling routines with "pg_" to ensure that  
they aren't mistaken for C-library functions.  This fixes warnings  
from cpluspluscheck on some platforms, and should help reduce reader  
confusion everywhere, since our functions aren't exactly interchangeable  
with the library versions (they may have different ideas about address  
family codes).  
  
This shouldn't be fixing any actual bugs, unless somebody's linker  
is misbehaving, so no need to back-patch.  
  
Discussion: https://postgr.es/m/20518.1559494394@sss.pgh.pa.us  

commit   : 232720be9b6412ec2b6bee405299bcbbbe700f0b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 19:01:40 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 19:01:40 -0400    

Remove use of "register" keyword in hashfn.c.  It's obsolescent  
according to recent C++ compilers, and no modern C compiler pays  
much attention to it either.  
  
Also fix one cosmetic warning about signed vs unsigned comparison.  
  
Discussion: https://postgr.es/m/20518.1559494394@sss.pgh.pa.us  

commit   : 5f110933e1145ad40116cf3c67a454cb6cb71cc2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 18:01:01 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 18:01:01 -0400    

Needs libpq-fe.h for references to PGConn.  
  
Discussion: https://postgr.es/m/17463.1566153454@sss.pgh.pa.us  

commit   : 5c66e99178c2f72042034cceb6bc4902650a2608    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 17:51:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 17:51:35 -0400    

This has to have <time.h>, or the references to "struct tm" don't  
mean what they should.  
  
We have some other recently-introduced issues of the same ilk,  
but this one seems old.  No backpatch though, as it's only a  
latent problem for most purposes.  

commit   : 4d4c66addfd4da51b0e4be456d6109bea4539fac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 17:11:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 18 Aug 2019 17:11:57 -0400    

If a table inherits from multiple unrelated parents, we must disallow  
changing the type of a column inherited from multiple such parents, else  
it would be out of step with the other parents.  However, it's possible  
for the column to ultimately be inherited from just one common ancestor,  
in which case a change starting from that ancestor should still be  
allowed.  (I would not be excited about preserving that option, were  
it not that we have regression test cases exercising it already ...)  
  
It's slightly annoying that this patch looks different from the logic  
with the same end goal in renameatt(), and more annoying that it  
requires an extra syscache lookup to make the test.  However, the  
recursion logic is quite different in the two functions, and a  
back-patched bug fix is no place to be trying to unify them.  
  
Per report from Manuel Rigger.  Back-patch to 9.5.  The bug exists in  
9.4 too (and doubtless much further back); but the way the recursion  
is done in 9.4 is a good bit different, so that substantial refactoring  
would be needed to fix it in 9.4.  I'm disinclined to do that, or risk  
introducing new bugs, for a bug that has escaped notice for this long.  
  
Discussion: https://postgr.es/m/CA+u7OA4qogDv9rz1HAb-ADxttXYPqQdUdPY_yd4kCzywNxRQXA@mail.gmail.com  

commit   : 7e78c872dd5b0f53bbeed90c2b6e610c14e9be4b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 18 Aug 2019 06:53:28 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 18 Aug 2019 06:53:28 +0200