PostgreSQL 13.0 (upcoming) commit log

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    

commit   : 9be4ce4fa33594e035eb421894247e5af61393ce    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Aug 2019 18:15:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 17 Aug 2019 18:15:38 -0400    

This test failed fairly reproducibly on some CLOBBER_CACHE_ALWAYS  
buildfarm animals.  The cause seems to be that if a parallel worker  
is slow enough to reach its lock wait, it may not be released by  
the first deadlock check run, and then later deadlock checks might  
decide to unblock the d2 session instead of the d1 session, leaving  
us in an undetected deadlock state (since the isolationtester client  
is waiting for d1 to complete first).  
  
Fix by introducing an additional lock wait at the end of the d2a1  
step, ensuring that the deadlock checker will recognize that d1  
has to be unblocked before d2a1 completes.  
  
Also reduce max_parallel_workers_per_gather to 3 in this test.  With the  
default max_worker_processes value, we were only getting one parallel  
worker for the d2a1 step, which is not the case I hoped to test.  We  
should get 3 for d1a2 and 2 for d2a1, as the code stands; and maybe 3  
for d2a1 if somebody figures out why the last parallel worker slot isn't  
free already.  
  
Discussion: https://postgr.es/m/22195.1566077308@sss.pgh.pa.us  

commit   : d78d452bc5ac46a970e4fca2b31f3d533815c39a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Aug 2019 12:36:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 17 Aug 2019 12:36:30 +0200    

If an assertion expression contained a macro, the failed assertion  
message would print the expanded macro, which is usually unhelpful and  
confusing.  Restructure the Assert macros to not expand any macros  
when constructing the failure message.  
  
This also fixes that the existing output for Assert et al. shows  
the *inverted* condition, which is also confusing and not how  
assertions usually work.  
  
Discussion: https://www.postgresql.org/message-id/flat/6c68efe3-117a-dcc1-73d4-18ba1ec532e2%402ndquadrant.com  

commit   : f7db0ac7d5b6ba9728616a1cc36288cb4f817e66    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 15:24:22 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 15:24:22 -0700    

Reported-By: Heikki Linnakangas  
Author: Michael Paquier  
Discussion: https://postgr.es/m/d6ffbebb-a0d2-181c-811d-b029b2225ed7@iki.fi  
Backpatch: 12-, where pluggable table access methods were introduced  

commit   : 00a5c4c17b76b2d68fab70ec0be0960590a3a7fe    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 15:19:50 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 15:19:50 -0700    

commit   : fb3b098fe88441f9531a5169008ea17eac01301f    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 10:35:31 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 10:35:31 -0700    

Most of the fmgr.h includes were obsoleted by 352a24a1f9d6f7d4abb1. A  
few others can be obsoleted using the underlying struct type in an  
implementation detail.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190803193733.g3l3x3o42uv4qj7l@alap3.anarazel.de  

commit   : 6a04d345fd8094058f08344af93022566222733a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 10:33:30 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 10:33:30 -0700    

For most uses of acl.h the details of how "Acl" internally looks like  
are irrelevant. It might make sense to move a lot of the  
implementation details into a separate header at a later point.  
  
The main motivation of this change is to avoid including fmgr.h (via  
array.h, which needs it for exposed structs) in a lot of files that  
otherwise don't need it. A subsequent commit will remove the fmgr.h  
include from a lot of files.  
  
Directly include utils/array.h and utils/expandeddatum.h from the  
files that need them, but previously included them indirectly, via  
acl.h.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190803193733.g3l3x3o42uv4qj7l@alap3.anarazel.de  

commit   : 0ae2dc4db2ae9940ab2bb1e4f4c0ff27f09f8aae    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 10:16:42 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 16 Aug 2019 10:16:42 -0700    

These aren't needed after 352a24a1f9d6. The remaining prototypes are  
not defined on the SQL level.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190803193733.g3l3x3o42uv4qj7l@alap3.anarazel.de  

commit   : 076e9d42099d092475ea9eaa2902ba101a27a585    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 16 Aug 2019 14:35:55 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 16 Aug 2019 14:35:55 +0900    

These seem to be leftovers from the original partitionwise-join patch,  
perhaps.  
  
Discussion: https://postgr.es/m/CAPmGK145YiMTPRnvev1dLz8na_-0aZ=Xyqn8f2QsJFBUTObNow@mail.gmail.com  

commit   : 1ced082b95b339e49fc3d9f15474f816e7a9cfb1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 20:04:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 20:04:19 -0400    

This is a variant of the problem fixed in commit 25b692568, which  
unfortunately we failed to detect at the time.  If an update trigger  
returns the "old" tuple, as it's entitled to do, then a subsequent  
iteration of the loop in ExecBRUpdateTriggers would have "oldtuple"  
equal to "trigtuple" and would fail to notice that it shouldn't  
free that.  
  
In addition to fixing the code, extend the test case added by  
25b692568 so that it covers multiple-trigger-iterations cases.  
  
This problem does not manifest in v12/HEAD, as a result of the  
relevant code having been largely rewritten for slotification.  
However, include the test case into v12/HEAD anyway, since this  
is clearly an area that someone could break again in future.  
  
Per report from Piotr Gabriel Kosinski.  Back-patch into all  
supported branches, since the bug seems quite old.  
  
Diagnosis and code fix by Thomas Munro, test case by me.  
  
Discussion: https://postgr.es/m/CAFMLSdP0rd7LqC3j-H6Fh51FYSt5A10DDh-3=W4PPc4LLUQ8YQ@mail.gmail.com  

commit   : fe9b7b2fe5973309c0a5f7d9240dde91aeeb94aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 15:21:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 15:21:47 -0400    

Commit 4b93f5799 rearranged things in plpgsql to make it cope better with  
composite types changing underneath it intra-session.  However, I failed to  
consider the case of a composite type being dropped and recreated entirely.  
In my defense, the previous coding didn't consider that possibility at all  
either --- but it would accidentally work so long as you didn't change the  
type's field list, because the built-at-compile-time list of component  
variables would then still match the type's new definition.  The new  
coding, however, occasionally tries to re-look-up the type by OID, and  
then fails to find the dropped type.  
  
To fix this, we need to save the TypeName struct, and then redo the type  
OID lookup from that.  Of course that's expensive, so we don't want to do  
it every time we need the type OID.  This can be fixed in the same way that  
4b93f5799 dealt with changes to composite types' definitions: keep an eye  
on the type's typcache entry to see if its tupledesc has been invalidated.  
(Perhaps, at some point, this mechanism should be generalized so it can  
work for non-composite types too; but for now, plpgsql only tries to  
cope with intra-session redefinitions of composites.)  
  
I'm slightly hesitant to back-patch this into v11, because it changes  
the contents of struct PLpgSQL_type as well as the signature of  
plpgsql_build_datatype(), so in principle it could break code that is  
poking into the innards of plpgsql.  However, the only popular extension  
of that ilk is pldebugger, and it doesn't seem to be affected.  Since  
this is a regression for people who were relying on the old behavior,  
it seems worth taking the small risk of causing compatibility issues.  
  
Per bug #15913 from Daniel Fiori.  Back-patch to v11 where 4b93f5799  
came in.  
  
Discussion: https://postgr.es/m/15913-a7e112e16dedcffc@postgresql.org  

commit   : bb5ae8f6c4161e1742a90f27b697eeb14812e65f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 12:22:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 12:22:12 -0400    

Previously, async.c got rid of duplicate notifications by scanning  
the list of pending events to compare each one to the proposed new  
event.  This works okay for very small numbers of distinct events,  
but degrades as O(N^2) for many events.  We can improve matters by  
using a hash table to probe for duplicates.  So as not to add a  
lot of overhead for the simple cases that the code did handle well  
before, create the hash table only once a (sub)transaction has  
queued more than 16 distinct notify events.  
  
A downside is that we now have to do per-event work to propagate  
a successful subtransaction's notify events up to its parent.  
(But this isn't significant unless the subtransaction had many  
events, in which case the O(N^2) behavior would have been in  
play already, so we still come out ahead.)  
  
We can make some lemonade out of this lemon, though: since we must  
examine each event anyway, it's now possible to de-duplicate events  
fully, rather than skipping that for events merged up from  
subtransactions.  Hence, remove the old weasel wording in notify.sgml  
about whether de-duplication happens or not, and adjust the test  
case in async-notify.spec that exhibited the old behavior.  
  
While at it, rearrange the definition of struct Notification to make  
it more compact and require just one palloc per event, rather than  
two or three.  This saves space when there are a lot of events,  
in fact more than enough to buy back the space needed for the hash  
table.  
  
Patch by me, based on discussions around a different patch  
submitted by Filip Rembiałkowski.  
  
Discussion: https://postgr.es/m/17822.1564186806@sss.pgh.pa.us  

commit   : 45aaaa42fefad6e2f164647e373346a5a4123dad    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 11:14:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 15 Aug 2019 11:14:26 -0400    

Clarify what external tools can do to this file, and add a bit  
of detail about what ALTER SYSTEM itself does.  
  
Discussion: https://postgr.es/m/aed6cc9f-98f3-2693-ac81-52bb0052307e@2ndquadrant.com  

commit   : f1bf619acdff15b88b5729f8de6df4eed609b3a0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Aug 2019 15:09:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 14 Aug 2019 15:09:19 -0400    

ALTER SYSTEM itself normally won't make duplicate entries (although  
up till this patch, it was possible to confuse it by writing case  
variants of a GUC's name).  However, if some external tool has appended  
entries to the file, that could result in duplicate entries for a single  
GUC name.  In such a situation, ALTER SYSTEM did exactly the wrong thing,  
because it replaced or removed only the first matching entry, leaving  
the later one(s) still there and hence still determining the active value.  
  
This patch fixes that by making ALTER SYSTEM sweep through the file and  
remove all matching entries, then (if not ALTER SYSTEM RESET) append the  
new setting to the end.  This means entries will be in order of last  
setting rather than first setting, but that shouldn't hurt anything.  
  
Also, make the comparisons case-insensitive so that the right things  
happen if you do, say, ALTER SYSTEM SET "TimeZone" = 'whatever'.  
  
This has been broken since ALTER SYSTEM was invented, so back-patch  
to all supported branches.  
  
Ian Barwick, with minor mods by me  
  
Discussion: https://postgr.es/m/aed6cc9f-98f3-2693-ac81-52bb0052307e@2ndquadrant.com  

commit   : 9c02cf56614366769682bb8b3f4e9eecf8f237c4    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 14 Aug 2019 11:32:35 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 14 Aug 2019 11:32:35 -0700    

The initial value of the nbtree stack downlink block number field  
recorded during an initial descent of the tree wasn't actually used.  
Both _bt_getstackbuf() callers overwrote the value with their own value.  
  
Remove the block number field from the stack struct, and add a child  
block number argument to _bt_getstackbuf() in its place.  This makes the  
overall design of _bt_getstackbuf() clearer.  
  
Author: Peter Geoghegan  
Reviewed-By: Anastasia Lubennikova  
Discussion: https://postgr.es/m/CAH2-Wzmx+UbXt2YNOUCZ-a04VdXU=S=OHuAuD7Z8uQq-PXTYUg@mail.gmail.com  

commit   : fded4773eb60541c6e7dbcf09c9bcb1cd36a063b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Aug 2019 06:50:47 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 14 Aug 2019 06:50:47 +0200    

The method of passing LC_COLLATE and LC_CTYPE to the backend during  
initdb is obsolete as of 61d967498802ab86d8897cb3c61740d7e9d712f6.  
This can all be removed.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/eeaf2f99-a1a6-8aca-3f43-9ab0b2fb112a%402ndquadrant.com  

commit   : 96e7e1bc08919ceb34d95140834f0db94266da2e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Aug 2019 13:37:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 14 Aug 2019 13:37:48 +0900    

This is a fix similar to 2d7d67cc, where slight plan alteration can  
cause a random failure of this regression test because of an incorect  
tuple ordering, except that this one involves lookups of pg_type.  
Similarly to the other case, add ORDER BY clauses to ensure the output  
order.  
  
The failure has been seen at least once on buildfarm member skink.  
  
Reported-by: Thomas Munro  
Discussion: https://postgr.es/m/CA+hUKGLjR9ZBvhXcr9b-NSBHPw9aRgbjyzGE+kqLsT4vwX+nkQ@mail.gmail.com  
Backpatch-through: 12  

commit   : 68ef887842ff716097bbb1bad86a40bb62247061    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 13 Aug 2019 17:16:44 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 13 Aug 2019 17:16:44 -0700    

Commit d2086b08b02 removed almost all cases where nbtree must release a  
read buffer lock and acquire a write buffer lock instead, so remaining  
cases in which that's still necessary are not notable enough to appear  
in the nbtree README.  
  
More importantly, holding on to a buffer pin in cases where nbtree must  
trade a read lock for a write lock is very unlikely to save any I/O.  
This seems to have been a long overlooked throwback to a time when  
nbtree cared about write-ordering dependencies, and performed  
synchronous buffer writes.  It hasn't worked that way in many years.  

commit   : 31d43710fb069a5c2be6ec1dbc9fa7261cf9feff    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Aug 2019 16:57:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 13 Aug 2019 16:57:58 -0400    

Commit 07b39083c inserted an unconditional reference to pg_opfamily,  
which of course fails on servers predating that catalog.  Fortunately,  
the case it's trying to solve can't occur on such old servers (AFAIK).  
Hence, just skip the additional code when the source predates 8.3.  
  
Per bug #15955 from sly.  Back-patch to all supported branches,  
like the previous patch.  
  
Discussion: https://postgr.es/m/15955-1daa2e676e903d87@postgresql.org  

commit   : af0ba49809b57203d87702b315b64f1fd53c728d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 13 Aug 2019 11:54:26 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 13 Aug 2019 11:54:26 -0700    

Use the PageIndexTupleOverwrite() bufpage.c routine within nbtree  
instead of deleting a tuple and re-inserting its replacement.  This  
makes the intent of affected code slightly clearer.  It also makes  
CREATE INDEX slightly faster, since there is no longer a need to shift  
every leaf page's line pointer array back and forth during index builds.  
  
Author: Peter Geoghegan, Anastasia Lubennikova  
Reviewed-By: Anastasia Lubennikova  
Discussion: https://postgr.es/m/CAH2-Wz=Zk=B9+Vwm376WuO7YTjFc2SSskifQm4Nme3RRRPtOSQ@mail.gmail.com  

commit   : 815ef2f568c754dcb539cca574f1982317d74db6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 13 Aug 2019 10:26:04 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 13 Aug 2019 10:26:04 -0400    

We only need to invoke constraint exclusion on partitioned tables when  
they are a partition, and they themselves contain a default partition;  
it's not necessary otherwise, and it's expensive, so avoid it.  Also, we  
were trying once for each clause separately, but we can do it for all  
the clauses at once.  
  
While at it, centralize setting of RelOptInfo->partition_qual instead of  
computing it in slightly different ways in different places.  
  
Per complaints from Simon Riggs about 4e85642d935e; reviewed by Yuzuko  
Hosoya, Kyotaro Horiguchi.  
  
Author: Amit Langote.  I (Álvaro) again mangled the patch somewhat.  
Discussion: https://postgr.es/m/CANP8+j+tMCY=nEcQeqQam85=uopLBtX-2vHiLD2bbp7iQQUKpA@mail.gmail.com  

commit   : 416c75cf38fbf58f4589fb27b520b64092a7ceff    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 13 Aug 2019 08:38:21 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 13 Aug 2019 08:38:21 +0200    

This moves us to the latest minor version of DocBook 4.  It requires  
no markup changes.  

commit   : 66bde49d96a9ddacc49dcbdf1b47b5bd6e31ead5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Aug 2019 13:53:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Aug 2019 13:53:41 +0900    

This addresses some issues with unnecessary code comments, fixes various  
typos in docs and comments, and removes some orphaned structures and  
definitions.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/9aabc775-5494-b372-8bcb-4dfc0bd37c68@gmail.com  

commit   : 2d7d67cc74d0f59e76464bd5009bc74f1591018e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Aug 2019 10:55:19 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Aug 2019 10:55:19 +0900    

This test case could fail because of an incorrect result ordering when  
looking up at pg_class entries.  This commit adds an ORDER BY to the  
culprit query.  The cause of the failure was likely caused by a plan  
switch.  By default, the planner would likely choose an index-only scan  
or an index scan, but even a small change in the startup cost could have  
caused a bitmap heap scan to be chosen, causing the failure.  
  
While on it, switch some filtering quals to a regular expression as per  
an idea of Tom Lane.  As previously shaped, the quals would have  
selected any relations whose name begins with "temp".  And that could  
cause failures if another test running in parallel began to use similar  
relation names.  
  
Per report from buildfarm member anole, though the failure was very  
rare.  This test has been introduced by 319a810, so backpatch down to  
v10.  
  
Discussion: https://postgr.es/m/20190807132422.GC15695@paquier.xyz  
Backpatch-through: 10  

commit   : 6754fe65a4c68c1e3b179080ab62c2f3ff6d877c    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 12 Aug 2019 15:21:32 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 12 Aug 2019 15:21:32 -0700    

contrib/amcheck failed to consider the possibility that unlogged  
relations will not have any main relation fork files when running in hot  
standby mode.  This led to low-level "can't happen" errors that complain  
about the absence of a relfilenode file.  
  
To fix, simply skip verification of unlogged index relations during  
recovery.  In passing, add a direct check for the presence of a main  
fork just before verification proper begins, so that we cleanly verify  
the presence of the main relation fork file.  
  
Author: Andrey Borodin, Peter Geoghegan  
Reported-By: Andrey Borodin  
Diagnosed-By: Andrey Borodin  
Discussion: https://postgr.es/m/DA9B33AC-53CB-4643-96D4-7A0BBC037FA1@yandex-team.ru  
Backpatch: 10-, where amcheck was introduced.  

commit   : 03c811a483b243952874d8e2b3f0c2e3793bc952    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 13:15:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 13:15:47 -0400    

As coded, the ICU-collation path in pattern_char_isalpha() failed  
to consider regular ASCII letters to be case-varying.  This led to  
like_fixed_prefix treating too much of an ILIKE pattern as being a  
fixed prefix, so that indexscans derived from an ILIKE clause might  
miss entries that they should find.  
  
Per bug #15892 from James Inform.  This is an oversight in the original  
ICU patch (commit eccfef81e), so back-patch to v10 where that came in.  
  
Discussion: https://postgr.es/m/15892-e5d2bea3e8a04a1b@postgresql.org  

commit   : 3c926587b5928795e54dfea65c712a604f63cdeb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 11:58:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 11:58:35 -0400    

Now that list_nth is O(1), there's no good reason to maintain a  
separate array of RTE pointers rather than indexing into  
estate->es_range_table.  Deleting the array doesn't save all that  
much either; but just on cleanliness grounds, it's better not to  
have duplicate representations of the identical information.  
  
Discussion: https://postgr.es/m/14960.1565384592@sss.pgh.pa.us  

commit   : 5ee190f8ec37c1bbfb3061e18304e155d600bc8e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 11:20:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 12 Aug 2019 11:20:18 -0400    

In the wake of commit 1cff1b95a, the result of list_concat no longer  
shares the ListCells of the second input.  Therefore, we can replace  
"list_concat(x, list_copy(y))" with just "list_concat(x, y)".  
  
To improve call sites that were list_copy'ing the first argument,  
or both arguments, invent "list_concat_copy()" which produces a new  
list sharing no ListCells with either input.  (This is a bit faster  
than "list_concat(list_copy(x), y)" because it makes the result list  
the right size to start with.)  
  
In call sites that were not list_copy'ing the second argument, the new  
semantics mean that we are usually leaking the second List's storage,  
since typically there is no remaining pointer to it.  We considered  
inventing another list_copy variant that would list_free the second  
input, but concluded that for most call sites it isn't worth worrying  
about, given the relative compactness of the new List representation.  
(Note that in cases where such leakage would happen, the old code  
already leaked the second List's header; so we're only discussing  
the size of the leak not whether there is one.  I did adjust two or  
three places that had been troubling to free that header so that  
they manually free the whole second List.)  
  
Patch by me; thanks to David Rowley for review.  
  
Discussion: https://postgr.es/m/11587.1550975080@sss.pgh.pa.us  

commit   : 251c8e39bc6b0a3ff1620d9ac10888a7660e6b88    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 12 Aug 2019 06:19:19 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 12 Aug 2019 06:19:19 +0300    

Take into account pg_server_to_any() may return input string "as is".  
  
Reported-by: Andrew Dunstan, Thomas Munro  
Discussion: https://postgr.es/m/0ed83a33-d900-466a-880a-70ef456c721f%402ndQuadrant.com  
Author: Alexander Korotkov, Thomas Munro  
Backpatch-through: 12  

commit   : b43f7c117e667fb51df36ca62e6c86054b0f8d03    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Aug 2019 18:55:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 11 Aug 2019 18:55:32 -0400    

This reverts much of commit f03a9ca4366d064d89b7cf7ed75d4e43f2ed0667,  
but leaves the relpages/reltuples probe in select_parallel.sql.  
The pg_stat_all_tables probes are unstable enough to be annoying,  
and it no longer seems likely that they will teach us anything more  
about the underlying problem.  I'd still like some more confirmation  
though that the observed plan instability is caused by VACUUM leaving  
relpages/reltuples as zero for one of these tables.  
  
Discussion: https://postgr.es/m/CA+hUKG+0CxrKRWRMf5ymN3gm+BECHna2B-q1w8onKBep4HasUw@mail.gmail.com  

commit   : d54ceb9e176152f930e60709e07c636e8e5414f5    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 11 Aug 2019 22:54:53 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 11 Aug 2019 22:54:53 +0300    

We have implemented jsonpath string comparison using default database locale.  
However, standard requires us to compare Unicode codepoints.  This commit  
implements that, but for performance reasons we still use per-byte comparison  
for "==" operator.  Thus, for consistency other comparison operators do per-byte  
comparison if Unicode codepoints appear to be equal.  
  
In some edge cases, when same Unicode codepoints have different binary  
representations in database encoding, we diverge standard to achieve better  
performance of "==" operator.  In future to implement strict standard  
conformance, we can do normalization of input JSON strings.  
  
Original patch was written by Nikita Glukhov, rewritten by me.  
  
Reported-by: Markus Winand  
Discussion: https://postgr.es/m/8B7FA3B4-328D-43D7-95A8-37B8891B8C78%40winand.at  
Author: Nikita Glukhov, Alexander Korotkov  
Backpatch-through: 12  

commit   : cabe0f298ea7efade11d8171c617e668934d0d09    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Aug 2019 11:30:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 10 Aug 2019 11:30:11 -0400    

This failed with either "tuple already updated by self" or "duplicate  
key value violates unique constraint", depending on whether the table  
had previously been analyzed or not.  The reason is that ANALYZE tried  
to insert or update the same pg_statistic rows twice, and there was no  
CommandCounterIncrement between.  So add one.  The same case works fine  
outside a transaction block, because then there's a whole transaction  
boundary between, as a consequence of the way VACUUM works.  
  
This issue has been latent all along, but the problem was unreachable  
before commit 11d8d72c2 added the ability to specify multiple tables  
in ANALYZE.  We could, perhaps, alternatively fix it by adding code to  
de-duplicate the list of VacuumRelations --- but that would add a  
lot of overhead to work around dumb commands, so it's not attractive.  
  
Per bug #15946 from Yaroslav Schekin.  Back-patch to v11.  
  
(Note: in v11 I also back-patched the test added by commit 23224563d;  
otherwise the problem doesn't manifest in the test I added, because  
"vactst" is empty when the tests for multiple ANALYZE targets are  
reached.  That seems like not a very good thing anyway, so I did this  
rather than rethinking the choice of test case.)  
  
Discussion: https://postgr.es/m/15946-5c7570a2884a26cf@postgresql.org  

commit   : d8cd68c8d472292ef8943a765bd1c69c0d4d61d8    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 9 Aug 2019 17:06:45 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 9 Aug 2019 17:06:45 -0700    

Rename the "tupindex" field from tuplesort.c's SortTuple struct to  
"srctape", since it can only ever be used to store a source/input tape  
number when merging external sort runs.  This has been the case since  
commit 8b304b8b72b, which removed replacement selection sort from  
tuplesort.c.  

commit   : 0662eb6219f1f4bafc1916a0bf2813cdc58e5eca    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Aug 2019 13:20:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Aug 2019 13:20:28 -0400    

Not much to be said here: commit 9fdb675fc should have checked  
constisnull, didn't.  
  
Per report from Piotr Włodarczyk.  Back-patch to v11 where  
bug was introduced.  
  
Discussion: https://postgr.es/m/CAP-dhMr+vRpwizEYjUjsiZ1vwqpohTm+3Pbdt6Pr7FEgPq9R0Q@mail.gmail.com  

commit   : 1661a4050593a472c369a6660ffec05b6b837c57    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Aug 2019 12:33:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 9 Aug 2019 12:33:43 -0400    

Merge setup_append_rel_array into setup_simple_rel_arrays.  There's no  
particularly good reason to keep them separate, and it's inconsistent  
with the lack of separation in expand_planner_arrays.  The only apparent  
benefit was that the fast path for trivial queries in query_planner()  
doesn't need to set up the append_rel_array; but all we're saving there  
is an if-test and NULL assignment, which surely ought to be negligible.  
  
Also improve some obsolete comments.  
  
Discussion: https://postgr.es/m/17220.1565301350@sss.pgh.pa.us  

commit   : b8f2da0ac5a24f669c8d320c58646759b8fc69a5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 9 Aug 2019 11:05:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 9 Aug 2019 11:05:14 +0900    

b654714 has reworked the way trailing CR/LF characters are removed from  
strings.  This commit introduces a new routine in common/string.c and  
refactors the code so as the logic is in a single place, mostly.  
  
Author: Michael Paquier  
Reviewed-by: Bruce Momjian  
Discussion: https://postgr.es/m/20190801031820.GF29334@paquier.xyz  

commit   : 28b901f73a3924187988bfaac57d20e422a432c3    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 8 Aug 2019 13:20:44 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 8 Aug 2019 13:20:44 -0700    

READTUP() routines do not and cannot use the resettable "tuplecontext"  
memory context, since it is deleted when merging begins.  Update an  
obsolete comment that claimed otherwise.  This was an oversight in  
commit e94568ecc10.  
  
In passing, fix an unrelated tuplesort typo.  

commit   : 956451e8bc9face2241d9a785e0d236a92f8e210    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Aug 2019 16:03:14 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 8 Aug 2019 16:03:14 -0400    

Reviewed by Tom Lane and Amit Langote  
Discussion: https://postgr.es/m/20190806222735.GA9535@alvherre.pgsql  

commit   : 15077ab63f29fd85ff519d1c456fda614774d28b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 8 Aug 2019 14:57:48 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 8 Aug 2019 14:57:48 -0400    

openssl doesn't like lower case subject attribute names. Error observed  
in buildfarm results.  
  
Backpatch to release 11.  

commit   : 43211c2a02f39d6568496168413dc00e0399dc2e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 8 Aug 2019 08:47:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 8 Aug 2019 08:47:55 +0200    

I left PG_CMD_PUTS around even though it could be handled by  
PG_CMD_PRINTF since PG_CMD_PUTS is sometimes called with non-literal  
arguments, and so that would create a potential problem if such a  
string contained percent signs.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  

commit   : e94cd0a8eb831d3ad756ad5f1e69b05392038355    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Aug 2019 18:09:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 7 Aug 2019 18:09:28 -0400    

VACUUM's reference page had this text, but ANALYZE's didn't.  That's  
a clear oversight given that section 5.7 explicitly delegates the  
responsibility to define permissions requirements to the individual  
commands' man pages.  
  
Per gripe from Isaac Morland.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CAMsGm5fp3oBUs-2iRfii0iEO=fZuJALVyM2zJLhNTjG34gpAVQ@mail.gmail.com  

commit   : e1f4c481b995d0f4ef9570aaf9638fe06bc5d742    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Aug 2019 16:55:31 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Aug 2019 16:55:31 -0400    

This include was probably copied from tuplestore.c, but it's not needed.  
  
Extracted from a larger patch submitted by vignesh C <vignesh21@gmail.com>  
  
Discussion: https://postgr.es/m/CALDaNm1B9naPDTm3ox1m_yZvOm3KA5S4kZQSWWAeLHAQ=3gV1Q@mail.gmail.com  

commit   : 12afc7145c03c212f26fea3a99e016da6a1c919c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Aug 2019 12:27:47 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Aug 2019 12:27:47 -0400    

Discussion: https://postgr.es/m/20190806222735.GA9535@alvherre.pgsql  

commit   : 4e85642d935eb13341584df7776eb76585d45819    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Aug 2019 12:21:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 7 Aug 2019 12:21:22 -0400    

We were applying constraint exclusion on the partition constraint when  
generating pruning steps for a clause, but only for the rather  
restricted situation of them being boolean OR operators; however it is  
possible to have differently shaped clauses that also benefit from  
constraint exclusion.  This applies particularly to the default  
partition since their constraints are in essence a long list of OR'ed  
subclauses ... but it applies to other cases too.  So in certain cases  
we're scanning partitions that we don't need to.  
  
Remove the specialized code in OR clauses, and add a generally  
applicable test of the clause refuting the partition constraint; mark  
the whole pruning operation as contradictory if it hits.  
  
This has the unwanted side-effect of testing some (most? all?)  
constraints more than once if constraint_exclusion=on.  That seems  
unavoidable as far as I can tell without some additional work, but  
that's not the recommended setting for that parameter anyway.  
However, because this imposes additional processing cost for all  
queries using partitioned tables, I decided not to backpatch this  
change.  
  
Author: Amit Langote, Yuzuko Hosoya, Álvaro Herrera  
Reviewers: Shawn Wang, Thibaut Madeleine, Yoshikazu Imai, Kyotaro  
Horiguchi; they were also uncredited reviewers for commit 489247b0e615.  
Discussion: https://postgr.es/m/9bb31dfe-b0d0-53f3-3ea6-e64b811424cf@lab.ntt.co.jp  

commit   : 1f33f211bc531d257f84fefb9208dd43e8718972    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 7 Aug 2019 16:06:45 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 7 Aug 2019 16:06:45 +0300    

Discussion: https://postgr.es/m/8B7FA3B4-328D-43D7-95A8-37B8891B8C78%40winand.at  
Author: Markus Winand  
Backpatch-through: 12  

commit   : 68343b4ad75305391b38f4b42734dc07f2fe7ee2    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 7 Aug 2019 19:05:17 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 7 Aug 2019 19:05:17 +0900    

commit   : 1169fcf129f41762fa8a2d82b52eabd788b3a4de    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Aug 2019 12:40:49 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 7 Aug 2019 12:40:49 +0300    

In serializable mode, heap_hot_search_buffer() incorrectly acquired a  
predicate lock on the root tuple, not the returned tuple that satisfied  
the visibility checks. As explained in README-SSI, the predicate lock does  
not need to be copied or extended to other tuple versions, but for that to  
work, the correct, visible, tuple version must be locked in the first  
place.  
  
The original SSI commit had this bug in it, but it was fixed back in 2013,  
in commit 81fbbfe335. But unfortunately, it was reintroduced a few months  
later in commit b89e151054. Wising up from that, add a regression test  
to cover this, so that it doesn't get reintroduced again. Also, move the  
code that sets 't_self', so that it happens at the same time that the  
other HeapTuple fields are set, to make it more clear that all the code in  
the loop operate on the "current" tuple in the chain, not the root tuple.  
  
Bug spotted by Andres Freund, analysis and original fix by Thomas Munro,  
test case and some additional changes to the fix by Heikki Linnakangas.  
Backpatch to all supported versions (9.4).  
  
Discussion: https://www.postgresql.org/message-id/20190731210630.nqhszuktygwftjty%40alap3.anarazel.de  

commit   : 64579be64a3811d08ea7ccf92b1a443d76b96412    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Aug 2019 18:16:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Aug 2019 18:16:31 +0900    

When parsing a timetz string with a dynamic timezone abbreviation or a  
timezone not specified, it was possible to generate incorrect timestamps  
based on a date which uses some non-initialized variables if the input  
string did not specify fully a date to parse.  This is already checked  
when a full timezone spec is included in the input string, but the two  
other cases mentioned above missed the same checks.  
  
This gets fixed by generating an error as this input is invalid, or in  
short when a date is not fully specified.  
  
Valgrind was complaining about this problem.  
  
Bug: #15910  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/15910-2eba5106b9aa0c61@postgresql.org  
Backpatch-through: 9.4  

commit   : 75c1921cd6c868c5995b88113b4463a4830b9a27    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Aug 2019 10:28:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Aug 2019 10:28:16 +0900    

As of now, logical decoding of a multi-insert has been scanning all  
xl_multi_insert_tuple entries only if XLH_INSERT_CONTAINS_NEW_TUPLE was  
getting set in the record.  This is not an issue on HEAD as multi-insert  
records are not used for system catalogs, but the logical decoding logic  
includes all the code necessary to handle that properly, except that the  
code missed to iterate correctly over all xl_multi_insert_tuple entries  
when the flag is not set.  Hence, when trying to use multi-insert for  
system catalogs, an assertion would be triggered.  
  
An upcoming patch is going to make use of multi-insert for system  
catalogs, and this fixes the logic to make sure that all entries are  
scanned correctly without softening the existing assertions.  
  
Reported-by: Daniel Gustafsson  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/CBFFD532-C033-49EB-9A5A-F67EAEE9EB0B@yesql.se  

commit   : efc77cf5f1deb96a5233c04d287ead01ee7b260d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Aug 2019 18:04:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Aug 2019 18:04:51 -0400    

contrib/intarray considers "arraycol <@ constant-array" to be indexable,  
but its GiST opclass code fails to reliably find index entries for empty  
array values (which of course should trivially match such queries).  
This is because the test condition to see whether we should descend  
through a non-leaf node is wrong.  
  
Unfortunately, empty array entries could be anywhere in the index,  
as these index opclasses are currently designed.  So there's no way  
to fix this except by lobotomizing <@ indexscans to scan the whole  
index ... which is what this patch does.  That's pretty unfortunate:  
the performance is now actually worse than a seqscan, in most cases.  
We'd be better off to remove <@ from the GiST opclasses entirely,  
and perhaps a future non-back-patchable patch will do so.  
  
In the meantime, applications whose performance is adversely impacted  
have a couple of options.  They could switch to a GIN index, which  
doesn't have this bug, or they could replace "arraycol <@ constant-array"  
with "arraycol <@ constant-array AND arraycol && constant-array".  
That will provide about the same performance as before, and it will find  
all non-empty subsets of the given constant-array, which is all that  
could reliably be expected of the query before.  
  
While at it, add some more regression test cases to improve code  
coverage of contrib/intarray.  
  
In passing, adjust resize_intArrayType so that when it's returning an  
empty array, it uses construct_empty_array for that rather than  
cowboy hacking on the input array.  While the hack produces an array  
that looks valid for most purposes, it isn't bitwise equal to empty  
arrays produced by other code paths, which could have subtle odd  
effects.  I don't think this code path is performance-critical  
enough to justify such shortcuts.  (Back-patch this part only as far  
as v11; before commit 01783ac36 we were not careful about this in  
other intarray code paths either.)  
  
Back-patch the <@ fixes to all supported versions, since this was  
broken from day one.  
  
Patch by me; thanks to Alexander Korotkov for review.  
  
Discussion: https://postgr.es/m/458.1565114141@sss.pgh.pa.us  

commit   : 4ecd05cb771313d8e4d4007ec02408e5f18de5d2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Aug 2019 17:08:07 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 6 Aug 2019 17:08:07 -0400    

src/test/kerberos and src/test/ldap try to run private authentication  
servers, which of course might fail.  The logs from these servers  
were being dropped into the tmp_check/ subdirectory, but they should  
be put in tmp_check/log/, because the buildfarm will only capture  
log files in that subdirectory.  Without the log output there's  
little hope of diagnosing buildfarm failures related to these servers.  
  
Backpatch to v11 where these test suites were added.  
  
Discussion: https://postgr.es/m/16017.1565047605@sss.pgh.pa.us  

commit   : 940c8b01b071b777ed56c086c383e054fbd0456e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 6 Aug 2019 18:11:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 6 Aug 2019 18:11:02 +0900    

Author: Amit Langote  
Discussion: https://postgr.es/m/CA+HiwqFhZ6ABoz-i=JZ5wMMyz-orx4asjR0og9qBtgEwOww6Yg@mail.gmail.com  

commit   : 98eab30b93d52a114bd65e154cda3402d0630667    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 5 Aug 2019 11:47:34 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 5 Aug 2019 11:47:34 -0700    

Commit a6417078 established a new project policy around OID assignment:  
new patches are encouraged to choose a random OID in the 8000..9999  
range when a manually-assigned OID is required (if multiple OIDs are  
required, a consecutive block of OIDs starting from the random point  
should be used).  Catalog entries added by committed patches that use  
OIDs from this "unstable" range are renumbered after feature freeze.  
This practice minimizes OID collisions among concurrently-developed  
patches.  
  
Show a specific random OID suggestion when the unused_oids script is  
run.  This makes it easy for patch authors to use a random OID from the  
unstable range, per the new policy.  
  
Author: Julien Rouhaud, Peter Geoghegan  
Reviewed-By: Tom Lane  
Discussion: https://postgr.es/m/CAH2-WzkkRs2ScmuBQ7xWi7xzp7fC1B3w0Nt8X+n4rBw5k+Z=zA@mail.gmail.com  

commit   : 4766dce0dd1a1a26db253dfc81773a2c55cd2555    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Aug 2019 11:20:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 5 Aug 2019 11:20:21 -0400    

Commit bf6c614a2 rearranged the lookup of the comparison operators  
needed in a hashed subplan, and in so doing, broke the cross-type  
case: it caused the original LHS-vs-RHS operator to be used to compare  
hash table entries too (which of course are all of the RHS type).  
This leads to C functions being passed a Datum that is not of the  
type they expect, with the usual hazards of crashes and unauthorized  
server memory disclosure.  
  
For the set of hashable cross-type operators present in v11 core  
Postgres, this bug is nearly harmless on 64-bit machines, which  
may explain why it escaped earlier detection.  But it is a live  
security hazard on 32-bit machines; and of course there may be  
extensions that add more hashable cross-type operators, which  
would increase the risk.  
  
Reported by Andreas Seltenreich.  Back-patch to v11 where the  
problem came in.  
  
Security: CVE-2019-10209  

commit   : ffa2d37e5fbd1243f918f622113d6e371667e5a0    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Aug 2019 07:48:41 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 5 Aug 2019 07:48:41 -0700    

Commit aa27977fe21a7dfa4da4376ad66ae37cb8f0d0b5 introduced this  
restriction for pg_temp.function_name(arg); do likewise for types  
created in temporary schemas.  Programs that this breaks should add  
"pg_temp." schema qualification or switch to arg::type_name syntax.  
Back-patch to 9.4 (all supported versions).  
  
Reviewed by Tom Lane.  Reported by Tom Lane.  
  
Security: CVE-2019-10208  

commit   : a76cfba663ceab79b891cc81a5f941051755b3b0    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 15:35:16 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 15:35:16 +0900    

Those data types use parsing and/or calculation wrapper routines which  
can generate some generic error messages in the event of a failure.  The  
caller of these routines can also pass a pointer variable settable by  
the routine to track if an error has happened, letting the caller decide  
what to do in the event of an error and what error message to generate.  
  
Those routines have been slacking the initialization of the tracking  
flag, which can be confusing when reading the code, so add some  
safeguards against calls of these parsing routines which could lead to a  
dubious result.  
  
The LSN parsing gains an assertion to make sure that the tracking flag  
is set, while numeric and float paths initialize the flag to a saner  
state.  
  
Author: Jeevan Ladhe  
Reviewed-by: Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/CAOgcT0NOM9oR0Hag_3VpyW0uF3iCU=BDUFSPfk9JrWXRcWQHqw@mail.gmail.com  

commit   : 05ba8370b8e4b5c8f3dd51986b9fdeb43fed5610    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 14:27:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 14:27:20 +0900    

OWNER_TO was used for the completion, which is not a supported grammar,  
but OWNER TO is.  
  
This error has been introduced by d37b816, so backpatch down to 9.6.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/7ab243e0-116d-3e44-d120-76b3df7abefd@gmail.com  
Backpatch-through: 9.6  

commit   : 8548ddc61b5858b6466e69f66a6b1a7ea9daef06    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 12:14:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 5 Aug 2019 12:14:58 +0900    

This addresses more issues with code comments, variable names and  
unreferenced variables.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/7ab243e0-116d-3e44-d120-76b3df7abefd@gmail.com  

commit   : 75506195da81d75597a4025b72f8367e6c45f60d    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Aug 2019 20:29:00 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Aug 2019 20:29:00 +0200    

This reverts commit 88bdbd3f746049834ae3cc972e6e650586ec3c9d.  
  
As committed, statement sampling used the existing duration threshold  
(log_min_duration_statement) when decide which statements to sample.  
The issue is that even the longest statements are subject to sampling,  
and so may not end up logged. An improvement was proposed, introducing  
a second duration threshold, but it would not be backwards compatible.  
So we've decided to revert this feature - the separate threshold should  
be part of the feature itself.  
  
Discussion: https://postgr.es/m/CAFj8pRDS8tQ3Wviw9%3DAvODyUciPSrGeMhJi_WPE%2BEB8%2B4gLL-Q%40mail.gmail.com  

commit   : 4f9ed8f3c5ef0034c98dd34549f85d8c72aab9ad    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Aug 2019 20:19:54 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sun, 4 Aug 2019 20:19:54 +0200    

This reverts commit 9dc122585551516309c9362e673effdbf3bd79bd.  
  
As committed, statement sampling used the existing duration threshold  
(log_min_duration_statement) when decide which statements to sample.  
The issue is that even the longest statements are subject to sampling,  
and so may not end up logged. An improvement was proposed, introducing  
a second duration threshold, but it would not be backwards compatible.  
So we've decided to revert this feature - the separate threshold should  
be part of the feature itself.  
  
Discussion: https://postgr.es/m/CAFj8pRDS8tQ3Wviw9%3DAvODyUciPSrGeMhJi_WPE%2BEB8%2B4gLL-Q%40mail.gmail.com  

commit   : e0f5048851ff88a53630a0c121a1cd15f6a2f1cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 14:05:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 14:05:34 -0400    

Perl has multiple internal representations of "undef", and just  
testing for SvTYPE(x) == SVt_NULL doesn't recognize all of them,  
leading to "cannot transform this Perl type to jsonb" errors.  
Use the approved test SvOK() instead.  
  
Report and patch by Ivan Panchenko.  Back-patch to v11 where  
this module was added.  
  
Discussion: https://postgr.es/m/1564783533.324795401@f193.i.mail.ru  

commit   : 803466b6ffaa2e5b94d8ce4d7fffa8185f2a0184    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 13:07:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 4 Aug 2019 13:07:12 -0400    

src/test/kerberos and src/test/ldap need to run a private authentication  
server of the relevant type, for which they need a free TCP port.  
They were just picking a random port number in 48K-64K, which works  
except when something's already using the particular port.  Notably,  
the probability of failure rises dramatically if one simply runs those  
tests in a tight loop, because each test cycle leaves behind a bunch of  
high ports that are transiently in TIME_WAIT state.  
  
To fix, split out the code that PostgresNode.pm already had for  
identifying a free TCP port number, so that it can be invoked to choose  
a port for the KDC or LDAP server.  This isn't 100% bulletproof, since  
conceivably something else on the machine could grab the port between  
the time we check and the time we actually start the server.  But that's  
a pretty short window, so in practice this should be good enough.  
  
Back-patch to v11 where these test suites were added.  
  
Patch by me, reviewed by Andrew Dunstan.  
  
Discussion: https://postgr.es/m/3397.1564872168@sss.pgh.pa.us  

commit   : 489247b0e615592111226297a0564e11616361a5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 4 Aug 2019 11:18:45 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sun, 4 Aug 2019 11:18:45 -0400    

When querying a partitioned table containing a default partition, we  
were wrongly deciding to include it in the scan too early in the  
process, failing to exclude it in some cases.  If we reinterpret the  
PruneStepResult.scan_default flag slightly, we can do a better job at  
detecting that it can be excluded.  The change is that we avoid setting  
the flag for that pruning step unless the step absolutely requires the  
default partition to be scanned (in contrast with the previous  
arrangement, which was to set it unless the step was able to prune it).  
So get_matching_partitions() must explicitly check the partition that  
each returned bound value corresponds to in order to determine whether  
the default one needs to be included, rather than relying on the flag  
from the final step result.  
  
Author: Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>  
Reviewed-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>  
Discussion: https://postgr.es/m/00e601d4ca86$932b8bc0$b982a340$@lab.ntt.co.jp  

commit   : 69edf4f8802247209e77f69e089799b3d83c13a4    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 4 Aug 2019 11:18:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 4 Aug 2019 11:18:57 +0900    

This portion of the code got forgotten in 7cce159 which has introduced a  
new routine to build this node, and this finishes the unification of the  
places where IndexInfo is initialized.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20190801041322.GA3435@paquier.xyz  

commit   : 2abd7ae9b20bcd810d4f19d28aefb97048813825    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Aug 2019 00:02:46 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 2 Aug 2019 00:02:46 -0700    

In 5f32b29c1819 I changed the creation of HashState.hashkeys to  
actually use HashState as the parent (instead of HashJoinState, which  
was incorrect, as they were executed below HashState), to fix the  
problem of hashkeys expressions otherwise relying on slot types  
appropriate for HashJoinState, rather than HashState as would be  
correct. That reliance was only introduced in 12, which is why it  
previously worked to use HashJoinState as the parent (although I'd be  
unsurprised if there were problematic cases).  
  
Unfortunately that's not a sufficient solution, because before this  
commit, the to-be-hashed expressions referenced inner/outer as  
appropriate for the HashJoin, not Hash. That didn't have obvious bad  
consequences, because the slots containing the tuples were put into  
ecxt_innertuple when hashing a tuple for HashState (even though Hash  
doesn't have an inner plan).  
  
There are less common cases where this can cause visible problems  
however (rather than just confusion when inspecting such executor  
trees). E.g. "ERROR: bogus varno: 65000", when explaining queries  
containing a HashJoin where the subsidiary Hash node's hash keys  
reference a subplan. While normally hashkeys aren't displayed by  
EXPLAIN, if one of those expressions references a subplan, that  
subplan may be printed as part of the Hash node - which then failed  
because an inner plan was referenced, and Hash doesn't have that.  
  
It seems quite possible that there's other broken cases, too.  
  
Fix the problem by properly splitting the expression for the HashJoin  
and Hash nodes at plan time, and have them reference the proper  
subsidiary node. While other workarounds are possible, fixing this  
correctly seems easy enough. It was a pretty ugly hack to have  
ExecInitHashJoin put the expression into the already initialized  
HashState, in the first place.  
  
I decided to not just split inner/outer hashkeys inside  
make_hashjoin(), but also to separate out hashoperators and  
hashcollations at plan time. Otherwise we would have ended up having  
two very similar loops, one at plan time and the other during executor  
startup. The work seems to more appropriately belong to plan time,  
anyway.  
  
Reported-By: Nikita Glukhov, Alexander Korotkov  
Author: Andres Freund  
Reviewed-By: Tom Lane, in an earlier version  
Discussion: https://postgr.es/m/CAPpHfdvGVegF_TKKRiBrSmatJL2dR9uwFCuR+teQ_8tEXU8mxg@mail.gmail.com  
Backpatch: 12-  

commit   : a9f301df0e76c38d4544477c1b3e5e29d57904e6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Aug 2019 09:51:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 2 Aug 2019 09:51:12 +0900    

This fixes one warning generated by GCC and present in the test case  
array part of ECPG.  This likely got missed in past fixes like 3a4b891  
because the compilation of those tests is not done by default.  
  
Reported-by: Sergei Kornilov  
Discussion: https://postgr.es/m/14951331562847675@sas2-a1efad875d04.qloud-c.yandex.net  

commit   : 6ae4e8eae78e0781633f7b40a1b5cc189bc40923    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 1 Aug 2019 14:52:43 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 1 Aug 2019 14:52:43 -0700    

Add _lookup_hash and _insert_hash functions for callers that have  
already calculated the hash value of the key.  
  
The immediate use case is for hash algorithms that write to disk in  
partitions. The hash value can be calculated once, used to perform a  
lookup, used to select the partition, then written to the partition  
along with the tuple. When the tuple is read back, the hash value does  
not need to be recalculated.  
  
Author: Jeff Davis  
Reviewed-by: Andres Freund  
Discussion: https://postgr.es/m/48abe675e1330f0c264ab2fe0d4ff23eb244f9ef.camel%40j-davis.com  

commit   : 7266d0997dd2a0632da38a594c78e25ff21df67e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Aug 2019 18:50:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Aug 2019 18:50:22 -0400    

This allows simplification of the plan tree in some common usage  
patterns: we can get rid of a join to the function RTE.  
  
In principle we could pull up any immutable expression, but restricting  
it to Consts avoids the risk that multiple evaluations of the expression  
might cost more than we can save.  (Possibly this could be improved in  
future --- but we've more or less promised people that putting a function  
in FROM guarantees single evaluation, so we'd have to tread carefully.)  
  
To do this, we need to rearrange when eval_const_expressions()  
happens for expressions in function RTEs.  I moved it to  
inline_set_returning_functions(), which already has to iterate over  
every function RTE, and in consequence renamed that function to  
preprocess_function_rtes().  A useful consequence is that  
inline_set_returning_function() no longer has to do this for itself,  
simplifying that code.  
  
In passing, break out pull_up_simple_subquery's code that knows where  
everything that needs pullup_replace_vars() processing is, so that  
the new pull_up_constant_function() routine can share it.  We'd  
gotten away with one-and-a-half copies of that code so far, since  
pull_up_simple_values() could assume that a lot of cases didn't apply  
to it --- but I don't think pull_up_constant_function() can make any  
simplifying assumptions.  Might as well make pull_up_simple_values()  
use it too.  
  
(Possibly this refactoring should go further: maybe we could share  
some of the code to fill in the pullup_replace_vars_context struct?  
For now, I left it that the callers fill that completely.)  
  
Note: the one existing test case that this patch changes has to be  
changed because inlining its function RTEs would destroy the point  
of the test, namely to check join order.  
  
Alexander Kuzmenkov and Aleksandr Parfenov, reviewed by  
Antonin Houska and Anastasia Lubennikova, and whacked around  
some more by me  
  
Discussion: https://postgr.es/m/402356c32eeb93d4fed01f66d6c7fe2d@postgrespro.ru  

commit   : a8d6a95eb992e942838e41029537564d81c4a50e    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 1 Aug 2019 12:29:19 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 1 Aug 2019 12:29:19 -0700    

Oversight in commit 71dcd743.  

commit   : 71dcd7438664d81235c72337cbbbfa780f7a0630    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 1 Aug 2019 09:34:14 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 1 Aug 2019 09:34:14 -0700    

Add sort support for inet, including support for abbreviated keys.  
Testing has shown that this reduces the time taken to sort medium to  
large inet/cidr inputs by ~50-60% in realistic cases.  
  
Author: Brandur Leach  
Reviewed-By: Peter Geoghegan, Edmund Horner  
Discussion: https://postgr.es/m/CABR_9B-PQ8o2MZNJ88wo6r-NxW2EFG70M96Wmcgf99G6HUQ3sw@mail.gmail.com  

commit   : da9456d22a7697ef2c5ba9dd1402d948b2ec7f09    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Aug 2019 11:50:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Aug 2019 11:50:00 -0400    

Commit a1c1af2a1 added logic in the deadlock checker to handle lock  
grouping, but it was very poorly tested, as evidenced by the bug  
fixed in 3420851a2.  Add a test case that exercises that a bit better  
(and catches the bug --- if you revert 3420851a2, this will hang).  
  
Since it's pretty hard to get parallel workers to take exclusive  
regular locks that their parents don't already have, this test operates  
by creating a deadlock among advisory locks taken in parallel workers.  
To make that happen, we must override the parallel-safety labeling of  
the advisory-lock functions, which we do by putting them in mislabeled,  
non-inlinable wrapper functions.  
  
We also have to remove the redundant PreventAdvisoryLocksInParallelMode  
checks in lockfuncs.c.  That seems fine though; if some user accidentally  
does what this test is intentionally doing, not much harm will ensue.  
(If there are any remaining bugs that are reachable that way, they're  
probably reachable in other ways too.)  
  
Discussion: https://postgr.es/m/3243.1564437314@sss.pgh.pa.us  

commit   : 4886da8327507dddd830786b0c7aaa9cfc480b4b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Aug 2019 11:36:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 1 Aug 2019 11:36:21 -0400    

There seems no good reason not to allow a parallel leader to execute  
these functions.  (The workers still can't, though.  Although the code  
would work, any such lock would go away at worker exit, which is not  
the documented behavior of advisory locks.)  
  
Discussion: https://postgr.es/m/11847.1564496844@sss.pgh.pa.us  

commit   : fd6ec93bf890314ac694dc8a7f3c45702ecc1bbd    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Aug 2019 11:05:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 1 Aug 2019 11:05:08 +0200    

In some cases we have elog(ERROR) while corruption is certain and we  
can give a clear error code ERRCODE_DATA_CORRUPTED or  
ERRCODE_INDEX_CORRUPTED.  
  
Author: Andrey Borodin <x4mmm@yandex-team.ru>  
Discussion: https://www.postgresql.org/message-id/flat/25F6C686-6442-4A6B-BAF8-A6F7B84B16DE@yandex-team.ru  

commit   : b2a3d706b8d76b9d65e953942fc1ccafe892f692    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 Aug 2019 09:37:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 1 Aug 2019 09:37:28 +0900    

When piling up loading of modules using check_password_hook_type,  
loading passwordcheck would remove any trace of a previously-loaded  
hook.  Unloading the module would also cause previous hooks to be  
entirely gone.  
  
Reported-by: Rafael Castro  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/15932-78f48f9ef166778c@postgresql.org  
Backpatch-through: 9.4  

commit   : 07b39083c2aca003c4b1f289d7dc2368b5e2297a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Jul 2019 15:42:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 31 Jul 2019 15:42:49 -0400    

Since pg_dump doesn't treat the member operators and functions of operator  
classes/families (that is, the pg_amop and pg_amproc entries, not the  
underlying operators/functions) as separate dumpable objects, it missed  
their dependency information.  I think this was safe when the code was  
designed, because the default object sorting rule emits operators and  
functions before opclasses, and there were no dependency types that could  
mess that up.  However, the introduction of range types in 9.2 broke it:  
now a type can have a dependency on an opclass, allowing dependency rules  
to push the opclass before the type and hence before custom operators.  
Lacking any information showing that it shouldn't do so, pg_dump emitted  
the objects in the wrong order.  
  
Fix by teaching getDependencies() to translate pg_depend entries for  
pg_amop/amproc rows to look like dependencies for their parent opfamily.  
  
I added a regression test for this in HEAD/v12, but not further back;  
life is too short to fight with 002_pg_dump.pl.  
  
Per bug #15934 from Tom Gottfried.  Back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/15934-58b8c8ab7a09ea15@postgresql.org  

commit   : f140007050a2ba874b85c4578d8417828f4b64b6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Jul 2019 09:42:15 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 31 Jul 2019 09:42:15 +0200    

The tests collate.icu.utf8 and collate.linux.utf8 were previously only  
run when explicitly selected via EXTRA_TESTS.  They require a UTF8  
database, because the error messages in the expected files refer to  
that, and they use some non-ASCII characters in the tests.  Since  
users can select any locale and encoding for the regression test run,  
it was not possible to include these tests automatically.  
  
To fix, use psql's \if facility to check various prerequisites such as  
platform and the server encoding and quit the tests at the very  
beginning if the configuration is not adequate.  We then need to  
maintain alternative expected files for these tests, but they are very  
tiny and never need to change after this.  
  
These two tests are now run automatically as part of the regression  
tests.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/052295c2-a2e1-9a21-bd36-8fbff8686cf3%402ndquadrant.com  

commit   : 870b1d6800cc2173ab672449047efbc30bdc1b57    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 31 Jul 2019 00:05:21 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 31 Jul 2019 00:05:21 -0700    

These were introduced by pgindent due to fixe to broken  
indentation (c.f. 8255c7a5eeba8). Previously the mis-indentation of  
function prototypes was creatively used to reduce indentation in a few  
places.  
  
As that formatting only exists in master and REL_12_STABLE, it seems  
better to fix it in both, rather than having some odd indentation in  
v12 that somebody might copy for future patches or such.  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20190728013754.jwcbe5nfyt3533vx@alap3.anarazel.de  
Backpatch: 12-  

commit   : 6384e87be28ee8d69ef11e49413b115506a3c6d3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 30 Jul 2019 18:29:55 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 30 Jul 2019 18:29:55 -0700    

Author: Andres Freund  

commit   : 652a8947d981db0367bcff5b123545eba0049878    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 31 Jul 2019 10:18:29 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 31 Jul 2019 10:18:29 +0900    

int_name has never been used for digest lookups since its introduction  
in e94dd6a.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/386C26CB-628B-4A4C-8879-D8BF190F2C77@yesql.se  

commit   : a29834beb1deeb0aa06742dd77ba1d21b444ca44    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jul 2019 21:43:27 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jul 2019 21:43:27 +0300    

The rd_amcache allows an index AM to cache arbitrary information in a  
relcache entry. This commit moves the cleanup of rd_amcache so that it  
can also be used by table AMs. Nothing takes advantage of that yet, but  
I'm sure it'll come handy for anyone writing new table AMs.  
  
Backpatch to v12, where table AM interface was introduced.  
  
Reviewed-by: Julien Rouhaud  

commit   : d8b094dabb0fa16388340ca823d0a38285d2d6ce    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jul 2019 21:14:14 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 30 Jul 2019 21:14:14 +0300    

This has been wrong ever since pg_rewind was added. The if-branch just  
above this, where we print the same error with an extra message supplied  
by XLogReadRecord() got this right, but the variable name was wrong in the  
else-branch. As a consequence, the error printed the WAL position as  
0/0 if there was an error reading a WAL file.  
  
Backpatch to 9.5, where pg_rewind was added.  

commit   : 14ef15a22246ca17c949e7a9d1abe14c8874d743    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 30 Jul 2019 19:17:12 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 30 Jul 2019 19:17:12 +0200    

When performing ANALYZE on inheritance trees, we collect two samples for  
each relation - one for the relation alone, and one for the inheritance  
subtree (relation and its child relations). And then we build statistics  
on each sample, so for each relation we get two sets of statistics.  
  
For regular (per-column) statistics this works fine, because the catalog  
includes a flag differentiating statistics built from those two samples.  
But we don't have such flag in the extended statistics catalogs, and we  
ended up updating the same row twice, triggering this error:  
  
  ERROR:  tuple already updated by self  
  
The simplest solution is to disable extended statistics on inheritance  
trees, which is what this commit is doing. In the future we may need to  
do something similar to per-column statistics, but that requires adding a  
flag to the catalog - and that's not backpatchable. Moreover, the current  
selectivity estimation code only works with individual relations, so  
building statistics on inheritance trees would be pointless anyway.  
  
Author: Tomas Vondra  
Backpatch-to: 10-  
Discussion: https://postgr.es/m/20190618231233.GA27470@telsasoft.com  
Reported-by: Justin Pryzby  

commit   : 04cf0bfc90dfae89a794d2bdd88fe3b8e313798e    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 30 Jul 2019 10:54:48 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 30 Jul 2019 10:54:48 +0900    

When building a list of relations for a parallel processing of a schema  
or a database (or just a single-entry list for the non-parallel case  
with the database name), the list is allocated and built on-the-fly for  
each database processed, leaking after one database-level reindex is  
done.  This accumulates leaks when processing all databases, and could  
become a visible issue with thousands of relations.  
  
This is fixed by introducing a new routine in simple_list.c to free all  
the elements in a simple list made of strings or OIDs.  The header of  
the list may be using a variable declaration or an allocated pointer,  
so we don't have a routine to free this part to keep the interface  
simple.  
  
Per report from coverity for an issue introduced by 5ab892c, and  
valgrind complains about the leak as well.  The idea to introduce a new  
routine in simple_list.c is from Tom Lane.  
  
Author: Michael Paquier  
Reviewed-by: Tom Lane  

commit   : 3420851a2c2d2ac49b8ba53ccec5d02aa1e6a272    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jul 2019 18:49:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 29 Jul 2019 18:49:04 -0400    

A "break" statement erroneously left behind by commit a1c1af2a1  
caused TopoSort to do the wrong thing if a lock's wait list  
contained multiple members of the same locking group.  
  
Because parallel workers don't normally need any locks not already  
taken by their leader, this is very hard --- maybe impossible ---  
to hit in production.  Still, if it did happen, the queries involved  
in an otherwise-resolvable deadlock would block until canceled.  
  
In addition to removing the bogus "break", add an Assert showing  
that the conflicting uses of the beforeConstraints[] array (for both  
counts and flags) don't overlap, and add some commentary explaining  
why not; because it's not obvious without explanation, IMHO.  
  
Original report and patch from Rui Hai Jiang; additional assert  
and commentary by me.  Back-patch to 9.6 where the bug came in.  
  
Discussion: https://postgr.es/m/CAEri+mLd3bpHLyW+a9pSe1y=aEkeuJpwBSwvo-+m4n7-ceRmXw@mail.gmail.com  

commit   : 1e2fddfa33d3c7cc93ca3ee0f32852699bd3e012    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Jul 2019 07:41:06 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 29 Jul 2019 07:41:06 +0200    

It is not safe to simply report an fsync error and continue.  We must  
exit the program instead.  
  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Sehrope Sarkuni <sehrope@jackdb.com>  
Discussion: https://www.postgresql.org/message-id/flat/9b49fe44-8f3e-eca9-5914-29e9e99030bf@2ndquadrant.com  

commit   : eb43f3d19324d7e5376b1f57fc2e5c142a6b5f3d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 29 Jul 2019 12:28:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 29 Jul 2019 12:28:30 +0900    

This is numbered take 8, and addresses again a set of issues with code  
comments, variable names and unreferenced variables.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/b137b5eb-9c95-9c2f-586e-38aba7d59788@gmail.com  

commit   : 7cce159349ccdb39ade07f869f08e4929ef2fe0b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 29 Jul 2019 09:58:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 29 Jul 2019 09:58:49 +0900    

When copying the definition of an index rebuilt concurrently for the new  
entry, the index information was taken directly from the old index using  
the relation cache.  In this case, predicates and expressions have  
some post-processing to prepare things for the planner, which loses some  
information including the collations added in any of them.  
  
This inconsistency can cause issues when attempting for example a table  
rewrite, and makes the new indexes rebuilt concurrently inconsistent  
with the old entries.  
  
In order to fix the problem, fetch expressions and predicates directly  
from the catalog of the old entry, and fill in IndexInfo for the new  
index with that.  This makes the process more consistent with  
DefineIndex(), and the code is refactored with the addition of a routine  
to create an IndexInfo node.  
  
Reported-by: Manuel Rigger  
Author: Michael Paquier  
Discussion: https://postgr.es/m/CA+u7OA5Hp0ra235F3czPom_FyAd-3+XwSJmX95r1+sRPOJc9VQ@mail.gmail.com  
Backpatch-through: 12  

commit   : a2a777d011971ace3a349a3f02b1bf6eeea07bf2    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 29 Jul 2019 10:12:37 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 29 Jul 2019 10:12:37 +1200    

Early previews of LLVM 9 reveal that our Min() macro causes compiler  
errors in LLVM headers reached by the #include directives in  
llvmjit_inline.cpp.  Let's just undefine it.  Per buildfarm animal  
seawasp.  Back-patch to 11.  
  
Reviewed-by: Fabien Coelho, Tom Lane  
Discussion: https://postgr.es/m/20190606173216.GA6306%40alvherre.pgsql  

commit   : b10f40bf0e4516d7832db8ccbe5f76319ad08682    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Jul 2019 12:02:27 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 28 Jul 2019 12:02:27 -0400    

We had no actual end-to-end test of NOTIFY message delivery.  In the  
core async.sql regression test, testing this is problematic because psql  
traditionally prints the PID of the sending backend, making the output  
unstable.  We also have an isolation test script, but it likewise  
failed to prove that delivery worked, because isolationtester.c had  
no provisions for detecting/reporting NOTIFY messages.  
  
Hence, add such provisions to isolationtester.c, and extend  
async-notify.spec to include direct tests of basic NOTIFY functionality.  
  
I also added tests showing that NOTIFY de-duplicates messages normally,  
but not across subtransaction boundaries.  (That's the historical  
behavior since we introduced subtransactions, though perhaps we ought  
to change it.)  
  
Patch by me, with suggestions/review by Andres Freund.  
  
Discussion: https://postgr.es/m/31304.1564246011@sss.pgh.pa.us  

commit   : 44460d7017cde005d7a2e246db0b32375bfec15d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 28 Jul 2019 22:02:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 28 Jul 2019 22:02:15 +0900    

The table has not been updated for some commands introduced in recent  
releases, so refresh it.  While on it, reorder entries alphabetically.  
  
Backpatch all the way down for all the commands which have gone  
missing.  
  
Reported-by: Jeremy Smith  
Discussion: https://postgr.es/m/15883-afff0ea3cc2dbbb6@postgresql.org  
Backpatch-through: 9.4  

commit   : b7a82317b66362880c16f1bd49573ab34f0dad1f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 28 Jul 2019 16:21:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 28 Jul 2019 16:21:53 +0900    

The frontend version of walkdir() is defined in file_utils.c, and not  
initdb.c.  
  
Author: Sehrope Sarkuni  
Discussion: https://postgr.es/m/CAH7T-artawnBt4=KODNCD8Mt2ZX4CCjJT8c=_=950xjutcRZ4Q@mail.gmail.com  

commit   : 30717637c1c58fcd02980a6752c7e13c9de12b69    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jul 2019 20:21:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jul 2019 20:21:54 -0400    

If a test sends a notice just before blocking, it's possible on  
slow machines for isolationtester to detect the blocked state before  
it's consumed the notice.  (For this to happen, the notice would have  
to arrive after isolationtester has waited for data for 10ms, so on  
fast/lightly-loaded machines it's hard to reproduce the failure.)  
But, if we have seen the backend as blocked, it's certainly already  
sent any notices it's going to send.  Therefore, one more round of  
PQconsumeInput and PQisBusy should be enough to collect and process  
any such notices.  
  
This appears to explain the instability noted in commit ebd499282, so undo  
the hack therein to not print notices from insert-conflict-specconflict.  
  
Patch by me, diagnosis by Andres Freund.  
  
Discussion: https://postgr.es/m/14616.1564251339@sss.pgh.pa.us  

commit   : ebd49928215e3854d91167e798949a75b34958d0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jul 2019 15:59:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 27 Jul 2019 15:59:57 -0400    

For its entire existence, isolationtester.c has forced client_min_messages  
to WARNING, but that seems like a very poor choice of test design.  It  
should be up to individual test scripts to manage whether they emit notices  
and to ensure that the results are stable.  (There were no NOTICE messages  
in the original set of isolation tests, so this was certainly dead code  
when committed, but perhaps it was needed at some earlier point.)  
  
It's possible that the original motivation was due to platform-dependent  
variations in the timing of stdout vs. stderr output.  That should be  
moot since commits 73bcb76b7/6eda3e9c2, but just in case, adjust  
isotesterNoticeProcessor to print to stdout not stderr.  (stderr seems  
like the wrong thing anyway: it should be for error printouts not expected  
test output.)  
  
Testing shows that the notices in insert-conflict-specconflict are indeed  
a bit timing-unstable on very slow machines, so hide them; maybe we can  
improve that later.  Also, make the notices in plpgsql-toast a bit less  
verbose than the original code would've had them.  
  
Discussion: https://postgr.es/m/14616.1564251339@sss.pgh.pa.us  

commit   : 5ab892c391c6bc54a00e7a8de5cab077cabace6a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 27 Jul 2019 22:21:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 27 Jul 2019 22:21:18 +0900    

When doing a schema-level or a database-level operation, a list of  
relations to build is created which gets processed in parallel using  
multiple connections, based on the recent refactoring for parallel slots  
in src/bin/scripts/.  System catalogs are processed first in a  
serialized fashion to prevent deadlocks, followed by the rest done in  
parallel.  
  
This new option is not compatible with --system as reindexing system  
catalogs in parallel can lead to deadlocks, and with --index as there is  
no conflict handling for indexes rebuilt in parallel depending in the  
same relation.  
  
Author: Julien Rouhaud  
Reviewed-by: Sergei Kornilov, Michael Paquier  
Discussion: https://postgr.es/m/CAOBaU_YrnH_Jqo46NhaJ7uRBiWWEcS40VNRQxgFbqYo9kApUsg@mail.gmail.com  

commit   : 4552c0f566667160ab3eeaf1620ebb969c1e7eb0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 08:26:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 08:26:33 +0200    

Recently released xfsprogs 5.1.0 has reflink support enabled by  
default, so the note that it's not enabled by default can be removed.  

commit   : 959f6d6a1821b7d9068244f500dd80953e768d16    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 07:56:20 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 07:56:20 +0200    

Make the directory where the pg_upgrade binary resides the default for  
new bindir, as running the pg_upgrade binary from where the new  
cluster is installed is a very common scenario.  Setting this as the  
defauly bindir for the new cluster will remove the need to provide it  
explicitly via -B in many cases.  
  
To support directories being missing from option parsing, extend the  
directory check with a missingOk mode where the path must be filled at  
a later point before being used.  Also move the exec_path check to  
earlier in setup to make sure we know the new cluster bindir when we  
scan for required executables.  
  
This removes the exec_path from the OSInfo struct as it is not used  
anywhere.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/9328.1552952117@sss.pgh.pa.us  

commit   : 0befb4f31386efb622e4df9f3a313aa1f2e17899    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 07:48:08 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 07:48:08 +0200    

Expand the validate_exec() calls to cover all the used binaries.  
  
Author: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/9328.1552952117@sss.pgh.pa.us  

commit   : 28cb0555c1153a0dcdf1c908d7265acafa413b57    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 07:46:02 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 27 Jul 2019 07:46:02 +0200    

Author: Daniel Gustafsson <daniel@yesql.se>  

commit   : 0994cfc0ac853de4245f003698160fe1b8c577bd    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Jul 2019 17:46:40 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 26 Jul 2019 17:46:40 -0400    

Per gripe from Ian Barwick  
  
Co-authored-by: Ian Barwick <ian@2ndquadrant.com>  
Discussion: https://postgr.es/m/CABvVfJWNnNKb8cHsTLhkTsvL1+G6BVcV+57+w1JZ61p8YGPdWQ@mail.gmail.com  

commit   : 8ab66081ca496fd74c406e435e20f4264881a02d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 13:07:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 13:07:08 -0400    

pg_timezone_names() tries to avoid showing the "Factory" zone in  
the view, mainly because that has traditionally had a very long  
"abbreviation" such as "Local time zone must be set--see zic manual page",  
so that showing it messes up psql's formatting of the whole view.  
Since tzdb version 2016g, IANA instead uses the abbreviation "-00",  
which is sane enough that there's no reason to discriminate against it.  
  
On the other hand, it emerges that FreeBSD and possibly other packagers  
are so wedded to backwards compatibility that they hack the IANA data  
to keep the old spelling --- and not just that old spelling, but even  
older spellings that IANA used back in the stone age.  This caused the  
filter logic to fail to suppress "Factory" at all on such platforms,  
though the formatting problem is definitely real in that case.  
  
To solve both problems, get rid of the hard-wired assumption about  
exactly what Factory's abbreviation is, and instead reject abbreviations  
exceeding 31 characters.  This will allow Factory to appear in the view  
if and only if it's using the modern abbreviation.  
  
In passing, simplify the code we add to zic.c to support "zic -P"  
to remove its now-obsolete hacks to not print the Factory zone's  
abbreviation.  Unlike pg_timezone_names(), there's no reason for  
that code to support old/nonstandard timezone data.  
  
Since we generally prefer to keep timezone-related behavior the  
same in all branches, and since this is arguably a bug fix,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/3961.1564086915@sss.pgh.pa.us  

commit   : 3754113f33651965d92aaad6f393757ac0cf8333    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 12:45:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 12:45:32 -0400    

Some platforms create a file named "localtime" in the system  
timezone directory, making it a copy or link to the active time  
zone file.  If Postgres is built with --with-system-tzdata, initdb  
will see that file as an exact match to localtime(3)'s behavior,  
and it may decide that "localtime" is the most preferred spelling of  
the active zone.  That's a very bad choice though, because it's  
neither informative, nor portable, nor stable if someone changes  
the system timezone setting.  Extend the preference logic added by  
commit e3846a00c so that we will prefer any other zone file that  
matches localtime's behavior over "localtime".  
  
On the same logic, also discriminate against "posixrules", which  
is another not-really-a-zone file that is often present in the  
timezone directory.  (Since we install "posixrules" but not  
"localtime", this change can affect the behavior of Postgres  
with or without --with-system-tzdata.)  
  
Note that this change doesn't prevent anyone from choosing these  
pseudo-zones if they really want to (i.e., by setting TZ for initdb,  
or modifying the timezone GUC later on).  It just prevents initdb  
from preferring these zone names when there are multiple matches to  
localtime's behavior.  
  
Since we generally prefer to keep timezone-related behavior the  
same in all branches, and since this is arguably a bug fix,  
back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/CADT4RqCCnj6FKLisvT8tTPfTP4azPhhDFJqDF1JfBbOH5w4oyQ@mail.gmail.com  
Discussion: https://postgr.es/m/27991.1560984458@sss.pgh.pa.us  

commit   : b9d2c5c7ac800bf20ea6cd4c556b6b3305863a8e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 11:59:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 26 Jul 2019 11:59:00 -0400    

Money values exceeding about 18 digits (depending on lc_monetary)  
could be inaccurately converted to numeric, due to select_div_scale()  
deciding it didn't need to compute any fractional digits.  Force  
its hand by setting the dscale of one division input to equal the  
number of fractional digits we need.  
  
In passing, rearrange the logic to not do useless work in locales  
where money values are considered integral.  
  
Per bug #15925 from Slawomir Chodnicki.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/15925-da9953e2674bb5c8@postgresql.org  

commit   : e829337d42d0e3c73ba9f380e81e51aab4865f8f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 17:23:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 17:23:36 +0200    

Turn most mentions of libpq functions into links.  At id attributes to  
most libpq functions, where not existing yet, so that they can be  
linked to.  (In a handful of cases there were problems with the PDF  
processing toolchain, so those instances were not changed.)  
  
Author: Fabien COELHO <coelho@cri.ensmp.fr>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/alpine.DEB.2.21.1905121032330.27203@lancre  

commit   : f4100839a00a9fffb19e70ed2e3c6a73ce2a5259    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 16:50:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 16:50:42 +0200    

When making an xref to a varlistentry, the stylesheets use the first  
<term> as the link text.  In the cases fixed here, the <term> element  
contained extra whitespace that ended up being part of the link text,  
which looked strange in the output in some cases.  This whitespace is  
significant, so remove it since we don't want it.  

commit   : 2e32a7711a8a6e3020c9fb431705dadaed305120    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 14:04:48 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 14:04:48 +0200    

Discussion: https://www.postgresql.org/message-id/517abe28-8a93-5b7a-ff40-b1fd61d33b26%402ndquadrant.com  

commit   : d0f5d25b393747157d35c775e0942a0c68957823    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 14:43:13 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 14:43:13 +0200    

The ids for linking to libpq functions were previously all lower-case.  
Change to mixed-case, matching the actual function name, for easier  
readability in the source.  The output isn't changed in a significant  
way, since the ids are converted to lower or upper case for file names  
and anchors.  

commit   : 27cd521e6e7084516fbc5e5a8492316b3ba8c25c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 26 Jul 2019 10:01:18 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Fri, 26 Jul 2019 10:01:18 +1200    

After starting slapd, wait until it can accept a connection before  
beginning the real test work.  This avoids occasional test failures.  
Back-patch to 11, where the LDAP tests arrived.  
  
Author: Thomas Munro  
Reviewed-by: Michael Paquier  
Discussion: https://postgr.es/m/20190719033013.GI1859%40paquier.xyz  

commit   : f63d9e68d4132a4608e9f50782aaacbe5ed6f57a    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Jul 2019 14:52:36 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Jul 2019 14:52:36 -0700    

Backpatch: 12-, like the previous commit  

commit   : af3deff3f2ac79585481181cb198b04c67486c09    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Jul 2019 14:22:52 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 25 Jul 2019 14:22:52 -0700    

Since 15d8f8312 we assert that - and since 7ef04e4d2cb2, 4da597edf1  
rely on - the slot type for an expression's  
ecxt_{outer,inner,scan}tuple not changing, unless explicitly flagged  
as such. That allows to either skip deforming (for a virtual tuple  
slot) or optimize the code for JIT accelerated deforming  
appropriately (for other known slot types).  
  
This assumption was sometimes violated for grouping sets, when  
nodeAgg.c internally uses tuplesorts, and the child node doesn't  
return a TTSOpsMinimalTuple type slot. Detect that case, and flag that  
the outer slot might not be "fixed".  
  
It's probably worthwhile to optimize this further in the future, and  
more granularly determine whether the slot is fixed. As we already  
instantiate per-phase transition and equal expressions, we could  
cheaply set the slot type appropriately for each phase.  But that's a  
separate change from this bugfix.  
  
This commit does include a very minor optimization by avoiding to  
create a slot for handling tuplesorts, if no such sorts are  
performed. Previously we created that slot unnecessarily in the common  
case of computing all grouping sets via hashing. The code looked too  
confusing without that, as the conditions for needing a sort slot and  
flagging that the slot type isn't fixed, are the same.  
  
Reported-By: Ashutosh Sharma  
Author: Andres Freund  
Discussion: https://postgr.es/m/CAE9k0PmNaMD2oHTEAhRyxnxpaDaYkuBYkLa1dpOpn=RS0iS2AQ@mail.gmail.com  
Backpatch: 12-, where the bug was introduced in 15d8f8312  

commit   : cb9bb15783f2d6b2e66f7c18bc35e849df623dfa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 14:42:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 14:42:02 -0400    

Per buildfarm.  

commit   : b654714f9bcfb4443bcc531c32f059fd85f798ec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 12:10:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 12:10:54 -0400    

libpq failed to ignore Windows-style newlines in connection service files.  
This normally wasn't a problem on Windows itself, because fgets() would  
convert \r\n to just \n.  But if libpq were running inside a program that  
changes the default fopen mode to binary, it would see the \r's and think  
they were data.  In any case, it's project policy to ignore \r in text  
files unconditionally, because people sometimes try to use files with  
DOS-style newlines on Unix machines, where the C library won't hide that  
from us.  
  
Hence, adjust parseServiceFile() to ignore \r as well as \n at the end of  
the line.  In HEAD, go a little further and make it ignore all trailing  
whitespace, to match what it's always done with leading whitespace.  
  
In HEAD, also run around and fix up everyplace where we have  
newline-chomping code to make all those places look consistent and  
uniformly drop \r.  It is not clear whether any of those changes are  
fixing live bugs.  Most of the non-cosmetic changes are in places that  
are reading popen output, and the jury is still out as to whether popen  
on Windows can return \r\n.  (The Windows-specific code in pipe_read_line  
seems to think so, but our lack of support for this elsewhere suggests  
maybe it's not a problem in practice.)  Hence, I desisted from applying  
those changes to back branches, except in run_ssl_passphrase_command()  
which is new enough and little-tested enough that we'd probably not have  
heard about any problems there.  
  
Tom Lane and Michael Paquier, per bug #15827 from Jorge Gustavo Rocha.  
Back-patch the parseServiceFile() change to all supported branches,  
and the run_ssl_passphrase_command() change to v11 where that was added.  
  
Discussion: https://postgr.es/m/15827-e6ba53a3a7ed543c@postgresql.org  

commit   : 20e99cdddbd3b55257827d621c2f9c592521cd4b    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 25 Jul 2019 11:24:23 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Thu, 25 Jul 2019 11:24:23 -0400    

Add a line to the project file setting the target SDK. Otherwise, in for  
example VS2017, if the default but optional 8.1 SDK is not installed the  
build will fail.  
  
Patch from Peifeng Qiu, slightly edited by me.  
  
Discussion: https://postgr.es/m/CABmtVJhw1boP_bd4=b3Qv5YnqEdL696NtHFi2ruiyQ6mFHkeQQ@mail.gmail.com  
  
Backpatch to all live branches.  

commit   : f5a4ab23e42ac35862e3f7dc021a41f41a34386c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 11:02:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 25 Jul 2019 11:02:43 -0400    

As of Fedora 30, it seems that the system-provided macros for setting  
up user privileges in SELinux policies don't grant the ability to read  
/etc/passwd, as they formerly did.  This restriction breaks psql  
(which tries to use getpwuid() to obtain the user name it's running  
under) and thereby the contrib/sepgsql regression test.  Add explicit  
specifications that we need the right to read /etc/passwd.  
  
Mike Palmiotto, per a report from me.  Back-patch to all supported  
branches.  
  
Discussion: https://postgr.es/m/23856.1563381159@sss.pgh.pa.us  

commit   : 35a34e62ed4974b9178a2dc924d645d6a12e7e9a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 13:58:53 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 25 Jul 2019 13:58:53 +0200    

commit   : ecbdd009344d3a00733e4382f50137b5e0248ce8    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 24 Jul 2019 18:45:58 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 24 Jul 2019 18:45:58 -0700    

After 277cb789836 ON CONFLICT ... SET ... RETURNING failed with  
ERROR:  virtual tuple table slot does not have system attributes  
when taking the update path, as the slot used to insert into the  
table (and then process RETURNING) was defined to be a virtual slot in  
that commit. Virtual slots don't support system columns except for  
tableoid and ctid, as the other system columns are AM dependent.  
  
Fix that by using a slot of the table's type. Add tests for system  
column accesses in ON CONFLICT ...  RETURNING.  
  
Reported-By: Roby, bisected to the relevant commit by Jeff Janes  
Author: Andres Freund  
Discussion: https://postgr.es/m/73436355-6432-49B1-92ED-1FE4F7E7E100@finefun.com.au  
Backpatch: 12-, where the bug was introduced in 277cb789836  

commit   : c8e177f0bba6bcd9db7180580d58968974d8f6a9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 25 Jul 2019 07:55:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 25 Jul 2019 07:55:23 +0900    

Oversight in 7d81bdc, which introduced a new routine in perl lacking a  
return clause.  Per buildfarm member crake.  
  
Backpatch down to 9.6 like its parent.  
  
Reported-by: Andrew Dunstan  
Discussion: https://postgr.es/m/16da29fa-d504-1380-7095-40de586dc038@2ndQuadrant.com  
Backpatch-through: 9.6  

commit   : 4e784f35145bc6e01d54282afe10d9bb5200ebfe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Jul 2019 18:14:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 24 Jul 2019 18:14:26 -0400    

describeOneTableDetails issued a partition-constraint-fetching query  
for every table, even ones it knows perfectly well are not partitions.  
  
To add insult to injury, it then proceeded to leak the empty PGresult  
if the table wasn't a partition.  Doing that a lot of times might  
amount to a meaningful leak, so this seems like a back-patchable bug.  
  
Fix that, and also fix a related PGresult leak in the partition-parent  
case (though that leak would occur only if we got no row, which is  
unexpected).  
  
Minor code beautification too, to make this code look more like the  
pre-existing code around it.  
  
Back-patch the whole change into v12.  However, the fact that we already  
know whether the table is a partition dates only to commit 1af25ca0c;  
back-patching the relevant changes from that is probably more churn  
than is justified in released branches.  Hence, in v11 and v10, just  
do the minimum to fix the PGresult leaks.  
  
Noted while messing around with adjacent code for yesterday's \d  
improvements.  

commit   : 6655a7299d835dea9e8e0ba69cc5284611b96f29    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 24 Jul 2019 20:24:07 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 24 Jul 2019 20:24:07 +0300    

Otherwise, after a deleted page gets even older, it becomes unrecyclable  
again. B-tree has the same problem, and has had since time immemorial,  
but let's at least fix this in GiST, where this is new.  
  
Backpatch to v12, where GiST page deletion was introduced.  
  
Reviewed-by: Andrey Borodin  
Discussion: https://www.postgresql.org/message-id/835A15A5-F1B4-4446-A711-BF48357EB602%40yandex-team.ru  

commit   : 9eb5607e69933f0a88b6774d1ba728f27afdbd3d    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 24 Jul 2019 20:24:05 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 24 Jul 2019 20:24:05 +0300    

The explicit check in gistScanPage() isn't currently really necessary, as  
a deleted page is always empty, so the loop would fall through without  
doing anything, anyway. But it's a marginal optimization, and it gives a  
nice place to attach a comment to explain how it works.  
  
Backpatch to v12, where GiST page deletion was introduced.  
  
Reviewed-by: Andrey Borodin  
Discussion: https://www.postgresql.org/message-id/835A15A5-F1B4-4446-A711-BF48357EB602%40yandex-team.ru  

commit   : 1a721248f3899ccf8c0c7512b91d8458f2394aeb    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Jul 2019 11:41:39 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 24 Jul 2019 11:41:39 -0400    

Windows hosts do not normally come with expr, so instead of using that  
to test the \setshell command, use echo instead, which is fairly  
universally available.  
  
Backpatch to release 11, where this came in.  
  
Problem found by me, patch by Fabien Coelho.  

commit   : fd7d387e0548fd371c06a91d75bc4632541ccfdd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jul 2019 11:25:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jul 2019 11:25:43 +0900    

Using pg_receivewal with synchronous_commit = remote_apply set in the  
backend is incompatible if pg_receivewal is a synchronous standby as it  
never applies WAL, so document this problem and solutions to it.  
  
Backpatch to 9.6, where remote_apply has been added.  
  
Author: Robert Haas, Jesper Pedersen  
Reviewed-by: Laurenz Albe, Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/1427a2d3-1e51-9335-1931-4f8853d90d5e@redhat.com  
Backpatch-through: 9.6  

commit   : 7d81bdc8c0ce838efa248928065e9b2da829f981    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jul 2019 10:53:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 24 Jul 2019 10:53:39 +0900    

Slow buildfarm machines have run into issues with this TAP test caused  
by a race condition related to the startup of a set of standbys, where  
it is possible to finish with an unexpected order in the WAL sender  
array of the primary.  
  
This closes the race condition by making sure that any standby started  
is registered into the WAL sender array of the primary before starting  
the next one based on lookups of pg_stat_replication.  
  
Backpatch down to 9.6 where the test has been introduced.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera, Noah Misch  
Discussion: https://postgr.es/m/20190617055145.GB18917@paquier.xyz  
Backpatch-through: 9.6  

commit   : 5562272a4229cfa57354aa203cffd36b4e7f70cb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Jul 2019 17:22:15 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 23 Jul 2019 17:22:15 -0400    

If the user creates a deferred constraint in a partition, and in a  
transaction they cause the constraint's trigger execution to be deferred  
until commit time *and* drop the constraint, then when commit time comes  
the queued trigger will fail to run because the trigger object will have  
been dropped.  
  
This is explained because when a constraint gets dropped in a  
partitioned table, the recursion to drop the ones in partitions is done  
by the dependency mechanism, not by ALTER TABLE traversing the recursion  
tree as in all other cases.  In the non-partitioned case, this problem  
is avoided by checking that the table is not "in use" by alter-table;  
other alter-table subcommands that recurse to partitions do that check  
for each partition.  But the dependency mechanism doesn't have a way to  
do that.  Fix the problem by applying the same check to all partitions  
during ALTER TABLE's "prep" phase, which correctly raises the necessary  
error.  
  
Reported-by: Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>  
Discussion: https://postgr.es/m/CAKcux6nZiO9-eEpr1ZD84bT1mBoVmeZkfont8iSpcmYrjhGWgA@mail.gmail.com  

commit   : 24f62e93f314c107b4fa679869e5ba9adb2d545f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jul 2019 17:04:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jul 2019 17:04:21 -0400    

Include partitioning information much as we do for partitioned tables.  
(However, \d+ doesn't show the partition bounds, because those are  
not stored for indexes.)  
  
In passing, fix a couple of queries to look less messy in -E output.  
  
Also, add some tests for \d on tables with nondefault tablespaces.  
(Somebody previously added a rather silly number of tests for \d  
on partitioned indexes, yet completely neglected other cases.)  
  
Justin Pryzby, reviewed by Fabien Coelho  
  
Discussion: https://postgr.es/m/20190422154902.GH14223@telsasoft.com  

commit   : eb5472da9f83c2e432ac27a053929947e354d20c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jul 2019 15:25:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 23 Jul 2019 15:25:56 -0400    

Add the name of the owning table to the footers for a TOAST table.  
Also, show all the same footers as for a regular table (in practice,  
this adds the index and perhaps the tablespace and access method).  
  
Justin Pryzby, reviewed by Fabien Coelho  
  
Discussion: https://postgr.es/m/20190422154902.GH14223@telsasoft.com  

commit   : 06140c201b982436974d71e756d7331767a41e57    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 Jul 2019 14:40:42 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 23 Jul 2019 14:40:42 +0200    

This sets both LC_COLLATE and LC_CTYPE with one option.  Similar  
behavior is already supported in initdb, CREATE COLLATION, and  
createdb.  
  
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>  
Discussion: https://www.postgresql.org/message-id/flat/d9d5043a-dc70-da8a-0166-1e218e6e34d4%402ndquadrant.com  

commit   : 3cae75f4209bcbb06285544de0f1c59f717a3159    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jul 2019 14:29:34 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 23 Jul 2019 14:29:34 +0900    

Oversight in 5f384037.  
  
Author: Álvaro Herrera  
Discussion: https://postgr.es/m/20190722151806.GA22634@alvherre.pgsql  

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

The logic in ATExecDropColumn that rejects dropping partition key  
columns is quite an inadequate defense, because it doesn't execute  
in cases where a column needs to be dropped due to cascade from  
something that only the column, not the whole partitioned table,  
depends on.  That leaves us with a badly broken partitioned table;  
even an attempt to load its relcache entry will fail.  
  
We really need to have explicit pg_depend entries that show that the  
column can't be dropped without dropping the whole table.  Hence,  
add those entries.  In v12 and HEAD, bump catversion to ensure that  
partitioned tables will have such entries.  We can't do that in  
released branches of course, so in v10 and v11 this patch affords  
protection only to partitioned tables created after the patch is  
installed.  Given the lack of field complaints (this bug was found  
by fuzz-testing not by end users), that's probably good enough.  
  
In passing, fix ATExecDropColumn and ATPrepAlterColumnType  
messages to be more specific about which partition key column  
they're complaining about.  
  
Per report from Manuel Rigger.  Back-patch to v10 where partitioned  
tables were added.  
  
Discussion: https://postgr.es/m/CA+u7OA4JKCPFrdrAbOs7XBiCyD61XJxeNav4LefkSmBLQ-Vobg@mail.gmail.com  
Discussion: https://postgr.es/m/31920.1562526703@sss.pgh.pa.us  

commit   : 7961886580a594e519ca7ed1811b464206738be5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 19:28:25 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 19:28:25 +0200    

This reverts commit 09f08930f0f6fd4a7350ac02f29124b919727198.  
  
The buildfarm client needs some adjustments first.  

commit   : 09f08930f0f6fd4a7350ac02f29124b919727198    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 14:40:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 14:40:55 +0200    

Change the defaults for the pg_hba.conf generated by initdb to "peer"  
for local (if supported, else "md5") and "md5" for host.  
  
(Changing from "md5" to SCRAM is left as a separate exercise.)  
  
"peer" is currently not supported on AIX, HP-UX, and Windows.  Users  
on those operating systems will now either have to provide a password  
to initdb or choose a different authentication method when running  
initdb.  
  
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/bec17f0a-ddb1-8b95-5e69-368d9d0a3390%40postgresql.org  

commit   : 1e6a759838f7c104f3cd1fe6981a98780da4131b    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Tue, 23 Jul 2019 00:14:11 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Tue, 23 Jul 2019 00:14:11 +1200    

When we already know the length that we're going to append, then it  
makes sense to use appendBinaryStringInfo instead of  
appendStringInfoString so that the append can be performed with a simple  
memcpy() using a known length rather than having to first perform a  
strlen() call to obtain the length.  
  
Discussion: https://postgr.es/m/CAKJS1f8+FRAM1s5+mAa3isajeEoAaicJ=4e0WzrH3tAusbbiMQ@mail.gmail.com  

commit   : 19781729f789f3c6b2540e02b96f8aa500460322    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 12:05:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 22 Jul 2019 12:05:03 +0200    

Some code could get confused when certain catalog state involving both  
identity and serial sequences was present, perhaps during an attempt  
to upgrade the latter to the former.  Specifically, dropping the  
default of a serial column maintains the ownership of the sequence by  
the column, and so it would then be possible to afterwards make the  
column an identity column that would now own two sequences.  This  
causes the code that looks up the identity sequence to error out,  
making the new identity column inoperable until the ownership of the  
previous sequence is released.  
  
To fix this, make the identity sequence lookup only consider sequences  
with the appropriate dependency type for an identity sequence, so it  
only ever finds one (unless something else is broken).  In the above  
example, the old serial sequence would then be ignored.  Reorganize  
the various owned-sequence-lookup functions a bit to make this  
clearer.  
  
Reported-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://www.postgresql.org/message-id/flat/470c54fc8590be4de0f41b0d295fd6390d5e8a6c.camel@cybertec.at  

commit   : efdcca55a3df27a12efb84a18bce6ea739927b80    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 22 Jul 2019 19:03:12 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 22 Jul 2019 19:03:12 +1200    

In nodeAppend.c and nodeMergeAppend.c there were some foreach loops which  
looped over the list of subplans and only performed any work if the  
subplan index was found in a Bitmapset.  With the old linked list  
implementation of List, this form made sense as accessing the Nth list  
element was O(N).  However, thanks to 1cff1b95a we now have array-based  
lists, so accessing the Nth element has become O(1).  
  
Here we make the most of the O(1) lookups and just loop over the set  
members of the Bitmapset with bms_next_member().  This performs slightly  
better when a small number of the list items are in the Bitmapset.  Micro  
benchmarks show that when the Bitmapset contains all or most of the list  
items then the new code is ever so slightly slower.  In practice, the cost  
is so small that it's drowned out by various other things such as locking  
the relations belonging to each subplan, etc.  
  
The primary goal here is to leave better code examples around which benefit  
better from the new list implementation.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CAKJS1f8ZcsLVgkF4wOfRyMYTcPgLFiUAOedFC+U2vK_aFZk-BA@mail.gmail.com  

commit   : 23bccc823d434d9dcf3c12622fe260d9235baae2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Jul 2019 10:01:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 22 Jul 2019 10:01:50 +0900    

This is numbered take 7, and addresses a set of issues with code  
comments, variable names and unreferenced variables.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/dff75442-2468-f74f-568c-6006e141062f@gmail.com  

commit   : e1a0f6a983068675813074847e1d0d61bd37ac0e    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 22 Jul 2019 10:29:41 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 22 Jul 2019 10:29:41 +1200    

3373c7155 changed how we determine EquivalenceClasses for relations and  
added an Assert to ensure all relations mentioned in each EC's ec_relids  
was a RELOPT_BASEREL.  However, the join removal code may remove a LEFT  
JOIN and since it does not clean up EC members belonging to the removed  
relations it can leave RELOPT_DEADREL rels in ec_relids.  
  
Fix this by adjusting the Assert to allow RELOPT_DEADREL rels too.  
  
Reported-by: sqlsmith via Andreas Seltenreich  
Discussion: https://postgr.es/m/87y30r8sls.fsf@ansel.ydns.eu  

commit   : 330cafdfaa11ebe53e3e59688acac1577ae0cb34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Jul 2019 11:42:11 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 21 Jul 2019 11:42:11 -0400    

Coverity complained about this code, apparently because it uses a local  
array of size FUNC_MAX_ARGS without a guard that the input argument list  
is no longer than that.  (Not sure why it complained today, since this  
code's been the same for a long time; possibly it re-analyzed everything  
the List API change touched?)  
  
Rather than add a guard, though, let's just get rid of the local array  
altogether.  It was only there to avoid list_nth() calls, and those are  
no longer expensive.  

commit   : 90317ab7e64bd2d855c73a6ba579de6d04a7b25c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 21 Jul 2019 22:27:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 21 Jul 2019 22:27:11 +0900    

Several buildfarm members have been complaining about that with gcc,  
like jacana.  Weirdly enough, Visual Studio's compilers do not find this  
issue.  
  
Author: Michael Paquier  
Reviewed-by: Andrew Dunstan  
Discussion: https://postgr.es/m/20190719050830.GK1859@paquier.xyz  

commit   : 3373c7155350cf6fcd51dd090f29e1332901e329    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 21 Jul 2019 17:30:58 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 21 Jul 2019 17:30:58 +1200    

Previously in order to determine which ECs a relation had members in, we  
had to loop over all ECs stored in PlannerInfo's eq_classes and check if  
ec_relids mentioned the relation.  For the most part, this was fine, as  
generally, unless queries were fairly complex, the overhead of performing  
the lookup would have not been that significant.  However, when queries  
contained large numbers of joins and ECs, the overhead to find the set of  
classes matching a given set of relations could become a significant  
portion of the overall planning effort.  
  
Here we allow a much more efficient method to access the ECs which match a  
given relation or set of relations.  A new Bitmapset field in RelOptInfo  
now exists to store the indexes into PlannerInfo's eq_classes list which  
each relation is mentioned in.  This allows very fast lookups to find all  
ECs belonging to a single relation.  When we need to lookup ECs belonging  
to a given pair of relations, we can simply bitwise-AND the Bitmapsets from  
each relation and use the result to perform the lookup.  
  
We also take the opportunity to write a new implementation of  
generate_join_implied_equalities which makes use of the new indexes.  
generate_join_implied_equalities_for_ecs must remain as is as it can be  
given a custom list of ECs, which we can't easily determine the indexes of.  
  
This was originally intended to fix the performance penalty of looking up  
foreign keys matching a join condition which was introduced by 100340e2d.  
However, we're speeding up much more than just that here.  
  
Author: David Rowley, Tom Lane  
Reviewed-by: Tom Lane, Tomas Vondra  
Discussion: https://postgr.es/m/6970.1545327857@sss.pgh.pa.us  

commit   : 894af78f185afee221a6762a1a49057043b7bbf5    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 20 Jul 2019 11:11:55 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 20 Jul 2019 11:11:55 -0700    

Solely relying on a relation's reltuples/relpages estimate to size the  
Bloom filters used by amcheck verification makes verification less  
effective when the estimates are very stale.  In extreme cases,  
verification options that use Bloom filters internally could be totally  
ineffective, without users receiving any clear indication that certain  
types of corruption might easily be missed.  
  
To fix, use RelationGetNumberOfBlocks() instead of relpages to size the  
downlink block Bloom filter.  Use the same RelationGetNumberOfBlocks()  
value to derive a minimum size for the heapallindexed Bloom filter,  
rather than completely trusting reltuples.  Verification will still be  
reasonably effective when the projected/estimated number of Bloom filter  
elements is at least 1/5 of the final number of elements, which is  
assured by the new sizing logic.  
  
Reported-By: Alexander Korotkov  
Discussion: https://postgr.es/m/CAH2-Wzk0ke2J42KrNYBKu0Xovjy-sU5ub7PWjgpbsKdAQcL4OA@mail.gmail.com  
Backpatch: 11-, where downlink/heapallindexed verification were added.  

commit   : a63378a03ec0a53c7c579dfdb3abff57811d8ced    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 Jul 2019 12:28:16 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 18 Jul 2019 12:28:16 +0200    

The current extended statistics code was a bit confused which collation  
to use.  When building the statistics, the collations defined as default  
for the data types were used (since commit 5e0928005).  The MCV code was  
however using the column collations for MCV serialization, and then  
DEFAULT_COLLATION_OID when computing estimates. So overall the code was  
using all three possible options, inconsistently.  
  
This uses the column colation everywhere - this makes it consistent with  
what 5e0928005 did for regular stats.  We however do not track the  
collations in a catalog, because we can derive them from column-level  
information.  This may need to change in the future, e.g. after allowing  
statistics on expressions.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  
Backpatch-to: 12  

commit   : e38a55ba46bbd2510baccdbaa01298cbca972b88    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 Jul 2019 16:28:28 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Fri, 19 Jul 2019 16:28:28 +0200    

The examine_opclause_expression function needs to return information on  
which side of the operator we found the Var, but the variable was called  
"isgt" which is rather misleading (it assumes the operator is either  
less-than or greater-than, but it may be equality or something else).  
Other places in the planner use a variable called "varonleft" for this  
purpose, so just adopt the same convention here.  
  
The code also assumed we don't care about this flag for equality, as  
(Var = Const) and (Const = Var) should be the same thing. But that does  
not work for cross-type operators, in which case we need to pass the  
parameters to the procedure in the right order. So just use the same  
code for all types of expressions.  
  
This means we don't need to care about the selectivity estimation  
function anymore, at least not in this code. We should only get the  
supported cases here (thanks to statext_is_compatible_clause).  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  
Backpatch-to: 12  

commit   : 6f40ee4f837ec1ac59c8ddc73b67a04978a184d5    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 19 Jul 2019 13:24:33 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 19 Jul 2019 13:24:33 -0700    

Make pgss_post_parse_analyze() more consistent with the other hooks,  
and avoid unnecessary overhead when pg_stat_statements.track=none.  
  
Author: Raymond Martin  
Reviewed-by: Fabien COELHO  
Discussion: https://postgr.es/m/BN8PR21MB1217B003C4F79DE230AA36B9B1580%40BN8PR21MB1217.namprd21.prod.outlook.com  

commit   : 421466863548de58199c7c6ececaae6b5f621b2f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jul 2019 14:48:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 19 Jul 2019 14:48:57 -0400    

Absorb commit e5e04c962a5d12eebbf867ca25905b3ccc34cbe0 from upstream  
IANA code, in hopes of silencing warnings from MSVC about negating  
a bool value.  
  
Discussion: https://postgr.es/m/20190719035347.GJ1859@paquier.xyz  

commit   : 1300fa66b2f3d0dcd2eed7a5eff9e3fc22807f7c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 11:42:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 11:42:33 +0900    

16828d5 has improved ALTER TABLE so as a column addition does not  
require a rewrite for a non-NULL default with constant expressions, but  
one spot in the documentation did not get updated consistently.  
The documentation also now clarifies the fact that this does not apply  
if the expression is volatile, where a table rewrite is still required.  
  
Reported-by: Daniel Westermann  
Author: Ian Barwick  
Reviewed-by: Michael Paquier, Daniel Westermann  
Discussion: https://postgr.es/m/DB6PR0902MB2184C7D5645CF15D75EB7957D2CF0@DB6PR0902MB2184.eurprd09.prod.outlook.com  
Backpatch-through: 11  

commit   : 5f3840370b63fdf17f704a285623ccc233fa8d4f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 09:31:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 09:31:58 +0900    

The existing facility of vacuumdb to handle parallel connections into a  
given database with an authentication set is moved to a common file in  
src/bin/scripts/, named scripts_parallel.c.  This introduces a set of  
routines to initialize, wait and terminate a set of connections,  
simplifying a bit the code of vacuumdb on the way.  More routines  
related to result handling and database connection are moved to  
common.c.  
  
The initial plan is to use that for reindexdb, but it could be applied  
to other tools like clusterdb.  
  
While on it, clean up a set of variables "progname" which were defined  
as routine arguments for error messages.  Since most of the callers have  
switched to pg_log_error() and such there is no need for this variable.  
  
Author: Julien Rouhaud  
Reviewed-by: Michael Paquier, Álvaro Herrera  
Discussion: https://postgr.es/m/CAOBaU_YrnH_Jqo46NhaJ7uRBiWWEcS40VNRQxgFbqYo9kApUsg@mail.gmail.com  

commit   : b538c90b1bded5464787e2b8e4431302d24eb601    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 Jul 2019 16:38:39 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 Jul 2019 16:38:39 -0700    

I was careless passing a datum directly to DATE_NOT_FINITE without  
calling DatumGetDateADT() first.  
  
Backpatch-through: 9.4  

commit   : 70a33b21099c046dc38f07ffb02b1e0cf2aff91d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 08:50:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 19 Jul 2019 08:50:14 +0900    

Noticed while browsing the code.  

commit   : e6feef571a016c9dac52a01aebad484768eb5c68    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 Jul 2019 12:42:39 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Thu, 18 Jul 2019 12:42:39 -0700    

The values 'infinity' and '-infinity' are a part of the DATE type  
itself, so a bound of the date 'infinity' is not the same as an  
unbounded/infinite range. However, it is still wrong to try to  
canonicalize such values, because adding or subtracting one has no  
effect. Fix by treating 'infinity' and '-infinity' the same as  
unbounded ranges for the purposes of canonicalization (but not other  
purposes).  
  
Backpatch to all versions because it is inconsistent with the  
documented behavior. Note that this could be an incompatibility for  
applications relying on the behavior contrary to the documentation.  
  
Author: Laurenz Albe  
Reviewed-by: Thomas Munro  
Discussion: https://postgr.es/m/77f24ea19ab802bc9bc60ddbb8977ee2d646aec1.camel%40cybertec.at  
Backpatch-through: 9.4  

commit   : d004147eb3ece6b5981dbdd3d918ffc3f23fc505    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 18 Jul 2019 13:22:56 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 18 Jul 2019 13:22:56 -0700    

Commit 857f9c36cda, which taught nbtree VACUUM to avoid unnecessary  
index scans, bumped the nbtree version number from 2 to 3, while adding  
the ability for nbtree indexes to be upgraded on-the-fly.  Various  
assertions that assumed that an nbtree index was always on version 2 had  
to be changed to accept any supported version (version 2 or 3 on  
Postgres 11).  
  
However, a few assertions were missed in the initial commit, all of  
which were in code paths that cache a local copy of the metapage  
metadata, where the index had been expected to be on the current version  
(no longer version 2) as a generic sanity check.  Rather than simply  
update the assertions, follow-up commit 0a64b45152b intentionally made  
the metapage caching code update the per-backend cached metadata version  
without changing the on-disk version at the same time.  This could even  
happen when the planner needed to determine the height of a B-Tree for  
costing purposes.  The assertions only fail on Postgres v12 when  
upgrading from v10, because they were adjusted to use the authoritative  
shared memory metapage by v12's commit dd299df8.  
  
To fix, remove the cache-only upgrade mechanism entirely, and update the  
assertions themselves to accept any supported version (go back to using  
the cached version in v12).  The fix is almost a full revert of commit  
0a64b45152b on the v11 branch.  
  
VACUUM only considers the authoritative metapage, and never bothers with  
a locally cached version, whereas everywhere else isn't interested in  
the metapage fields that were added by commit 857f9c36cda.  It seems  
unlikely that this bug has affected any user on v11.  
  
Reported-By: Christoph Berg  
Bug: #15896  
Discussion: https://postgr.es/m/15896-5b25e260fdb0b081%40postgresql.org  
Backpatch: 11-, where VACUUM was taught to avoid unnecessary index scans.  

commit   : bc8393cf27731055467a83068c680c86f9c112ea    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Jul 2019 10:37:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 18 Jul 2019 10:37:13 -0400    

Now that commit fec0778c8 drew a clear line between public and private  
fields in SPITupleTable, it seems pretty silly that the count of valid  
tuples isn't on the public side of that line.  The reason why not was  
that there wasn't such a count.  For reasons lost in the mists of time,  
spi.c preferred to keep a count of remaining free entries in the array.  
But that seems pretty pointless: it's unlike the way we handle similar  
code everywhere else, and it involves extra subtractions that surely  
outweigh having to do a comparison rather than test-for-zero to check  
for array-full.  
  
Hence, rearrange so that this code does the expansible array logic  
the same as everywhere else, with a count of valid entries alongside  
the allocated array length.  And document the count as public.  
  
I looked for core-code callers where it would make sense to start  
relying on tuptable->numvals rather than the separate SPI_processed  
variable.  Right now there don't seem to be places where it'd be  
a win to do so without more code restructuring than I care to  
undertake today.  In principle, though, having SPITupleTables be  
fully self-contained should be helpful down the line.  
  
Discussion: https://postgr.es/m/16852.1563395722@sss.pgh.pa.us  

commit   : 7d24f6a49076f975ca87926b3cde8fdea3448ecb    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 Jul 2019 18:16:50 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 Jul 2019 18:16:50 +0200    

When evaluating clauses on a multivariate MCV list, we build a bitmap  
tracking how the clauses match each item of the MCV list.  When updating  
the bitmap we need to consider the current value (tracking how the item  
matches preceding clauses), match for the current clause and whether the  
clauses are connected by AND or OR.  
  
Until now the logic was copied on every place updating the bitmap, which  
was not quite readable.  So just move it to a separate function and call  
it where needed.  
  
Backpatch to 12, where the code was introduced. While not a bugfix, this  
should make maintenance and future backpatches easier.  
  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  

commit   : e4deae7396f2a5576c0c8289e2bfc005ed3d6989    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 15 Jul 2019 02:00:31 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 15 Jul 2019 02:00:31 +0200    

There were two issues in how the extended statistics handled NULL values  
in opclauses. Firstly, the code was oblivious to the possibility that  
Const may be NULL (constisnull=true) in which case the constvalue is  
undefined. We need to treat this as a mismatch, and not call the proc.  
  
Secondly, the MCV item itself may contain NULL values too - the code  
already did check that, and updated the match bitmap accordingly, but  
failed to ensure we won't call the operator procedure anyway. It did  
work for AND-clauses, because in that case false in the bitmap stops  
evaluation of further clauses. But for OR-clauses ir was not easy to  
get incorrect estimates or even trigger a crash.  
  
This fixes both issues by extending the existing check so that it looks  
at constisnull too, and making sure it skips calling the procedure.  
  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  

commit   : e8b6ae2130e3a95bb776708a9a7c9cb21fe8ac87    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 13 Jul 2019 00:12:16 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 13 Jul 2019 00:12:16 +0200    

We expect opclauses to have exactly one Var and one Const, but the code  
was checking the Const by calling is_pseudo_constant_clause() which is  
incorrect - we need a proper constant.  
  
Fixed by using plain IsA(x,Const) to check type of the node. We need to  
do these checks in two places, so move it into a separate function that  
can be called in both places.  
  
Reported by Andreas Seltenreich, based on crash reported by sqlsmith.  
  
Backpatch to v12, where this code was introduced.  
  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  
Backpatch-to: 12  

commit   : a4303a078c661ebafe8c8c2167b2ad9bf16b32ce    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 Jul 2019 18:13:39 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 17 Jul 2019 18:13:39 +0200    

The TYPECACHE_GT_OPR is not needed (it used to be in older version of  
the MCV code), but the compiler failed to detect this as the result was  
used in a fmgr_info() call, populating a FmgrInfo entry.  
  
Backpatch to v12, where this code was introduced.  
  
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu  
Backpatch-to: 12  

commit   : 21039555cdec75836d246fcbcd4b44ee63dabfad    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 17 Jul 2019 19:39:54 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 17 Jul 2019 19:39:54 -0700    

Author: Brad DeJong  
Discussion: https://postgr.es/m/CAJnrtnxDYOQFsDfWz2iri0T_fFL2ZbbzgCOE=4yaMcszgcsf4A@mail.gmail.com  
Backpatch: 12-  

commit   : 1c1602b8b685a68796f8ba48e41f778c0c42ba43    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jul 2019 10:05:59 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 18 Jul 2019 10:05:59 +0900    

The documentation mentioned that data checksums cannot be changed after  
initialization, which is not true as pg_checksums can do that with its  
--enable option introduced in v12.  This simply removes the sentence  
telling so.  
  
Reported-by: Basil Bourque  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/15909-e9d74271f1647472@postgresql.org  
Backpatch-through: 12  

commit   : 93907478e15f5762800b6acbe2eff03167843874    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 19:15:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 19:15:21 -0400    

Brazil no longer observes DST.  
Historical corrections for Palestine, Hong Kong, and Italy.  

commit   : f285322f9cd3145ea2e5b870e6ba7e0c641422ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 18:26:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 18:26:23 -0400    

A large fraction of this diff is just due to upstream's somewhat  
random decision to rename a bunch of internal variables and struct  
fields.  However, there is an interesting new feature in zic:  
it's grown a "-b slim" option that emits zone files without 32-bit  
data and other backwards-compatibility hacks.  We should consider  
whether we wish to enable that.  

commit   : fec0778c8098cebec2d5cb3674ac7151d8d95638    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 14:55:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 14:55:13 -0400    

The fields that we consider public are "tupdesc" and "vals", which  
historically are in the middle of the struct.  Move them to the front  
(this should be perfectly safe to do in HEAD) and add comments to make  
it quite clear which fields are public or not.  
  
Also adjust spi.sgml's documentation of the struct to match.  
That doc had bit-rotted somewhat, as it was missing some fields.  
(Arguably we should just remove all the private fields from the docs,  
but for now I refrained.)  
  
Daniel Gustafsson, reviewed by Fabien Coelho  
  
Discussion: https://postgr.es/m/0D19F836-B743-4340-B6A2-F148CA3DD1F0@yesql.se  

commit   : 860c095fd548cd25586e4273e9b489082b4ffa13    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 13:13:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 13:13:15 -0400    

At least on Fedora and RHEL, it's not in the same RPM that's needed  
for building sepgsql itself.  Today is the second or third time I've  
had to rediscover how to install that, so let's document it this time.  

commit   : 82c8a3c52adfd993b72289bfa8739f97216a06df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 13:04:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 13:04:59 -0400    

The aggregate-order difference explained in my previous commit  
turns out to also affect the order of log entries emitted in the  
contrib/sepgsql regression test.  Per buildfarm.  
  
Discussion: https://postgr.es/m/21272.1563318411@sss.pgh.pa.us  

commit   : d97b714a219959a50f9e7b37ded674f5132f93f3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 11:15:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 17 Jul 2019 11:15:28 -0400    

Formerly, lcons was about the same speed as lappend, but with the new  
List implementation, that's not so; with a long List, data movement  
imposes an O(N) cost on lcons and list_delete_first, but not lappend.  
  
Hence, invent list_delete_last with semantics parallel to  
list_delete_first (but O(1) cost), and change various places to use  
lappend and list_delete_last where this can be done without much  
violence to the code logic.  
  
There are quite a few places that construct result lists using lcons not  
lappend.  Some have semantic rationales for that; I added comments about  
it to a couple that didn't have them already.  In many such places though,  
I think the coding is that way only because back in the dark ages lcons  
was faster than lappend.  Hence, switch to lappend where this can be done  
without causing semantic changes.  
  
In ExecInitExprRec(), this results in aggregates and window functions that  
are in the same plan node being executed in a different order than before.  
Generally, the executions of such functions ought to be independent of  
each other, so this shouldn't result in visibly different query results.  
But if you push it, as one regression test case does, you can show that  
the order is different.  The new order seems saner; it's closer to  
the order of the functions in the query text.  And we never documented  
or promised anything about this, anyway.  
  
Also, in gistfinishsplit(), don't bother building a reverse-order list;  
it's easy now to iterate backwards through the original list.  
  
It'd be possible to go further towards removing uses of lcons and  
list_delete_first, but it'd require more extensive logic changes,  
and I'm not convinced it's worth it.  Most of the remaining uses  
deal with queues that probably never get long enough to be worth  
sweating over.  (Actually, I doubt that any of the changes in this  
patch will have measurable performance effects either.  But better  
to have good examples than bad ones in the code base.)  
  
Patch by me, thanks to David Rowley and Daniel Gustafsson for review.  
  
Discussion: https://postgr.es/m/21272.1563318411@sss.pgh.pa.us  

commit   : dfd0121dc73aab491bcaad2d2b7a2a749389add8    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Jul 2019 12:14:08 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 17 Jul 2019 12:14:08 +1200    

Potential future SMGR implementations may not want to create  
tablespace directories when creating an SMGR relation.  Move that  
logic to mdcreate().  Move the initialization of md-specific  
data structures from smgropen() to a new callback mdopen().  
  
Author: Thomas Munro  
Reviewed-by: Shawn Debnath (as part of an earlier patch set)  
Discussion: https://postgr.es/m/CA%2BhUKG%2BOZqOiOuDm5tC5DyQZtJ3FH4%2BFSVMqtdC4P1atpJ%2Bqhg%40mail.gmail.com  

commit   : 3093eb2b83645a083a47ea62769ffd89e31f3664    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 18:17:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 18:17:47 -0400    

This should lappend the OIDs, not lcons them; the existing code produced  
a list in reversed order.  This is harmless for single-key FKs or FKs  
where all the key columns are of the same type, which probably explains  
how it went unnoticed.  But if those conditions are not met,  
ATAddForeignKeyConstraint would make the wrong decision about whether an  
existing FK needs to be revalidated.  I think it would almost always err  
in the safe direction by revalidating a constraint that didn't need it.  
You could imagine scenarios where the pfeqop check was fooled by  
swapping the types of two FK columns in one ALTER TABLE, but that case  
would probably be rejected by other tests, so it might be impossible to  
get to the worst-case scenario where an FK should be revalidated and  
isn't.  (And even then, it's likely to be fine, unless there are weird  
inconsistencies in the equality behavior of the replacement types.)  
However, this is a performance bug at least.  
  
Noted while poking around to see whether lcons calls could be converted  
to lappend.  
  
This bug is old, dating to commit cb3a7c2b9, so back-patch to all  
supported branches.  

commit   : c245776906b065fcd59831a25c3b24ad3ddcd849    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 13:12:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 13:12:24 -0400    

It seems worth getting rid of these functions because they require the  
caller to retain a ListCell pointer into a List that it's modifying,  
which is a dangerous practice with the new List implementation.  
(The only other List-modifying function that takes a ListCell pointer  
as input is list_delete_cell, which nowadays is preferentially used  
via the constrained API foreach_delete_current.)  
  
There was only one remaining caller of these functions after commit  
2f5b8eb5a, and that was some fairly ugly GEQO code that can be much  
more clearly expressed using a list-index variable and list_insert_nth.  
Hence, rewrite that code, and remove the functions.  
  
Discussion: https://postgr.es/m/26193.1563228600@sss.pgh.pa.us  

commit   : 2f5b8eb5a28b4e6de9d20cc7d2c6028c6c7a8aa8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 12:04:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 12:04:06 -0400    

heap.c and relcache.c contained nearly identical copies of logic  
to insert OIDs into an OID list while preserving the list's OID  
ordering (and rejecting duplicates, in one case but not the other).  
  
The comments argue that this is faster than qsort for small numbers  
of OIDs, which is at best unproven, and seems even less likely to be  
true now that lappend_cell_oid has to move data around.  In any case  
it's ugly and hard-to-follow code, and if we do have a lot of OIDs  
to consider, it's O(N^2).  
  
Hence, replace with simply lappend'ing OIDs to a List, then list_sort  
the completed List, then remove adjacent duplicates if necessary.  
This is demonstrably O(N log N) and it's much simpler for the  
callers.  It's possible that this would be somewhat inefficient  
if there were a very large number of duplicates, but that seems  
unlikely in the existing usage.  
  
This adds list_deduplicate_oid and list_oid_cmp infrastructure  
to list.c.  I didn't bother with equivalent functionality for  
integer or pointer Lists, but such could always be added later  
if we find a use for it.  
  
Discussion: https://postgr.es/m/26193.1563228600@sss.pgh.pa.us  

commit   : 569ed7f48312c70ed4a79daec1d7688fda4e74ac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 11:51:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 16 Jul 2019 11:51:44 -0400    

In the wake of commit 1cff1b95a, the obvious way to sort a List  
is to apply qsort() directly to the array of ListCells.  list_qsort  
was building an intermediate array of pointers-to-ListCells, which  
we no longer need, but getting rid of it forces an API change:  
the comparator functions need to do one less level of indirection.  
  
Since we're having to touch the callers anyway, let's do two additional  
changes: sort the given list in-place rather than making a copy (as  
none of the existing callers have any use for the copying behavior),  
and rename list_qsort to list_sort.  It was argued that the old name  
exposes more about the implementation than it should, which I find  
pretty questionable, but a better reason to rename it is to be sure  
we get the attention of any external callers about the need to fix  
their comparator functions.  
  
While we're at it, change four existing callers of qsort() to use  
list_sort instead; previously, they all had local reinventions  
of list_qsort, ie build-an-array-from-a-List-and-qsort-it.  
(There are some other places where changing to list_sort perhaps  
would be worthwhile, but they're less obviously wins.)  
  
Discussion: https://postgr.es/m/29361.1563220190@sss.pgh.pa.us  

commit   : 0896ae561b6c799d45cb61d8a3b18fbb442130a7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 16 Jul 2019 13:23:53 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 16 Jul 2019 13:23:53 +0900    

This is numbered take 7, and addresses a set of issues around:  
- Fixes for typos and incorrect reference names.  
- Removal of unneeded comments.  
- Removal of unreferenced functions and structures.  
- Fixes regarding variable name consistency.  
  
Author: Alexander Lakhin  
Discussion: https://postgr.es/m/10bfd4ac-3e7c-40ab-2b2e-355ed15495e8@gmail.com  

commit   : 4c3d05d875dd173a81a995c6e14d69496b467eec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jul 2019 23:27:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jul 2019 23:27:13 -0400    

These memory context switches are useless in the wake of commit  
1cff1b95a.  Noted by Jesper Pedersen.  
  
Discussion: https://postgr.es/m/f078ce63-9e04-0f3e-d200-d7ee66279abe@redhat.com  

commit   : c6bce6ebb668c7da03d01244d34cac0335561103    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 15 Jul 2019 20:57:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 15 Jul 2019 20:57:24 -0400    

Reported-by: Ian Barwick  
  
Discussion: https://postgr.es/m/538950ec-b86a-1650-6078-beb7091c09c2@2ndquadrant.com  
  
Backpatch-through: 9.4  

commit   : 5823677acc567d7790cc68972de12f6718913d7d    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jul 2019 11:53:12 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jul 2019 11:53:12 +1200    

Author: Fabien Coelho  
Reviewed-by: Ibrar Ahmed  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1904081737390.5867%40lancre  

commit   : ce8f946764005e1bde5a538542205e55f81bb6cc    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jul 2019 11:31:44 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 16 Jul 2019 11:31:44 +1200    

Author: Fabien Coelho  
Reviewed-by: Ibrar Ahmed  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1904061810510.3678%40lancre  

commit   : bfdbac2ab3ef1a12a7de231552b128ed83ad00bb    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 15 Jul 2019 14:35:06 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 15 Jul 2019 14:35:06 -0700    

The logic just added by commit e3899ffd falls back on a 50:50 page split  
in the event of a new item that's just to the right of our provisional  
"many duplicates" split point.  Fix a comment that incorrectly claimed  
that the new item had to be just to the left of our provisional split  
point.  
  
Backpatch: 12-, just like commit e3899ffd.  

commit   : e3899ffd8beafdaaa037b503163a9f572e9fc729    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 15 Jul 2019 13:19:13 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 15 Jul 2019 13:19:13 -0700    

Specific ever-decreasing insertion patterns could cause successive  
unbalanced nbtree page splits.  Problem cases involve a large group of  
duplicates to the left, and ever-decreasing insertions to the right.  
  
To fix, detect the situation by considering the newitem offset before  
performing a split using nbtsplitloc.c's "many duplicates" strategy.  If  
the new item was inserted just to the right of our provisional "many  
duplicates" split point, infer ever-decreasing insertions and fall back  
on a 50:50 (space delta optimal) split.  This seems to barely affect  
cases that already had acceptable space utilization.  
  
An alternative fix also seems possible.  Instead of changing  
nbtsplitloc.c split choice logic, we could instead teach _bt_truncate()  
to generate a new value for new high keys by interpolating from the  
lastleft and firstright key values.  That would certainly be a more  
elegant fix, but it isn't suitable for backpatching.  
  
Discussion: https://postgr.es/m/CAH2-WznCNvhZpxa__GqAa1fgQ9uYdVc=_apArkW2nc-K3O7_NA@mail.gmail.com  
Backpatch: 12-, where the nbtree page split enhancements were introduced.  

commit   : 1cff1b95ab6ddae32faa3efe0d95a820dbfdc164    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jul 2019 13:41:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 15 Jul 2019 13:41:58 -0400    

Originally, Postgres Lists were a more or less exact reimplementation of  
Lisp lists, which consist of chains of separately-allocated cons cells,  
each having a value and a next-cell link.  We'd hacked that once before  
(commit d0b4399d8) to add a separate List header, but the data was still  
in cons cells.  That makes some operations -- notably list_nth() -- O(N),  
and it's bulky because of the next-cell pointers and per-cell palloc  
overhead, and it's very cache-unfriendly if the cons cells end up  
scattered around rather than being adjacent.  
  
In this rewrite, we still have List headers, but the data is in a  
resizable array of values, with no next-cell links.  Now we need at  
most two palloc's per List, and often only one, since we can allocate  
some values in the same palloc call as the List header.  (Of course,  
extending an existing List may require repalloc's to enlarge the array.  
But this involves just O(log N) allocations not O(N).)  
  
Of course this is not without downsides.  The key difficulty is that  
addition or deletion of a list entry may now cause other entries to  
move, which it did not before.  
  
For example, that breaks foreach() and sister macros, which historically  
used a pointer to the current cons-cell as loop state.  We can repair  
those macros transparently by making their actual loop state be an  
integer list index; the exposed "ListCell *" pointer is no longer state  
carried across loop iterations, but is just a derived value.  (In  
practice, modern compilers can optimize things back to having just one  
loop state value, at least for simple cases with inline loop bodies.)  
In principle, this is a semantics change for cases where the loop body  
inserts or deletes list entries ahead of the current loop index; but  
I found no such cases in the Postgres code.  
  
The change is not at all transparent for code that doesn't use foreach()  
but chases lists "by hand" using lnext().  The largest share of such  
code in the backend is in loops that were maintaining "prev" and "next"  
variables in addition to the current-cell pointer, in order to delete  
list cells efficiently using list_delete_cell().  However, we no longer  
need a previous-cell pointer to delete a list cell efficiently.  Keeping  
a next-cell pointer doesn't work, as explained above, but we can improve  
matters by changing such code to use a regular foreach() loop and then  
using the new macro foreach_delete_current() to delete the current cell.  
(This macro knows how to update the associated foreach loop's state so  
that no cells will be missed in the traversal.)  
  
There remains a nontrivial risk of code assuming that a ListCell *  
pointer will remain good over an operation that could now move the list  
contents.  To help catch such errors, list.c can be compiled with a new  
define symbol DEBUG_LIST_MEMORY_USAGE that forcibly moves list contents  
whenever that could possibly happen.  This makes list operations  
significantly more expensive so it's not normally turned on (though it  
is on by default if USE_VALGRIND is on).  
  
There are two notable API differences from the previous code:  
  
* lnext() now requires the List's header pointer in addition to the  
current cell's address.  
  
* list_delete_cell() no longer requires a previous-cell argument.  
  
These changes are somewhat unfortunate, but on the other hand code using  
either function needs inspection to see if it is assuming anything  
it shouldn't, so it's not all bad.  
  
Programmers should be aware of these significant performance changes:  
  
* list_nth() and related functions are now O(1); so there's no  
major access-speed difference between a list and an array.  
  
* Inserting or deleting a list element now takes time proportional to  
the distance to the end of the list, due to moving the array elements.  
(However, it typically *doesn't* require palloc or pfree, so except in  
long lists it's probably still faster than before.)  Notably, lcons()  
used to be about the same cost as lappend(), but that's no longer true  
if the list is long.  Code that uses lcons() and list_delete_first()  
to maintain a stack might usefully be rewritten to push and pop at the  
end of the list rather than the beginning.  
  
* There are now list_insert_nth...() and list_delete_nth...() functions  
that add or remove a list cell identified by index.  These have the  
data-movement penalty explained above, but there's no search penalty.  
  
* list_concat() and variants now copy the second list's data into  
storage belonging to the first list, so there is no longer any  
sharing of cells between the input lists.  The second argument is  
now declared "const List *" to reflect that it isn't changed.  
  
This patch just does the minimum needed to get the new implementation  
in place and fix bugs exposed by the regression tests.  As suggested  
by the foregoing, there's a fair amount of followup work remaining to  
do.  
  
Also, the ENABLE_LIST_COMPAT macros are finally removed in this  
commit.  Code using those should have been gone a dozen years ago.  
  
Patch by me; thanks to David Rowley, Jesper Pedersen, and others  
for review.  
  
Discussion: https://postgr.es/m/11587.1550975080@sss.pgh.pa.us  

commit   : 67b9b3ca328392f9afc4e66fe03564f5fc87feff    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Jul 2019 17:03:46 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Mon, 15 Jul 2019 17:03:46 +1200    

In order to be able to work with FullTransactionId values during replay  
without increasing the size of the WAL, infer the epoch.  In general we  
can't do that safely, but during replay we can because we know that  
nextFullXid can't advance concurrently.  
  
Prevent frontend code from seeing this new function, due to the above  
restriction.  Perhaps in future it will be possible to extract the value  
entirely from independent WAL records, and then this restriction can be  
lifted.  
  
Author: Thomas Munro, based on earlier code from Andres Freund  
Discussion: https://postgr.es/m/CA%2BhUKG%2BmLmuDjMi6o1dxkKvGRL56Y2Rz%2BiXAcrZV03G9ZuFQ8Q%40mail.gmail.com  

commit   : 5925e5549890416bcf588334d9d0bc99f8ad6c7f    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 14 Jul 2019 14:30:27 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 14 Jul 2019 14:30:27 +0200    

This adds a built-in function to generate UUIDs.  
  
PostgreSQL hasn't had a built-in function to generate a UUID yet,  
relying on external modules such as uuid-ossp and pgcrypto to provide  
one.  Now that we have a strong random number generator built-in, we  
can easily provide a version 4 (random) UUID generation function.  
  
This patch takes the existing function gen_random_uuid() from pgcrypto  
and makes it a built-in function.  The pgcrypto implementation now  
internally redirects to the built-in one.  
  
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>  
Discussion: https://www.postgresql.org/message-id/6a65610c-46fc-2323-6b78-e8086340a325@2ndquadrant.com  

commit   : 565f3390005318ea4c982b8d054d56e9fe5a6454    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 15:22:21 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 15:22:21 +0300    

6254c55f81, c085e1c1cb and 075f0a880f all change system catalog.  But  
catversion bump is missed in all of them.  So, do catversion bump now.  
  
Also, I need mention patch reviewer Fabien Coelho, who has been missed in  
commit messages of 6254c55f81, c085e1c1cb and 075f0a880f.  

commit   : 075f0a880fbf790f4a3dcac83e2d5125bcad9646    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 14:57:53 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 14:57:53 +0300    

Opclass support functions already can handle this operator, just catalog  
adjustment appears to be required.  
  
Discussion: https://postgr.es/m/f71ba19d-d989-63b6-f04a-abf02ad9345d%40postgrespro.ru  
Author: Nikita Glukhov  
Reviewed-by: Tom Lane, Alexander Korotkov  

commit   : c085e1c1cb4e29637552f5d250d45ad0cb83e5cf    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 14:56:18 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 14:56:18 +0300    

Index-based calculation of this operator is exact.  So, signature of  
gist_bbox_distance() function is changes so that caller is responsible for  
setting *recheck flag.  
  
Discussion: https://postgr.es/m/f71ba19d-d989-63b6-f04a-abf02ad9345d%40postgrespro.ru  
Author: Nikita Glukhov  
Reviewed-by: Tom Lane, Alexander Korotkov  

commit   : 6254c55f815623bb74e2cf27562437dc3b2aa2c8    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 14:55:01 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 14 Jul 2019 14:55:01 +0300    

Some of <-> operators between geometric types have their commutators missed.  
This commit adds them.  The motivation is upcoming kNN support for some of those  
operators.  
  
Discussion: https://postgr.es/m/f71ba19d-d989-63b6-f04a-abf02ad9345d%40postgrespro.ru  
Author: Nikita Glukhov  
Reviewed-by: Tom Lane, Alexander Korotkov  

commit   : 6e74c64bcf61eab94091f6b17dfd0ab585b1a77e    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sun, 14 Jul 2019 12:07:40 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sun, 14 Jul 2019 12:07:40 +0100    

Performance of a SELECT FOR UPDATE may be quite distinct from the  
non-UPDATE version of the query, so treat all of the FOR UPDATE clause  
as being significant for distinguishing queries.  
  
Andrew Gierth and Vik Fearing, reviewed by Sergei Kornilov, Thomas  
Munro, Tom Lane  
  
Discussion: https://postgr.es/m/87h8e4hfwv.fsf@news-spur.riddles.org.uk  

commit   : 0369f4736665864edd7bf43736df190afa223c4c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 14 Jul 2019 14:19:54 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Sun, 14 Jul 2019 14:19:54 +1200    

We choose a random value for delta, not balance.  Back-patch to 9.6 where  
the mistake arrived.  
  
Author: Fabien Coelho  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1904081752210.5867@lancre  

commit   : 8a0cbb88524e8b6121597285b811640ee793b3e8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 13 Jul 2019 13:34:22 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 13 Jul 2019 13:34:22 -0700    

Commit 578b229718e8f15fa779e20f086c4b6bb3776106 replaced it with a  
concurrent "nextval" test.  That version does not detect PostgreSQL's  
incompatibility with xlc 13.1.3, so bring back an OID-based test that  
does.  Back-patch to v12, where that commit first appeared.  
  
Discussion: https://postgr.es/m/20190707170035.GA1485546@rfd.leadboat.com  

commit   : 39aadc984221f57ce7dc11dd3c8c719e10198549    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Jul 2019 16:51:31 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 13 Jul 2019 16:51:31 +0900