PostgreSQL 13.0 (upcoming) commit log

commit   : 92f9468657f0916ce8589e13d5ebda60c7973c31    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 29 May 2020 17:14:33 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 29 May 2020 17:14:33 +0900    

This commit updates the "Viewing Statistics" section more like  
the existing catalogs chapter.  
  
- Change its layout so that an introductory paragrap is put above  
   the table for each statistics view. Previously the explanations  
   were below the tables.  
  
- Separate each view to different section and add index terms for them.  
  
Author: Fujii Masao  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/6f8a482c-b3fa-4ed9-21c3-6d222a2cb87d@oss.nttdata.com  

commit   : 6a4a335b841520739b7b2f0e608acdf3b814daad    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Thu, 28 May 2020 15:08:12 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Thu, 28 May 2020 15:08:12 -0700    

LLVM has removed this header, in the branch that will become llvm  
11. But as it turns out we didn't actually need it, so just remove it.  
  
Author: Jesse Zhang <sbjesse@gmail.com>  
Discussion: https://postgr.es/m/CAGf+fX7bvtP0YXMu7pOsu_NwhxW6dArTkxb=jt7M2-UJkyJ_3g@mail.gmail.com  
Backpatch: 11, where JIT support using llvm was introduced.  

commit   : 9003b76e169e8524f8d7c7547aded4749b9c39a1    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Thu, 28 May 2020 13:44:54 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Thu, 28 May 2020 13:44:54 -0400    

Two of the members of rconn were left uninitialized. When  
dblink_open() is called without an outer transaction it  
handles the initialization for us, but with an outer  
transaction it does not. Arrange for initialization  
in all cases. Backpatch to all supported versions.  
  
Reported-by: Alexander Lakhin  
Discussion: https://www.postgresql.org/message-id/flat/9bd0744f-5f04-c778-c5b3-809efe9c30c7%40joeconway.com#c545909a41664991aca60c4d70a10ce7  

commit   : 887cdff4dcbdfbfdbf9a29dfad0edc09c6ec3398    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Thu, 28 May 2020 13:16:47 -0400    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Thu, 28 May 2020 13:16:47 -0400    

The repeat() function loops for potentially a long time without  
ever checking for interrupts. This prevents, for example, a query  
cancel from interrupting until the work is all done. Fix by  
inserting a CHECK_FOR_INTERRUPTS() into the loop.  
  
Backpatch to all supported versions.  
  
Discussion: https://www.postgresql.org/message-id/flat/8692553c-7fe8-17d9-cbc1-7cddb758f4c6%40joeconway.com  

commit   : 5b1c61e8b8f98f4a1c42856819b6dea600669f47    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 May 2020 12:37:00 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 May 2020 12:37:00 +0300    

ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE was used in an ereport with the  
same message but different errdetail a few lines earlier, so use that  
here as well.  
  
Backpatch-through: 11  

commit   : 0099db4ce1a19038d0d837bf82a35c989332cc58    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 May 2020 12:35:18 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 28 May 2020 12:35:18 +0300    

The same comment was copied to a few different places, with the same typo.  
Backpatch down to v11, where this typo was introduced.  

commit   : f93bb0ce64005c84e1d1d431eed31e0da4835078    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 May 2020 16:40:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 May 2020 16:40:07 +0900    

segment_open and segment_close were mentioned with incorrect names.  
  
Discussion: https://postgr.es/m/20200525234944.GA1573@paquier.xyz  

commit   : 55ca50deb8ffaec3b81d83c9f54c94f7e519f3a6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 May 2020 15:39:05 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 28 May 2020 15:39:05 +0900    

The default unit for max_slot_wal_keep_size is megabytes.  While on it,  
also change temp_file_limit to use a more consistent wording.  
  
Reported-by: Jeff Janes, Fujii Masao  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/CAMkU=1wWZhhjpwRFKJ9waQGxxROeC0P6UqPvb90fAaGz7dhoHA@mail.gmail.com  

commit   : 0a737be03cf7708e8e27f9596be3406275ec3d49    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 May 2020 16:07:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 27 May 2020 16:07:55 +0200    

This is not handled uniformly throughout the code, but at least nearby  
code can be consistent.  

commit   : 896ddf9b3cd7dcf70e43f733ae8fec5dfe6e31af    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 26 May 2020 16:06:30 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 26 May 2020 16:06:30 -0700    

Disk-based HashAgg relies on writing to multiple tapes  
concurrently. Avoid fragmentation of the tapes' blocks by  
preallocating many blocks for a tape at once. No file operations are  
performed during preallocation; only the block numbers are reserved.  
  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/20200519151202.u2p2gpiawoaznsv2%40development  

commit   : 49223e106b0a43452d64b4e52719532012c81e25    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 26 May 2020 15:58:39 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 26 May 2020 15:58:39 +0200    

Make the wording of new libpq messages more similar to existing  
messages in the backend.  

commit   : add4211600bfece1efb3d62befbc55b521790d76    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 26 May 2020 14:09:36 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 26 May 2020 14:09:36 +0200    

This was done for all scanners in  
421167362242ce1fb46d6d720798787e7cd65aad but not added to the new one.  

commit   : d9101e9806e446a413bcef16d3ab65602ed028ad    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 May 2020 21:53:53 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 May 2020 21:53:53 -0400    

Reported-by: Daniel Gustafsson  
  
Discussion: https://postgr.es/m/54F7560D-498A-4E51-BAA4-17D4AAB2AA57@yesql.se  
  
Backpatch-through: master  

commit   : ac5852fb3042a4562e8a8bab26aaa00fa8183068    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 May 2020 20:19:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 25 May 2020 20:19:28 -0400    

These were missed when these were added to pg_hba.conf in PG 12;  
updates docs and pg_hba.conf.sample.  
  
Reported-by: Arthur Nascimento  
  
Bug: 16380  
  
Discussion: https://postgr.es/m/20200421182736.GG19613@momjian.us  
  
Backpatch-through: 12  

commit   : 587322de36921557fcfcfdd40291669c8ee46968    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 25 May 2020 16:23:48 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 25 May 2020 16:23:48 -0700    

The stmt_len changes do not affect behavior.  LimitPath has no other  
support functions, so that part changes only debugging output.  

commit   : 650eac8d7b6df7147ff4bb29b354510fe1929671    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 25 May 2020 16:21:04 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 25 May 2020 16:21:04 -0700    

The target failed, tested $PATH binaries, or tested a stale temporary  
installation.  Commit c66b438db62748000700c9b90b585e756dd54141 missed  
this.  Back-patch to 9.5 (all supported versions).  

commit   : 5832396432b1ce8349a0028b52295a9874014416    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 May 2020 15:18:11 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 25 May 2020 15:18:11 +0900    

pg_shmem_allocations was in the wrong position with pg_stats.  
  
Author: Ian Barwick  
Discussion: https://postgr.es/m/de7279d4-7ea0-037f-d7d2-1161682339db@2ndquadrant.com  

commit   : a995b371ae29de2d38c4b7881cf414b1560e9746    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 23 May 2020 14:03:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 23 May 2020 14:03:04 +0900    

The following commands have been missing calls to object access hooks  
InvokeObjectPost{Create|Alter}Hook normally applied to all commands:  
- ALTER RULE RENAME TO  
- ALTER USER MAPPING  
- CREATE ACCESS METHOD  
- CREATE STATISTICS  
  
Thanks also to Robert Haas for the discussion.  
  
Author: Mark Dilger  
Reviewed-by: Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/435CD295-F409-44E0-91EC-DF32C7AFCD76@enterprisedb.com  

commit   : c99cec96b8b1e067744b8a70961a3447a2293de0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 May 2020 17:39:16 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 22 May 2020 17:39:16 -0400    

They were introduced in 898e5e3290a7; backpatch to 12.  

commit   : eaae947e2b99a84c8f321fe084d87daff0f77d02    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 22 May 2020 23:33:58 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 22 May 2020 23:33:58 +0900    

Explain that the followings are tracked only when track_io_timing GUC  
is enabled.  
  
- blk_read_time and blk_write_time in pg_stat_database  
- time spent reading and writing data file blocks in EXPLAIN output  
   with BUFFERS option  
  
Whther track_io_timing is enabled affects also blk_read_time and  
blk_write_time in pg_stat_statements, but which was already documented.  
  
Author: Atsushi Torikoshi  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CACZ0uYHo_NwbxpLH76OGF-O=13tkR0ZM0zeyGEhZ+JEXZVRyCA@mail.gmail.com  

commit   : 574925bfd0a8175f6e161936ea11d9695677ba09    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 22 May 2020 10:36:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 22 May 2020 10:36:49 +0200    

Probably copied from nearby calls where it is necessary.  But this one  
also casts away constness, so it was doubly annoying.  

commit   : bb2ae6fa47e5d84b6c5a9e3845021e7df031ec32    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 22 May 2020 15:45:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Fri, 22 May 2020 15:45:00 +0900    

The previous indentation of optimizer functions was unclear; adjust the  
indentation dashes so that a deeper level of indentation indicates that  
the outer optimizer function calls the inner one.  
  
Author: Richard Guo, with additional change by me  
Reviewed-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/CAMbWs4-U-ogzpchGsP2BBMufCss1hktm%2B%2BeTJK_dUC196pw0cQ%40mail.gmail.com  

commit   : 10e1521f5c29da2dbe331462feb5408d5ef16915    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 22:07:17 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 22:07:17 -0400    

Reported-by: Erwin Brandstetter  
  
Discussion: https://postgr.es/m/CAGHENJ4X626ZfYhondXSP4sQgC5zDtsp_LNg1QaD+U7vfgYXQQ@mail.gmail.com  
  
Backpatch-through: head  

commit   : 6ed02e6ac3aac86e8f527e111064012e7911cf43    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 20:34:37 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 20:34:37 -0400    

Reported-by: Erwin Brandstetter  
  
Discussion: https://postgr.es/m/CAGHENJ4X626ZfYhondXSP4sQgC5zDtsp_LNg1QaD+U7vfgYXQQ@mail.gmail.com  
  
Backpatch-through: head  

commit   : 1c2ff3ef07d25ca4d291d35f8a31fe513fde58ab    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 20:28:38 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 20:28:38 -0400    

Reported-by: yigong hu  
  
Discussion: https://postgr.es/m/CAOxFffcourucFqSk+tZA13ErS3XRYkDy6EeaPff4AvHGiEEuug@mail.gmail.com  
  
Backpatch-through: 9.5  

commit   : c20fd088f1c5fb5e492f40d427c45b8de38c879c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 19:49:30 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 21 May 2020 19:49:30 -0400    

Discussion: https://postgr.es/m/2304.1586532634@sss.pgh.pa.us  
  
Backpatch-through: 9.5  

commit   : 449e14a5618432f01066c33055229b96666bd925    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 21 May 2020 13:36:45 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 21 May 2020 13:36:45 -0700    

The B-Tree index deduplication strategy used during CREATE INDEX and  
REINDEX differs from the lazy strategy used by retail inserts.  Make  
that clear by adding a new paragraph to the B-Tree implementation  
section of the documentation.  
  
In passing, do some copy-editing of nearby deduplication documentation.  

commit   : 3350fb5d1f9d73de15428e9bfa83dce96421fc14    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Thu, 21 May 2020 08:31:16 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Thu, 21 May 2020 08:31:16 -0700    

commit   : e4db972ed5f12c09403ff0be24e12e5d4032aaaa    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 May 2020 15:49:20 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 May 2020 15:49:20 +0900    

Since 74a308c, any security-sensitive information gets cleared from  
memory this way.  This was forgotten in 4dc6355.  
  
Author: Daniel Gustafsson  
Reviewed-by: Peter Eisentraut, Michael Paquier  
Discussion: https://postgr.es/m/935443BA-D42E-4CE0-B181-1AD79E6DD45A@yesql.se  

commit   : d2a9959907a03682f4fe182086f9936aca6b2a4f    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 May 2020 14:41:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 21 May 2020 14:41:15 +0900    

When installing binaries and libraries using the MSVC installation  
routines, the operation gets done after moving to the root folder, whose  
location is detected by checking if "configure" exists two times in a  
row.  So, calling the installation script from src/tools/msvc/ with an  
extra "configure" file four levels up the root path of the code tree  
causes the execution to go further up, leading to a failure in finding  
the builds.  This commit fixes the issue by moving to the root folder of  
the code tree only once, when necessary.  
  
Author: Arnold Müller  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/16343-f638f67e7e52b86c@postgresql.org  
Backpatch-through: 9.5  

commit   : e1218f59ea4c0605e72298fa121d5aef4c66def2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 May 2020 14:35:39 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 20 May 2020 14:35:39 -0400    

This doc update was missed in 898e5e3290a7.  Backpatch to 12.  
  
Pointed out by Pavel Luzanov  
Discussion: https://postgr.es/m/642e9fbc-b832-698b-9a8f-d626afd7014d@postgrespro.ru  

commit   : 39cb2ee09cf900454c1bf14f56048b40c840a490    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 May 2020 14:20:50 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 May 2020 14:20:50 +0900    

The description missed a comma and lacked an explanation of what happens  
with REPLICA IDENTITY USING INDEX when the dependent index is dropped.  
  
Author: Marina Polyakova  
Reviewed-by: Daniel Gustafsson, Michael Paquier  
Discussion: https://postgr.es/m/ad1a0badc32658b1bbb07aa312346a1d@postgrespro.ru  
Backpatch-through: 9.5  

commit   : a56e7046d6f2a2ad23ffb9083eba9bc822f18881    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 May 2020 09:12:52 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 20 May 2020 09:12:52 +0900    

Oversight in 2c8dd05d, where the view's column has been renamed.  
  
Reported-by: Fujii Masao  
Discussion: https://postgr.es/m/c049ffcf-d2fe-90f7-c8ba-0741035aa6a7@oss.nttdata.com  

commit   : c7d65a252cdb7219deb48899fa643c5fd2cc3877    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 May 2020 20:09:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 19 May 2020 20:09:59 -0400    

This should be plain old ColId.  Making it so makes the grammar less  
complicated, and makes the compiled tables a kilobyte or so smaller  
(likely because they don't have to deal with a keyword classification  
that's not used anyplace else).  

commit   : 67b0b2dbf947c2308050e49b4591a4bb0e9650fd    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 19 May 2020 15:04:34 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 19 May 2020 15:04:34 -0700    

Commit 624686abcf8 added an assertion that verified that _bt_search  
successfully relocated the leaf page undergoing deletion.  Page deletion  
cannot deal with the case where the descent stack is to the right of the  
page, so this seemed critical (deletion can only handle the case where  
the descent stack is to the left of the leaf/target page).  However, the  
assertion went a bit too far.  
  
Since only a buffer pin is held on the leaf page throughout the call to  
_bt_search, nothing guarantees that it can't have split during this  
small window.  And if does actually split, _bt_search may end up  
"relocating" a page to the right of the original target leaf page.  This  
scenario seems extremely unlikely, but it must still be considered.  
Remove the assertion, and document how we cope in this scenario.  

commit   : c301c2e739c642199f9e4c62d867dc7bd5ef0fd1    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 18 May 2020 19:28:46 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 18 May 2020 19:28:46 -0400    

FETCH FIRST .. ONLY implements this correctly, but we missed to include  
it for FETCH FIRST .. WITH TIES in commit 357889eb17bb.  
  
Author: Vik Fearing  
Discussion: https://postgr.es/m/6aa690ef-551d-e24f-2690-c38c2442947c@postgresfriends.org  

commit   : 7966b7980138ebcee7ae986ebcc393aea38a35c0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 May 2020 16:09:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 May 2020 16:09:19 -0400    

commit   : fe0062c900efa5618197a8e3c88b027e93248db4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 May 2020 13:21:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 18 May 2020 13:21:36 -0400    

g_comment_start and g_comment_end have been unused since commit  
30ab5bd43d8f2082659191de8ae19be98c960ad7.  
  
Daniel Gustafsson  
  
Discussion: https://postgr.es/m/2CA1BA9F-CDF9-41BE-96A1-2EFD2A3EA6CA@yesql.se  

commit   : b31d6efe3d06ca5983bbe63084322b5494b7c3ef    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 18 May 2020 10:20:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 18 May 2020 10:20:09 -0400    

Reported-by: Daniel Gustafsson  
  
Discussion: https://postgr.es/m/0A9D816E-F49C-470B-A23F-8B4AF999382B@yesql.se  

commit   : ac449d88016080663dbc1cd48004b5a481c034ce    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 18 May 2020 12:49:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 18 May 2020 12:49:30 +0200    

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

commit   : a01debe3db3d7f09797460500f217530b502c2de    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 18 May 2020 11:55:11 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 18 May 2020 11:55:11 +0200    

Author: Daniel Gustafsson  

commit   : 7e041b0c1d13b243b595d0b00145cb1116e4c327    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 18 May 2020 07:53:26 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 18 May 2020 07:53:26 +0530    

Reported-by: Sawada Masahiko  
Author: Sawada Masahiko  
Reviewed-by: Amit Kapila  
Backpatch-through: 9.5  
Discussion: https://postgr.es/m/CA+fd4k4Ws7M7YQ8PqSym5WB1y75dZeBTd1sZJUQdfe0KJQ-iSA@mail.gmail.com  

commit   : 18b9d22cef988c4a67d440f6cafc160d9c05871b    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 17 May 2020 13:02:16 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 17 May 2020 13:02:16 +0300    

 * Rename column "Opfamily Name" to "Operator family" for uniformity.  
 * Rename column alias from "t1" to "t".  

commit   : 29b6ddd38d0914340c3c4bb4bb4bd5c4a3c02dca    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 17 May 2020 12:53:34 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 17 May 2020 12:53:34 +0300    

Make number of translate_columns elements match the number of output columns.  
The only "true" value, which was previously specified, seems to be intended  
for opfamily operator "purpose" column.  But that column has already translated  
values substituted.  So, all elements in translate_columns[] should be "false".  

commit   : b1953e67e4c481f8d3844dcdd8fdd4054d7e7604    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 17 May 2020 12:41:19 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 17 May 2020 12:41:19 +0300    

This commit changes ORDER BY clause for \dAo and \dAp psql commands in  
the following way.  
 * Operators for the same types are grouped together.  
 * Same-class operators and procedures are listed before cross-class operators  
   and procedures.  
  
Modification of ORDER BY clause for \dAp required removing DISTINCT clause,  
which doesn't seem to affect anything.  
  
Discussion: https://postgr.es/m/20200511210856.GA18368%40alvherre.pgsql  
Author: Alvaro Herrera revised by me  
Reviewed-by: Alexander Korotkov, Nikita Glukhov  

commit   : eeba6c7e4366057a09c53efe11f144db55e68c5e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 16 May 2020 22:19:02 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 16 May 2020 22:19:02 -0400    

Author: Erik Rijkers <er@xs4all.nl>  
Discussion: https://postgr.es/m/508f2fb1764c3bd518ee96a4f2247d6f@xs4all.nl  

commit   : 3048898e73c75f54bb259323382e0e7f6368cb6f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 21:00:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 21:00:05 -0400    

Synchronize the event names for parallel hash join waits with other  
event names, by getting rid of the slashes and dropping "-ing"  
suffixes.  Rename ClogGroupUpdate to XactGroupUpdate, to match the  
new SLRU name.  Move the ProcSignalBarrier event to the IPC category;  
it doesn't belong under IO.  
  
Also a bit more wordsmithing in the wait event documentation tables.  
  
Discussion: https://postgr.es/m/4505.1589640417@sss.pgh.pa.us  

commit   : 2c8dd05d6cbc86b7ad21cfd7010e041bb4c3950b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 17 May 2020 09:22:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 17 May 2020 09:22:07 +0900    

d140f2f3 has renamed receivedUpto to flushedUpto, and has added  
writtenUpto to the WAL receiver's shared memory information, but  
pg_stat_wal_receiver was not consistent with that.  This commit renames  
received_lsn to flushed_lsn, and adds a new column called written_lsn.  
  
Bump catalog version.  
  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera  
Discussion: https://postgr.es/m/20200515090817.GA212736@paquier.xyz  

commit   : e78b93094518b1e262cba8115470f252dde6f446    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 19:44:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 19:44:49 -0400    

libpq's exports.txt was overlooked in commit 36d108761, which the  
buildfarm is quite unhappy about.  
  
Also, I'd gathered that the plan included renaming PQgetSSLKeyPassHook  
to PQgetSSLKeyPassHook_OpenSSL, but that didn't happen in the patch  
as committed.  I'm taking it on my own authority to do so now, since  
the window before beta1 is closing fast.  

commit   : 36d1087611bf96b0cd716666fc8c4a2d168fa501    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 16 May 2020 16:20:43 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 16 May 2020 16:20:43 -0400    

4dc6355210 provided a way for libraries and clients to modify how libpq  
handles client certificate passphrases, by installing a hook. However,  
these routines are quite specific to how OpenSSL works, so it's  
misleading and not future-proof to have these names not refer to OpenSSL.  
Change all the names to add "_OpenSSL" after "Hook", and fix the docs  
accordingly.  
  
Author: Daniel Gustafsson  
  
Discussion: https://postgr.es/m/981DE552-E399-45C2-9F60-3F0E3770CC61@yesql.se  

commit   : 1cbc143f06113cbd1b94790c0781aa4b410cffc2    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 16 May 2020 15:10:36 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Sat, 16 May 2020 15:10:36 -0400    

Reported privately by Justin Pryzby  

commit   : fa27dd40d5c5f56a1ee837a75c97549e992e32a4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 11:54:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 11:54:51 -0400    

Thomas Munro fixed a longstanding annoyance in pg_bsd_indent, that  
it would misformat lines containing IsA() macros on the assumption  
that the IsA() call should be treated like a cast.  This improves  
some other cases involving field/variable names that match typedefs,  
too.  The only places that get worse are a couple of uses of the  
OpenSSL macro STACK_OF(); we'll gladly take that trade-off.  
  
Discussion: https://postgr.es/m/20200114221814.GA19630@alvherre.pgsql  

commit   : e02ad575d8ab6b44500d2a3fd8c3212345e3aa2b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 11:49:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 16 May 2020 11:49:14 -0400    

This is just to provide a clean basis for comparison of the results  
of the new version.  I did fix a typo that crept into 242dfcbaf.  
  
Discussion: https://postgr.es/m/20200114221814.GA19630@alvherre.pgsql  

commit   : 7ccb2f54d9f3f3c5b4ac092d62c846b02a47f8d5    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sat, 16 May 2020 18:15:18 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sat, 16 May 2020 18:15:18 +0900    

In a logical replication subscriber, a table using REPLICA IDENTITY FULL  
which has a primary key would try to use the primary key's index  
available to scan for a tuple, but an assertion only assumed as correct  
the case of an index associated to REPLICA IDENTITY USING INDEX.  This  
commit corrects the assertion so as the use of a primary key index is a  
valid case.  
  
Reported-by: Dilip Kumar  
Analyzed-by: Dilip Kumar  
Author: Euler Taveira  
Reviewed-by: Michael Paquier, Masahiko Sawada  
Discussion: https://postgr.es/m/CAFiTN-u64S5bUiPL1q5kwpHNd0hRnf1OE-bzxNiOs5zo84i51w@mail.gmail.com  
Backpatch-through: 10  

commit   : 474e7da6485687425d216eda1685d7e530b24fd6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 21:47:21 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 21:47:21 -0400    

It's just weird that this name wasn't chosen to look like an  
identifier.  The suspicion that it wasn't thought about too  
hard is reinforced by the fact that it wasn't documented in  
the pg_locks view (until I did so, a day or two back).  
  
Update, and add a comment reminding future adjusters of this  
array to fix the docs too.  
  
Do some desultory wordsmithing on various entries in the wait  
events tables.  
  
Discussion: https://postgr.es/m/24595.1589326879@sss.pgh.pa.us  

commit   : 1d3743023ef8fa665902e791b0d52e9a1ab419cb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 19:59:29 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 19:59:29 -0400    

In commit 850196b610d2 I (Álvaro) failed to handle the case of walsender  
shutting down on an error before setting up its 'xlogreader' pointer;  
the error handling code dereferences the pointer, causing a crash.  
Fix by testing the pointer before trying to dereference it.  
  
Kyotaro authored the code fix; I adopted Nathan's test case to be used  
by the TAP tests and added the necessary PostgresNode change.  
  
Reported-by: Nathan Bossart <bossartn@amazon.com>  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/C04FC24E-903D-4423-B312-6910E4D846E5@amazon.com  

commit   : 14a91010912632cae322b06fce0425faedcf7353    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 19:55:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 19:55:56 -0400    

This was mostly confusing, especially since some wait events in  
this class had the suffix and some did not.  
  
While at it, stop exposing MainLWLockNames[] as a globally visible  
name; any code using that directly is almost certainly wrong, as  
its name has been misleading for some time.  
(GetLWLockIdentifier() is what to use instead.)  
  
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us  

commit   : 8048404939bb0fcef80b0ab57910b6e10d4289a3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 19:05:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 19:05:39 -0400    

The previous coding zeroed out offsetof(ReplicationStateCtl, states)  
more bytes than it was entitled to, as a consequence of starting the  
zeroing from the wrong pointer (or, if you prefer, using the wrong  
calculation of how much to zero).  
  
It's unsurprising that this has not caused any reported problems,  
since it can be expected that the newly-allocated block is at the end  
of what we've used in shared memory, and we always make the shmem  
block substantially bigger than minimally necessary.  Nonetheless,  
this is wrong and it could bite us someday; plus it's a dangerous  
model for somebody to copy.  
  
This dates back to the introduction of this code (commit 5aa235042),  
so back-patch to all supported branches.  

commit   : 36ac359d3621578cefc2156a3917024cdd3b1829    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 18:11:03 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 18:11:03 -0400    

Choose names that fit into the conventions for wait event names  
(particularly, that multi-word names are in the style MultiWordName)  
and hopefully convey more information to non-hacker users than the  
previous names did.  
  
Also rename SerializablePredicateLockListLock to  
SerializablePredicateListLock; the old name was long enough to cause  
table formatting problems, plus the double occurrence of "Lock" seems  
confusing/error-prone.  
  
Also change a couple of particularly opaque LWLock field names.  
  
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us  

commit   : a0ab4f4909a3f52e8b8243d2ae2dbb6f5027136c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 18:05:34 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 18:05:34 -0400    

commit   : 242dfcbafac592a3f097ec2e4e36fe1b739f7f29    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 16:50:34 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 16:50:34 -0400    

_bt_killitems marks btree items dead when a scan leaves the page where  
they live, but it does so with only share lock (to improve concurrency).  
This was historicall okay, since killing a dead item has no  
consequences.  However, with the advent of data checksums and  
wal_log_hints, this action incurs a WAL full-page-image record of the  
page.  Multiple concurrent processes would write the same page several  
times, leading to WAL bloat.  The probability of this happening can be  
reduced by only killing items if they're not already dead, so change the  
code to do that.  
  
The problem could eliminated completely by having _bt_killitems upgrade  
to exclusive lock upon seeing a killable item, but that would reduce  
concurrency so it's considered a cure worse than the disease.  
  
Backpatch all the way back to 9.5, since wal_log_hints was introduced in  
9.4.  
  
Author: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>  
Discussion: https://postgr.es/m/CA+fd4k6PeRj2CkzapWNrERkja5G0-6D-YQiKfbukJV+qZGFZ_Q@mail.gmail.com  

commit   : 5da14938f7bfb96b648ee3c47e7ea2afca5bcc4a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 14:28:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 15 May 2020 14:28:19 -0400    

Originally, the names assigned to SLRUs had no purpose other than  
being shmem lookup keys, so not a lot of thought went into them.  
As of v13, though, we're exposing them in the pg_stat_slru view and  
the pg_stat_reset_slru function, so it seems advisable to take a bit  
more care.  Rename them to names based on the associated on-disk  
storage directories (which fortunately we *did* think about, to some  
extent; since those are also visible to DBAs, consistency seems like  
a good thing).  Also rename the associated LWLocks, since those names  
are likewise user-exposed now as wait event names.  
  
For the most part I only touched symbols used in the respective modules'  
SimpleLruInit() calls, not the names of other related objects.  This  
renaming could have been taken further, and maybe someday we will do so.  
But for now it seems undesirable to change the names of any globally  
visible functions or structs, so some inconsistency is unavoidable.  
  
(But I *did* terminate "oldserxid" with prejudice, as I found that  
name both unreadable and not descriptive of the SLRU's contents.)  
  
Table 27.12 needs re-alphabetization now, but I'll leave that till  
after the other LWLock renamings I have in mind.  
  
Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us  

commit   : 756abe2bc7608b38c579c510eb66f2bd80d10785    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 13:24:22 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 15 May 2020 13:24:22 -0400    

Add some more terms, clarify some definitions, remove redundant terms,  
move a couple of terms to keep alphabetical order.  
  
Co-authored-by: Jürgen Purtz <juergen@purtz.de>  
Co-authored-by: Erik Rijkers <er@xs4all.nl>  
Co-authored-by: Laurenz Albe <laurenz.albe@cybertec.at>  
Discussion: https://postgr.es/m/7b9b469e804777ac9df4d37716db935e@xs4all.nl  

commit   : 6755b618997424b9e651126f59bf4109d680fffe    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 12:47:07 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 12:47:07 -0400    

This avoids using <link> and supplied text.  

commit   : 85af628da5e8dfea068559d076ad26b9a3378bfc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 12:38:40 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 12:38:40 -0400    

This is for use by the PG 13 release notes, but might be used for minor  
release notes in the future.  
  
Backpatch-through: 9.5  

commit   : 75fcdd2ae2174c49a56acb4d10c920a6a45570f7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 12:05:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 12:05:43 -0400    

Add missing xreflabels for index types, geqo, libpq, spi, server-side  
languages, ecpg, and vaacuumlo.  
  
Backpatch-through: 9.5  

commit   : bc1c1de2cc30411bc5551ce1c7443914efa1fb86    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 11:21:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 11:21:43 -0400    

commit   : 065ea0c30d2c8290af368721708bd369b5020996    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 10:57:14 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 10:57:14 -0400    

commit   : e90807085c7f398c52a1567daf9cacff578031cf    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 10:40:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 10:40:09 -0400    

commit   : e936fcb54d22561ad49c6c18f91dcb7566a58da1    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 09:55:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 09:55:43 -0400    

Backpatch-through: 9.5  

commit   : 8d4b23fcae1f368122eb900489d6d24df75cff13    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 08:52:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 08:52:24 -0400    

commit   : ec5afb0a4e050616fe6953e597fd1f61d47edc3a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 08:29:57 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 15 May 2020 08:29:57 -0400    

commit   : a9cf48a4cf0c878684a2f52a3a88e29399b2065e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 15 May 2020 08:10:00 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 15 May 2020 08:10:00 +0530    

COPY TO released the ACCESS SHARE lock immediately when it was done rather  
than holding on to it until the end of the transaction.  
  
This breaks the case where a REPEATABLE READ transaction could see an  
empty table if it repeats a COPY statement and somebody truncated the  
table in the meantime.  
  
Before 4dded12faad the lock was also released after COPY FROM, but the  
commit failed to notice the irregularity in COPY TO.  
  
This is old behavior but doesn't seem important enough to backpatch.  
  
Author: Laurenz Albe, based on suggestion by Robert Haas and Tom Lane  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/7bcfc39d4176faf85ab317d0c26786953646a411.camel@cybertec.at  

commit   : 39e7bcbbff82e25441529349134bf41fc336169b    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 14 May 2020 22:36:21 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 14 May 2020 22:36:21 -0400    

commit   : ff87fabef20ef40c8438e25fe28e9159f874183d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 15 May 2020 08:19:30 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 15 May 2020 08:19:30 +0900    

The reasons why event triggers are disabled in standalone mode are  
documented in the code path of ddl_command_start, and other places  
checking if standalone mode is enabled or not mention to refer to the  
comment for ddl_command_start, except for table_rewrite that duplicated  
the same explanation.  
  
Reported-by: David G. Johnston  
Discussion: https://postgr.es/m/CAKFQuwYqHtXpvr2mBJRwH9f+Y5y1GXw3rhbaAu0Dk2MoNevsmA@mail.gmail.com  

commit   : 2e619f86a96c32a710a09a4ff555952746813ba8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 18:44:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 18:44:18 -0400    

I abbreviated the heck out of the column headings, and made a few  
small wording changes, to get it to build warning-free.  I can't  
say that the result is pretty, but it's probably better than  
removing this table entirely.  
  
As of this commit, we have zero "exceed the available area" warnings  
in a US-letter PDF build, and one such warning (about an 863-millipoint  
overrun) in an A4 build.  I expect to get rid of that one by renaming  
wait events, so I'm not doing anything about it at the formatting  
level.  
  
Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us  

commit   : 3d14c174cbbb6f83d8ac63fa7d0e1f42e0ae8d30    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 18:13:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 18:13:08 -0400    

In one or two places it seemed reasonable to modify the example so as  
to shorten its output slightly; but for the most part I just added a  
&zwsp; after 67 characters, which is the most we can fit on a line  
of monospace text in A4 format.  
  
Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us  

commit   : 5cbfce562f7cd2aab0cdc4694ce298ec3567930e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 13:06:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 13:06:38 -0400    

Includes some manual cleanup of places that pgindent messed up,  
most of which weren't per project style anyway.  
  
Notably, it seems some people didn't absorb the style rules of  
commit c9d297751, because there were a bunch of new occurrences  
of function calls with a newline just after the left paren, all  
with faulty expectations about how the rest of the call would get  
indented.  

commit   : 1255466f8358ecac29581aa5ecec76628dc2e33c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 14 May 2020 11:51:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 14 May 2020 11:51:09 -0400    

commit   : 29c3e2dd5a6aeaf1a23d7d83d665501e2dcc6955    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 11:10:31 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 14 May 2020 11:10:31 -0400    

There is little point in using the LWLockRegisterTranche mechanism for  
built-in tranche names.  It wastes cycles, it creates opportunities for  
bugs (since failing to register a tranche name is a very hard-to-detect  
problem), and the lack of any centralized list of names encourages  
sloppy nonconformity in name choices.  Moreover, since we have a  
centralized list of the tranches anyway in enum BuiltinTrancheIds, we're  
certainly not buying any flexibility in return for these disadvantages.  
  
Hence, nuke all the backend-internal LWLockRegisterTranche calls,  
and instead provide a const array of the builtin tranche names.  
  
(I have in mind to change a bunch of these names shortly, but this  
patch is just about getting them into one place.)  
  
Discussion: https://postgr.es/m/9056.1589419765@sss.pgh.pa.us  

commit   : 07451e1f1adc4ff832196f1f47def13e49d2ed38    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 14 May 2020 20:14:58 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 14 May 2020 20:14:58 +0900    

This addresses some whitespace issues with programlisting, and corrects  
the spelling of "Enter PEM pass phrase" to be consistent with the code.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/401F9024-20EA-4239-83C4-6B7AD35F94BD@yesql.se  

commit   : 267cc6ed29668fcf2e527f514f0fbbeaa73c388e    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 14 May 2020 13:53:16 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 14 May 2020 13:53:16 +0300    

The type is called "pem_password_cb", not "pem_passwd_cb".  
  
Author: Daniel Gustafsson  
Discussion: https://www.postgresql.org/message-id/22108CF6-228B-45CF-9CDA-5C5F658DCC22@yesql.se  

commit   : 34dae902ca1c7d32a24b711131911e3045c0097d    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 14 May 2020 12:44:44 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 14 May 2020 12:44:44 +0300    

amcheck expects at least hikey to always exist on leaf page even if it is  
deleted page.  But replica reinitializes page during replay of page deletion,  
causing deleted page to have no items.  Thus, replay of page deletion can  
cause an error in concurrent amcheck run.  
  
This commit relaxes amcheck expectation making it tolerate deleted page with  
no items.  
  
Reported-by: Konstantin Knizhnik  
Discussion: https://postgr.es/m/CAPpHfdt_OTyQpXaPJcWzV2N-LNeNJseNB-K_A66qG%3DL518VTFw%40mail.gmail.com  
Author: Alexander Korotkov  
Reviewed-by: Peter Geoghegan  
Backpatch-through: 11  

commit   : e8abf585ab453ca9c2f66f2138baf6d3c9c8fbf0    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 14 May 2020 08:39:26 +0300    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 14 May 2020 08:39:26 +0300    

Commit 3eb77eba5a moved the loop and refactored it, and inadvertently  
changed the effect of fsync=off so that it also skipped removing entries  
from the pendingOps table. That was not intentional, and leads to an  
assertion failure if you turn fsync on while the server is running and  
reload the config.  
  
Backpatch-through: 12-  
Reviewed-By: Thomas Munro  
Discussion: https://www.postgresql.org/message-id/3cbc7f4b-a5fa-56e9-9591-c886deb07513%40iki.fi  

commit   : a169155453e3d1c40c729a5318fd5298a990e5b0    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 14 May 2020 09:23:56 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 14 May 2020 09:23:56 +0530    

Visual Studio 2015 and later versions should still be able to do the same  
as Visual Studio 2012, but the declaration of locale_name is missing in  
_locale_t, causing the code compilation to fail, hence this falls back  
instead on to enumerating all system locales by using EnumSystemLocalesEx  
to find the required locale name.  If the input argument is in Unix-style  
then we can get ISO Locale name directly by using GetLocaleInfoEx() with  
LCType as LOCALE_SNAME.  
  
In passing, change the documentation references of the now obsolete links.  
  
Note that this problem occurs only with NLS enabled builds.  
  
Author: Juan José Santamaría Flecha, Davinder Singh and Amit Kapila  
Reviewed-by: Ranier Vilela and Amit Kapila  
Backpatch-through: 9.5  
Discussion: https://postgr.es/m/CAHzhFSFoJEWezR96um4-rg5W6m2Rj9Ud2CNZvV4NWc9tXV7aXQ@mail.gmail.com  

commit   : cee9cadb592fed6a6cb126f02002aba029544bd8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 13 May 2020 20:42:09 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 13 May 2020 20:42:09 -0700    

The defect suppressed a Standby Status Update message when bytes flushed  
to disk had changed but bytes received had not changed.  If  
pg_recvlogical then exited with no intervening Standby Status Update,  
the next pg_recvlogical repeated already-flushed records.  The defect  
could also cause superfluous messages, which are functionally harmless.  
Back-patch to 9.5 (all supported versions).  
  
Discussion: https://postgr.es/m/20200502221647.GA3941274@rfd.leadboat.com  

commit   : 8222a9d9a12356349114ec275b01a1a58da2b941    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Wed, 13 May 2020 20:42:09 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Wed, 13 May 2020 20:42:09 -0700    

pg_recvlogical merely called PQfinish(), so the backend sent messages  
after the disconnect.  When that caused EPIPE in internal_flush(),  
before a LogicalConfirmReceivedLocation(), the next pg_recvlogical would  
repeat already-acknowledged records.  Whether or not the defect causes  
EPIPE, post-disconnect messages could contain an ErrorResponse that the  
user should see.  One properly ends PGRES_COPY_OUT by repeating  
PQgetCopyData() until it returns a negative value.  Augment one of the  
tests to cover the case of WAL past --endpos.  Back-patch to v10, where  
commit 7c030783a5bd07cadffc2a1018bc33119a4c7505 first appeared.  Before  
that commit, pg_recvlogical never reached PGRES_COPY_OUT.  
  
Reported by Thomas Munro.  
  
Discussion: https://postgr.es/m/CAEepm=1MzM2Z_xNe4foGwZ1a+MO_2S9oYDq3M5D11=JDU_+0Nw@mail.gmail.com  

commit   : 4fa8bd392d02637b4e4f27b79c06079e47765cbc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 23:36:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 23:36:58 -0400    

The previous design for this table didn't really work in narrow views,  
such as PDF output; besides which its reliance on large morerows  
values made it a pain to maintain (cf ab3e4fbd5, for example).  
  
I experimented with a couple of ways to fix it, but the best and  
simplest is to split it up into a separate table for each event  
type category.  
  
I also rearranged the event ordering to be strictly alphabetical,  
as nobody would ever be able to find entries otherwise.  
  
There is work afoot to revise the set of event names described  
in this table, but this commit just changes the layout, not the  
contents.  
  
In passing, add a missing entry to pg_locks.locktype,  
and cross-reference that to the related wait event list.  
  
Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us  

commit   : a042750646db7ea28ff722855cf163401761937f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 23:03:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 23:03:39 -0400    

This changes our catalog and view descriptions to use a style inspired  
by the new format for function/operator tables: each table entry is  
formatted roughly like a <varlistentry>, with the column name and type  
on the first line and then an indented description.  This provides much  
more room for expansive descriptions than we had before, and thereby  
eliminates a passel of PDF build warnings.  
  
Discussion: https://postgr.es/m/12984.1588643549@sss.pgh.pa.us  

commit   : 7fd89f4d7a51af77175a876613cffb490b9e5df1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 22:48:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 22:48:09 -0400    

Previously, AsyncShmemInit forcibly initialized the first page of the  
async SLRU, to save dealing with that case in asyncQueueAddEntries.  
But this is a poor tradeoff, since many installations do not ever use  
NOTIFY; for them, expending those cycles in AsyncShmemInit is a  
complete waste.  Besides, this only saves a couple of instructions  
in asyncQueueAddEntries, which hardly seems likely to be measurable.  
  
The real reason to change this now, though, is that now that we track  
SLRU access stats, the existing code is causing the postmaster to  
accumulate some access counts, which then get inherited into child  
processes by fork(), messing up the statistics.  Delaying the  
initialization into the first child that does a NOTIFY fixes that.  
  
Hence, we can revert f3d23d83e, which was an incorrect attempt at  
fixing that issue.  Also, add an Assert to pgstat.c that should  
catch any future errors of the same sort.  
  
Discussion: https://postgr.es/m/8367.1589391884@sss.pgh.pa.us  

commit   : d82a5058fdb5905abc9867da302000c39aa30f01    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 13 May 2020 22:48:11 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 13 May 2020 22:48:11 -0400    

commit   : 17cc133f017cb13737e23ce0da4415daf2c34cc3    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 May 2020 15:31:14 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 May 2020 15:31:14 -0400    

The additional pain from level 4 is excessive for the gain.  
  
Also revert all the source annotation changes to their original  
wordings, to avoid back-patching pain.  
  
Discussion: https://postgr.es/m/31166.1589378554@sss.pgh.pa.us  

commit   : 81ca8686305c4c62d723ab224ad5c414f350a3a0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 13:08:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 13 May 2020 13:08:12 -0400    

Instead of re-identifying which statistics bucket to use for a given  
SLRU on every counter increment, do it once during shmem initialization.  
This saves a fair number of cycles, and there's no real cost because  
we could not have a bucket assignment that varies over time or across  
backends anyway.  
  
Also, get rid of the ill-considered decision to let pgstat.c pry  
directly into SLRU's shared state; it's cleaner just to have slru.c  
pass the stats bucket number.  
  
In consequence of these changes, there's no longer any need to store  
an SLRU's LWLock tranche info in shared memory, so get rid of that,  
making this a net reduction in shmem consumption.  (That partly  
reverts fe702a7b3.)  
  
This is basically code review for 28cac71bd, so I also cleaned up  
some comments, removed a dangling extern declaration, fixed some  
things that should be static and/or const, etc.  
  
Discussion: https://postgr.es/m/3618.1589313035@sss.pgh.pa.us  

commit   : 850196b610d2a1802b4ed7f9f608153a949eda34    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 May 2020 12:17:08 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 13 May 2020 12:17:08 -0400    

* Have both physical and logical walsender share a 'xlogreader' state  
  struct for tracking state.  This replaces the existing globals sendSeg  
  and sendCxt.  
  
* Change WALRead not to receive XLogReaderState->seg and ->segcxt as  
  separate arguments anymore; just use the ones from 'state'.  This is  
  made possible by the above change.  
  
* have the XLogReader segment_open contract require the callbacks to  
  install the file descriptor in the state struct themselves instead of  
  returning it.  xlogreader was already ignoring any possible failed  
  return from the callbacks, relying solely on them never returning.  
  
  (This point is not altogether excellent, as it means the callbacks  
  have to know more of XLogReaderState; but to really improve on that  
  we would have to pass back error info from the callbacks to  
  xlogreader.  And the complexity would not be saved but instead just  
  transferred to the callers of WALRead, which would have to learn how  
  to throw errors from the open_segment callback in addition of, as  
  currently, from pg_pread.)  
  
* segment_open no longer receives the 'segcxt' as a separate argument,  
  since it's part of the XLogReaderState argument.  
  
Per comments from Kyotaro Horiguchi.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20200511203336.GA9913@alvherre.pgsql  

commit   : 043e3e04016077735f986726a3a74192c295ace7    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 May 2020 22:20:37 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 May 2020 22:20:37 +0900    

This commit changes pg_stat_get_slru() so that it uses  
TimestampTzGetDatum() for stats_reset field because that field  
stores the timestamp with time zone value. Previously  
Int64GetDatum() was used.  
  
Author: Fujii Masao  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/b8784fe6-1401-ab35-aa14-d57b5bb8e312@oss.nttdata.com  

commit   : f3d23d83ef9a33344391acbaa92a6235a4350791    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 May 2020 22:19:25 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 13 May 2020 22:19:25 +0900    

Previously since SLRUStats was not initialized, SLRU stats counters  
could begin with non-zero value. Which could lead to incorrect results  
in pg_stat_slru view.  
  
Author: Fujii Masao  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/976bbb73-a112-de3c-c488-b34b64609793@oss.nttdata.com  

commit   : ac3a4866c0bf1d7a14009f18d3b42ffcb063a7e9    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 12 May 2020 17:17:12 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 12 May 2020 17:17:12 -0400    

commit   : 87c291e29d6bf403c6adefd81ddafa134c254a3e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 May 2020 16:15:55 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 May 2020 16:15:55 -0400    

contrib/pgcrypto did contain an unedited fall-through marker after all.  

commit   : 3e9744465dbe51822c7d76baca1f934d54ba9452    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 May 2020 16:01:52 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 12 May 2020 16:01:52 -0400    

Use it at level 4, a bit more restrictive than the default level, and  
tweak our commanding comments to FALLTHROUGH.  
  
(However, leave zic.c alone, since it's external code; to avoid the  
warnings that would appear there, change CFLAGS for that file in the  
Makefile.)  
  
Author: Julien Rouhaud <rjuju123@gmail.com>  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://postgr.es/m/20200412081825.qyo5vwwco3fv4gdo@nol  
Discussion: https://postgr.es/m/flat/E1fDenm-0000C8-IJ@gemulon.postgresql.org  

commit   : 6a918c3ac8a6b1d8b53cead6fcb7cbd84eee5750    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 12 May 2020 20:04:39 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 12 May 2020 20:04:39 +0200    

The explain format used by incremental sort was somewhat inconsistent  
with other nodes, making it harder to parse and understand. This commit  
addresses that by  
  
 - adding an extra space to better separate groups of values  
  
 - using colons instead of equal signs to separate key/value  
  
 - properly capitalizing first letter of a key  
  
 - using separate lines for full and pre-sorted groups  
  
These changes were proposed by Justin Pryzby and mostly copy the final  
explain format used to report WAL usage.  
  
Author: Justin Pryzby  
Reviewed-by: James Coleman  
Discussion: https://postgr.es/m/20200419023625.GP26953@telsasoft.com  

commit   : 1a40d37a9faff562a36bd255a993fd3503bdf2b1    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 12 May 2020 19:37:13 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 12 May 2020 19:37:13 +0200    

Author: Justin Pryzby, James Coleman  
Discussion: https://postgr.es/m/20200419023625.GP26953@telsasoft.com  

commit   : 7b48f1b490978a8abca61e9a9380f8de2a56f266    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 May 2020 13:03:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 12 May 2020 13:03:43 -0400    

Run renumber_oids.pl to move high-numbered OIDs down, as per pre-beta  
tasks specified by RELEASE_CHANGES.  For reference, the command was  
./renumber_oids.pl --first-mapped-oid=8000 --target-oid=5032  
  
Also run reformat_dat_file.pl while I'm here.  
  
Renumbering recently-added types changed some results in the opr_sanity  
test.  To make those a bit easier to eyeball-verify, change the queries  
to show regtype not just bare type OIDs.  (I think we didn't have  
regtype when these queries were written.)  

commit   : 2793bbe75e276476877ff9af6bb7effe92eff782    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 12 May 2020 19:55:55 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Tue, 12 May 2020 19:55:55 +0900    

My oversight in commit c8434d64c.  

commit   : 078c9cd258e5ad8f54081c971b7b927f845e7505    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 12 May 2020 14:43:57 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 12 May 2020 14:43:57 +0900    

The existing callers of XLogReadDetermineTimeline() performing recovery  
need to check a replay LSN position when determining on which timeline  
to read a WAL page.  A portion of the comment describing this function  
said exactly that, while referring to a routine for fetching a write  
LSN, something not available in recovery.  
  
Author: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20200511.101619.2043820539323292957.horikyota.ntt@gmail.com  

commit   : 81ec990a23b9cbfaa5684e90091164f1d85f24d3    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 12 May 2020 13:56:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 12 May 2020 13:56:19 +0900    

Commit 2eb34ac369 changed error messages emit when commands are  
rejected during recovery. But it forgot to update the standbycheck  
regression test output with those error message changes.  
  
Reported-by: Michail Nikolaev  
Author: Michail Nikolaev  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CANtu0ojFPgcspH=0nNZ+qmu0XD69sXKtVttuSoYKHawRADSQGg@mail.gmail.com  

commit   : b89d90b051a1da7a447b25dc749ce42ccb4dc5bd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 May 2020 22:58:47 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 May 2020 22:58:47 -0400    

Add section about function table reformatting.  

commit   : 57775e82b235b2c815d9fd85cea53d77373a9203    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2020 20:41:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2020 20:41:06 -0400    

I can't see any way to make this table fit in PDF column width  
without either a fundamental redesign or abbreviating EXCLUSIVE.  
So I did the latter.  
  
It'd be nicer if the abbreviating didn't leak into the HTML output  
as well; but the hackery required to make the output different  
seems like more trouble than it's really worth.  
  
Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us  

commit   : aa976d3b9004bd2c275e4ad17fa897ce5fe5127e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 May 2020 21:24:08 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 May 2020 21:24:08 -0400    

commit   : ca4599b0dcc4ed44e24cc4f2cd39677a19356324    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 May 2020 21:19:57 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 11 May 2020 21:19:57 -0400    

commit   : 4d1563717fb1860168a40b852e1d61a33ecdd62f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2020 20:03:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2020 20:03:55 -0400    

Even after the tweaking I did in commit 5545b69ae, some of the  
longer keywords mentioned in the SQL standard don't fit the  
available space in PDF output.  
  
I experimented with various solutions like putting such keywords  
on their own table lines, but everything looked ugly or confusing  
or both; worse, the weirdness also appeared in the HTML version,  
which (normally) doesn't need it.  
  
The best answer seems to be to insert &zwsp; into long keywords  
so that they can be broken into two lines when, and only when,  
needed.  It doesn't look too awful if the break happens after  
an underscore --- and fortunately, all the problematic keywords  
have underscores.  
  
Discussion: https://postgr.es/m/6916.1589146280@sss.pgh.pa.us  

commit   : 60c90c16c1885bb9aa2047b66f958b865c5d397e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2020 14:15:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 11 May 2020 14:15:49 -0400    

Use xreflabel attributes instead of endterm attributes to control the  
appearance of links to subsections of SQL command reference pages.  
This is simpler, it matches what we do elsewhere (e.g. for GUC variables),  
and it doesn't draw "Unresolved ID reference" warnings from the PDF  
toolchain.  
  
Fix some places where the text was absolutely dependent on an <xref>  
rendering exactly so, by using a <link> around the required text  
instead.  At least one of those spots had already been turned into  
bad grammar by subsequent changes, and the whole idea is just too  
fragile for my taste.  <xref> does NOT have fixed output, don't write  
as if it does.  
  
Consistently include a page-level link in cross-man-page references,  
because otherwise they are useless/nonsensical in man-page output.  
Likewise, be consistent about mentioning "below" or "above" in same-page  
references; we were doing that in about 90% of the cases, but now it's  
100%.  
  
Also get rid of another nonfunctional-in-PDF idea, of making  
cross-references to functions by sticking ID tags on <row> constructs.  
We can put the IDs on <indexterm>s instead --- which is probably not any  
more sensible in abstract terms, but it works where the other doesn't.  
(There is talk of attaching cross-reference IDs to most or all of  
the docs' function descriptions, but for now I just fixed the two  
that exist.)  
  
Discussion: https://postgr.es/m/14480.1589154358@sss.pgh.pa.us  

commit   : 624686abcf87d26fe7c03543c4a54aad2237cb93    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 11 May 2020 11:01:07 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 11 May 2020 11:01:07 -0700    

Restructure the function that locates the root of the to-be-deleted  
subtree during nbtree page deletion.  Handle the conditions that make  
page deletion unsafe in a slightly more uniform way, and acknowledge the  
fact that the behavior with incomplete splits on internal pages is  
different (as pointed out in the nbtree README as of commit 35bc0ec7).  
Also invent new terminology that avoids ambiguity around which pages are  
about to be deleted.  Consistently use the term "to-be-deleted subtree",  
not the ambiguous term "branch".  
  
We were calling the subtree parent page the "top parent page", but that  
was quite misleading.  The top parent page usually refers to a page  
unlinked from its siblings and marked deleted (during the second stage  
of page deletion).  There was one kind of top parent page that we merely  
removed a downlink from, and another kind of top parent page that we  
actually marked deleted.  Eliminate the ambiguity by inventing a new  
term ("subtree parent page") that refers to the former kind of page  
only.  

commit   : a8be5364ac1678e35029f547632d4002552f943c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 11 May 2020 12:46:41 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 11 May 2020 12:46:41 -0400    

The one in xlogreader.h was pointed out by Antonin Houska; I (Álvaro) noticed the  
others by grepping.  
  
Author: Antonin Houska <ah@cybertec.at>  
Discussion: https://postgr.es/m/28250.1589186654@antos  

commit   : 7a9c9ce6411720c2bbeaf6e64855d4263c47ea80    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 May 2020 13:14:32 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 11 May 2020 13:14:32 +0200    

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

commit   : 336aa51b70e9cf7da3969a3f102ff4913717083d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 May 2020 16:20:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 10 May 2020 16:20:28 -0400    

This patch eliminates a few more "exceed the available area" warnings  
whose causes aren't particularly connected to anything else.  
  
The only one really worthy of comment is that I increased the space  
allowed for an <orderedlist>'s numbers, because the default of 1em  
doesn't quite work for more than one digit.  The rest are one-off  
insertions of &zwsp; and suchlike tweaks, in places where they  
shouldn't do any damage to the material.  (In particular, although  
I split some long identifiers with zwsp's, there are other nearby  
occurrences of each one; so those changes shouldn't hurt greppability  
of the document sources.)  

commit   : e111c9f90ab6090859127cbb22156f4858b6a40c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Sun, 10 May 2020 10:58:54 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Sun, 10 May 2020 10:58:54 +0900    

The last caller of this routine was removed in b416691, and as a wise  
man said one day, dead code tends to silently break.  
  
Per discussion between Fujii Masao, Peter Geoghegan, Vignesh C and me.  
  
Reported-by: Peter Geoghegan  
Discussion: https://postgr.es/m/CAH2-Wz=sg5H8-vG4d5UmAofdcRMpeTDt2K-NUWp4GSfhenRGAQ@mail.gmail.com  

commit   : 9356e43544287f1b727e6cb3350f98e35ecea752    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 May 2020 19:09:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 May 2020 19:09:44 -0400    

I made up a very crude hack to compare the docs with reality (as  
embodied in the system catalogs) ... and indeed they don't match  
everywhere.  Missing oid columns, wrong data types, wrong "references"  
links, columns listed in the wrong order.  None of this seems quite  
important enough to back-patch.  

commit   : 96d175e3e2ea1bbf734f21444126a711da12108b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 May 2020 16:28:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 May 2020 16:28:09 -0400    

Somehow we'd never noticed this oversight, even though it means  
that such basic columns as pg_proc.proargtypes were not being  
validated by the oidjoins test.  Correct the query and update  
the test script with the newly-found dependencies.  

commit   : ebeb3dea772652887b67a7549906f5a9ec8a487f    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 9 May 2020 19:41:42 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 9 May 2020 19:41:42 +0200    

Incremental sort always processes at least one full group group before  
switching to prefix groups, so it's enough to check just the number of  
full groups. There was no risk of division by zero due to the extra  
condition, but it made the code harder to understand.  
  
Reported-by: Ranier Vilela  
Discussion: https://postgr.es/m/CAEudQAp+7qoS92-4V1vLChpdY3vEkLCbf+gye6P-4cirE-0z0A@mail.gmail.com  

commit   : 9155b4be9a13038d59a7a09a27b7fbce3819eb08    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 9 May 2020 19:41:36 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 9 May 2020 19:41:36 +0200    

ExecReScanIncrementalSort was resetting bounded=false, which means the  
optimization would be disabled on all rescans. This happens because  
ExecSetTupleBound is called before the rescan, not after it.  
  
Author: James Coleman  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/20200414065336.GI1492@paquier.xyz  

commit   : c4427226483c78618ba45eff34917400a77718a5    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 9 May 2020 19:41:18 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 9 May 2020 19:41:18 +0200    

The executor flags were not handled entirely correctly, although the  
bugs were mostly harmless and it was mostly comment inaccuracy. We don't  
need to strip any of the flags for child nodes.  
  
Incremental sort does not support backward scans of mark/restore, so  
MARK/BACKWARDS flags should not be possible. So we simply ensure this  
using an assert, and we don't bother removing them when initializing  
the child node.  
  
With REWIND it's a bit less clear - incremental sort does not support  
REWIND, but there is no way to signal this - it's legal to just ignore  
the flag. We however continue passing the flag to child nodes, because  
they might be useful to leverage that.  
  
Reported-by: Michael Paquier  
Author: James Coleman  
Reviewed-by: Tomas Vondra  
Discussion: https://postgr.es/m/20200414065336.GI1492@paquier.xyz  

commit   : 6c298881c20797ac424558b9ff68d9781e03f6c4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 May 2020 13:05:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 9 May 2020 13:05:08 -0400    

We seem to have forgotten to do this in the v12 cycle, so add it as  
a task in the RELEASE_CHANGES list, in hopes we won't forget again.  
  
While here, fix findoidjoins.c so that it actually works in the  
new dispensation where OID is a regular column, and change it to only  
consider system relations (this avoids being fooled by the OID column  
in the brintest test table).  
  
Also tweak the largeobject test so that the somewhat-recently-added  
manual creation of a LO with an OID in the system range doesn't  
fool findoidjoins.c.  For the moment I just made that use an unused  
OID, but we might have to find a more robust solution someday.  

commit   : 89a7d21dfc9d891d2b3dcfea161b58d4ea458af6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 May 2020 19:38:46 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 May 2020 19:38:46 -0400    

Almost all error messages already include file name where relevant, but  
this one had been overlooked.  Repair.  
  
Backpatch to 9.5.  
  
Author: Euler Taveira <euler.taveira@2ndquadrant.com>  
Discussion: https://postgr.es/m/CAH503wA_VOrcKL_43p9atRejCDYmOZ8MzfK9S6TJrQqBqNeAXA@mail.gmail.com  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  

commit   : b060dbe0001a1d6bf26cd294710f3cb203868d46    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 May 2020 15:30:34 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 8 May 2020 15:30:34 -0400    

Code review for 0dc8ead46363, prompted by a bug closed by 91c40548d5f7.  
  
XLogReader's system for opening and closing segments had gotten too  
complicated, with callbacks being passed at both the XLogReaderAllocate  
level (read_page) as well as at the WALRead level (segment_open).  This  
was confusing and hard to follow, so restructure things so that these  
callbacks are passed together at XLogReaderAllocate time, and add  
another callback to the set (segment_close) to make it a coherent whole.  
Also, ensure XLogReaderState is an argument to all the callbacks, so  
that they can grab at the ->private data if necessary.  
  
Document the whole arrangement more clearly.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://postgr.es/m/20200422175754.GA19858@alvherre.pgsql  

commit   : 871696ba20e0251e86041576373809d1c7ca161d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 May 2020 20:35:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 May 2020 20:35:03 +0200    

*in* database, *in* cluster, *on* server; and some related fixes  

commit   : 7666ef313dcc22c8716ee74dfefab8e5ea628678    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 May 2020 13:33:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 8 May 2020 13:33:00 +0200    

There were a few different ways to line-wrap the error messages.  Make  
them all the same, and use placeholders for the actual program names,  
to save translation work.  

commit   : 086ffddf3656fb3d24d9a73ce36cb1102e42cc90    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 6 May 2020 16:25:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 6 May 2020 16:25:54 +0200    

Several combinations of generated columns and inheritance in CREATE  
TABLE were not handled correctly.  Specifically:  
  
- Disallow a child column specifying a generation expression if the  
  parent column is a generated column.  The child column definition  
  must be unadorned and the parent column's generation expression will  
  be copied.  
  
- Prohibit a child column of a generated parent column specifying  
  default values or identity.  
  
- Allow a child column of a not-generated parent column specifying  
  itself as a generated column.  This previously did not work, but it  
  was possible to arrive at the state via other means (involving ALTER  
  TABLE), so it seems sensible to support it.  
  
Add tests for each case.  Also add documentation about the rules  
involving generated columns and inheritance.  
  
Discussion:  
    https://www.postgresql.org/message-id/flat/15830.1575468847%40sss.pgh.pa.us  
    https://www.postgresql.org/message-id/flat/2678bad1-048f-519a-ef24-b12962f41807%40enterprisedb.com  
    https://www.postgresql.org/message-id/flat/CAJvUf_u4h0DxkCMCeEKAWCuzGUTnDP-G5iVmSwxLQSXn0_FWNQ%40mail.gmail.com  

commit   : 501e41dd3cb945287fdcfe25e8906e79872fcc44    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Apr 2020 14:10:01 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Apr 2020 14:10:01 +0200    

When creating a new index, the attstorage setting of the table column  
is copied to regular (non-expression) index columns.  But a later  
ALTER TABLE ... SET STORAGE is not propagated to indexes, thus  
creating an inconsistent and undumpable state.  
  
Discussion: https://www.postgresql.org/message-id/flat/9765d72b-37c0-06f5-e349-2a580aafd989%402ndquadrant.com  

commit   : f9463d2a903da930531d124ea8bbbff8c097d86b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 8 May 2020 08:33:05 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 8 May 2020 08:33:05 +0530    

Commit 6e654546fb avoids locking bufmgr partitions to make pg_buffercache  
less disruptive on production systems but forgot to update the docs.  
  
Reported-by: Sawada Masahiko  
Author: Sawada Masahiko  
Reviewed-by: Amit Kapila  
Backpatch-through: 10  
Discussion: https://postgr.es/m/CA+fd4k6sD8oeP1qJbFAor=rCpYckU9DsywHiYx3x5Hz5Z8Ua_w@mail.gmail.com  

commit   : f2ff2035962cd2ddd56c1593709d48ca0d3a78c5    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 8 May 2020 10:36:40 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 8 May 2020 10:36:40 +0900    

TimelineHistoryRead and TimelineHistoryWrite wait events are reported  
during waiting for a read and write of a timeline history file, respectively.  
However, previously, TimelineHistoryRead wait event was not reported  
while readTimeLineHistory() was reading a timeline history file. Also  
TimelineHistoryWrite was not reported while writeTimeLineHistory() was  
writing one line with the details of the timeline split, at the end.  
This commit fixes these issues.  
  
Back-patch to v10 where wait events for a timeline history file was added.  
  
Author: Masahiro Ikeda  
Reviewed-by: Michael Paquier, Fujii Masao  
Discussion: https://postgr.es/m/d11b0c910b63684424e06772eb844ab5@oss.nttdata.com  

commit   : cd8c73a38a23c364e71973d6832a585616d24756    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 7 May 2020 16:08:54 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 7 May 2020 16:08:54 -0700    

Factor out code common to _bt_lock_branch_parent() and _bt_pagedel()  
into a new utility function.  This new function is used to check that  
the left sibling of a deletion target page does not have the  
INCOMPLETE_SPLIT page flag set.  If it is set then deletion is unsafe;  
there won't be a usable pivot tuple (with a downlink) in the parent page  
that points to the deletion target page.  The page deletion algorithm is  
not prepared to deal with that.  Also restructure an existing, related  
utility function that checks if the right sibling of the target page has  
the ISHALFDEAD page flag set.  
  
This organization highlights the symmetry between the two cases.  The  
goal is to make the design of page deletion clearer.  Both functions  
involve a sibling page with a flag that indicates that there was an  
interrupted operation (a page split or a page deletion) that resulted in  
a page pointed to by sibling pages, but not pointed to in the parent.  
And, both functions indicate if page deletion is unsafe due to the  
absence of a particular downlink in the parent page.  

commit   : db89f0e3a45e98c1065355af75f41b5652333111    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 May 2020 15:59:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 May 2020 15:59:51 -0400    

checkcondition_str() failed to report multiple matches for a prefix  
pattern correctly: it would dutifully merge the match positions, but  
then after exiting that loop, if the last prefix-matching word had  
had no suitable positions, it would report there were no matches.  
The upshot would be failing to recognize a match that the query  
should match.  
  
It looks like you need all of these conditions to see the bug:  
* a phrase search (else we don't ask for match position details)  
* a prefix search item (else we don't get to this code)  
* a weight restriction (else checkclass_str won't fail)  
  
Noted while investigating a problem report from Pavel Borisov,  
though this is distinct from the issue he was on about.  
  
Back-patch to 9.6 where phrase search was added.  

commit   : b2fd8ebe239f726b99923f827e908a92f6f4f232    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 May 2020 14:25:18 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 7 May 2020 14:25:18 -0400    

This converts the contrib documentation to the new style, and mops up  
a couple of function tables that were outside chapter 9 in the main  
docs.  
  
A few contrib modules choose not to present their functions in the  
standard tabular format.  There might be room to rethink those decisions  
now that the standard format is more friendly to verbose descriptions.  
But I have not undertaken to do that here; I just converted existing  
tables.  

commit   : c265ed9b355fdd2a80e7af64e88cddabd3d39151    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 May 2020 13:06:31 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 May 2020 13:06:31 -0400    

Reported-by: Amit Langote  

commit   : db9e99da2c61f46bfe37032bab1ee602e5c8335c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 May 2020 10:01:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 May 2020 10:01:22 -0400    

commit   : 545a065880be8ccddfb116a0915bfdac0cd41902    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 May 2020 09:00:24 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 7 May 2020 09:00:24 -0400    

This merges three partition publication items into two.  

commit   : fb544735f11480a697fcab791c058adc166be1fa    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 6 May 2020 19:34:22 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 6 May 2020 19:34:22 -0400    

Reported-by: Andrey M. Borodin  
  
Discussion: https://postgr.es/m/D49B37B1-E2B9-4F67-8C6C-5CFD4015E8C5@yandex-team.ru  

commit   : c3d1fdb59891e78df9ffb89b3e8bea780bd90568    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 6 May 2020 19:07:29 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 6 May 2020 19:07:29 -0400    

Reported-by: Fabien COELHO  
  
Discussion: https://postgr.es/m/alpine.DEB.2.22.394.2005051811320.2183756@pseudo  

commit   : 90be091480d439db6876f6cbebf9ea42ccb79496    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 May 2020 15:58:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 May 2020 15:58:23 -0400    

In the wake of commit f21599311, we don't need to set table columns'  
align specs retail.  Undo a few such settings I'd added in commit  
5545b69ae.  (The column width adjustments stay, though.)  

commit   : 5be594caf818e0b5e33f8dec191f2707394a6d95    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 6 May 2020 12:29:41 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 6 May 2020 12:29:41 -0400    

We were acquiring object locks then deleting objects one by one, instead  
of acquiring all object locks first, ignoring those that did not exist,  
and then deleting all objects together.   The latter is the correct  
protocol to use, and what this commits changes to code to do.  Failing  
to follow that leads to "cache lookup failed for relation XYZ" error  
reports when DROP OWNED runs concurrently with other DDL -- for example,  
a session termination that removes some temp tables.  
  
Author: Álvaro Herrera  
Reported-by: Mithun Chicklore Yogendra (Mithun CY)  
Reviewed-by: Ahsan Hadi, Tom Lane  
Discussion: https://postgr.es/m/CADq3xVZTbzK4ZLKq+dn_vB4QafXXbmMgDP3trY-GuLnib2Ai1w@mail.gmail.com  

commit   : f21599311e50a43c90a3d33ef4f60193a774321a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 May 2020 12:23:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 6 May 2020 12:23:43 -0400    

I concluded that we really just ought to force all tables in PDF output  
to default to "left" alignment (instead of "justify"); that is what the  
HTML toolchain does and that's what most people have been designing the  
tables to look good with.  There are few if any places where "justify"  
produces better-looking output, and there are many where it looks  
horrible.  So change stylesheet-fo.xsl to make that true.  
  
Also tweak column widths in a few more tables to make them look better  
and avoid "exceed the available area" warnings.  This commit fixes  
basically everything that can be fixed through that approach.  The  
remaining tables that give warnings either are scheduled for redesign  
as per recent discussions, or need a fundamental rethink because they  
Just Don't Work in a narrow view.  

commit   : beb2516e961490723fb1a2f193406afb3d71ea9c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 6 May 2020 21:08:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 6 May 2020 21:08:15 +0900    

Attempting to use an installation path of Python that includes spaces  
caused the MSVC builds to fail.  This fixes the issue by using the same  
quoting method as ad7595b for OpenSSL.  
  
Author: Victor Wagner  
Discussion: https://postgr.es/m/20200430150608.6dc6b8c4@antares.wagner.home  
Backpatch-through: 9.5  

commit   : 7dc37ccea8599f460ec95b8a0208e2047a6fb4bf    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 17:45:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 17:45:34 -0400    

commit   : d08ac7d85fc844bb5b2cb456a858e9f4d344722c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 17:43:27 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 17:43:27 -0400    

commit   : 0025a90f732b06027f6eaa6d35dbb303baffef10    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 5 May 2020 14:42:10 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 5 May 2020 14:42:10 -0700    

Oversight in commit bc3087b626d.  

commit   : 18c117cc56269f064d1b81674771d1559cf88b3d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 5 May 2020 14:36:54 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 5 May 2020 14:36:54 -0700    

Oversight in commit d114cc53.  

commit   : e0acac67da46951bf00d4d0df33a8020cac7308c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 17:21:57 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 17:21:57 -0400    

commit   : b0e02f47cdb0be44a229e261e932221575381269    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 16:31:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 16:31:44 -0400    

commit   : bb20f2c80d81377b036b1a673261ca842282ee10    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 May 2020 16:06:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 May 2020 16:06:49 -0400    

Moving this setting into the main configuration file was ill-considered,  
perhaps, because that typically causes it to be set before  
timezone_abbreviations has been set.  Which in turn means that zone  
abbreviations don't work, only full zone names.  
  
We could imagine hacking things so that such cases do work, but the  
stability of the hack would be questionable, and the value isn't really  
that high.  Instead just document that you should use a numeric zone  
offset or a full zone name.  
  
Per bug #16404 from Reijo Suhonen.  
Back-patch to v12 where this was changed.  
  
Discussion: https://postgr.es/m/16404-4603a99603fbd04c@postgresql.org  

commit   : 98c017c5760c1107a846c85eb20a1b3b80cad8c7    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 14:40:27 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 14:40:27 -0400    

Reported-by: Justin Pryzby  

commit   : ab3f2f45d28235ee60ac2426f2282f401a0b0c12    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 13:18:05 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 13:18:05 -0400    

Reported-by: Justin Pryzby  

commit   : 46da7bf671c002659d48dad72d325167db8df84b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 May 2020 13:10:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 5 May 2020 13:10:09 -0400    

Both the backend and libpq leaked buffers containing encrypted data  
to be transmitted, so that the process size would grow roughly as  
the total amount of data sent.  
  
There were also far-less-critical leaks of the same sort in GSSAPI  
session establishment.  
  
Oversight in commit b0b39f72b, which I failed to notice while  
reviewing the code in 2c0cdc818.  
  
Per complaint from pmc@citylink.  
Back-patch to v12 where this code was introduced.  
  
Discussion: https://postgr.es/m/20200504115649.GA77072@gate.oper.dinoex.org  

commit   : d4329a60d5708382957e61d1036a03929f75c9fc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 12:42:55 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 12:42:55 -0400    

commit   : 61dfa727494ffa337cadde51a01d3a1813c1f6d2    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 11:42:28 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 11:42:28 -0400    

commit   : 3114d26bfb93962e503df19210086abe67f2044e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 10:33:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 10:33:50 -0400    

commit   : 41297fa7d86d0410efc90aebdd39f686b81bf09e    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 10:32:50 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 5 May 2020 10:32:50 -0400    

Minor corrections from individuals.  

commit   : d5627f3cd0ba191f1e647d66f6d5bb09ff95b786    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 5 May 2020 08:49:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 5 May 2020 08:49:52 +0200    

commit   : c5114e42fa1ddd2c44a03339ffa436e732477397    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 5 May 2020 14:16:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 5 May 2020 14:16:01 +0900    

The following docs are updated:  
- High-availaility section  
- pg_basebackup  
- pg_receivewal  
  
Per the principle of least privilege, we want to encourage users to  
interact with those areas using roles that have replication rights, but  
superusers were mentioned first.  
  
Author: Daniel Gustafsson  
Reviewed-by: Fujii Masao, Michael Paquier  
Discussion: https://postgr.es/m/ECEBD212-7101-41EB-84F3-2F356E4B6401@yesql.se  

commit   : 849ac3581329bdcbcfdba4452fa9c1ec6e10c24c    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 4 May 2020 23:09:45 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 4 May 2020 23:09:45 -0400    

This still needs markup, indenting, and word wrap.  

commit   : 69bfaf2e1de49de76d7dec1c45511932a5ef502b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 5 May 2020 08:00:53 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 5 May 2020 08:00:53 +0530    

In commit 33e05f89c5, we have added the option to display WAL usage  
statistics in Explain and auto_explain.  The display format used two spaces  
between each field which is inconsistent with Buffer usage statistics which  
is using one space between each field.  Change the format to make WAL usage  
statistics consistent with Buffer usage statistics.  
  
This commit also changed the usage of "full page writes" to  
"full page images" for WAL usage statistics to make it consistent with  
other parts of code and docs.  
  
Author: Julien Rouhaud, Amit Kapila  
Reviewed-by: Justin Pryzby, Kyotaro Horiguchi and Amit Kapila  
Discussion: https://postgr.es/m/CAB-hujrP8ZfUkvL5OYETipQwA=e3n7oqHFU=4ZLxWS_Cza3kQQ@mail.gmail.com  

commit   : 5545b69ae65f27ba1f4ceaf24486e98c186e9412    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 May 2020 16:16:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 May 2020 16:16:42 -0400    

The PDF toolchain defaults to laying out all columns of a table with  
equal widths, in contrast to the HTML rendering which automatically  
varies the column widths to fit the data.  In many places, this  
results in very badly laid-out tables, with lots of useless whitespace  
in some places and text that overruns its cell in other places.  
  
For tables that have reasonably static content, we can improve  
matters by adding <colspec> entries to hand-assign the column widths.  
This commit does that for a few of the tables that were worst off;  
it eliminates close to 200 "contents ... exceed the available area"  
warnings in an A4 PDF build.  
  
I also forced align="left" in these tables, overriding the PDF  
toolchain's default which is evidently "justify".  (The HTML toolchain  
seems to default to that already.)  Anyplace where things are tight  
enough that we need to worry about this, forced justification tends to  
look truly awful.  

commit   : 20c6905dee43a8888090674cb3db9f953ae7f646    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 4 May 2020 11:23:44 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 4 May 2020 11:23:44 -0700    

Add a test case to contrib/amcheck that creates coverage of code paths  
that are used to verify posting list tuples (tuples created when  
deduplication merges together existing tuples to avoid a leaf page  
split).  

commit   : 47046763c3ed1f16b81a389df7e44be5f3dba83c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 May 2020 13:48:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 May 2020 13:48:30 -0400    

We had a mishmash of <replaceable>, <replaceable class="parameter">,  
and <parameter> markup for operator/function arguments.  Use <parameter>  
consistently for things that are in fact names of parameters (including  
OUT parameters), reserving <replaceable> for things that aren't.  The  
latter class includes some made-up-by-the-docs type class names, like  
"numeric_type", as well as placeholders for arguments that don't have  
well-defined types.  Possibly we could do better with those categories  
as well, but for the moment I'm content not to have parameter names  
marked up in different ways in different places.  
  
(This commit aligns the earlier sections of chapter 9 with a policy  
that I'd arrived at while working on commit 1ad23335f, which is why  
the last few sections need no changes.)  

commit   : 1ad23335f36b07f4574906a8dc66a3d62af7c40c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 May 2020 12:18:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 4 May 2020 12:18:06 -0400    

With the usual quota of minor and less-minor editorial changes.  

commit   : 9f87ae38eaffcc7f72c45bfeb79e09dd6e8c2f48    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 3 May 2020 12:19:31 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Sun, 3 May 2020 12:19:31 +0300    

Reported-by: Oleg Bartunov  

commit   : 7dd777938bbeae8113f73849920a5b19bef723d9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 3 May 2020 10:45:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 3 May 2020 10:45:52 +0200    

commit   : 9dc72514179d85e81ea594130ff0eb655188f225    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 2 May 2020 14:04:33 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 2 May 2020 14:04:33 -0700    

Remove one of the arguments to btvacuumpage(), and give up on the idea  
that it's a recursive function.  We now use the term "backtracking" to  
refer to the case where an earlier block must be visited to make sure no  
tuples that need to be removed were missed.  
  
Advertising btvacuumpage() as a recursive function was unhelpful.  In  
reality the function always simulates recursion with a loop (it doesn't  
actually call itself).  This wasn't just necessary as a precaution (per  
the comments mentioning tail recursion), though.  There is no reliable  
natural limit on the number of times we can backtrack.  
  
There are important behavioral difference when "recursing"/backtracking,  
mostly related to page deletion.  We don't perform page deletion when  
backtracking due to the extra complexity.  And when we recurse, we're  
not performing a physical order scan anymore, so we expect fairly  
different conditions to hold for the page.  Structuring the code like  
this makes it clearer how _bt_pagedel() cooperates with btvacuumpage()  
and btvacuumscan() (as established in commit b0229f26 and commit  
73a076b0).  
  
Author: Peter Geoghegan  
Reviewed-By: Masahiko Sawada  
Discussion: https://postgr.es/m/CAH2-WzmRGMDWiLMcb+zagG9652PboNN4Gfcq1Gc_wJL6A716MA@mail.gmail.com  

commit   : b68a560f8ebfc7eed679d09facdce5512a38c9c2    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sat, 2 May 2020 11:39:26 -0400    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sat, 2 May 2020 11:39:26 -0400    

If the client is compiled with GSSAPI support and tries to start up GSS  
with the server, but the server is not compiled with GSSAPI support, we  
would mistakenly end up falling through to call ProcessStartupPacket  
with secure_done = true, but the client might then try to perform SSL,  
which the backend wouldn't understand and we'd end up failing the  
connection with:  
  
FATAL:  unsupported frontend protocol 1234.5679: server supports 2.0 to 3.0  
  
Fix by arranging to track ssl_done independently from gss_done, instead  
of trying to use the same boolean for both.  
  
Author: Andrew Gierth  
Discussion: https://postgr.es/m/87h82kzwqn.fsf@news-spur.riddles.org.uk  
Backpatch: 12-, where GSSAPI encryption was added.  

commit   : d5d09692ea6b96944d24c44db1451f085b64ba09    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 15:30:10 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 15:30:10 +0200    

The extra memset meant pg_stat_reset_slru() always reset all the entries  
even when reset of a single entry was requested, but the timestamp was  
left uninitialized.  
  
Reported-by: Atsushi Torikoshi  
Discussion: https://postgr.es/m/CACZ0uYFe16pjZxQYaTn53mspyM7dgMPYL3DJLjjPw69GMCC2Ow%40mail.gmail.com  

commit   : e685ca63ca4f5d6c9c27499d94fc71d2065b55d9    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 15:26:47 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 15:26:47 +0200    

This should have been included in 2e08d314ed.  
  
Reported-by: Fujii Masao  
Discussion: https://postgr.es/m/20200119143707.gyinppnigokesjok@development  

commit   : 747134838870b842c5aae673065da7227517e5b5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 2 May 2020 10:33:10 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 2 May 2020 10:33:10 +0200    

commit   : 60fbb4d762506c352c1af1229288a0753742cd95    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 01:25:00 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 01:25:00 +0200    

Commit de0dc1a847 added code to cost_incremental_sort to handle varno 0.  
Explicitly removing the RelabelType is not really necessary, because the  
pull_varnos handles that just fine, which simplifies the code a bit.  
  
Author: Richard Guo  
Discussion: https://postgr.es/m/CAMbWs4_3_D2J5XxOuw68hvn0-gJsw9FXNSGcZka9aTymn9UJ8A%40mail.gmail.com  
Discussion: https://postgr.es/m/20200411214639.GK2228%40telsasoft.com  

commit   : 2e08d314ed07363636a5da65f2a3abf7135f8ba8    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 00:36:25 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Sat, 2 May 2020 00:36:25 +0200    

The "pg_xact" entry was duplicate with "clog" and was added by mistake.  
  
Reported-by: Fujii Masao  
Discussion: https://postgr.es/m/20200119143707.gyinppnigokesjok@development  

commit   : 0da06d9faf9e865c7d16a358a30ebe1a0014a709    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 May 2020 17:28:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 May 2020 17:28:00 -0400    

Writing a trailing semicolon in a macro is almost never the right thing,  
because you almost always want to write a semicolon after each macro  
call instead.  (Even if there was some reason to prefer not to, pgindent  
would probably make a hash of code formatted that way; so within PG the  
rule should basically be "don't do it".)  Thus, if we have a semi inside  
the macro, the compiler sees "something;;".  Much of the time the extra  
empty statement is harmless, but it could lead to mysterious syntax  
errors at call sites.  In perhaps an overabundance of neatnik-ism, let's  
run around and get rid of the excess semicolons whereever possible.  
  
The only thing worse than a mysterious syntax error is a mysterious  
syntax error that only happens in the back branches; therefore,  
backpatch these changes where relevant, which is most of them because  
most of these mistakes are old.  (The lack of reported problems shows  
that this is largely a hypothetical issue, but still, it could bite  
us in some future patch.)  
  
John Naylor and Tom Lane  
  
Discussion: https://postgr.es/m/CACPNZCs0qWTqJ2QUSGJ07B7uvAvzMb-KbG2q+oo+J3tsWN5cqw@mail.gmail.com  

commit   : d66935448f41b1e0af11a939b6c5aaa9a619524a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 May 2020 16:16:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 1 May 2020 16:16:28 -0400    

With the usual quota of minor editorial changes.  

commit   : 69cf853fe798c6d590db892d80677e45609e3395    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 12:19:44 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 12:19:44 -0700    

On further reflection, code comments added by commit b0229f26 slightly  
misrepresented how we determine the oldest bpto.xact for the index.  
btvacuumpage() does not treat the bpto.xact of a page that it put in the  
FSM as a candidate to be the oldest deleted page (the delete-marked page  
that has the oldest bpto.xact XID among all pages encountered).  
  
The definition of a deleted page for the purposes of the bpto.xact  
calculation is different from the definition used by the bulk delete  
statistics.  The bulk delete statistics don't distinguish between pages  
that were deleted by the current VACUUM, pages deleted by a previous  
VACUUM operation but not yet recyclable/reusable, and pages that are  
reusable (though reusable pages are counted separately).  
  
Backpatch: 11-, just like commit b0229f26.  

commit   : 4e21f8b63354323897fa2ab778bfe003c44df75b    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 10:03:38 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 10:03:38 -0700    

commit   : 73a076b03f1cf0761329ace55ec3601d47f04075    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 09:51:09 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 09:51:09 -0700    

The logic for determining how many nbtree pages in an index are deleted  
pages sometimes undercounted pages.  Pages that were deleted by the  
current VACUUM operation (as opposed to some previous VACUUM operation  
whose deleted pages have yet to be reused) were sometimes overlooked.  
The final count is exposed to users through VACUUM VERBOSE's "%u index  
pages have been deleted" output.  
  
btvacuumpage() avoided double-counting when _bt_pagedel() deleted more  
than one page by assuming that only one page was deleted, and that the  
additional deleted pages would get picked up during a future call to  
btvacuumpage() by the same VACUUM operation.  _bt_pagedel() can  
legitimately delete pages that the btvacuumscan() scan will not visit  
again, though, so that assumption was slightly faulty.  
  
Fix the accounting by teaching _bt_pagedel() about its caller's  
requirements.  It now only reports on pages that it knows btvacuumscan()  
won't visit again (including the current btvacuumpage() page), so  
everything works out in the end.  
  
This bug has been around forever.  Only backpatch to v11, though, to  
keep _bt_pagedel() is sync on the branches that have today's bugfix  
commit b0229f26da.  Note that this commit changes the signature of  
_bt_pagedel(), just like commit b0229f26da.  
  
Author: Peter Geoghegan  
Reviewed-By: Masahiko Sawada  
Discussion: https://postgr.es/m/CAH2-WzkrXBcMQWAYUJMFTTvzx_r4q=pYSjDe07JnUXhe+OZnJA@mail.gmail.com  
Backpatch: 11-  

commit   : b0229f26da753688af586580707facc29616f97c    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 08:39:52 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 1 May 2020 08:39:52 -0700    

Commit 857f9c36cda (which taught nbtree VACUUM to skip a scan of the  
index from btcleanup in situations where it doesn't seem worth it) made  
VACUUM maintain the oldest btpo.xact among all deleted pages for the  
index as a whole.  It failed to handle all the details surrounding pages  
that are deleted by the current VACUUM operation correctly (though pages  
deleted by some previous VACUUM operation were processed correctly).  
  
The most immediate problem was that the special area of the page was  
examined without a buffer pin at one point.  More fundamentally, the  
handling failed to account for the full range of _bt_pagedel()  
behaviors.  For example, _bt_pagedel() sometimes deletes internal pages  
in passing, as part of deleting an entire subtree with btvacuumpage()  
caller's page as the leaf level page.  The original leaf page passed to  
_bt_pagedel() might not be the page that it deletes first in cases where  
deletion can take place.  
  
It's unclear how disruptive this bug may have been, or what symptoms  
users might want to look out for.  The issue was spotted during  
unrelated code review.  
  
To fix, push down the logic for maintaining the oldest btpo.xact to  
_bt_pagedel().  btvacuumpage() is now responsible for pages that were  
fully deleted by a previous VACUUM operation, while _bt_pagedel() is now  
responsible for pages that were deleted by the current VACUUM operation  
(this includes half-dead pages from a previous interrupted VACUUM  
operation that become fully deleted in _bt_pagedel()).  Note that  
_bt_pagedel() should never encounter an existing deleted page.  
  
This commit theoretically breaks the ABI of a stable release by changing  
the signature of _bt_pagedel().  However, if any third party extension  
is actually affected by this, then it must already be completely broken  
(since there are numerous assumptions made in _bt_pagedel() that cannot  
be met outside of VACUUM).  It seems highly unlikely that such an  
extension actually exists, in any case.  
  
Author: Peter Geoghegan  
Reviewed-By: Masahiko Sawada  
Discussion: https://postgr.es/m/CAH2-WzkrXBcMQWAYUJMFTTvzx_r4q=pYSjDe07JnUXhe+OZnJA@mail.gmail.com  
Backpatch: 11-, where the "skip full scan" feature was introduced.  

commit   : 3c800ae0b931c85f6ae949bc468fa3e51f9d5716    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 1 May 2020 11:49:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 1 May 2020 11:49:52 +0200    

commit   : 78bad97faa160c292ea91a0ea8f081907903ee79    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 May 2020 17:40:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 1 May 2020 17:40:41 +0900    

The pg_rewind docs currently assert that the state of the target's  
data directory after rewind is equivalent to the source's data  
directory.  This clarifies the documentation to describe that the base  
state is further back in time and that the target's data directory will  
include the current state from the source of any copied blocks since the  
point of divergence.  
  
This commit also improves the section "How It Works":  
- Describe the update of the pg_control file.  
- Reorganize the list of files and directories ignored during the  
rewind.  
  
Author: James Coleman  
Discussion: https://postgr.es/m/CAAaqYe-sgqCos7MXF4XiY8rUPy3CEmaCY9EvfhX-DhPhPBF5_A@mail.gmail.com  

commit   : d9c501da70b079a7138f8b339339169d5bd24143    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 30 Apr 2020 14:33:13 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 30 Apr 2020 14:33:13 -0700    

Add test coverage for the nbtutils.c routines concerned with IndexScans  
that have native ScalarArrayOpExpr quals.  The ScalarArrayOpExpr  
specialized mark and restore routines, and the "find extreme element"  
routine now have some test coverage.  
  
These functions are probably infrequently exercised by real world  
queries, so having some coverage seems like a good idea.  The mark and  
restore routines were originally added by a bugfix that came several  
weeks after the first stable release of Postgres 9.2 (see commit  
70bc5833195).  

commit   : dd1f645cc8831f55591e466c56b3953b9d100993    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 30 Apr 2020 12:31:56 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 30 Apr 2020 12:31:56 -0700    

XLogRegisterBufData() does not copy data pointed to by caller's pointer  
argument.  
  
Oversight in commit 0d861bbb702.  
  
Author: Peter Eisentraut  
Reported-By: Peter Eisentraut  
Discussion: https://postgr.es/m/21800dbe-a13e-22f7-d423-b81db9d249f5@2ndquadrant.com  

commit   : 30e82f1bc9888d7f84bdcad33f460dd8db752b08    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Apr 2020 12:53:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Apr 2020 12:53:44 -0400    

Minor editorial changes in the first two sections; larger ones  
in the JSON section.  

commit   : eb892102e01a2073df9250d65e33ec1ed21798df    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 30 Apr 2020 09:34:54 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 30 Apr 2020 09:34:54 +0200    

see also a00c53b0cb  

commit   : 7462c1d78cd8bc1cfca352cef0e3e234b9d3b62b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 30 Apr 2020 09:06:49 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 30 Apr 2020 09:06:49 +0200    

commit   : 401aad67045b2d467571b54abe229fdd115a228c    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Apr 2020 13:39:10 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Apr 2020 13:39:10 +0900    

The libpq parameters ssl{max|min}protocolversion are renamed to use  
underscores, to become ssl_{max|min}_protocol_version.  The related  
environment variables still use the names introduced in commit ff8ca5f  
that added the feature.  
  
Per complaint from Peter Eisentraut (this was also mentioned by me in  
the original patch review but the issue got discarded).  
  
Author: Daniel Gustafsson  
Reviewed-by: Peter Eisentraut, Michael Paquier  
Discussion: https://postgr.es/m/b319e449-318d-e691-4997-1327e166fcc4@2ndquadrant.com  

commit   : 4ad047a6eac356436b88681a9383a52cde2ffe9c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Apr 2020 00:34:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Apr 2020 00:34:05 -0400    

Make the markup a bit less ad-hoc.  A function-table cell now contains  
several <para> units, and we label the ones that contain function  
signatures with role="func_signature".  The CSS or FO stylesheets then  
key off of that to decide how to set the indentation.  A very useful  
win from this approach is that we can have more than one signature  
entry per table cell, simplifying the documentation of closely-related  
operators and functions.  
  
This patch mostly just replaces the markup in the tables I converted so  
far.  But I did alter a couple of places where multiple signatures were  
helpful.  
  
Discussion: https://postgr.es/m/5561.1587922854@sss.pgh.pa.us  

commit   : ab2343d4cb806c43e8a7269d38b3bdddea185213    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 29 Apr 2020 18:17:49 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 29 Apr 2020 18:17:49 -0700    

_bt_getbuf() cannot return an invalid buffer.  
  
Oversight in commit 2ed5b87f96d.  

commit   : e30b0b5cfaeb4f1f739f82c34c5ae2773852a088    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Apr 2020 08:14:02 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 30 Apr 2020 08:14:02 +0900    

Commit 79dfa8a has introduced a check to catch when the minimum protocol  
version was set higher than the maximum version, however an error was  
getting generated when both bounds are set even if they are able to  
work, causing a backend to not use a new SSL context but keep the old  
one.  
  
Author: Daniel Gustafsson  
Discussion: https://postgr.es/m/14BFD060-8C9D-43B4-897D-D5D9AA6FC92B@yesql.se  

commit   : 1816a1c6ffe46782eee9a16a974b4aa3f4b8457b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 29 Apr 2020 18:46:42 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 29 Apr 2020 18:46:42 -0400    

Checkpointer uses its MyLatch to wake up when a checkpoint request is  
received.  But before commit c6550776394e the latch was not used for  
anything else, so the code could just go to sleep after each loop  
without rechecking the sleeping condition.  That commit added a separate  
ResetLatch in its code path[1], which can cause a checkpoint to go  
unnoticed for potentially a long time.  
  
Fix by skipping sleep if any checkpoint flags are set.  Also add a test  
to verify this; authored by Kyotaro Horiguchi.  
  
[1] CreateCheckPoint -> InvalidateObsoleteReplicationSlots ->  
ConditionVariableTimeSleep  
  
Report and diagnosis by Kyotaro Horiguchi.  
Co-authored-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20200408.141956.891237856186513376.horikyota.ntt@gmail.com  

commit   : fef819ac534d6efb9608fa0bbb93c6fe6c87440e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 29 Apr 2020 10:13:25 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 29 Apr 2020 10:13:25 +0200    

from 927474ce1a2  

commit   : d0abe78d84274cc203f3d117b8006dc2164ca31a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 Apr 2020 20:39:04 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 28 Apr 2020 20:39:04 -0400    

Lack of these checks could cause visible misbehavior, including  
assertion failures.  This was missed in commit c6550776394e, whereby  
restart_lsn becomes invalid when the size limit is exceeded.  
  
Also reword some existing error messages, and add errdetail(), so that  
the reported errors all match in spirit.  
  
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20200408.093710.447591748588426656.horikyota.ntt@gmail.com  

commit   : 52b164c5a00095a34685e66bf64b009578b9cfda    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 28 Apr 2020 16:12:56 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 28 Apr 2020 16:12:56 -0700    

Make sure that we have test coverage of the posting list tuple path  
within _bt_xid_horizon().  
  
Per off-list complaint from Andres Freund.  

commit   : 6baa17fbd1a76cd4056168fa718b7e7fd65748ec    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 28 Apr 2020 13:35:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 28 Apr 2020 13:35:40 +0200    

Some translatable strings have been moved to scanner_yyerror(), so we  
need to add that, too.  

commit   : ef11051bbe96ea2d06583e4b3b9daaa02657dd42    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 28 Apr 2020 11:07:56 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 28 Apr 2020 11:07:56 +0300    

pg_statio_all_tables view appears to have a wrong grouping.  As the result  
numbers of toast index blocks read and hit were multiplied to the number of  
table indexes.  This commit fixes the view definition.  
  
Backpatching this appears difficult.  We don't have a mechanism to patch a  
system catalog of existing instances in minor upgrade.  We can write a  
release notes instruction to do this manually.  But per discussion this is  
probably not so critical bug for doing such an intrusive fix.  
  
Reported-by: Andrei Zubkov  
Discussion: https://postgr.es/m/CAPpHfdtMYkkNudLMG9G0dxX_B%3Dn5sfKzOyxxrvWYtSicaGW0Lw%40mail.gmail.com  

commit   : ebf6de8692766177a36e7f5fb7545a52a0d5d881    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 Apr 2020 07:55:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 28 Apr 2020 07:55:51 +0900    

This part of the test was included originally in 4e87c48, but got  
reverted as of f9c1b8d because of timing issues in the test, where,  
after more analysis, we found that the standbys may not have recovered  
from the archives all the segments needed by the test.  This stabilizes  
the test by making sure that standbys replay up to the position returned  
by pg_switch_wal(), meaning that all segments are recovered before the  
manual checkpoint that tests WAL segment recycling and its interactions  
with archive status files.  
  
Author: Jehan-Guillaume de Rorthais  
Reviewed-by: Kyotaro Horiguchi, Michael Paquier  
Discussion: https://postgr.es/m/20200424034248.GL33034@paquier.xyz  

commit   : 0278d3f79a30cd9ccd6646b8447b25c60ae7d01d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Apr 2020 13:04:35 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 27 Apr 2020 13:04:35 -0400    

When pg_basebackup -R is used, we inject standby.signal into the  
tar file for the main tablespace. The proper thing to do is to pad  
each file injected into the tar file out to a 512-byte boundary  
by appending nulls, but here the file is of length 0 and we add  
511 zero bytes.  Since 0 is already a multiple of 512, we should  
not add any zero bytes. Do that instead.  
  
Patch by me, reviewed by Tom Lane.  
  
Discussion: http://postgr.es/m/CA+TgmobWbfReO9-XFk8urR1K4wTNwqoHx_v56t7=T8KaiEoKNw@mail.gmail.com  

commit   : e81e5741a6c5d2000b70ea4d5aeceb7669fbccbf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Apr 2020 12:21:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Apr 2020 12:21:04 -0400    

Queries such as '!(foo<->bar)' failed to find matching rows when  
implemented as a GiST or GIN index search.  That's because of  
failing to handle phrase searches as tri-valued when considering  
a query without any position information for the target tsvector.  
We can only say that the phrase operator might match, not that it  
does match; and therefore its NOT also might match.  The previous  
coding incorrectly inverted the approximate phrase result to  
decide that there was certainly no match.  
  
To fix, we need to make TS_phrase_execute return a real ternary result,  
and then bubble that up accurately in TS_execute.  As long as we have  
to do that anyway, we can simplify the baroque things TS_phrase_execute  
was doing internally to manage tri-valued searching with only a bool  
as explicit result.  
  
For now, I left the externally-visible result of TS_execute as a plain  
bool.  There do not appear to be any outside callers that need to  
distinguish a three-way result, given that they passed in a flag  
saying what to do in the absence of position data.  This might need  
to change someday, but we wouldn't want to back-patch such a change.  
  
Although tsginidx.c has its own TS_execute_ternary implementation for  
use at upper index levels, that sadly managed to get this case wrong  
as well :-(.  Fixing it is a lot easier fortunately.  
  
Per bug #16388 from Charles Offenbacher.  Back-patch to 9.6 where  
phrase search was introduced.  
  
Discussion: https://postgr.es/m/16388-98cffba38d0b7e6e@postgresql.org  

commit   : 5ac24755485a5c1cc1cef084f08706246ee4f66c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Apr 2020 11:00:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 27 Apr 2020 11:00:28 -0400    

We need to select symbol font explicitly, or it comes out misaligned.  
  
Alexander Lakhin, Tom Lane  
  
Discussion: https://postgr.es/m/10598.1587928415@sss.pgh.pa.us  

commit   : d51f704fd8cbae03cd9b29fe103dd027d521ff04    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 27 Apr 2020 14:24:20 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 27 Apr 2020 14:24:20 +0200    

commit   : 641b76d9d12fd728f71f61e8a2b2bb2bedab021b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Apr 2020 14:59:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 27 Apr 2020 14:59:36 +0900    

Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200408165653.GF2228@telsasoft.com  

commit   : 459f4076c87ac953aa0efa7ddf84df08f8fafe7c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Apr 2020 11:45:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 26 Apr 2020 11:45:54 -0400    

It wasn't totally clear about punctuation other than what's  
specified being ignored.  
  
Pavel Borisov and Tom Lane  
  
Discussion: https://postgr.es/m/CALT9ZEFsBdsogVjG40Z4KfM1Um=wj1FE9hJ00GK3oVfzz0sFNg@mail.gmail.com  

commit   : f057980149ddccd4b862d2c6b3920ed498b0d7ec    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 26 Apr 2020 13:48:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 26 Apr 2020 13:48:33 +0200    

from 303640199d0  

commit   : 896135512ef67cc084f5e058cfa9b4954ca26861    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Apr 2020 18:45:27 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Apr 2020 18:45:27 -0700    

Buildfarm member chipmunk has failed twice due to taking >30s, and  
twenty-four runs of other members have used >5s.  The test is new in  
v13, so no back-patch.  

commit   : 7154aa16a64dd4afc2cbf02e7ce86dc6711a1087    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 25 Apr 2020 16:45:20 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 25 Apr 2020 16:45:20 -0700    

Avoid accessing the leaf page's top parent tuple without a buffer lock  
held during the second phase of nbtree page deletion.  The old approach  
was safe, though only because VACUUM never drops its buffer pin (and  
because only VACUUM itself can modify a half-dead page).  Even still, it  
seems like a good idea to be strict here.  Tighten things up by copying  
the top parent page's block number to a local variable before releasing  
the buffer lock on the leaf page -- not after.  
  
This is a follow-up to commit fa7ff642, which fixed a similar issue in  
the first phase of nbtree page deletion.  
  
Update some related comments in passing.  
  
Discussion: https://postgr.es/m/CAH2-WzkLgyN3zBvRZ1pkNJThC=xi_0gpWRUb_45eexLH1+k2_Q@mail.gmail.com  

commit   : fa7ff642c22ceccad869af5add00c2661d4d091e    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 25 Apr 2020 14:17:02 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 25 Apr 2020 14:17:02 -0700    

Avoid accessing the deletion target page's special area during nbtree  
page deletion at a point where there is no buffer lock held.  This issue  
was detected by a patch that extends Valgrind's memcheck tool to mark  
nbtree pages that are unsafe to access (due to not having a buffer lock  
or buffer pin) as NOACCESS.  
  
We do hold a buffer pin at this point, and only access the special area,  
so the old approach was safe.  Even still, it seems like a good idea to  
tighten up the rules in this area.  There is no reason to not simply  
insist on always holding a buffer lock (not just a pin) when accessing  
nbtree pages.  
  
Update some related comments in passing.  
  
Discussion: https://postgr.es/m/CAH2-WzkLgyN3zBvRZ1pkNJThC=xi_0gpWRUb_45eexLH1+k2_Q@mail.gmail.com  

commit   : f246ea3b2a5e0b75e44f0f18157c4b5e10b5547f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Apr 2020 10:18:12 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Apr 2020 10:18:12 -0700    

Before sleeping, WalSndWaitForWal() sends a keepalive if MyWalSnd->write  
< sentPtr.  When the latest physical LSN yields no logical replication  
messages (a common case), that keepalive elicits a reply.  Processing  
the reply updates pg_stat_replication.replay_lsn.  WalSndLoop() lacks  
that; when WalSndLoop() slept, replay_lsn advancement could stall until  
wal_receiver_status_interval elapsed.  This sometimes stalled  
src/test/subscription/t/001_rep_changes.pl for up to 10s.  
  
Reviewed by Fujii Masao and Michael Paquier.  
  
Discussion: https://postgr.es/m/20200418070142.GA1075445@rfd.leadboat.com  

commit   : 72a3dc321d76c93842d502793f93b9dc2d2305b2    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Apr 2020 10:17:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 25 Apr 2020 10:17:26 -0700    

This reverts commit 421685812290406daea58b78dfab0346eb683bbb.  It caused  
idle physical walsenders to busy-wait, as reported by Fujii Masao.  
  
Discussion: https://postgr.es/m/20200417054146.GA1061007@rfd.leadboat.com  

commit   : d9a4cce29d563e4e6f6eec8b807736d98b1ad553    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sat, 25 Apr 2020 05:09:30 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sat, 25 Apr 2020 05:09:30 +0100    

CreateRole() was passing a Value node, not a RoleSpec node, for the  
newly-created role name when adding the role as a member of existing  
roles for the IN ROLE syntax.  
  
This mistake went unnoticed because the node in question is used only  
for error messages and is not accessed on non-error paths.  
  
In older pg versions (such as 9.5 where this was found), this results  
in an "unexpected node type" error in place of the real error. That  
node type check was removed at some point, after which the code would  
accidentally fail to fail on 64-bit platforms (on which accessing the  
Value node as if it were a RoleSpec would be mostly harmless) or give  
an "unexpected role type" error on 32-bit platforms.  
  
Fix the code to pass the correct node type, and add an lfirst_node  
assertion just in case.  
  
Per report on irc from user m1chelangelo.  
  
Backpatch all the way, because this error has been around for a long  
time.  

commit   : 6c5f9161682697418156b6391038318d130fe6e4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Apr 2020 17:53:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Apr 2020 17:53:23 -0400    

Thanks to Juan José Santamaría Flecha.  
  
Discussion: https://postgr.es/m/5752.1587740484@sss.pgh.pa.us  

commit   : bd8c5cee961af86e65b873e9debba13cfcb3cb89    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Apr 2020 17:21:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Apr 2020 17:21:44 -0400    

Sticking this comment at the end of the last line was a bad idea: it's  
not particularly readable, and it tempts pgindent to mess with line  
breaks within the comment, which in turn reveals that win32tzlist.pl's  
clean_displayname() does the wrong thing to clean up such line breaks.  
While that's not hard to fix, there's basically no excuse for this  
arrangement to begin with, especially since it makes the table layout  
needlessly vary across back branches with different pgindent rules.  
Let's just put the comment inside the braces, instead.  
  
This commit just moves and reformats the comments, and updates  
win32tzlist.pl to match; there's no actual data change.  
  
Per odd-looking results from Juan José Santamaría Flecha.  
Back-patch, since the point is to make win32_tzmap[] look the  
same in all supported branches again.  
  
Discussion: https://postgr.es/m/5752.1587740484@sss.pgh.pa.us  

commit   : f8d3e2ab27d22c1f032b0541fd7650e02e8907f7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Apr 2020 15:51:35 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Apr 2020 15:51:35 -0400    

This includes the usual amount of editorial cleanup, such as  
correcting wrong or less-helpful-than-they-could-be examples.  
  
I moved the two tsvector-updating triggers into "9.28 Trigger  
Functions", which seems like a better home for them.  (I believe  
that section didn't exist when this text was originally written.)  

commit   : 395a9a124877d3c41328fcfebcf0c68df86d9bfd    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 24 Apr 2020 15:16:04 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 24 Apr 2020 15:16:04 -0400    

e.g., REL_12_STABLE  

commit   : 05021a2c0cd212dbe9d7883e2d1677ba739653d5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Apr 2020 14:08:29 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 24 Apr 2020 14:08:29 -0400    

Per report from Andres Freund, who also says that this fix  
works for him.  
  
Discussion: http://postgr.es/m/20200405193118.alprgmozhxcfabkw@alap3.anarazel.de  

commit   : baf17ad9dff4552b7e494d3f574972c21d9f90bc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Apr 2020 12:02:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Apr 2020 12:02:36 -0400    

Commit 32ff26911 introduced use of rank() into the triggers view to  
calculate the spec-mandated action_order column.  As written, this  
prevents query constraints on the table-name column from being pushed  
below the window aggregate step.  That's bad for performance of this  
typical usage pattern, since the view now has to be evaluated for all  
tables not just the one(s) the user wants to see.  It's also the cause  
of some recent buildfarm failures, in which trying to evaluate the view  
rows for triggers in process of being dropped resulted in "cache lookup  
failed for function NNN" errors.  Those rows aren't of interest to the  
test script doing the query, but the filter that would eliminate them  
is being applied too late.  None of this happened before the rank()  
call was there, so it's a regression compared to v10 and before.  
  
We can improve matters by changing the rank() call so that instead of  
partitioning by OIDs, it partitions by nspname and relname, casting  
those to sql_identifier so that they match the respective view output  
columns exactly.  The planner has enough intelligence to know that  
constraints on partitioning columns are safe to push down, so this  
eliminates the performance problem and the regression test failure  
risk.  We could make the other partitioning columns match view outputs  
as well, but it'd be more complicated and the performance benefits  
are questionable.  
  
Side note: as this stands, the planner will push down constraints on  
event_object_table and trigger_schema, but not on event_object_schema,  
because it checks for ressortgroupref matches not expression  
equivalence.  That might be worth improving someday, but it's not  
necessary to fix the immediate concern.  
  
Back-patch to v11 where the rank() call was added.  Ordinarily we'd not  
change information_schema in released branches, but the test failure has  
been seen in v12 and presumably could happen in v11 as well, so we need  
to do this to keep the buildfarm happy.  The change is harmless so far  
as users are concerned.  Some might wish to apply it to existing  
installations if performance of this type of query is of concern,  
but those who don't are no worse off.  
  
I bumped catversion in HEAD as a pro forma matter (there's no  
catalog incompatibility that would really require a re-initdb).  
Obviously that can't be done in the back branches.  
  
Discussion: https://postgr.es/m/5891.1587594470@sss.pgh.pa.us  

commit   : 4cac3a49e691040ddb3f7776ea1f0d63383cbe15    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Apr 2020 10:54:47 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 24 Apr 2020 10:54:47 -0400    

DST law changes in Morocco and the Canadian Yukon.  
Historical corrections for Shanghai.  
  
The America/Godthab zone is renamed to America/Nuuk to reflect  
current English usage; however, the old name remains available as a  
compatibility link.  

commit   : 3a8961577677dd4e910ed239047ad6c02cb2591b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 24 Apr 2020 09:33:22 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 24 Apr 2020 09:33:22 +0200    

commit   : f9c1b8dba4da4c17bc6b7c76dec476de6725660b    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 24 Apr 2020 11:33:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 24 Apr 2020 11:33:41 +0900    

The test is proving to have timing issues when looking at archive status  
files on standbys after crash recovery, while other parts of the test  
rely on pg_stat_archiver as a wait point to make sure that a given state  
of the archiving is reached.  The coverage is not heavily impacted by  
the removal those extra tests.  
  
Per reports from several buildfarm animals, like crake, piculet,  
culicidae and francolin.  
  
Discussion: https://postgr.es/m/20200424005929.GK33034@paquier.xyz  
Backpatch-through: 9.5  

commit   : 4e87c4836ab9059cdec17b0a288db3622a42ac18    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 24 Apr 2020 08:48:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 24 Apr 2020 08:48:28 +0900    

78ea8b5 has fixed an issue related to the recycling of WAL segments on  
standbys depending on archive_mode.  However, it has introduced a  
regression with the handling of WAL segments ready to be archived during  
crash recovery, causing those files to be recycled without getting  
archived.  
  
This commit fixes the regression by tracking in shared memory if a live  
cluster is either in crash recovery or archive recovery as the handling  
of WAL segments ready to be archived is different in both cases (those  
WAL segments should not be removed during crash recovery), and by using  
this new shared memory state to decide if a segment can be recycled or  
not.  Previously, it was not possible to know if a cluster was in crash  
recovery or archive recovery as the shared state was able to track only  
if recovery was happening or not, leading to the problem.  
  
A set of TAP tests is added to close the gap here, making sure that WAL  
segments ready to be archived are correctly handled when a cluster is in  
archive or crash recovery with archive_mode set to "on" or "always", for  
both standby and primary.  
  
Reported-by: Benoît Lobréau  
Author: Jehan-Guillaume de Rorthais  
Reviewed-by: Kyotaro Horiguchi, Fujii Masao, Michael Paquier  
Discussion: https://postgr.es/m/20200331172229.40ee00dc@firost  
Backpatch-through: 9.5  

commit   : 3436c5e28374d4e0587634fda09faf4a38a9d848    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Apr 2020 15:38:04 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Apr 2020 15:38:04 -0400    

In the footsteps of aaf069aa3, remove ACLDEBUG, which was the only  
other remaining undocumented symbol in pg_config_manual.h.  The fact  
that nobody had bothered to document it in seventeen years is a good  
clue to its usefulness.  In practice, none of the tracing logic it  
enabled would be of any value without additional effort.  
  
Discussion: https://postgr.es/m/6631.1587565046@sss.pgh.pa.us  

commit   : ee88ef55dbacfca15ad425e849280669e3d6ee4d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Apr 2020 15:27:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Apr 2020 15:27:37 -0400    

Nobody really uses this stuff, especially not since we created  
valgrind-based infrastructure that does the same thing better.  
It is thus unsurprising that the generation.c and slab.c versions  
were actually broken.  Rather than fix 'em, let's just remove 'em.  
  
Alexander Lakhin  
  
Discussion: https://postgr.es/m/8936216c-3492-3f6e-634b-d638fddc5f91@gmail.com  

commit   : 5b0aa112a8f74e93d28c2dc002cfdaea5c40eeda    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Apr 2020 15:12:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 23 Apr 2020 15:12:42 -0400    

Also rearrange that page a bit for more consistency and less  
duplication.  
  
In passing, fix erroneous examples of the results of abbrev(cidr)  
in datatype.sgml, and do a bit of copy-editing there.  

commit   : ab7646ff92c799303b9ee70ce88b89e07dae717c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 23 Apr 2020 09:47:50 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 23 Apr 2020 09:47:50 -0400    

The previous commit renamed the struct's typedef, but not the struct  
name itself.  

commit   : 3989dbdf1293ecc16991065a3d84857a945ea853    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 23 Apr 2020 08:44:06 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 23 Apr 2020 08:44:06 -0400    

Function names declared "extern" now use BackupManifest in the name  
rather than just Manifest, and data types use backup_manifest  
rather than just manifest.  
  
Per note from Michael Paquier.  
  
Discussion: http://postgr.es/m/20200418125713.GG350229@paquier.xyz  

commit   : 299298bc873374ed49fa2f39944c09ac62bd75e3    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Wed, 22 Apr 2020 19:52:07 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Wed, 22 Apr 2020 19:52:07 -0700    

In a9c35cf85ca I changed ExecMakeTableFunctionResult() to dynamically  
allocate the FunctionCallInfo used to call the SRF. Unfortunately I  
did not account for the fact that the surrounding memory context has  
query lifetime, leading to a leak till the end of the query.  
  
In most cases the leak is fairly inconsequential, but if the  
FunctionScan is done many times in the query, the leak can add  
up. This happens e.g. if the function scan is on the inner side of a  
nested loop, due to a lateral join.  
EXPLAIN SELECT sum(f) FROM generate_series(1, 100000000) g(i), generate_series(i, i+1) f;  
quickly shows the leak.  
  
Instead of explicitly freeing the FunctionCallInfo it seems better to  
make sure all the per-set temporary state in  
ExecMakeTableFunctionResult() is cleaned up wholesale. Currently  
that's probably just the FunctionCallInfo allocation, but since  
there's some initialization work, and since there's already an  
appropriate context, this seems like a more robust approach.  
  
Bug: #16112  
Reported-By: Ben Cornett  
Author: Andres Freund  
Reviewed-By: Tom Lane  
Discussion: https://postgr.es/m/16112-4448bbf55a404189%40postgresql.org  
Backpatch: 12, a9c35cf85ca  

commit   : 0a89e93bfaa6f2b0a37c19c92943207e3f600098    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 Apr 2020 11:32:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 Apr 2020 11:32:17 +0900    

This commit does:  
  
- get rid of the garbage code for unused --print-parse-wal option.  
- add help message for --quiet option into usage().  
- fix typo of option name in help message.  
  
Author: Fujii Masao  
Reviewed-by: Robert Haas  
Discussion: https://postgr.es/m/ff4710f7-2331-4f6b-012e-d76da3275e91@oss.nttdata.com  

commit   : 1cc34640cabcb32b4f062673cce1d6b1819d492d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Apr 2020 21:32:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Apr 2020 21:32:38 -0400    

David Johnston reminded me that the per-point calculations being done  
by these operators are equivalent to complex multiplication/division.  
(Once I would've recognized that immediately, but it's been too long  
since I did any of that sort of math.)  
  
Also put in a footnote mentioning that "rotation" of a box doesn't do  
what you might expect, as I'd griped about in the referenced thread.  
  
Discussion: https://postgr.es/m/158110996889.1089.4224139874633222837@wrigleys.postgresql.org  

commit   : 48107e396f75ea65192153707a8c476f66b59061    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 22 Apr 2020 16:09:55 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 22 Apr 2020 16:09:55 -0700    

The mask was added by commit 8224de4f, which introduced INCLUDE nbtree  
indexes.  The status bits really were reserved initially.  We now use 2  
out of 4 of the bits for additional tuple metadata, though.  Rename the  
mask to BT_STATUS_OFFSET_MASK.  
  
Also consolidate related nbtree.h code comments about the format of  
pivot tuples and posting list tuples.  

commit   : de0dc1a84710f127fdd40f87e783797cc2d69a77    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 23 Apr 2020 00:15:24 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 23 Apr 2020 00:15:24 +0200    

When estimating the number of pre-sorted groups in cost_incremental_sort  
we must not pass Vars with varno 0 to estimate_num_groups, which would  
cause failues in find_base_rel. This may happen when sorting output of  
set operations, thanks to generate_append_tlist.  
  
Unlike recurse_set_operations we can't easily access the original target  
list, so if we find any Vars with varno 0, we fall back to the default  
estimate DEFAULT_NUM_DISTINCT.  
  
Reported-by: Justin Pryzby  
Discussion: https://postgr.es/m/20200411214639.GK2228%40telsasoft.com  

commit   : 92c12e46d5f1e25fc85608a6d6a19b8f5ea02600    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 Apr 2020 16:23:19 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 22 Apr 2020 16:23:19 -0400    

See https://mapscaping.com/blogs/geo-candy/what-is-the-difference-between-elevation-relief-and-altitude  
No patching of regression tests.  
  
Reported-by: taf1@cornell.edu  
  
Discussion: https://postgr.es/m/158506544539.679.2278386310645558048@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 748507c780a39c8e31276bf29dd18d7b32a91b34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Apr 2020 15:27:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Apr 2020 15:27:43 -0400    

Make header/trailer comments agree with the actual names of some macros.  
These seem like legit names in earlier iterations of respective patches  
(commit b779168ff "Detect PG_PRINTF_ATTRIBUTE automatically." and  
commit 6869b4f25 "Add C++ support to configure.") but the macro had  
been renamed out of sync with the header / trailer comment in the final  
committed patch.  
  
Even more nitpickily, make the dashed underlines agree with the lengths  
of the macro names everyplace.  There doesn't seem to have been any  
meeting of the minds previously on whether those should match or not,  
but at least some people have been trying to make 'em match.  
  
Jesse Zhang, Tom Lane  
  
Discussion: https://postgr.es/m/CAGf+fX7DDyq6WfCy6X_KtD28MkbNBE6NkRi26fSf25dfUwX0zw@mail.gmail.com  

commit   : 791090bd775b6a2b488ae2078c8479fcd3324a2c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Apr 2020 14:43:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 22 Apr 2020 14:43:26 -0400    

This also makes an attempt to flesh out the docs for some of the more  
severely underdocumented geometric operators and functions.  
  
This effort exposed that the point <^ point (point_below) and  
point >^ point (point_above) operators are misnamed; they should be  
<<| and |>>, because they act like the other operators named that  
way and not like the other operators named <^ and >^.  But I just  
documented them that way; fixing it is matter for another patch.  
  
The haphazard datatype coverage of many of the operators is also  
now depressingly obvious.  
  
Discussion: https://postgr.es/m/158110996889.1089.4224139874633222837@wrigleys.postgresql.org  

commit   : 9f2c4edec2e2182a2fef8495efdaf90a65d64e6c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 22 Apr 2020 22:12:19 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 22 Apr 2020 22:12:19 +1200    

This Assert was trying to ensure that the number of columns in the foreign  
key being cloned was the same number of attributes in the parentRel.  Of  
course, it's perfectly valid to have columns in the table which are not  
part of the foreign key constraint. It appears that this Assert was  
misunderstanding that.  
  
Reported-by: Rajkumar Raghuwanshi  
Reviewed-by: amul sul  
Discussion: https://postgr.es/m/CAKcux6=z1dtiWw5BOpqDx-U6KTiq+zD0Y2m810zUtWL+giVXWA@mail.gmail.com  

commit   : aaf069aa345231823464f65b33c479a0958fe147    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 21 Apr 2020 19:57:33 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 21 Apr 2020 19:57:33 +0200    

This has been broken since PostgreSQL 12 and was probably never really  
used.  PostgreSQL 12 added an analogous HEAPAMSLOTDEBUGALL, which  
still works right now, but it's also not very useful, so remove that  
as well.  
  
Discussion: https://www.postgresql.org/message-id/flat/645c0646-4218-d4c3-409a-a7003a0c108d%402ndquadrant.com  

commit   : cd123234404ef9a45415060633d3be31329820b2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Apr 2020 08:08:28 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Apr 2020 08:08:28 +0900    

readOneRecord() is used now when looking for a checkpoint record to  
check if the target server is an ancestor of the source across multiple  
timelines, and using a restore_command if available improves the  
stability of the operation.  This part was missed in a7e8ece.  
  
Reported-by: Kyotaro Horiguchi  
Discussion: https://postgr.es/m/20200421.150830.1410714948345179794.horikyota.ntt@gmail.com  

commit   : c33869cc3bfc42bce822251f2fa1a2a346f86cc5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Apr 2020 18:37:26 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Apr 2020 18:37:26 -0400    

It's important to know that a trigger is cloned from a parent table,  
because of the behavior that the trigger is dropped on detach.  Make  
psql's \d display it.  
  
We'd like to backpatch, but lack of the pg_trigger.tgparentid column  
makes it more difficult.  Punt for now.  If somebody wants to volunteer  
an implementation that reads pg_depend on older versions, that can  
probably be backpatched.  
  
Authors: Justin Pryzby, Amit Langote, Álvaro Herrera  
Discussion: https://postgr.es/m/20200419002206.GM26953@telsasoft.com  

commit   : 27dbe1a18423f2f80c10d191844a0ba4dea650ff    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Apr 2020 07:27:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 22 Apr 2020 07:27:03 +0900    

Checking if Subject Alternative Names (SANs) from a certificate match  
with the hostname connected to leaked memory after each lookup done.  
  
This is broken since acd08d7 that added support for SANs in SSL  
certificates, so backpatch down to 9.5.  
  
Author: Roman Peshkurov  
Reviewed-by: Hamid Akhtar, Michael Paquier, David Steele  
Discussion: https://postgr.es/m/CALLDf-pZ-E3mjxd5=bnHsDu9zHEOnpgPgdnO84E2RuwMCjjyPw@mail.gmail.com  
Backpatch-through: 9.5  

commit   : 8803506c411e457adc2531c6ecb69e002e8a83c6    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Apr 2020 17:14:18 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Apr 2020 17:14:18 -0400    

Add a couple of lines to make it explicit that indexes, constraints,  
triggers are added, removed, or left alone.  
  
Backpatch to pg11.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/20200421162038.GA18628@alvherre.pgsql  

commit   : d12bdba77b0fce9df818bc84ad8b1d8e7a96614b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Apr 2020 15:58:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Apr 2020 15:58:42 -0400    

index.c supposed that it could just use a PG_TRY block to clean up the  
state associated with an active REINDEX operation.  However, that code  
doesn't run if we do a FATAL exit --- for example, due to a SIGTERM  
shutdown signal --- while the REINDEX is happening.  And that state does  
get consulted during catalog accesses, which makes it problematic if we  
do any catalog accesses during shutdown --- for example, to clean up any  
temp tables created in the session.  
  
If this combination of circumstances occurred, we could find ourselves  
trying to access already-freed memory.  In debug builds that'd fairly  
reliably cause an assertion failure.  In production we might often  
get away with it, but with some bad luck it could cause a core dump.  
  
Another possible bad outcome is an erroneous conclusion that an  
index-to-be-accessed is being reindexed; but it looks like that would  
be unlikely to have any consequences worse than failing to drop temp  
tables right away.  (They'd still get dropped by the next session that  
uses that temp schema.)  
  
To fix, get rid of the use of PG_TRY here, and instead hook into  
the transaction abort mechanisms to clean up reindex state.  
  
Per bug #16378 from Alexander Lakhin.  This has been wrong for a  
very long time, so back-patch to all supported branches.  
  
Discussion: https://postgr.es/m/16378-7a70ca41b3ec2009@postgresql.org  

commit   : 5836d326552cd0bada1b63281892a8515f07af0f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Apr 2020 14:23:42 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Apr 2020 14:23:42 -0400    

Working on commit 1c455078b led me to check through FunctionCallInvoke  
call sites to see if every one was being honest about (a) making sure  
that fcinfo.isnull is initially false, and (b) checking its state after  
the call.  Sure enough, I found some violations.  
  
The main one is that finalize_partialaggregate re-used serialfn_fcinfo  
without resetting isnull, even though it clearly intends to cater for  
serialfns that return NULL.  There would only be an issue with a  
non-strict serialfn, since it's unlikely that a serialfn would return  
NULL for non-null input.  We have no non-strict serialfns in core, and  
there may be none in the wild either, which would account for the lack  
of complaints.  Still, it's clearly wrong, so back-patch that fix to  
9.6 where finalize_partialaggregate was introduced.  
  
Also, arrayfuncs.c and rowtypes.c contained various callers that were  
not bothering to check for result nulls.  While what's being called is  
a comparison or hash function that probably *shouldn't* return null,  
that's a lousy excuse for not having any check at all.  There are  
existing places that just Assert(!fcinfo->isnull) in comparable  
situations, so I added that to the places that were calling btree  
comparison or hash support functions.  In the places calling  
boolean-returning equality functions, it's quite cheap to have them  
treat isnull as FALSE, so make those places do that.  Also remove some  
"locfcinfo->isnull = false" assignments that are unnecessary given the  
assumption that no previous call returned null.  These changes seem like  
mostly neatnik-ism or debugging support, so I didn't back-patch.  

commit   : afccd76f1ccef73a341e9b0c6efb29a429f35aa4    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Apr 2020 13:57:00 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 21 Apr 2020 13:57:00 -0400    

When a partition is detached, any triggers that had been cloned from its  
parent were not properly disentangled from its parent triggers.  
This resulted in triggers that could not be dropped because they  
depended on the trigger in the trigger in the no-longer-parent table:  
  ALTER TABLE t DETACH PARTITION t1;  
  DROP TRIGGER trig ON t1;  
    ERROR:  cannot drop trigger trig on table t1 because trigger trig on table t requires it  
    HINT:  You can drop trigger trig on table t instead.  
  
Moreover the table can no longer be re-attached to its parent, because  
the trigger name is already taken:  
  ALTER TABLE t ATTACH PARTITION t1 FOR VALUES FROM (1)TO(2);  
    ERROR:  trigger "trig" for relation "t1" already exists  
  
The former is a bug introduced in commit 86f575948c77.  (The latter is  
not necessarily a bug, but it makes the bug more uncomfortable.)  
  
To avoid the complexity that would be needed to tell whether the trigger  
has a local definition that has to be merged with the one coming from  
the parent table, establish the behavior that the trigger is removed  
when the table is detached.  
  
Backpatch to pg11.  
  
Author: Justin Pryzby <pryzby@telsasoft.com>  
Reviewed-by: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://www.postgresql.org/message-id/flat/20200408152412.GZ2228@telsasoft.com  

commit   : 1542e16f2ca257656717ab8ea263bc310f1b6d51    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 21 Apr 2020 09:59:24 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 21 Apr 2020 09:59:24 -0700    

Commit 0d861bbb, which introduced deduplication to nbtree, added some  
logic to take large posting list tuples into account when choosing a  
split point.  We subtract firstright posting list overhead from the  
projected new high key size when calculating leftfree/rightfree values  
for an affected candidate split point.  Posting list tuples aren't  
special to nbtsplitloc.c, but taking them into account like this makes a  
huge difference in practice.  Posting list tuples are frequently tuple  
size outliers.  
  
However, commit 0d861bbb missed a closely related issue: split interval  
itself is calculated based on the assumption that tuples on the page  
being split are roughly equisized.  That assumption was acceptable back  
when commit fab25024 taught the logic for choosing a split point about  
suffix truncation, but it's pretty questionable now that very large  
tuple sizes are common.  This oversight led to unbalanced page splits in  
low cardinality multi-column indexes when deduplication was used: page  
splits that don't give sufficient weight to how unbalanced the split is  
when the interval happens to include some large posting list tuples (and  
when most other tuples on the page are not so large).  
  
Nail this down by calculating an initial split interval in a way that's  
attuned to the actual cost that we want to keep under control (not a  
fuzzy proxy for the cost): apply a leftfree + rightfree evenness test to  
each candidate split point that actually gets included in the split  
interval (for the default strategy).  This replaces logic that used a  
percentage of all legal split points for the page as the basis of the  
initial split interval.  
  
Discussion: https://postgr.es/m/CAH2-WznJt5aT2uUB2Bs+JBLdwe0XTX67+xeLFcaNvCKxO=QBVQ@mail.gmail.com  

commit   : 1c455078b0950cb6bad83198d818a55f02649fd4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Apr 2020 12:56:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Apr 2020 12:56:55 -0400    

Although selfuncs.c will never call a target operator with null inputs,  
some functions might return null anyway.  The existing coding will fail  
if that happens (since FunctionCall2Coll will punt), which seems  
undesirable given that matchingsel() has such a broad range of potential  
applicability --- in fact, we already have a problem because we apply it  
to jsonb_path_exists_opr, which can return null.  Hence, rejigger the  
underlying functions mcv_selectivity and histogram_selectivity to cope,  
treating a null result as false.  
  
While we are at it, we can move the InitFunctionCallInfoData overhead  
out of the inner loops, which isn't a huge number of cycles but might  
save something considering we are likely calling functions as cheap  
as int4eq().  Plus, the number of loop cycles to be expected is much  
more than it was when this code was written, since typical settings  
of default_statistics_target are higher.  
  
In view of that consideration, let's apply the same change to  
var_eq_const, eqjoinsel_inner, and eqjoinsel_semi.  We do not expect  
equality functions to ever return null for non-null inputs (and  
certainly that code has been that way a long time without complaints),  
but the cycle savings seem attractive, especially in the eqjoinsel loops  
where there's potentially an O(N^2) savings.  
  
Similar code exists in ineq_histogram_selectivity and  
get_variable_range, but I forebore from changing those for now.  
The performance argument for changing ineq_histogram_selectivity  
is really weak anyway, since that will only iterate log2(N) times.  
  
Nikita Glukhov and Tom Lane  
  
Discussion: https://postgr.es/m/9d3b0959-95d6-c37e-2c0b-287bcfe5c705@postgrespro.ru  

commit   : 9d25e1aa311c0f0c77155382e6608545b7bf579c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Apr 2020 11:21:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Apr 2020 11:21:15 -0400    

"operator" is a reserved word in C++, so per project conventions,  
don't use it as an identifier in header files.  
  
My oversight in commit a80818605.  

commit   : 2117c3cb3d51e73290f464ad725fe829c96b9213    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Apr 2020 11:13:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Apr 2020 11:13:05 -0400    

Older gcc versions don't like duplicate typedefs, so get rid of  
that in favor of doing it like we do it elsewhere, ie just use  
a "struct" declaration when trying to avoid importing a whole  
header file.  
  
Also, there seems no reason to include stringinfo.h here at all,  
so get rid of that addition too.  
  
Discussion: https://postgr.es/m/27239.1587415696@sss.pgh.pa.us  

commit   : 67f82e966b524fc0eb44024976c5178612a77fc8    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 21 Apr 2020 14:05:43 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 21 Apr 2020 14:05:43 +0900    

Previously in the "Standby Server Operation" section, pg_ctl promote and  
protmote_trigger_file were documented as a method to trigger standby  
promotion, but pg_promote() function not.  
  
This commit also adds parentheses into <function>pg_promote</function>  
in some docs to make it clearer that a function is being referred to.  
  
Author: Masahiro Ikeda  
Reviewed-by: Michael Paquier, Laurenz Albe, Tom Lane, Fujii Masao  
Discussion: https://postgr.es/m/de0068417a9f4046bac693cbcc00bdc9@oss.nttdata.com  

commit   : f192312dc07601c5abb2e04126b434c70f7c8e50    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 20 Apr 2020 21:41:13 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 20 Apr 2020 21:41:13 -0400    

Reported-by: Jürgen Purtz  
  
Discussion: https://postgr.es/m/709d7809-d7f4-8175-47f3-4d131341bba8@purtz.de  
  
Author: Jürgen Purtz  
  
Backpatch-through: 9.5  

commit   : 1ec42696bed5709e4ff885c109d1e48d92b2b331    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Apr 2020 18:44:12 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Apr 2020 18:44:12 -0400    

Also some mop-up in section 9.9.  

commit   : 079ac29d4dafe581748ceca523aa90c8ce8b035b    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 20 Apr 2020 14:37:38 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 20 Apr 2020 14:37:38 -0400    

basebackup.c is already a pretty big and complicated file, so it  
makes more sense to keep the backup manifest support routines  
in a separate file, for clarity and ease of maintenance.  
  
Discussion: http://postgr.es/m/CA+TgmoavRak5OdP76P8eJExDYhPEKWjMb0sxW7dF01dWFgE=uA@mail.gmail.com  

commit   : 1e324cb0e7613dc035a403c4201c7dc004e7dedb    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Apr 2020 13:42:41 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Apr 2020 13:42:41 -0400    

... as added in the prior commit.  
  
(We'd like to have tab-completion for the other object types too, but  
they don't have sub-command completion yet.)  
  
Author: Ibrar Ahmed <ibrar.ahmad@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/CALtqXTcogrFEVP9uou5vFtnGsn+vHZUu9+9a0inarfYVOHScYQ@mail.gmail.com  

commit   : 5fc703946bf3b18642ce83b937671d254a8ac5b5    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Apr 2020 13:42:12 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 20 Apr 2020 13:42:12 -0400    

Commit f2fcad27d59c (9.6 era) added the ability to mark objects as  
dependent an extension, but forgot to add a way for such dependencies to  
be removed.  This commit fixes that oversight.  
  
Strictly speaking this should be backpatched to 9.6, but due to lack of  
demand we're not doing so at this time.  
  
Discussion: https://postgr.es/m/20200217225333.GA30974@alvherre.pgsql  
Reviewed-by: ahsan hadi <ahsan.hadi@gmail.com>  
Reviewed-by: Ibrar Ahmed <ibrar.ahmad@gmail.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  

commit   : 4157f73b4ba7fa0c6fb117cb9b5a771875850c83    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Apr 2020 12:29:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 20 Apr 2020 12:29:28 -0400    

Along the way, update the older examples for bytea to use "hex"  
output format.  That lets us get rid of the lame disclaimer about  
how the examples assume bytea_output = escape, which was only half  
true anyway because none of the more-recently-added examples had  
paid any attention to that.  

commit   : 7e4e574744c13aac613909a59bf38ef5aae5bd8c    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Mon, 20 Apr 2020 12:53:40 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Mon, 20 Apr 2020 12:53:40 +0200    

The views pg_stat_progress_* had not gotten the memo that  
pg_read_all_stats is supposed to be able to read all statistics. Also  
make a pass over all text-returning pg_stat_xyz functions that could  
return "insufficient privilege" and make sure they also respect  
pg_read_all_status.  
  
Reported-by: Andrey M. Borodin  
Reviewed-by: Andrey M. Borodin, Kyotaro Horiguchi  
Discussion: https://postgr.es/m/13145F2F-8458-4977-9D2D-7B2E862E5722@yandex-team.ru  

commit   : 9aece5cd05f1b21b67eac0dc4f105853eec3e4eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Apr 2020 17:44:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Apr 2020 17:44:28 -0400    

Notably, this replaces the previous handwaving about these functions'  
behavior with "character"-type inputs with some actual facts.  

commit   : 0cacb2b79d8fa1aeec34cd956544f0c96e7915ed    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 19 Apr 2020 10:32:26 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Sun, 19 Apr 2020 10:32:26 -0700    

commit   : 81e83216d5b6826167d5116bd084b7b3a364b0b3    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Apr 2020 12:17:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 19 Apr 2020 12:17:02 -0400    

I took the opportunity to do some copy-editing in this area as well,  
and to add some new material such as a note about BETWEEN's syntactical  
peculiarities.  
  
Of note is that quite a few of the examples of transcendental functions  
needed to be updated, because the displayed output no longer matched  
what you get on a modern server.  I believe some of these cases are  
side-effects of the new Ryu algorithm in float8out.  Others appear to be  
because the examples predate the addition of type numeric, and were  
expecting that float8 calculations would be done although the given  
syntax would actually lead to calling the numeric function nowadays.  

commit   : 73afabcdc20e227beb8094efb44753b4de1c5c0a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 19 Apr 2020 14:59:29 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 19 Apr 2020 14:59:29 +0200    

The normalization-check target needs to be run last, after moving the  
newly generated files into place.  Also, we need an additional  
dependency so that unicode_norm.o is rebuilt first.  Otherwise,  
norm_test will still test the old files but against the new expected  
results, which will probably fail.  

commit   : 00f4aba46d537452da41e6d398f8f4c915de586d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Apr 2020 15:36:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Apr 2020 15:36:43 -0400    

Jonathan Katz felt that slightly different indentation settings made  
for a better-looking result, so sync stylesheet-fo.xsl (for PDF) and  
stylesheet.css (for non-website-style HTML) with those choices.  
  
Discussion: https://postgr.es/m/31464.1587156281@sss.pgh.pa.us  

commit   : f332241a60aa9c0945d74642cb3dbcbc11621154    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Apr 2020 14:02:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 18 Apr 2020 14:02:44 -0400    

We have repeatedly seen the buildfarm reach the Assert(false) in  
SyncRepGetSyncStandbysPriority.  This apparently is due to failing to  
consider the possibility that the sync_standby_priority values in  
shared memory might be inconsistent; but they will be whenever only  
some of the walsenders have updated their values after a change in  
the synchronous_standby_names setting.  That function is vastly too  
complex for what it does, anyway, so rewriting it seems better than  
trying to apply a band-aid fix.  
  
Furthermore, the API of SyncRepGetSyncStandbys is broken by design:  
it returns a list of WalSnd array indexes, but there is nothing  
guaranteeing that the contents of the WalSnd array remain stable.  
Thus, if some walsender exits and then a new walsender process  
takes over that WalSnd array slot, a caller might make use of  
WAL position data that it should not, potentially leading to  
incorrect decisions about whether to release transactions that  
are waiting for synchronous commit.  
  
To fix, replace SyncRepGetSyncStandbys with a new function  
SyncRepGetCandidateStandbys that copies all the required data  
from shared memory while holding the relevant mutexes.  If the  
associated walsender process then exits, this data is still safe to  
make release decisions with, since we know that that much WAL *was*  
sent to a valid standby server.  This incidentally means that we no  
longer need to treat sync_standby_priority as protected by the  
SyncRepLock rather than the per-walsender mutex.  
  
SyncRepGetSyncStandbys is no longer used by the core code, so remove  
it entirely in HEAD.  However, it seems possible that external code is  
relying on that function, so do not remove it from the back branches.  
Instead, just remove the known-incorrect Assert.  When the bug occurs,  
the function will return a too-short list, which callers should treat  
as meaning there are not enough sync standbys, which seems like a  
reasonably safe fallback until the inconsistent state is resolved.  
Moreover it's bug-compatible with what has been happening in non-assert  
builds.  We cannot do anything about the walsender-replacement race  
condition without an API/ABI break.  
  
The bogus assertion exists back to 9.6, but 9.6 is sufficiently  
different from the later branches that the patch doesn't apply at all.  
I chose to just remove the bogus assertion in 9.6, feeling that the  
probability of a bad outcome from the walsender-replacement race  
condition is too low to justify rewriting the whole patch for 9.6.  
  
Discussion: https://postgr.es/m/21519.1585272409@sss.pgh.pa.us  

commit   : 3cb02e307e350caf3c9099c6f661a95fd00e7e4c    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 18 Apr 2020 14:10:37 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 18 Apr 2020 14:10:37 +1200    

In some corner cases, this could also lead to corrupted values being  
included in the tuple.  
  
Users who are concerned that they are affected by this should first  
upgrade and then perform a base backup of their database and restore onto  
an off-line server. They should then query each table with generated  
columns to ensure there are no rows where the generated expression does  
not match a newly calculated version of the GENERATED ALWAYS expression.  
If no crashes occur and no rows are returned then you're not affected.  
  
Fixes bug #16369.  
  
Reported-by: Cameron Ezell  
Discussion: https://postgr.es/m/16369-5845a6f1bef59884@postgresql.org  
Backpatch-through: 12 (where GENERATED ALWAYS columns were added.)  

commit   : 737d69ffc3cfb2e093975411c1becd65ad029478    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Apr 2020 20:50:26 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Apr 2020 20:50:26 -0400    

The table layout ideas proposed in commit e894c6183 were not as widely  
popular as I'd hoped.  After discussion, we've settled on a layout  
that's effectively a single-column table with cell contents much like a  
<varlistentry> description of the function or operator; though we're not  
actually using <varlistentry>, because it'd add way too much vertical  
space.  Instead the effect is accomplished using line-break processing  
instructions to separate the description and example(s), plus CSS or FO  
customizations to produce indentation of all but the first line in each  
cell.  While technically this is a bit grotty, it does have the  
advantage that we won't need to write nearly as much boilerplate markup.  
  
This patch updates tables 9.30, 9.31, and 9.33 (which were touched by  
the previous patch) to the revised style, and additionally converts  
table 9.10.  A lot of work still remains to do, but hopefully it won't  
be too controversial.  
  
Thanks to Andrew Dunstan, Pierre Giraud, Robert Haas, Alvaro Herrera,  
David Johnston, Jonathan Katz, Isaac Morland for valuable ideas.  
  
Discussion: https://postgr.es/m/8691.1586798003@sss.pgh.pa.us  

commit   : 6741cfa5964768279a13e01e46931664fe0903a4    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Apr 2020 16:53:01 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Apr 2020 16:53:01 -0400    

This reverts commit 9e24109f1a4e4d8d1d372b004d6a0dd06e673fe7.  
  
This caused build errors when building without openssl, and it's  
simplest just to revert it.  

commit   : f342d7ad03e61a1cea0339cf0c5aea0d01c3b43e    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Apr 2020 15:57:19 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Apr 2020 15:57:19 -0400    

This should have been protected by #ifdef USE_OPENSSL in commit  
896fcdb230.  
  
Per the real complaint this time from Daniel Gustafsson.  

commit   : a9659fb65497af8d2db66101f2ff7233d02997f1    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Apr 2020 14:44:33 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Apr 2020 14:44:33 -0400    

Apparently in some language versions of Visual Studio nmake outputs some  
material after the version number and before the end of the line. This  
has been seen in Chinese versions. Therefore, we no longer demand that  
the version string comes at the end of a line.  
  
Per complaint from Cuiping Lin.  
  
Backpatch to all live branches.  

commit   : 9e24109f1a4e4d8d1d372b004d6a0dd06e673fe7    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Apr 2020 14:11:18 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 17 Apr 2020 14:11:18 -0400    

In commit 4dc6355210 I neglected to put #ifdef USE_OPENSSL around the  
declarations of the new items. This is remedied here.  
  
Per complaint from Daniel Gustafsson.  

commit   : 3125a5baec1cf6d3aaeb8964bc3b3c49835e0452    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Apr 2020 13:41:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 17 Apr 2020 13:41:59 -0400    

recordExtObjInitPriv and removeExtObjInitPriv were sloppy about  
calling ReleaseSysCache.  The cases cannot occur given current usage  
in ALTER EXTENSION ADD/DROP, since we wouldn't get here for these  
relkinds; but it seems wise to clean up better.  
  
In passing, extend test logic in test_pg_dump to exercise the  
dropped-column code paths here.  
  
Since the case is unreachable at present, there seems no great  
need to back-patch; hence fix HEAD only.  
  
Kyotaro Horiguchi, with test case and comment adjustments by me  
  
Discussion: https://postgr.es/m/20200417.151831.1153577605111650154.horikyota.ntt@gmail.com  

commit   : 4db819ba403901d38c4e4328883412c59061bb58    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 17 Apr 2020 18:37:38 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 17 Apr 2020 18:37:38 +0900    

Author: Fujii Masao  
Reviewed-by: Robert Haas  
Discussion: https://postgr.es/m/951743d0-fd7e-8e2b-d489-1368a58b7304@oss.nttdata.com  

commit   : 198efe774b0d2065d828cf7822376a2871c671fc    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Apr 2020 10:45:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 17 Apr 2020 10:45:08 +0900    

The result of the query used to retrieve the WAL segment size from the  
backend was not getting freed in two code paths.  Both pg_basebackup and  
pg_receivewal exit immediately if a failure happened on this query, so  
this was not an actual problem, but it could be an issue if this code  
gets used for other tools in different ways, be they future tools in  
this code tree or external, existing, ones.  
  
Oversight in commit fc49e24, so backpatch down to 11.  
  
Author: Jie Zhang  
Discussion: https://postgr.es/m/970ad9508461469b9450b64027842331@G08CNEXMBPEKD06.g08.fujitsu.local  
Backpatch-through: 11  

commit   : 5b736e9cf95793ca6a4c00d291a06dfe3559c8ec    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Fri, 17 Apr 2020 10:29:49 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Fri, 17 Apr 2020 10:29:49 +1200    

It was previously thought that remove_useless_groupby_columns() needed to  
keep track of which constraints the generated plan depended upon, however,  
this is unnecessary. The confusion likely arose regarding this because of  
check_functional_grouping(), which does need to track the dependency to  
ensure VIEWs with columns which are functionally dependant on the GROUP BY  
remain so. For remove_useless_groupby_columns(), cached plans will just  
become invalidated when the primary key's underlying index is removed  
through the normal relcache invalidation code.  
  
Here we just remove the unneeded code which records the dependency and  
updates the comments. The previous comments claimed that we could not use  
UNIQUE constraints for the same optimization due to lack of a  
pg_constraint record for NOT NULL constraints (which are required because  
NULLs can be duplicated in a unique index). Since we don't actually need a  
pg_constraint record to handle the invalidation, it looks like we could  
add code to do this in the future. But not today.  
  
We're not really fixing any bug in the code here, this fix is just to set  
the record straight on UNIQUE constraints. This code was added back in  
9.6, but due to lack of any bug, we'll not be backpatching this.  
  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/CAApHDvrdYa=VhOoMe4ZZjZ-G4ALnD-xuAeUNCRTL+PYMVN8OnQ@mail.gmail.com  

commit   : fc576b7c4f3a5f045d443fc771d9e0f54b33e72b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Apr 2020 14:45:54 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 16 Apr 2020 14:45:54 -0400    

fixup_whole_row_references() did the wrong thing with a dropped column,  
resulting in a commit-time warning about a cache reference leak.  
  
I (tgl) added a test case exercising this, but back-patched the test  
only as far as v10; the patch didn't apply cleanly to 9.6 and it  
didn't seem worth the trouble to adapt it.  The bug is pretty old  
though, so apply the code change all the way back.  
  
Michael Luo, with cosmetic improvements by me  
  
Discussion: https://postgr.es/m/BYAPR08MB5606D1453D7F50E2AF4D2FD29AD80@BYAPR08MB5606.namprd08.prod.outlook.com  

commit   : 24d2d38b1eb86c0b410ad0f07f66566a83c6f05c    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 16 Apr 2020 10:44:03 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 16 Apr 2020 10:44:03 +0530    

Earlier we were inconsistent in allowing the usage of parallel and  
full options.  Change it such that we disallow them only when they are  
combined in a way that we don't support.  
  
In passing, improve the comments in some of the existing tests of parallel  
vacuum.  
  
Reported-by: Tushar Ahuja  
Author: Justin Pryzby, Amit Kapila  
Reviewed-by: Sawada Masahiko, Michael Paquier, Mahendra Singh Thalor and  
Amit Kapila  
Discussion: https://postgr.es/m/58c8d171-e665-6fa3-a9d3-d9423b694dae%40enterprisedb.com  

commit   : 542d7817f774ea9d94798eb95cdf250d4f1527d9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 16 Apr 2020 13:57:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 16 Apr 2020 13:57:07 +0900    

Since 0d8c9c1, pg_basebackup would generate an error if connected to a  
backend version older than 12 where backup manifests are not supported.  
Avoiding this error is possible by using the --no-manifest option.  
  
This error handling could be confusing for some users, where patching a  
backup script that interacts with multiple backend versions would cause  
the addition of --no-manifest to potentially not generate a backup  
manifest even for Postgres 13 and newer versions.  As we want to  
encourage the use of backup manifests as much as possible, this commit  
silently disables manifests where not supported, instead of generating  
an error.  
  
While on it, rework a bit the code to make it more consistent with the  
surroundings when generating the BASE_BACKUP command.  
  
Per discussion with Andres Freund, Stephen Frost, Robert Haas, Álvaro  
Herrera, Kyotaro Horiguchi, Tom Lane, David Steele, and me.  
  
Author: Michael Paquier  
Discussion: https://postgr.es/m/20200410080910.GZ1606@paquier.xyz  

commit   : f0ca378d4c139eda99ef14998115c1674dac3fc5    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 15 Apr 2020 15:47:26 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Wed, 15 Apr 2020 15:47:26 -0700    

Spotted during post-commit review of the nbtree deduplication commit  
(commit 0d861bbb).  

commit   : 8f4ee44bcdbcd437f860f2d048125a118335b088    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Apr 2020 15:56:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 15 Apr 2020 15:56:01 +0900    

A query used to read default ACL information from the catalogs did not  
free a set of PQExpBuffer.  
  
Oversight in commit e2090d9, so backpatch down to 9.6.  
  
Author: Jie Zhang  
Reviewed-by: Sawada Masahiko  
Discussion: https://postgr.es/m/05bcbc5857f948efa0b451b85a48ae10@G08CNEXMBPEKD06.g08.fujitsu.local  
Backpatch-through: 9.6  

commit   : a2ac73e7be7adf2a9248d14322d3a5e055ea4fd0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 15 Apr 2020 11:15:12 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 15 Apr 2020 11:15:12 +0900    

This commit prevents pg_basebackup from receiving backup_manifest file  
when --no-manifest is specified. Previously, when pg_basebackup was  
writing a tarfile to stdout, it tried to receive backup_manifest file even  
when --no-manifest was specified, and reported an error.  
  
Also remove unused -m option from pg_basebackup.  
  
Also fix typo in BASE_BACKUP command documentation.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier, Robert Haas  
Discussion: https://postgr.es/m/01e3ed3a-8729-5aaa-ca84-e60e3ca59db8@oss.nttdata.com  

commit   : 4a05a6409567719829ec84d7689b41c55009d75f    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 14 Apr 2020 14:38:28 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 14 Apr 2020 14:38:28 -0700    

A comment from the Berkeley days incorrectly claimed that the page  
management code cares about the contents of the hole in the center of  
the page (at least in the case of the left half of an nbtree page  
split).  Commit 8fa30f906be added an addendum that stated that the  
original comment was "probably obsolete".  It's definitely obsolete,  
though, so remove the original comment plus the addendum.  

commit   : 2d59643dbccaf73bc1f90875ea02dcad641379cd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Apr 2020 17:30:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Apr 2020 17:30:13 -0400    

Commit 913bbd88d overlooked that the result of coerce_to_target_type  
might need collation fixups.  Per report from Andreas Joseph Krogh.  
  
Discussion: https://postgr.es/m/VisenaEmail.72.37d08ec2b8cb8fb5.17179940cd3@tc7-visena  

commit   : 0516f94d18c57cc5dce72ff8fb84a05d24a67063    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 14 Apr 2020 16:55:34 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 14 Apr 2020 16:55:34 -0400    

The consensus of the project appears to be that this provides little  
benefit and is simply an annoyance.  
  
Discussion: https://postgr.es/m/27481.1586618092@sss.pgh.pa.us  

commit   : e60c6f6ea17b50833242653fe2781f6d47429540    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 14 Apr 2020 16:47:07 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Tue, 14 Apr 2020 16:47:07 -0400    

Back in commits 1df92eeafe, f884a96819, and 592123efbb I used some  
hackish code to set the script search path, unaware despite decades of  
perl that there was a completely standard way to do this. This patch  
changes those cases to use the standard perl FindBin package.  

commit   : 149f2ae88ab0510be3239caf45699d7373f2c6e8    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Apr 2020 13:41:32 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 14 Apr 2020 13:41:32 -0400    

Patch by me, at the request of Andres Freund. Reviewed by  
Justin Pryzby, Erik Rijkers, Álvaro Herrera, and Andrew  
Dunstan.  
  
Discussion: http://postgr.es/m/20200327203225.hcm6ag4grwsiruea@alap3.anarazel.de  

commit   : 80634e3b181562015762b5846583ff67f8037a80    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 14 Apr 2020 09:33:18 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 14 Apr 2020 09:33:18 -0700    

Nest the "update metapage as part of insert into root-like page" branch  
inside the broader "insert into internal page" branch.  This improves  
readability.  

commit   : 8128b0c152a67917535f50738ac26da4f984ddd9    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Apr 2020 14:45:43 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 14 Apr 2020 14:45:43 +0900    

This fixes some comments and documentation new as of Postgres 13, and is  
a follow-up of the work done in dd0f37e.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200408165653.GF2228@telsasoft.com  

commit   : f762b2feba276a627585cb7e834fb7a1bf4c549d    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 13 Apr 2020 21:11:03 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 13 Apr 2020 21:11:03 -0700    

Clearly it's not okay for nbtree to split a page that is the only page  
on its level, and then find that it has to split the parent one level up  
in turn.  There is simply no code to handle the split_only_page case in  
the _bt_insertonpg() "newitem won't fit" branch (only the "newitem fits"  
branch handles split_only_page).  Add a defensive assertion that will  
fail if a split_only_page call to _bt_insertonpg() somehow ends up  
splitting the target/parent page.  
  
I (pgeoghegan) believe that we don't need split_only_page handling for  
the "newitem won't fit" branch because anybody calling _bt_insertonpg()  
like this would have to hold a lock on the same one and only child page.  

commit   : a6fea120a7e3858e642bb5e96027f166a1a6f134    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 14 Apr 2020 08:10:27 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 14 Apr 2020 08:10:27 +0530    

Reported-by: Justin Pryzby  
Author: Justin Pryzby, with few changes by me  
Reviewed-by: Amit Kapila and Sawada Masahiko  
Discussion: https://postgr.es/m/20200322021801.GB2563@telsasoft.com  

commit   : 826ee1a019127d611bb0fd22ca878142bfb077ac    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 13 Apr 2020 19:26:41 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 13 Apr 2020 19:26:41 -0700    

It seems like a good idea for nbtree's retail insert code to be  
absolutely consistent with nbtree's page split code for anything that  
naturally requires equivalent handling.  Anything that concerns  
inserting newitem (which is handled as part of the page split atomic  
action when a page split is required) should work in exactly the same  
way.  With that in mind, make _bt_insertonpg() handle 'cbuf' in a way  
that matches _bt_split().  

commit   : d60cfb6bf2b4812e97271e7b5ba3ad4713406b9d    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 13 Apr 2020 18:47:28 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 13 Apr 2020 18:47:28 -0700    

Per buildfarm member hoverfly, a slow walsender could make the test  
fail.  Back-patch to v10, where the test was introduced.  
  
Discussion: https://postgr.es/m/20200414013849.GA886648@rfd.leadboat.com  

commit   : e56d717d8a23c48e4ab27b6bd6815c50dc3a378a    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 13 Apr 2020 19:54:09 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 13 Apr 2020 19:54:09 -0400    

Now that warnings are enabled across the board, this code that tries to  
print an undef variable emits one.  Silently printing the empty string  
achieves the previous behavior.  
  
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>  
Discussion: https://postgr.es/m/E1jO1VT-0008Qk-TM@gemulon.postgresql.org  

commit   : bc3087b626d1073c9b7c9687b334785909ca2237    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 13 Apr 2020 16:39:55 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 13 Apr 2020 16:39:55 -0700    

An nbtree split point can be thought of as a point between two adjoining  
tuples from an imaginary version of the page being split that includes  
the incoming/new item (in addition to the items that really are on the  
page).  These adjoining tuples are called the lastleft and firstright  
tuples.  
  
The variables that represent split points contained a field called  
firstright, which is an offset number of the first data item from the  
original page that goes on the new right page.  The corresponding tuple  
from origpage was usually the same thing as the actual firstright tuple,  
but not always: the firstright tuple is sometimes the new/incoming item  
instead.  This situation seems unnecessarily confusing.  
  
Make things clearer by renaming the origpage offset returned by  
_bt_findsplitloc() to "firstrightoff".  We now have a firstright tuple  
and a firstrightoff offset number which are comparable to the  
newitem/lastleft tuples and the newitemoff/lastleftoff offset numbers  
respectively.  Also make sure that we are consistent about how we  
describe nbtree page split point state.  
  
Push the responsibility for dealing with pg_upgrade'd !heapkeyspace  
indexes down to lower level code, relieving _bt_split() from dealing  
with it directly.  This means that we always have a palloc'd left page  
high key on the leaf level, no matter what.  This enables simplifying  
some of the code (and code comments) within _bt_split().  
  
Finally, restructure the page split code to make it clearer why suffix  
truncation (which only takes place during leaf page splits) is  
completely different to the first data item truncation that takes place  
during internal page splits.  Tuples are marked as having fewer  
attributes stored in both cases, and the firstright tuple is truncated  
in both cases, so it's easy to imagine somebody missing the distinction.  

commit   : 8f00d84afc0dad577b65df5a313e5306cee3d11f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 13 Apr 2020 12:06:11 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 13 Apr 2020 12:06:11 -0400    

This replaces a few occurrences of ugly code with a more clean and  
idiomatic usage. The problem was highlighted by perlcritic, but we're  
not enforcing the policy that led to the discovery.  
  
Discussion: https://postgr.es/m/20200412074245.GB623763@rfd.leadboat.com  

commit   : 7be5d8df1f74b78620167d3abf32ee607e728919    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 13 Apr 2020 11:55:45 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 13 Apr 2020 11:55:45 -0400    

We've had a mixture of the warnings pragma, the -w switch on the shebang  
line, and no warnings at all. This patch removes the -w swicth and add  
the warnings pragma to all perl sources missing it. It raises the  
severity of the TestingAndDebugging::RequireUseWarnings  perlcritic  
policy to level 5, so that we catch any future violations.  
  
Discussion: https://postgr.es/m/20200412074245.GB623763@rfd.leadboat.com  

commit   : 8930e43ecd3f683c457865131d7a932401a2188f    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 13 Apr 2020 11:46:18 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 13 Apr 2020 11:46:18 -0400    

This makes it easier to do a web search for details of the policy that's  
been violated, as well as displaying the name that might be needed for a  
policy override.  
  
Various perlcritic settings changes are being discussed, but this one  
should be uncontroversial.  

commit   : 7a6b017b34783eb7ee4e93f93a52bde2bb017c8c    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 13 Apr 2020 10:48:23 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 13 Apr 2020 10:48:23 -0400    

The previous commit missed an instance.  
  
Noriyoshi Shinoda  
  
Discussion: http://postgr.es/m/TU4PR8401MB115291AE850BA7CF1AEB2F0BEEDD0@TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM  

commit   : ef08ca113fe302b9ddf298964756eadcd41e77a1    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Apr 2020 15:31:16 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 13 Apr 2020 15:31:16 +0530    

Reported-by: Justin Pryzby and Euler Taveira  
Author: Justin Pryzby and Julien Rouhaud  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/CAB-hujrP8ZfUkvL5OYETipQwA=e3n7oqHFU=4ZLxWS_Cza3kQQ@mail.gmail.com  

commit   : 0c620a5803afbb667da7ac4bcc91b245a214a80c    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Apr 2020 10:21:15 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 13 Apr 2020 10:21:15 +0200    

Move the file name to a format parameter to ease translatability.  Add  
error code where missing.  Make the wording consistent.  

commit   : e894c61836e4b967f7ec65358fdaed2ba86ed238    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Apr 2020 18:03:20 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Apr 2020 18:03:20 -0400    

We've long fought with the draconian space limitations of our  
traditional table layout for describing SQL functions and operators.  
This commit introduces a new approach, though so far I've only applied  
it to a few of those tables.  The new way makes use of DocBook's support  
for different layouts in different rows of a table, and allows the  
descriptions and examples for a function or operator to run to several  
lines without as much ugliness and wasted space as before.  
  
The core layout concept is now  
  
     Name              Signature  
                      Description  
                 Example     Example Result  
  
so that a function or operator really has three table rows not one,  
but we group them to look like one row by having the name column  
have only one entry for all three rows.  (Actually, there could be  
four or more rows if you wanted to have more than one example, which  
is another thing that was painful before but works easily now.)  
This is handled by a "morerows" annotation on the name entry, which  
isn't perfect (notably, the toolchain is not smart enough to avoid  
breaking these row groups across PDF pages) but there seems no better  
solution in DocBook.  The name column is normally fairly narrow,  
allowing plenty of space for the other column(s), and not wasting too  
much space when one of the other components runs to multiple lines.  
  
The varying row layout is managed by defining named "spans" and then  
tagging entries with a "spanname" of "name", "sig", "desc", "example",  
or "exresult".  This provides a bit of semantic annotation to go with  
the formatting improvement, which seems like a good thing.  (It seems  
that we have to re-define these spans afresh for each table, which is  
annoying, but it's not any worse than the duplication involved in  
the table headers.  At least that gives us an opportunity to vary the  
relative column widths per-table, which is handy since function tables  
sometimes need much wider name columns than operator tables.)  
  
Signature entries should be written in the style  
    <function>fname</function>(<type>typename</type> ...)  
    <returnvalue>typename</returnvalue>  
The <returnvalue> tag produces a right arrow before the result type  
name.  (I'll document that convention in a user-visible place later.)  
  
While this provides significantly more horizontal space than before  
for examples, it's still true that PDF output is a lot narrower than  
typical webpage viewing windows, so some examples need to be broken  
in places where there is no whitespace.  I've added &zwsp; markers in  
suitable places to allow the tables to render warning-free in PDF.  
  
I've so far converted only the date/time operator, date/time function,  
and enum function tables in sections 9.9 and 9.10; these were chosen  
to provide a reasonable sample of the formatting problems that need  
to be solved.  Assuming that this looks good on the website and doesn't  
provoke howls of anguish, I'll work on the other similar tables in the  
near future.  
  
There's a moderate amount of new editorial content in this patch along  
with the raw formatting changes; for instance I had to write text  
descriptions for operators that lacked them.  I failed to resist the  
temptation to improve some other descriptions and examples, too.  
  
Patch by me, with thanks to Alexander Lakhin for assistance with  
figuring out some formatting issues.  
  
Discussion: https://postgr.es/m/9326.1581457869@sss.pgh.pa.us  

commit   : 88d934f0387a66ba372643913f99e845d0ea144a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Apr 2020 14:03:24 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 12 Apr 2020 14:03:24 -0400    

We already had a couple of places using zero-width spaces for formatting  
hackery, and we're going to need more if we ever want the PDF manuals to  
look decent.  But please let's not write hard-coded Unicode escapes.  
We can avoid that by using a custom entity, which also provides a place  
to put a teeny bit of documentation about what it is and how to use it.  
  
I'd previously posted a patch using "&break;" for this, but on reflection  
that would be horrible to grep for.  Instead let's use "&zwsp;", based  
on the name of the Unicode symbol ("zero width space").  
  
Discussion: https://postgr.es/m/9326.1581457869@sss.pgh.pa.us  

commit   : dbc60c5593f26dc777a3be032bff4fb4eab1ddd1    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Sun, 12 Apr 2020 11:26:05 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Sun, 12 Apr 2020 11:26:05 -0400    

Also, use "verify" rather than "validate" to refer to the process  
being undertaken here. Per discussion, that is a more appropriate  
term.  
  
Discussion: https://www.postgresql.org/message-id/172c9d9b-1d0a-1b94-1456-376b1e017322@2ndquadrant.com  
Discussion: http://postgr.es/m/CA+TgmobLgMh6p8FmLbj_rv9Uhd7tPrLnAyLgGd2SoSj=qD-bVg@mail.gmail.com  

commit   : 26640c40715c7f2045cf1b7c6753cac40b64d1e8    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 11 Apr 2020 21:07:20 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 11 Apr 2020 21:07:20 -0700    

Fixes an oversight in commit 20fbb711.  

commit   : 35cb574aa84723f4661e9fc51340130e64cb5dfc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Apr 2020 15:02:38 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Apr 2020 15:02:38 -0400    

The placement of the fall-through comment in this code appears not to  
work to suppress the warning in recent gcc.  Move it to the bottom of  
the case group, and add an assertion that we didn't get there through  
some other code path.  Also improve wording of nearby comments.  
  
Julien Rouhaud, comment hacking by me  
  
Discussion: https://postgr.es/m/CAOBaU_aLdPGU5wCpaowNLF-Q8328iR7mj1yJAhMOVsdLwY+sdg@mail.gmail.com  

commit   : 328c70997bc3518a50bd9a8ff33de349a7223413    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 11 Apr 2020 10:30:12 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 11 Apr 2020 10:30:12 -0700    

Specifically, remember lookup_type_cache() results instead of retrieving  
them once per comparison.  Under CLOBBER_CACHE_ALWAYS, this reduced  
src/test/subscription/t/001_rep_changes.pl elapsed time by an order of  
magnitude, which reduced check-world elapsed time by 9%.  
  
Discussion: https://postgr.es/m/20200406085420.GC162712@rfd.leadboat.com  

commit   : 421685812290406daea58b78dfab0346eb683bbb    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 11 Apr 2020 10:30:00 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 11 Apr 2020 10:30:00 -0700    

Before sleeping, WalSndWaitForWal() sends a keepalive if MyWalSnd->write  
< sentPtr.  That is important in logical replication.  When the latest  
physical LSN yields no logical replication messages (a common case),  
that keepalive elicits a reply, and processing the reply updates  
pg_stat_replication.replay_lsn.  WalSndLoop() lacks that; when  
WalSndLoop() slept, replay_lsn advancement could stall until  
wal_receiver_status_interval elapsed.  This sometimes stalled  
src/test/subscription/t/001_rep_changes.pl for up to 10s.  
  
Discussion: https://postgr.es/m/20200406063649.GA3738151@rfd.leadboat.com  

commit   : 969f9d0b4ba574bb8df65683dbf7a09c030f3e67    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Apr 2020 12:39:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Apr 2020 12:39:19 -0400    

Before discarding the old hash table in ExecReScanHashJoin, capture  
its statistics, ensuring that we report the maximum hashtable size  
across repeated rescans of the hash input relation.  We can repurpose  
the existing code for reporting hashtable size in parallel workers  
to help with this, making the patch pretty small.  This also ensures  
that if rescans happen within parallel workers, we get the correct  
maximums across all instances.  
  
Konstantin Knizhnik and Tom Lane, per diagnosis by Thomas Munro  
of a trouble report from Alvaro Herrera.  
  
Discussion: https://postgr.es/m/20200323165059.GA24950@alvherre.pgsql  

commit   : 5c27bce7f39ded1f027475221b732bbbc31a2bfe    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Apr 2020 12:29:06 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Apr 2020 12:29:06 -0400    

ExecReScanHashJoin will destroy the join's hash table if it expects  
that the inner relation will produce different rows on rescan.  
Up to now it's not bothered to clear the additional pointer to that  
hash table that exists in the child HashState node.  However, it's  
possible for the query to terminate without building a fresh hash  
table (this happens if the outer relation is found to be empty  
during the final rescan).  So we can end with a dangling pointer  
to a deleted hash table.  That was harmless originally, but since  
9.0 EXPLAIN ANALYZE has used that pointer to print hash table  
statistics.  In debug builds this reproducibly results in garbage  
statistics.  In non-debug builds there's frequently no ill effects,  
but in principle one could get wrong EXPLAIN ANALYZE output, or  
perhaps even a crash if free() has released the hashtable memory  
back to the OS.  
  
To fix, just make sure we clear the additional pointer when destroying  
the hash table.  In problematic cases, EXPLAIN ANALYZE will then print  
no hashtable statistics (reverting to its pre-9.0 behavior).  This isn't  
ideal, but since the problem manifests only in unusual corner cases,  
it's hard to justify taking any risks to do better in the back  
branches.  A follow-on patch will improve matters in HEAD.  
  
Konstantin Knizhnik and Tom Lane, per diagnosis by Thomas Munro  
of a trouble report from Alvaro Herrera.  
  
Discussion: https://postgr.es/m/20200323165059.GA24950@alvherre.pgsql  

commit   : 12fb189bfeaf03faea5b6f15544c1f71e9ef4677    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Apr 2020 15:07:25 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Apr 2020 15:07:25 +0200    

Introduced by 83fd4532a72179c370e318075a10e0e2aa832024.  To fix, the  
tuple descriptors need to be copied into the current memory context.  
  
Discussion: https://www.postgresql.org/message-id/04d78603-edae-9243-9dde-fe3037176a7d@2ndquadrant.com  

commit   : 5a1d0c9925fbda9ec434061dee74b1b5d9a16038    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Apr 2020 09:44:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 11 Apr 2020 09:44:14 +0200    

Introduced by 83fd4532a72179c370e318075a10e0e2aa832024  

commit   : 8a47b775a16fb4f1e154c0f319a030498e123164    
  
author   : Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sat, 11 Apr 2020 08:04:57 +0100    
  
committer: Andrew Gierth <rhodiumtoad@postgresql.org>    
date     : Sat, 11 Apr 2020 08:04:57 +0100    

Commit ac8623760 "fixed" a typo in an example of what would happen in  
the event of a typo. Restore the original typo and add a comment about  
its intentionality. Backpatch to 12 where the error was introduced.  
  
Per report from irc user Nicolás Alvarez.  

commit   : 20fbb711ef43ef70093378ff5efdf1b6e8cc10d8    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Apr 2020 17:44:08 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 10 Apr 2020 17:44:08 -0700    

Add a DEBUG1 message indicating that verification of the index structure  
is underway.  Also reduce the severity level of the existing "tree  
level" debug message to DEBUG1.  It should never have been made DEBUG2.  
Any B-Tree index with more than a couple of levels will generally also  
have so many pages that the per-page DEBUG2 messages will become  
completely unmanageable.  
  
In passing, add a new "Tip" to the docs that advises users that run into  
corruption that the debug messages might provide useful additional  
context.  

commit   : f333d35428c1cba8d35065b6dbb2dd46e18bd929    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Apr 2020 13:12:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Apr 2020 13:12:58 -0400    

The docs explained that a SHARE ROW EXCLUSIVE lock is needed on the  
referenced table, but failed to say the same about the table being  
altered.  Since the page says that ACCESS EXCLUSIVE lock is taken  
unless otherwise stated, this left readers with the wrong conclusion.  
  
Discussion: https://postgr.es/m/834603375.3470346.1586482852542@mail.yahoo.com  

commit   : 401418ca6a689f772cbfa1aedc7485cbbcde7a94    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Apr 2020 12:00:28 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Apr 2020 12:00:28 -0400    

Ashutosh Bapat  
  
Discussion: https://postgr.es/m/CAG-ACPWPB8Lc_aFj25eiPFqi31YB5vmaZnb39mbHSf5Yej=miA@mail.gmail.com  

commit   : 7c91e9055d254524d76a72b35a919b8ff9931802    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Apr 2020 10:44:09 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 10 Apr 2020 10:44:09 -0400    

CREATE GROUP is an exact alias for CREATE ROLE, and CREATE USER is  
almost an exact alias, as can easily be confirmed by checking the  
code.  So the man page syntax descriptions ought to match up.  The  
last few additions of role options seem to have forgotten to update  
create_group.sgml, though.  Fix that, and add a naggy reminder to  
create_role.sgml in hopes of not forgetting again.  
  
Discussion: https://postgr.es/m/158647836143.655.9853963229391401576@wrigleys.postgresql.org  

commit   : dd0f37eccecc2db5c0ffafefbf697a2c916e8bc3    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Apr 2020 11:18:39 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 10 Apr 2020 11:18:39 +0900    

This fixes some comments and documentation new as of Postgres 13.  
  
Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200408165653.GF2228@telsasoft.com  

commit   : e083fa34ced0d53807a57482048bb4c135c3d006    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Apr 2020 17:28:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Apr 2020 17:28:58 -0400    

Depending on specific values of restart_lsn or pg_current_wal_lsn()  
is obviously unsafe.  The previous coding tried to dodge this issue  
by rounding off, but that's not good enough, as shown by multiple  
buildfarm members.  Nuke all the uses of these values except for  
null-ness checks, pending some credible argument why we should think  
something else could be usefully stable.  
  
Kyotaro Horiguchi, further modified by me  
  
Discussion: https://postgr.es/m/E1jM1Sa-0003mS-99@gemulon.postgresql.org  

commit   : 2e0e409e3cbab4f4ac01a6f70931817cfd2bdcb1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Apr 2020 15:38:43 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Apr 2020 15:38:43 -0400    

Suppress a probably-meaningless uninitialized-variable warning  
(induced by my previous patch, I'm sorry to say).  
  
Improve mark_hl_fragments()'s test for overlapping cover strings:  
it failed to consider the possibility that the current string is  
strictly within another one.  That's unlikely given the preceding  
splitting into MaxWords fragments, but I don't think it's impossible.  
  
Discussion: https://postgr.es/m/16345-2e0cf5cddbdcd3b4@postgresql.org  

commit   : a4d4f59196ea8745fe4c048085d6d2bd66e8e7d8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Apr 2020 15:11:08 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Apr 2020 15:11:08 -0400    

Now that I've had my nose in that code, I thought the docs about  
it left something to be desired.  

commit   : c9b0c678d30aa3f6bbf996ea15af8acbfcfb2ac8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Apr 2020 13:19:23 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Apr 2020 13:19:23 -0400    

This code could produce very poor results when asked to highlight a  
string based on a query using phrase-match operators.  The root cause  
is that hlCover(), which is supposed to find a minimal substring that  
matches the query, was written assuming that word position is not  
significant.  I'm only 95% convinced that its algorithm was correct even  
for plain AND/OR queries; but it definitely fails completely for phrase  
matches, causing it to possibly not identify a cover string at all.  
  
Hence, rewrite hlCover() with a less-tense algorithm that just tries  
all the possible substrings, earlier and shorter ones first.  (This is  
not as bad as it sounds performance-wise, because all of the string  
matching has been done already: the repeated tsquery match checks  
boil down to pointer comparisons.)  
  
Unfortunately, since that approach produces more candidate cover  
strings than before, it also exposes that there were bugs in the  
heuristics in mark_hl_words() for selecting a best cover string.  
Fixes there include:  
* Do not apply the ShortWord filter to words that appear in the query.  
* Remove a misguided optimization for quickly rejecting a cover.  
* Fix order-of-operation bug that could cause computation of a  
wrong figure of merit (poslen) when shortening a cover.  
* Change the preference rule so that candidate headlines that do not  
include their whole cover string (after MaxWords trimming) are lowest  
priority, since they may not actually satisfy the user's query.  
  
This results in some changes in existing regression test cases,  
but they all seem reasonable.  Note in particular that the tests  
involving strings like "1 2 3" were previously being affected by  
the ShortWord filter, masking the normal matching behavior.  
  
Per bug #16345 from Augustinas Jokubauskas; the new test cases are  
based on that example.  Back-patch to 9.6 where phrase search was  
added to tsquery.  
  
Discussion: https://postgr.es/m/16345-2e0cf5cddbdcd3b4@postgresql.org  

commit   : b10f8bb9fd39da44efd411aec5c643b92bd23676    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Apr 2020 12:36:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 9 Apr 2020 12:36:59 -0400    

This code was woefully unreadable and under-commented.  Try to improve  
matters by adding comments, using some macros to make complicated  
if-tests more readable, using boolean type where appropriate, etc.  
There are a couple of tiny coding improvements too, but this commit  
includes (I hope) no behavioral change.  
  
Nonetheless, back-patch as far as 9.6, because a followup bug-fixing  
commit depends on this.  
  
Discussion: https://postgr.es/m/16345-2e0cf5cddbdcd3b4@postgresql.org  

commit   : e92e4a2b68fe877677278c1300db1780956c984e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Apr 2020 16:17:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 9 Apr 2020 16:17:55 +0200    

CREATE TABLE LIKE INCLUDING GENERATED would fail if a generated column  
referred to a column with a higher attribute number.  This is because  
the column mapping mechanism created the mapping incrementally as  
columns are added.  This was sufficient for previous uses of that  
mechanism (omitting dropped columns), and it also happened to work if  
generated columns only referred to columns with lower attribute  
numbers, but here it failed.  
  
This fix is to build the attribute mapping in a separate loop before  
processing the columns in detail.  
  
Bug: #16342  
Reported-by: Ethan Waldo <ewaldo@healthetechs.com>  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  

commit   : c4f82a779d2676bfca1694a6f9b5499e6cc5f60f    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Apr 2020 22:38:24 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Apr 2020 22:38:24 +0900    

Author: Fujii Masao  
Reviewed-by: Robert Haas  
Discussion: https://postgr.es/m/78f76a3d-1a28-a97d-0394-5c96985dd1c0@oss.nttdata.com  

commit   : 1ec50a81ec0acd452c7520de19e607a6de8fba5e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Apr 2020 22:37:11 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Apr 2020 22:37:11 +0900    

If there is already a backup_manifest file in the database cluster,  
it belongs to the past backup that was used to start this server.  
It is not correct for the backup being taken now. So this commit  
changes pg_basebackup so that it always skips such backup_manifest  
file. The backup_manifest file for the current backup will be injected  
separately if users want it.  
  
Author: Fujii Masao  
Reviewed-by: Robert Haas  
Discussion: https://postgr.es/m/78f76a3d-1a28-a97d-0394-5c96985dd1c0@oss.nttdata.com  

commit   : 5c71362174eb56676f8b91c73ec066dd5513fd4b    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 9 Apr 2020 09:49:30 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 9 Apr 2020 09:49:30 +0530    

Currently, we don't account for buffer usage incurred by parallel workers  
for parallel create index.  This commit allows each worker to record the  
buffer usage stats and leader backend to accumulate that stats at the  
end of the operation.  This will allow pg_stat_statements to display  
correct buffer usage stats for (parallel) create index command.  
  
Reported-by: Julien Rouhaud  
Author: Sawada Masahiko  
Reviewed-by: Dilip Kumar, Julien Rouhaud and Amit Kapila  
Backpatch-through: 11, where this was introduced  
Discussion: https://postgr.es/m/20200328151721.GB12854@nol  

commit   : 58ad961f19f7eca26e6d60eb07adcffeafd0082e    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Apr 2020 12:56:36 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 9 Apr 2020 12:56:36 +0900    

The added note explains that the numbers of planning and execution in  
the statement are not always expected to match because their statistics are  
updated at their respective end phase, and only for successful operations.  
  
Author: Pascal Legrand, Julien Rouhaud, tweaked a bit by Fujii Masao  
Discussion: https://postgr.es/m/1585857868967-0.post@n3.nabble.com  

commit   : c3e4cbaab936a17b579d85c5ff28bcb2251736d0    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 8 Apr 2020 17:50:55 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 8 Apr 2020 17:50:55 -0400    

1. Tell Msys2 not to mangle the tablespace map parameter  
2. If rmdir doesn't work, fall back to trying unlink on the entry in  
   pg_tblspc.  
  
Discussion: https://postgr.es/m/7330a7c7-ce5f-9769-39a1-bdb0b32bb4a6@2ndQuadrant.com  

commit   : f45b8e51b6838ab820df13983c194f737be48778    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Apr 2020 19:19:45 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Apr 2020 19:19:45 +0200    

commit   : cea09246e57821b8a97a6483a7df6c7345b055ef    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 8 Apr 2020 18:30:11 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 8 Apr 2020 18:30:11 +0200    

The test never did ANALYZE on the test table, so the plans depended on  
various defaults (e.g. number of groups being 200). This worked most of  
the time, but with CLOBBER_CACHE_ALWAYS the autoanalyze often managed  
to build accurate stats, changing the  plan.  
  
Fixed by increasing the size of test tables a bit, making the Sort a bit  
more expensive than Incremental Sort. The tests were constructed to test  
transitions in the Incremental Sort algorithm, and this change does not  
break that.  
  
Reviewed-by: James Coleman  
Discussion: https://postgr.es/m/CAPpHfds1waRZ=NOmueYq0sx1ZSCnt+5QJvizT8ndT2=etZEeAQ@mail.gmail.com  

commit   : a9d70c108786712a1023c65e360602edf7bafbf4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Apr 2020 11:23:39 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Apr 2020 11:23:39 -0400    

Repair an oversight in commit 8728b2c70: if we're postponing restore  
of event triggers to the end, we must also postpone restoring any  
comments on them, since of course we cannot create the comments first.  
(This opens yet another opportunity for an event trigger to bollix  
the restore, but there's no help for that.)  
  
Per bug #16346 from Alexander Lakhin.  
  
Like the previous commit, back-patch to all supported branches.  
  
Hamid Akhtar and Tom Lane  
  
Discussion: https://postgr.es/m/16346-6210ad7a0ea81be1@postgresql.org  

commit   : d140f2f3e225ea53e2d92ab6833b8c186c90666c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 8 Apr 2020 23:45:09 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 8 Apr 2020 23:45:09 +1200    

GetWalRcvWriteRecPtr() previously reported the latest *flushed*  
location.  Adopt the conventional terminology used elsewhere in the tree  
by renaming it to GetWalRcvFlushRecPtr(), and likewise for some related  
variables that used the term "received".  
  
Add a new definition of GetWalRcvWriteRecPtr(), which returns the latest  
*written* value.  This will allow later patches to use the value for  
non-data-integrity purposes, without having to wait for the flush  
pointer to advance.  
  
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/CA%2BhUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq%3DAovOddfHpA%40mail.gmail.com  

commit   : 83fd4532a72179c370e318075a10e0e2aa832024    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Apr 2020 09:59:27 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 8 Apr 2020 09:59:27 +0200    

To control whether partition changes are replicated using their own  
identity and schema or an ancestor's, add a new parameter that can be  
set per publication named 'publish_via_partition_root'.  
  
This allows replicating a partitioned table into a different partition  
structure on the subscriber.  
  
Author: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Rafia Sabih <rafia.pghackers@gmail.com>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Reviewed-by: Petr Jelinek <petr@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/CA+HiwqH=Y85vRK3mOdjEkqFK+E=ST=eQiHdpj43L=_eJMOOznQ@mail.gmail.com  

commit   : 1aac32df89eb19949050f6f27c268122833ad036    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 8 Apr 2020 11:37:27 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 8 Apr 2020 11:37:27 +0300    

0f5ca02f53 introduces 3 new keywords.  It appears to be too much for relatively  
small feature.  Given now we past feature freeze, it's already late for  
discussion of the new syntax.  So, revert.  
  
Discussion: https://postgr.es/m/28209.1586294824%40sss.pgh.pa.us  

commit   : 02a2e8b442002a698336954633b0ccc4e30061e6    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 8 Apr 2020 18:29:51 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 8 Apr 2020 18:29:51 +1200    

2nd pass of modifying various places which obtain the next power  
of 2 of a number and make them use the new functions added in  
f0705bb62.  
  
In passing, also modify num_combinations(). This can be implemented  
using simple bitshifting rather than looping.  
  
Reviewed-by: John Naylor  
Discussion: https://postgr.es/m/20200114173553.GE32763%40fetter.org  

commit   : c0187869a0f6eb05135d388462522a593ced1b88    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Apr 2020 15:04:51 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 8 Apr 2020 15:04:51 +0900    

Attempting to use a COLLATE clause with a type that it not collatable in  
a partition bound expression could crash the server.  This commit fixes  
the code by adding more checks similar to what is done when computing  
index or partition attributes by making sure that there is a collation  
iff the type is collatable.  
  
Backpatch down to 12, as 7c079d7 introduced this problem.  
  
Reported-by: Alexander Lakhin  
Author: Dmitry Dolgov  
Discussion: https://postgr.es/m/16325-809194cf742313ab@postgresql.org  
Backpatch-through: 12  

commit   : d025cf88ba5a64487ee4a17ef23e8f55b1536606    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 8 Apr 2020 16:55:03 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 8 Apr 2020 16:55:03 +1200    

First pass of modifying various places that obtain the next power of 2 of  
a number and make them use the new functions added in pg_bitutils.h  
instead.  
  
This also removes the _hash_log2() function. There are no longer any  
callers in core. Other users can swap their _hash_log2(n) call to make use  
of pg_ceil_log2_32(n).  
  
Author: David Fetter, with some minor adjustments by me  
Reviewed-by: John Naylor, Jesse Zhang  
Discussion: https://postgr.es/m/20200114173553.GE32763%40fetter.org  

commit   : 50a38f65177ea7858bc97f71ba0757ba04c1c167    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Apr 2020 20:42:04 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 7 Apr 2020 20:42:04 -0700    

If the memory context's maxBlockSize is too big, a single block  
allocation can suddenly exceed work_mem. For Hash Aggregation, this  
can mean spilling to disk too early or reporting a confusing memory  
usage number for EXPLAN ANALYZE.  
  
Introduce CreateWorkExprContext(), which is like CreateExprContext(),  
except that it creates the AllocSet with a maxBlockSize that is  
reasonable in proportion to work_mem.  
  
Right now, CreateWorkExprContext() is only used by Hash Aggregation,  
but it may be generally useful in the future.  
  
Discussion: https://postgr.es/m/412a3fbf306f84d8d78c4009e11791867e62b87c.camel@j-davis.com  

commit   : f0705bb6286d8a24e08ddd99641264ba947ebd03    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Wed, 8 Apr 2020 16:22:52 +1200    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Wed, 8 Apr 2020 16:22:52 +1200    

There are many areas in the code where we need to determine the next  
highest power of 2 of a given number.  We tend to always do that in an  
ad-hoc way each time, generally with some tight for loop which performs a  
bitshift left once per loop and goes until it finds a number above the  
given number.  
  
Here we add two generic functions which make use of the existing  
pg_leftmost_one_pos* functions which, when available, will allow us to  
calculate the next power of 2 without any looping.  
  
Here we don't add any code which uses these new functions. That will be  
done in follow-up commits.  
  
Author: David Fetter, with some minor adjustments by me  
Reviewed-by: John Naylor, Jesse Zhang  
Discussion: https://postgr.es/m/20200114173553.GE32763%40fetter.org  

commit   : 7a5d74b7dd4b1324e8a8fff4086d51d4f43b1721    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Apr 2020 00:10:16 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Apr 2020 00:10:16 -0400    

In commit 4dbcb3f84 I removed some code from parse_coerce.c, and also  
removed some apparently-no-longer-needed #includes.  But removing  
datum.h broke some not-compiled-by-default code.  
  
Discussion: https://postgr.es/m/20200407205436.pyjhddw5bn5upvsu@development  

commit   : 9e9abed746280086474e2191b8c399b5fd9b0678    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Apr 2020 19:16:37 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Apr 2020 19:16:37 -0400    

Trying to ensure that a slot's restart_lsn or amount of reserved bytes  
exactly match some specific values seems unnecessary, and fragile as  
shown by failures in multiple buildfarm members.  
  
Discussion: https://postgr.es/m/20200407232602.GA21559@alvherre.pgsql  

commit   : 3985b600f57d75b9743d86430cb5c21370057a23    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 8 Apr 2020 13:36:45 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 8 Apr 2020 13:36:45 +1200    

Provide PrefetchSharedBuffer(), a variant that takes SMgrRelation, for  
use in recovery.  Rename LocalPrefetchBuffer() to PrefetchLocalBuffer()  
for consistency.  
  
Add a return value to all of these.  In recovery, tolerate and report  
missing files, so we can handle relations unlinked before crash recovery  
began.  Also report cache hits and misses, so that callers can do faster  
buffer lookups and better I/O accounting.  
  
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>  
Reviewed-by: Andres Freund <andres@anarazel.de>  
Discussion: https://postgr.es/m/CA%2BhUKGJ4VJN8ttxScUFM8dOKX0BrBiboo5uz1cq%3DAovOddfHpA%40mail.gmail.com  

commit   : 981643dcdb70b6ce70d8a08417f71f465f236cb5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Apr 2020 22:12:14 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Apr 2020 22:12:14 -0400    

This case didn't work because columns merged by FULL JOIN USING are  
represented in the parse tree by COALESCE expressions, and the logic  
for recognizing a partitionable join failed to match upper-level join  
clauses to such expressions.  To fix, synthesize suitable COALESCE  
expressions and add them to the nullable_partexprs lists.  This is  
pretty ugly and brute-force, but it gets the job done.  (I have  
ambitions of rethinking the way outer-join output Vars are  
represented, so maybe that will provide a cleaner solution someday.  
For now, do this.)  
  
Amit Langote, reviewed by Justin Pryzby, Richard Guo, and myself  
  
Discussion: https://postgr.es/m/CA+HiwqG2WVUGmLJqtR0tPFhniO=H=9qQ+Z3L_ZC+Y3-EVQHFGg@mail.gmail.com  

commit   : c8434d64ce03c32e0029417a82ae937f2055268f    
  
author   : Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 8 Apr 2020 10:25:00 +0900    
  
committer: Etsuro Fujita <efujita@postgresql.org>    
date     : Wed, 8 Apr 2020 10:25:00 +0900    

Previously, the partitionwise join technique only allowed partitionwise  
join when input partitioned tables had exactly the same partition  
bounds.  This commit extends the technique to some cases when the tables  
have different partition bounds, by using an advanced partition-matching  
algorithm introduced by this commit.  For both the input partitioned  
tables, the algorithm checks whether every partition of one input  
partitioned table only matches one partition of the other input  
partitioned table at most, and vice versa.  In such a case the join  
between the tables can be broken down into joins between the matching  
partitions, so the algorithm produces the pairs of the matching  
partitions, plus the partition bounds for the join relation, to allow  
partitionwise join for computing the join.  Currently, the algorithm  
works for list-partitioned and range-partitioned tables, but not  
hash-partitioned tables.  See comments in partition_bounds_merge().  
  
Ashutosh Bapat and Etsuro Fujita, most of regression tests by Rajkumar  
Raghuwanshi, some of the tests by Mark Dilger and Amul Sul, reviewed by  
Dmitry Dolgov and Amul Sul, with additional review at various points by  
Ashutosh Bapat, Mark Dilger, Robert Haas, Antonin Houska, Amit Langote,  
Justin Pryzby, and Tomas Vondra  
  
Discussion: https://postgr.es/m/CAFjFpRdjQvaUEV5DJX3TW6pU5eq54NCkadtxHX2JiJG_GvbrCA@mail.gmail.com  

commit   : 41a194f49177daf9348bfde2c42e85b806dcee31    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Apr 2020 20:50:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Apr 2020 20:50:02 -0400    

Our documentation describes four allowed input syntaxes for circles,  
but the regression tests tried only three ... with predictable  
consequences.  Remarkably, this has been wrong since the circle  
datatype was added in 1997, but nobody noticed till now.  
  
David Zhang, with some help from me  
  
Discussion: https://postgr.es/m/332c47fa-d951-7574-b5cc-a8f7f7201202@highgo.ca  

commit   : 75848bc74411130ede23995d0ab1aefb12c4c4b0    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 7 Apr 2020 17:36:23 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 7 Apr 2020 17:36:23 -0700    

The goal of separating hotly accessed per-backend data from PGPROC  
into PGXACT is to make accesses fast (GetSnapshotData() in  
particular). But delayChkpt is not actually accessed frequently; only  
when starting a checkpoint. As it is frequently modified (multiple  
times in the course of a single transaction), storing it in the same  
cacheline as hotly accessed data unnecessarily dirties a contended  
cacheline.  
  
Therefore move delayChkpt to PGPROC.  
  
This is part of a larger series of patches intending to improve  
GetSnapshotData() scalability. It is committed and pushed separately,  
as it is independently beneficial (small but measurable win, limited  
by the other frequent modifications of PGXACT).  
  
Author: Andres Freund  
Reviewed-By: Robert Haas, Thomas Munro, David Rowley  
Discussion: https://postgr.es/m/20200301083601.ews6hz5dduc3w2se@alap3.anarazel.de  

commit   : 2b88fdde30d8e9bf833b75a014189e9148233b85    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 8 Apr 2020 02:06:00 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Wed, 8 Apr 2020 02:06:00 +0200    

SLRU page hits were tracked only in SimpleLruReadPage, but that's not  
enough because we may hit the page in SimpleLruReadPage_ReadOnly in  
which case we don't call SimpleLruReadPage at all.  
  
Reported-by: Kuntal Ghosh  
Discussion: https://postgr.es/m/20200119143707.gyinppnigokesjok@development  

commit   : 91c40548d5f7a9241d9fa344fae8069cfdb92bf2    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 6 Apr 2020 21:28:55 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 6 Apr 2020 21:28:55 -0700    

Before the fix every 2PC commit/abort leaked a file descriptor. As the  
files are opened using BasicOpenFile(), that quickly leads to the  
backend running out of file descriptors.  
  
Once enough 2PC abort/commit have caused enough FDs to leak, any IO  
in the backend will fail with "Too many open files", as  
BasicOpenFilePerm() will have triggered all open files known to fd.c  
to be closed.  
  
The leak causing the problem at hand is a consequence of 0dc8ead46,  
but is only exascerbated by it. Previously most XLogPageReadCB  
callbacks used static variables to cache one open file, but after the  
commit the cache is private to each XLogReader instance. There never  
was infrastructure to close FDs at the time of XLogReaderFree, but the  
way XLogReader was used limited the leak to one FD.  
  
This commit just closes the during XLogReaderFree() if the FD is  
stored in XLogReaderState.seg.ws_segno. This may not be the way to  
solve this medium/long term, but at least unbreaks 2PC.  
  
Discussion: https://postgr.es/m/20200406025651.fpzdb5yyb7qyhqko@alap3.anarazel.de  

commit   : 7e2ffb3885007183af7b161e046e126be2cfba12    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Apr 2020 18:58:19 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Apr 2020 18:58:19 -0400    

Food for the gods must always be found somehow, even when the land starves.  

commit   : 60cbd7751c1ec6ffdf2ffc520ddeb35cb2f2ed70    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 7 Apr 2020 15:56:52 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 7 Apr 2020 15:56:52 -0700    

Since heap TID is supposed to be just another key attribute to the  
implementation, it doesn't make much sense to have separate  
BTreeTupleSetNAtts() and BTreeTupleSetAltHeapTID() functions.  Merge the  
two functions together.  This slightly simplifies _bt_truncate().  

commit   : c6550776394e25c1620bc8258427c8f1d448080d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Apr 2020 18:35:00 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Apr 2020 18:35:00 -0400    

Replication slots are useful to retain data that may be needed by a  
replication system.  But experience has shown that allowing them to  
retain excessive data can lead to the primary failing because of running  
out of space.  This new feature allows the user to configure a maximum  
amount of space to be reserved using the new option  
max_slot_wal_keep_size.  Slots that overrun that space are invalidated  
at checkpoint time, enabling the storage to be released.  
  
Author: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>  
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>  
Reviewed-by: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20170228.122736.123383594.horiguchi.kyotaro@lab.ntt.co.jp  

commit   : b63c293bcbd7439f883cd4cf748f6755df0fbb3c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Apr 2020 17:46:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Apr 2020 17:46:29 -0400    

We invented \gx to allow the "\pset expanded" flag to be forced on  
for the duration of one command output, but that turns out to not  
be nearly enough to satisfy the demand for variant output formats.  
Hence, make it possible to change any pset option(s) for the duration  
of a single command output, by writing "option=value ..." inside  
parentheses, for example  
	\g (format=csv csv_fieldsep='\t') somefile  
  
\gx can now be understood as a shorthand for including expanded=on  
inside the parentheses.  
  
Patch by me, expanding on a proposal by Pavel Stehule  
  
Discussion: https://postgr.es/m/CAFj8pRBx9OnBPRJVtfA5ycUpySge-XootAXAsv_4rrkHxJ8eRg@mail.gmail.com  

commit   : 0f5ca02f53ac2b211d8518f0882c49284c0c9610    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 7 Apr 2020 23:51:10 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 7 Apr 2020 23:51:10 +0300    

This commit adds following optional clause to BEGIN and START TRANSACTION  
commands.  
  
  WAIT FOR LSN lsn [ TIMEOUT timeout ]  
  
New clause pospones transaction start till given lsn is applied on standby.  
This clause allows user be sure, that changes previously made on primary would  
be visible on standby.  
  
New shared memory struct is used to track awaited lsn per backend.  Recovery  
process wakes up backend once required lsn is applied.  
  
Author: Ivan Kartyshov, Anna Akenteva  
Reviewed-by: Craig Ringer, Thomas Munro, Robert Haas, Kyotaro Horiguchi  
Reviewed-by: Masahiko Sawada, Ants Aasma, Dmitry Ivanov, Simon Riggs  
Reviewed-by: Amit Kapila, Alexander Korotkov  
Discussion: https://postgr.es/m/0240c26c-9f84-30ea-fca9-93ab2df5f305%40postgrespro.ru  

commit   : 357889eb17bb9c9336c4f324ceb1651da616fe57    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Apr 2020 16:22:13 -0400    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 7 Apr 2020 16:22:13 -0400    

WITH TIES is an option to the FETCH FIRST N ROWS clause (the SQL  
standard's spelling of LIMIT), where you additionally get rows that  
compare equal to the last of those N rows by the columns in the  
mandatory ORDER BY clause.  
  
There was a proposal by Andrew Gierth to implement this functionality in  
a more powerful way that would yield more features, but the other patch  
had not been finished at this time, so we decided to use this one for  
now in the spirit of incremental development.  
  
Author: Surafel Temesgen <surafel3000@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Tomas Vondra <tomas.vondra@2ndquadrant.com>  
Discussion: https://postgr.es/m/CALAY4q9ky7rD_A4vf=FVQvCGngm3LOes-ky0J6euMrg=_Se+ag@mail.gmail.com  
Discussion: https://postgr.es/m/87o8wvz253.fsf@news-spur.riddles.org.uk  

commit   : 26a944cf29ba67bb49f42656dd2be98fe2485f5f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Apr 2020 15:57:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Apr 2020 15:57:58 -0400    

Since the existing bit number argument can't exceed INT32_MAX, it's  
not possible for these functions to manipulate bits beyond the first  
256MB of a bytea value.  Lift that restriction by redeclaring the  
bit number arguments as int8 (which requires a catversion bump,  
hence is not back-patchable).  
  
The similarly-named functions for bit/varbit don't really have a  
problem because we restrict those types to at most VARBITMAXLEN bits;  
hence leave them alone.  
  
While here, extend the encode/decode functions in utils/adt/encode.c  
to allow dealing with values wider than 1GB.  This is not a live bug  
or restriction in current usage, because no input could be more than  
1GB, and since none of the encoders can expand a string more than 4X,  
the result size couldn't overflow uint32.  But it might be desirable  
to support more in future, so make the input length values size_t  
and the potential-output-length values uint64.  
  
Also add some test cases to improve the miserable code coverage  
of these functions.  
  
Movead Li, editorialized some by me; also reviewed by Ashutosh Bapat  
  
Discussion: https://postgr.es/m/20200312115135445367128@highgo.ca  

commit   : 9c74ceb20b991f786f71666d4b4d557d2744a567    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 7 Apr 2020 19:20:20 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 7 Apr 2020 19:20:20 +0200    

Reported-by: Thomas Munro  

commit   : d22782a5392f6a1cb6cfca34031b93eb9dd2aa03    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 7 Apr 2020 18:03:24 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 7 Apr 2020 18:03:24 +0200    

Some places still used "Maximum" instead of "Peak" when displaying info  
about sort space, so fix that. Also, add a comment clarifying why it's  
correct to check the number of full/prefix sort groups.  
  
Author: James Coleman  
Discussion: https://postgr.es/m/CAPpHfds1waRZ=NOmueYq0sx1ZSCnt+5QJvizT8ndT2=etZEeAQ@mail.gmail.com  

commit   : 4bd0ad9e44be9fbc3ad77747d7672dab1c3df7d9    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Apr 2020 00:49:29 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 8 Apr 2020 00:49:29 +0900    

Previously when there were multiple timelines listed in the history file  
of the recovery target timeline, archive recovery searched all of them,  
starting from the newest timeline to the oldest one, to find the segment  
to read. That is, archive recovery had to continuously fail scanning  
the segment until it reached the timeline that the segment belonged to.  
These scans for non-existent segment could be harmful on the recovery  
performance especially when archival area was located on the remote  
storage and each scan could take a long time.  
  
To address the issue, this commit changes archive recovery so that  
it skips scanning the timeline that the segment to read doesn't belong to.  
  
Author: Kyotaro Horiguchi, tweaked a bit by Fujii Masao  
Reviewed-by: David Steele, Pavel Suderevsky, Grigory Smolkin  
Discussion: https://postgr.es/m/16159-f5a34a3a04dc67e0@postgresql.org  
Discussion: https://postgr.es/m/20200129.120222.1476610231001551715.horikyota.ntt@gmail.com  

commit   : ba3e76cc571eba3dea19c9465ff15ac3ac186576    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 7 Apr 2020 16:43:18 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 7 Apr 2020 16:43:18 +0200    

Commit d2d8a229bc introduced Incremental Sort, but it was considered  
only in create_ordered_paths() as an alternative to regular Sort. There  
are many other places that require sorted input and might benefit from  
considering Incremental Sort too.  
  
This patch modifies a number of those places, but not all. The concern  
is that just adding Incremental Sort to any place that already adds  
Sort may increase the number of paths considered, negatively affecting  
planning time, without any benefit. So we've taken a more conservative  
approach, based on analysis of which places do affect a set of queries  
that did seem practical. This means some less common queries may not  
benefit from Incremental Sort yet.  
  
Author: Tomas Vondra  
Reviewed-by: James Coleman  
Discussion: https://postgr.es/m/CAPpHfds1waRZ=NOmueYq0sx1ZSCnt+5QJvizT8ndT2=etZEeAQ@mail.gmail.com  

commit   : c7654f6a37792ab9525ff98b710c23b27c7868a5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Apr 2020 22:22:13 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Apr 2020 22:22:13 -0400    

It turns out that the code did indeed rely on a zeroed  
TuplesortInstrumentation.sortMethod field to indicate  
"this worker never did anything", although it seems the  
issue only comes up during certain race-condition-y cases.  
  
Hence, rearrange the TuplesortMethod enum to restore  
SORT_TYPE_STILL_IN_PROGRESS to having the value zero,  
and add some comments reinforcing that that isn't optional.  
  
Also future-proof a loop over the possible values of the enum.  
sizeof(bits32) happened to be the correct limit value,  
but only by purest coincidence.  
  
Per buildfarm and local investigation.  
  
Discussion: https://postgr.es/m/12222.1586223974@sss.pgh.pa.us  

commit   : 4c04be9b05ad2ec5acd27c3417bf075c13cab134    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 7 Apr 2020 11:33:56 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 7 Apr 2020 11:33:56 +1200    

The txid_XXX family of fmgr functions exposes 64 bit transaction IDs to  
users as int8.  Now that we have an SQL type xid8 for FullTransactionId,  
define a new set of functions including pg_current_xact_id() and  
pg_current_snapshot() based on that.  Keep the old functions around too,  
for now.  
  
It's a bit sneaky to use the same C functions for both, but since the  
binary representation is identical except for the signedness of the  
type, and since older functions are the ones using the wrong signedness,  
and since we'll presumably drop the older ones after a reasonable period  
of time, it seems reasonable to switch to FullTransactionId internally  
and share the code for both.  
  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Takao Fujii <btfujiitkp@oss.nttdata.com>  
Reviewed-by: Yoshikazu Imai <imai.yoshikazu@fujitsu.com>  
Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com>  
Discussion: https://postgr.es/m/20190725000636.666m5mad25wfbrri%40alap3.anarazel.de  

commit   : aeec457de8a8820368e343e791accffe24dc7198    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 7 Apr 2020 11:08:14 +1200    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Tue, 7 Apr 2020 11:08:14 +1200    

Similar to xid, but 64 bits wide.  This new type is suitable for use in  
various system views and administration functions.  
  
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>  
Reviewed-by: Takao Fujii <btfujiitkp@oss.nttdata.com>  
Reviewed-by: Yoshikazu Imai <imai.yoshikazu@fujitsu.com>  
Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com>  
Discussion: https://postgr.es/m/20190725000636.666m5mad25wfbrri%40alap3.anarazel.de  

commit   : 4bea576b032d6e5435ef0946194aada314e67691    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 7 Apr 2020 01:16:57 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Tue, 7 Apr 2020 01:16:57 +0200    

Per report from lapwing.  

commit   : 23ba3b5ee278847e4fad913b80950edb2838fd35    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 6 Apr 2020 23:58:10 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 6 Apr 2020 23:58:10 +0200    

The last test in incremental_sort suite prints a parallel plan, but some  
of the buildfarm animals have custom max_parallel_workers_per_gather  
values, causing failures. Fixed by setting the GUC to an explicit value.  
  
Discussion: https://postgr.es/m/CAPpHfds1waRZ=NOmueYq0sx1ZSCnt+5QJvizT8ndT2=etZEeAQ@mail.gmail.com  

commit   : ce2cee0ade8a6a360322c51201fda1fc25be7773    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 6 Apr 2020 14:46:33 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 6 Apr 2020 14:46:33 -0700    

An assertion added by commit 0d861bbb checked that _bt_killitems() only  
processes a BTScanPosItem whose heap TID is contained in a posting list  
tuple when its page offset number still matches what is on the page  
(i.e. when it matches the posting list tuple's current offset number).  
This was only correct in the common case where the page can't have  
changed since we first read it.  It was not correct in cases where we  
don't drop the buffer pin (and don't need to verify the page hasn't  
changed using its LSN).  The latter category includes scans involving  
unlogged tables, and scans that use a non-MVCC snapshot, per the logic  
originally introduced by commit 2ed5b87f.  
  
The assertion still seems helpful.  Fix it by taking cases where the  
page may have been concurrently modified into account.  
  
Reported-By: Anastasia Lubennikova, Alexander Lakhin  
Discussion: https://postgr.es/m/c4e38e9a-0f9c-8e53-e639-adf343f94472@postgrespro.ru  

commit   : 7d6d82a52493ad47c57662d0ac6758da551e87a5    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 6 Apr 2020 23:19:13 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 6 Apr 2020 23:19:13 +0200    

When executed with force_parallel_mode=regress, the function was exiting  
too early and thus failed to print the worker stats. Fixed by making it  
more like show_sort_info.  
  
Discussion: https://postgr.es/m/CAPpHfds1waRZ=NOmueYq0sx1ZSCnt+5QJvizT8ndT2=etZEeAQ@mail.gmail.com  

commit   : d2d8a229bc58a2014dce1c7a4fcdb6c5ab9fb8da    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 6 Apr 2020 21:33:28 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Mon, 6 Apr 2020 21:33:28 +0200    

Incremental Sort is an optimized variant of multikey sort for cases when  
the input is already sorted by a prefix of the requested sort keys. For  
example when the relation is already sorted by (key1, key2) and we need  
to sort it by (key1, key2, key3) we can simply split the input rows into  
groups having equal values in (key1, key2), and only sort/compare the  
remaining column key3.  
  
This has a number of benefits:  
  
- Reduced memory consumption, because only a single group (determined by  
  values in the sorted prefix) needs to be kept in memory. This may also  
  eliminate the need to spill to disk.  
  
- Lower startup cost, because Incremental Sort produce results after each  
  prefix group, which is beneficial for plans where startup cost matters  
  (like for example queries with LIMIT clause).  
  
We consider both Sort and Incremental Sort, and decide based on costing.  
  
The implemented algorithm operates in two different modes:  
  
- Fetching a minimum number of tuples without check of equality on the  
  prefix keys, and sorting on all columns when safe.  
  
- Fetching all tuples for a single prefix group and then sorting by  
  comparing only the remaining (non-prefix) keys.  
  
We always start in the first mode, and employ a heuristic to switch into  
the second mode if we believe it's beneficial - the goal is to minimize  
the number of unnecessary comparions while keeping memory consumption  
below work_mem.  
  
This is a very old patch series. The idea was originally proposed by  
Alexander Korotkov back in 2013, and then revived in 2017. In 2018 the  
patch was taken over by James Coleman, who wrote and rewrote most of the  
current code.  
  
There were many reviewers/contributors since 2013 - I've done my best to  
pick the most active ones, and listed them in this commit message.  
  
Author: James Coleman, Alexander Korotkov  
Reviewed-by: Tomas Vondra, Andreas Karlsson, Marti Raudsepp, Peter Geoghegan, Robert Haas, Thomas Munro, Antonin Houska, Andres Freund, Alexander Kuzmenkov  
Discussion: https://postgr.es/m/CAPpHfdscOX5an71nHd8WSUH6GNOCf=V7wgDaTXdDd9=goN-gfA@mail.gmail.com  
Discussion: https://postgr.es/m/CAPpHfds1waRZ=NOmueYq0sx1ZSCnt+5QJvizT8ndT2=etZEeAQ@mail.gmail.com  

commit   : 3c8553547b1493c4afdb80393f4a47dbfa019a79    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Apr 2020 12:00:37 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 6 Apr 2020 12:00:37 -0400    

Since commit 8f59f6b9c0, CLOBBER_CACHE_ALWAYS buildfarm members have  
been failing this test case because the error message now sometimes  
includes an error cursor position.  It seems largely just luck that  
that never happened before, and there are likely to be more ways it  
could happen in future.  Hence, rather than trying to prevent it,  
adjust the test script to suppress that component of the report.  
  
At some point we might need to back-patch this, but refrain until  
there's a demonstrated need.  (We'd need a different fix before v12,  
anyway, since VERBOSITY=sqlstate is a recent thing.)  
  
Tom Lane and Andres Freund  
  
Discussion: https://postgr.es/m/30675.1586111599@sss.pgh.pa.us  

commit   : f1ac27bfda6ce8a399d8001843e9aefff5814f9b    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Apr 2020 15:15:52 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 6 Apr 2020 15:15:52 +0200    

Mainly, this adds support code in logical/worker.c for applying  
replicated operations whose target is a partitioned table to its  
relevant partitions.  
  
Author: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Rafia Sabih <rafia.pghackers@gmail.com>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Reviewed-by: Petr Jelinek <petr@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/CA+HiwqH=Y85vRK3mOdjEkqFK+E=ST=eQiHdpj43L=_eJMOOznQ@mail.gmail.com  

commit   : b7ce6de93b59852c55d09acdaeebbf5aaf89114e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 6 Apr 2020 16:24:51 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 6 Apr 2020 16:24:51 +0530    

This commit allows autovacuum to log WAL usage statistics added by commit  
df3b181499.  
  
Author: Julien Rouhaud  
Reviewed-by: Dilip Kumar and Amit Kapila  
Discussion: https://postgr.es/m/CAB-hujrP8ZfUkvL5OYETipQwA=e3n7oqHFU=4ZLxWS_Cza3kQQ@mail.gmail.com  

commit   : 8ef9451f58ee92d1cdb910e72010dbe75e76f9b8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Apr 2020 11:44:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Apr 2020 11:44:23 +0900    

This new cache lookup routine has been introduced in a40caf5, and more  
code paths can directly use it.  
  
Note that in cluster_rel(), the code was returning immediately if the  
tuple's entry in pg_index for the clustered index was not valid.  This  
commit changes the code so as a lookup error is raised instead,  
something that could not happen from the start as we check for the  
existence of the index beforehand, while holding an exclusive lock on  
the parent table.  
  
Author: Justin Pryzby  
Reviewed-by: Álvaro Herrera, Michael Paquier  
Discussion: https://postgr.es/m/20200202161718.GI13621@telsasoft.com  

commit   : 33e05f89c53e5a1533d624046bb6fb0da7bb7141    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 6 Apr 2020 08:02:15 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 6 Apr 2020 08:02:15 +0530    

This commit adds a new option WAL similar to existing option BUFFERS in the  
EXPLAIN command.  This option allows to include information on WAL record  
generation added by commit df3b181499 in EXPLAIN output.  
  
This also allows the WAL usage information to be displayed via  
the auto_explain module.  A new parameter auto_explain.log_wal controls  
whether WAL usage statistics are printed when an execution plan is logged.  
This parameter has no effect unless auto_explain.log_analyze is enabled.  
  
Author: Julien Rouhaud  
Reviewed-by: Dilip Kumar and Amit Kapila  
Discussion: https://postgr.es/m/CAB-hujrP8ZfUkvL5OYETipQwA=e3n7oqHFU=4ZLxWS_Cza3kQQ@mail.gmail.com  

commit   : a40caf5f862ca8b7e927b2ab2567e934868e9376    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Apr 2020 11:03:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 6 Apr 2020 11:03:49 +0900    

A table rewritten by ALTER TABLE would lose tracking of an index usable  
for CLUSTER.  This setting is tracked by pg_index.indisclustered and is  
controlled by ALTER TABLE, so some extra work was needed to restore it  
properly.  Note that ALTER TABLE only marks the index that can be used  
for clustering, and does not do the actual operation.  
  
Author: Amit Langote, Justin Pryzby  
Reviewed-by: Ibrar Ahmed, Michael Paquier  
Discussion: https://postgr.es/m/20200202161718.GI13621@telsasoft.com  
Backpatch-through: 9.5  

commit   : fc3f4453a2bc95549682e23600b22e658cb2d6d7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 5 Apr 2020 18:23:30 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 5 Apr 2020 18:23:30 -0700    

This is for the benefit of running postgres under the rr  
debugger. When using rr signal handlers running while a syscall is  
active use an alternative stack. As e.g. bgworkers are started from  
within signal handlers, the forked backend then has a different stack  
base than postmaster. Previously that subsequently lead to those  
processes triggering spurious "stack depth limit exceeded" errors.  
  
Discussion: https://postgr.es/m/20200327182217.ubrrl32lyfhxfwk5@alap3.anarazel.de  

commit   : f946069e6827e729857b9f2db06bf27a1c0563ee    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 5 Apr 2020 17:47:30 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 5 Apr 2020 17:47:30 -0700    

There's a very low risk that RecentGlobalXmin could be far enough in  
the past to be older than relfrozenxid, or even wrapped  
around. Luckily the consequences of that having happened wouldn't be  
too bad - the page wouldn't be pruned for a while.  
  
Avoid that risk by using TransactionXmin instead. As that's announced  
via MyPgXact->xmin, it is protected against wrapping around (see code  
comments for details around relfrozenxid).  
  
Author: Andres Freund  
Discussion: https://postgr.es/m/20200328213023.s4eyijhdosuc4vcj@alap3.anarazel.de  
Backpatch: 9.5-  

commit   : 549a3e23c3d618103487161b19dbbf8fd2206a5c    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sun, 5 Apr 2020 12:03:09 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sun, 5 Apr 2020 12:03:09 -0700    

Reported-By: David Rowley  

commit   : a9d9bdd3ad21a73b481911f22279e004679d172e    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 5 Apr 2020 10:02:00 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 5 Apr 2020 10:02:00 +0200    

Fixup for "Drop slot's LWLock before returning from SaveSlotToPath()"  
  
Reported-by: Michael Paquier <michael@paquier.xyz>  

commit   : 18d85e9b8a2b784bcee350c59cf20c5c697a1c1f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Apr 2020 00:53:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 5 Apr 2020 00:53:25 -0400    

Commit 7cb0a423f overlooked that the multi-level partition test table  
pagg_tab_ml still had an exactly even row split at its upper level of  
partitioning, so that some of the sub-aggregation plan steps still had  
exactly equal costs, leading to plan instability.  Tweak the partition  
boundaries some more to make the row distribution unequal at both  
levels.  This leads to more changes in the "expected" plan order than  
the previous round, but it seems fine.  (Actually, I'm surprised that  
this didn't affect even more plans in this test: looking at the  
underlying costs shows that some of the parallel plan groups are  
*not* getting sorted by cost.  Bug?)  
  
Per buildfarm member lousyjack,  
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lousyjack&dt=2020-04-04%2021%3A03%3A04  
  
Discussion: https://postgr.es/m/24467.1585838693@sss.pgh.pa.us  

commit   : 6b466bf5f2bea0c89fab54eef696bcfc7ecdafd7    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sun, 5 Apr 2020 07:34:04 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sun, 5 Apr 2020 07:34:04 +0530    

This commit adds three new columns in pg_stat_statements output to  
display WAL usage statistics added by commit df3b181499.  
  
This commit doesn't bump the version of pg_stat_statements as the  
same is done for this release in commit 17e0328224.  
  
Author: Kirill Bychik and Julien Rouhaud  
Reviewed-by: Julien Rouhaud, Fujii Masao, Dilip Kumar and Amit Kapila  
Discussion: https://postgr.es/m/CAB-hujrP8ZfUkvL5OYETipQwA=e3n7oqHFU=4ZLxWS_Cza3kQQ@mail.gmail.com  

commit   : 70de4e950c3b9db620346317f30d31827ac6c3f1    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 4 Apr 2020 15:45:45 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 4 Apr 2020 15:45:45 -0700    

Oversight in today's commit c6b92041d38512a4176ed76ad06f713d2e6c01a8.  
Per buildfarm member jacana.  
  
Discussion: http://postgr.es/m/20200404223212.GC3442685@rfd.leadboat.com  

commit   : 07871d40c72e498b6e034eb674df5d8d206976bc    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Apr 2020 18:03:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Apr 2020 18:03:30 -0400    

Commit 77ec5affb added an assertion to enforce_generic_type_consistency  
that boils down to "if the function result is polymorphic, there must be  
at least one polymorphic argument".  This should be true for user-created  
functions, but there are built-in functions for which it's not true, as  
pointed out by Jaime Casanova.  Hence, go back to the old behavior of  
leaving the return type alone.  There's only a limited amount of stuff  
you can do with such a function result, but it does work to some extent;  
add some regression test cases to ensure we don't break that again.  
  
Discussion: https://postgr.es/m/CAJGNTeMbhtsCUZgJJ8h8XxAJbK7U2ipsX8wkHRtZRz-NieT8RA@mail.gmail.com  

commit   : c6b92041d38512a4176ed76ad06f713d2e6c01a8    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 4 Apr 2020 12:25:34 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 4 Apr 2020 12:25:34 -0700    

Until now, only selected bulk operations (e.g. COPY) did this.  If a  
given relfilenode received both a WAL-skipping COPY and a WAL-logged  
operation (e.g. INSERT), recovery could lose tuples from the COPY.  See  
src/backend/access/transam/README section "Skipping WAL for New  
RelFileNode" for the new coding rules.  Maintainers of table access  
methods should examine that section.  
  
To maintain data durability, just before commit, we choose between an  
fsync of the relfilenode and copying its contents to WAL.  A new GUC,  
wal_skip_threshold, guides that choice.  If this change slows a workload  
that creates small, permanent relfilenodes under wal_level=minimal, try  
adjusting wal_skip_threshold.  Users setting a timeout on COMMIT may  
need to adjust that timeout, and log_min_duration_statement analysis  
will reflect time consumption moving to COMMIT from commands like COPY.  
  
Internally, this requires a reliable determination of whether  
RollbackAndReleaseCurrentSubTransaction() would unlink a relation's  
current relfilenode.  Introduce rd_firstRelfilenodeSubid.  Amend the  
specification of rd_createSubid such that the field is zero when a new  
rel has an old rd_node.  Make relcache.c retain entries for certain  
dropped relations until end of transaction.  
  
Bump XLOG_PAGE_MAGIC, since this introduces XLOG_GIST_ASSIGN_LSN.  
Future servers accept older WAL, so this bump is discretionary.  
  
Kyotaro Horiguchi, reviewed (in earlier, similar versions) by Robert  
Haas.  Heikki Linnakangas and Michael Paquier implemented earlier  
designs that materially clarified the problem.  Reviewed, in earlier  
designs, by Andrew Dunstan, Andres Freund, Alvaro Herrera, Tom Lane,  
Fujii Masao, and Simon Riggs.  Reported by Martijn van Oosterhout.  
  
Discussion: https://postgr.es/m/20150702220524.GA9392@svana.org  

commit   : 552fcebff04699103cefd2efa71fae1274893dbe    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 4 Apr 2020 09:08:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 4 Apr 2020 09:08:12 +0200    

This reverts commit 246f136e76ecd26844840f2b2057e2c87ec9868d.  
  
That patch wasn't quite complete enough.  
  
Discussion: https://www.postgresql.org/message-id/flat/E1jIpJu-0007Ql-CL%40gemulon.postgresql.org  

commit   : df3b181499b40523bd6244a4e5eb554acb9020ce    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Sat, 4 Apr 2020 10:02:08 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Sat, 4 Apr 2020 10:02:08 +0530    

This allows gathering the WAL generation statistics for each statement  
execution.  The three statistics that we collect are the number of WAL  
records, the number of full page writes and the amount of WAL bytes  
generated.  
  
This helps the users who have write-intensive workload to see the impact  
of I/O due to WAL.  This further enables us to see approximately what  
percentage of overall WAL is due to full page writes.  
  
In the future, we can extend this functionality to allow us to compute the  
the exact amount of WAL data due to full page writes.  
  
This patch in itself is just an infrastructure to compute WAL usage data.  
The upcoming patches will expose this data via explain, auto_explain,  
pg_stat_statements and verbose (auto)vacuum output.  
  
Author: Kirill Bychik, Julien Rouhaud  
Reviewed-by: Dilip Kumar, Fujii Masao and Amit Kapila  
Discussion: https://postgr.es/m/CAB-hujrP8ZfUkvL5OYETipQwA=e3n7oqHFU=4ZLxWS_Cza3kQQ@mail.gmail.com  

commit   : 0588ee63aa2d8c5765d086991555cd9acdd4d86f    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 3 Apr 2020 19:52:16 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Fri, 3 Apr 2020 19:52:16 -0700    

Don't try to be precise about it, just use a constant 16 bytes of  
chunk overhead. Being smarter would require knowing the memory context  
where the chunk will be allocated, which is not known by all callers.  
  
Discussion: https://postgr.es/m/20200325220936.il3ni2fj2j2b45y5@alap3.anarazel.de  

commit   : 3e0d80fd8d3dd4f999e0d3aa3e591f480d8ad1fd    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 22:28:37 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 22:28:37 -0400    

Commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661 allowed BASE_BACKUP to  
acquire a ResourceOwner without a transaction so that the backup  
manifest functionality could use a BufFile, but it overlooked the fact  
that when a walsender is used with replication=database, it might have  
a transaction in progress, because in that mode, SQL and replication  
commands can be mixed.  Try to fix things up so that the two cleanup  
mechanisms don't conflict.  
  
Per buildfarm member serinus, which triggered the problem when  
CREATE_REPLICATION_SLOT failed from inside a transaction.  It passed  
on the subsequent run, so evidently the failure doesn't happen every  
time.  

commit   : db1531cae00941bfe4f6321fdef1e1ef355b6bed    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 20:15:27 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 20:15:27 -0400    

lapwing is complaining that about a call to pg_gmtime, saying that  
it "expected 'const pg_time_t *' but argument is of type 'time_t *'".  
I at first thought that the problem had someting to do with const,  
but Thomas Munro suggested that it might be just because time_t  
and pg_time_t are different identifers. lapwing is i686 rather than  
x86_64, and pg_time_t is always int64, so that seems like a good  
guess.  
  
There is other code that just casts time_t to pg_time_t without  
any conversion function, so try that approach here.  
  
Introduced in commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661.  

commit   : 9f8f881caa0fabdf7ff46cc55a991ffeab39bd92    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 19:51:18 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 19:51:18 -0400    

Report by Tom Lane.  
  
Discussion: http://postgr.es/m/22394.1585951968@sss.pgh.pa.us  

commit   : 19c0422ad012636d00ba221bd7052cb71448efca    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 19:01:59 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 19:01:59 -0400    

It may be necessary to go further and remove this test altogether,  
but I'm going to try this fix first. It's not clear, at least to  
me, exactly how this is breaking buildfarm members, but it appears  
to be doing so.  

commit   : 460314db08e8688e1a54a0a26657941e058e45c5    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 17:16:31 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 17:16:31 -0400    

Second try at getting the buildfarm to be happy with 003_corrution.pl  
as added by commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661.  
  
Per suggestion from Álvaro Herrera.  
  
Discussion: http://postgr.es/m/20200403205412.GA8279@alvherre.pgsql  

commit   : 0568e7a2a4f133a7c16776bcae92c53fcf247b73    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Apr 2020 17:00:25 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Apr 2020 17:00:25 -0400    

Move have_partkey_equi_join and match_expr_to_partition_keys to  
relnode.c, since they're used only there.  Refactor  
build_joinrel_partition_info to split out the code that fills the  
joinrel's partition key lists; this doesn't have any non-cosmetic  
impact, but it seems like a useful separation of concerns.  
Improve assorted nearby comments.  
  
Amit Langote, with a little further editorialization by me  
  
Discussion: https://postgr.es/m/CA+HiwqG2WVUGmLJqtR0tPFhniO=H=9qQ+Z3L_ZC+Y3-EVQHFGg@mail.gmail.com  

commit   : 21dc48840c24e70b1b1f0f6478f3dba5343182dd    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 15:40:35 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 15:40:35 -0400    

The buildfarm is very unhappy right now because TAP test  
003_corruption.pl uses TestLib::tempdir to generate the name of  
a temporary directory that is used as a tablespace name, and  
this results in a 'symbolic link target too long' error message  
on many of the buildfarm machines, but not on my machine.  
  
It appears that other people have run into similar problems in  
the past and that TestLib::tempdir_short was the solution, so  
let's try using that instead.  

commit   : 87e300434058a157bbc4ef8d039937abdefa7610    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 15:28:59 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 15:28:59 -0400    

It seems that we have a policy that every Perl subroutine should  
end with an explicit "return", so add explicit "return"  
statements to all the new subroutines added by my prior  
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661.  
  
Per buildfarm.  

commit   : 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 14:59:47 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 14:59:47 -0400    

A manifest is a JSON document which includes (1) the file name, size,  
last modification time, and an optional checksum for each file backed  
up, (2) timelines and LSNs for whatever WAL will need to be replayed  
to make the backup consistent, and (3) a checksum for the manifest  
itself. By default, we use CRC-32C when checksumming data files,  
because we are trying to detect corruption and user error, not foil an  
adversary. However, pg_basebackup and the server-side BASE_BACKUP  
command now have options to select a different algorithm, so users  
wanting a cryptographic hash function can select SHA-224, SHA-256,  
SHA-384, or SHA-512. Users not wanting file checksums at all can  
disable them, or disable generating of the backup manifest altogether.  
Using a cryptographic hash function in place of CRC-32C consumes  
significantly more CPU cycles, which may slow down backups in some  
cases.  
  
A new tool called pg_validatebackup can validate a backup against the  
manifest. If no checksums are present, it can still check that the  
right files exist and that they have the expected sizes. If checksums  
are present, it can also verify that each file has the expected  
checksum. Additionally, it calls pg_waldump to verify that the  
expected WAL files are present and parseable. Only plain format  
backups can be validated directly, but tar format backups can be  
validated after extracting them.  
  
Robert Haas, with help, ideas, review, and testing from David Steele,  
Stephen Frost, Andrew Dunstan, Rushabh Lathia, Suraj Kharage, Tushar  
Ahuja, Rajkumar Raghuwanshi, Mark Dilger, Davinder Singh, Jeevan  
Chalke, Amit Kapila, Andres Freund, and Noah Misch.  
  
Discussion: http://postgr.es/m/CA+TgmoZV8dw1H2bzZ9xkKwdrk8+XYa+DC9H=F7heO2zna5T6qg@mail.gmail.com  

commit   : ce77abe63cfc85fb0bc236deb2cc34ae35cb5324    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 4 Apr 2020 03:13:17 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 4 Apr 2020 03:13:17 +0900    

When BUFFERS option is enabled, EXPLAIN command includes the information  
on buffer usage during each plan node, in its output. In addition to that,  
this commit makes EXPLAIN command include also the information on  
buffer usage during planning phase, in its output. This feature makes it  
easier to discern the cases where lots of buffer access happen during  
planning.  
  
This commit revives the original commit ed7a509571 that was reverted by  
commit 19db23bcbd. The original commit had to be reverted because  
it caused the regression test failure on the buildfarm members prion and  
dory. But since commit c0885c4c30 got rid of the caues of the test failure,  
the original commit can be safely introduced again.  
  
Author: Julien Rouhaud, slightly revised by Fujii Masao  
Reviewed-by: Justin Pryzby  
Discussion: https://postgr.es/m/16109-26a1a88651e90608@postgresql.org  

commit   : e41955faf060f90918303ce0623df9d765144bf6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Apr 2020 13:15:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Apr 2020 13:15:30 -0400    

entryGetItem()'s three code paths each contained bugs associated  
with filtering the entries for gin_fuzzy_search_limit.  
  
The posting-tree path failed to advance "advancePast" after having  
decided to filter an item.  If we ran out of items on the current  
page and needed to advance to the next, what would actually happen  
is that entryLoadMoreItems() would re-load the same page.  Eventually,  
the random dropItem() test would accept one of the same items it'd  
previously rejected, and we'd move on --- but it could take awhile  
with small gin_fuzzy_search_limit.  To add insult to injury, this  
case would inevitably cause entryLoadMoreItems() to decide it needed  
to re-descend from the root, making things even slower.  
  
The posting-list path failed to implement gin_fuzzy_search_limit  
filtering at all, so that all entries in the posting list would  
be returned.  
  
The bitmap-result path used a "gotitem" variable that it failed to  
update in the one place where it'd actually make a difference, ie  
at the one "continue" statement.  I think this was unreachable in  
practice, because if we'd looped around then it shouldn't be the  
case that the entries on the new page are before advancePast.  
Still, the "gotitem" variable was contributing nothing to either  
clarity or correctness, so get rid of it.  
  
Refactor all three loops so that the termination conditions are  
more alike and less unreadable.  
  
The code coverage report showed that we had no coverage at all for  
the re-descend-from-root code path in entryLoadMoreItems(), which  
seems like a very bad thing, so add a test case that exercises it.  
We also had exactly no coverage for gin_fuzzy_search_limit, so add a  
simplistic test case that at least hits those code paths a little bit.  
  
Back-patch to all supported branches.  
  
Adé Heyward and Tom Lane  
  
Discussion: https://postgr.es/m/CAEknJCdS-dE1Heddptm7ay2xTbSeADbkaQ8bU2AXRCVC2LdtKQ@mail.gmail.com  

commit   : c0885c4c30698a1beef40a8df0edb253750d3b43    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Sat, 4 Apr 2020 01:25:44 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Sat, 4 Apr 2020 01:25:44 +0900    

The explain regression test runs EXPLAIN commands via the function  
that filters unstable outputs. To produce more stable test output,  
this commit improves the function so that it also filters out text-mode  
Buffers lines. This is necessary because text-mode Buffers lines vary  
depending the system state.  
  
This improvement will get rid of the regression test failure that  
the commit ed7a509571 caused on the buildfarm members prion and  
dory because of the instability of Buffers lines.  
  
Author: Fujii Masao  
Reviewed-by: Tom Lane  
Discussion: https://postgr.es/m/20200403025751.GB1759@paquier.xyz  

commit   : 347d2b07fcc250680f75b5f89ba49d4805782c6b    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 3 Apr 2020 13:23:20 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 3 Apr 2020 13:23:20 -0300    

More work is still needed, but this is a good start.  
  
Co-authored-by: Corey Huinker <corey.huinker@gmail.com>  
Co-authored-by: Jürgen Purtz <juergen@purtz.de>  
Co-authored-by: Roger Harkavy <rogerharkavy@gmail.com>  
Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>  
Discussion: https://postgr.es/m/CADkLM=eP6HOeqDjn0FdXuGRusQu4oWH_LFsKjjafmhvWD=aSpQ@mail.gmail.com  

commit   : 3031440e9809bbf7cf279b85306df2e3b686539d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 11:58:58 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 11:58:58 -0400    

Commit ac44367efbef198c57a18b96dbc6a39191720994 introduced this  
problem.  
  
Report and fix by Fujii Masao.  
  
Discussion: http://postgr.es/m/d332b8f0-0c72-3cd6-6945-7a86a503662a@oss.nttdata.com  

commit   : c12e43a2e0d45a6b59f2cea53f1b82e52fdcff7a    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 11:50:38 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 3 Apr 2020 11:50:38 -0400    

These functions make it easier to write code that wants to compute a  
checksum for some data while allowing the user to configure the type  
of checksum that gets used.  
  
This is another piece of infrastructure for the upcoming patch to add  
backup manifests.  
  
Patch written from scratch by me, but it is similar to previous work  
by Rushabh Lathia and Suraj Kharage. Suraj also reviewed this version  
off-list. Advice on how not to break Windows from Davinder Singh.  
  
Discussion: http://postgr.es/m/CA+TgmoZV8dw1H2bzZ9xkKwdrk8+XYa+DC9H=F7heO2zna5T6qg@mail.gmail.com  
Discussion: http://postgr.es/m/CA+TgmoZRTBiPyvQEwV79PU1ePTtSEo2UeVncrkJMbn1sU1gnRA@mail.gmail.com  

commit   : 6dd9f357792545b626e28b2e1f73cb4c32c437f1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Apr 2020 11:24:56 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 3 Apr 2020 11:24:56 -0400    

contrib/lo's lo_manage() thought it could use  
trigdata->tg_trigger->tgname in its error message about  
not being called as a trigger.  That naturally led to a core dump.  
  
unique_key_recheck() figured it could Assert that fcinfo->context  
is a TriggerData node in advance of having checked that it's  
being called as a trigger.  That's harmless in production builds,  
and perhaps not that easy to reach in any case, but it's logically  
wrong.  
  
The first of these per bug #16340 from William Crowell;  
the second from manual inspection of other CALLED_AS_TRIGGER  
call sites.  
  
Back-patch the lo.c change to all supported branches, the  
other to v10 where the thinko crept in.  
  
Discussion: https://postgr.es/m/16340-591c7449dc7c8c47@postgresql.org  

commit   : 19db23bcbda99e93321cb0636677ec9c6e121a2a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Apr 2020 12:20:42 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Apr 2020 12:20:42 +0900    

This reverts commit ed7a5095716ee498ecc406e1b8d5ab92c7662d10.  
  
Per buildfarm member prion.  

commit   : 18808f8c893d4f425f2d21b2a1ffc8e51f1bd0ba    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Apr 2020 12:15:56 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Apr 2020 12:15:56 +0900    

This commit introduces new wait events RecoveryConflictSnapshot and  
RecoveryConflictTablespace. The former is reported while waiting for  
recovery conflict resolution on a vacuum cleanup. The latter is reported  
while waiting for recovery conflict resolution on dropping tablespace.  
  
Also this commit changes the code so that the wait event Lock is reported  
while waiting in ResolveRecoveryConflictWithVirtualXIDs() for recovery  
conflict resolution on a lock. Basically the wait event Lock is reported  
during that wait, but previously was not reported only when that wait  
happened in ResolveRecoveryConflictWithVirtualXIDs().  
  
Author: Masahiko Sawada  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CA+fd4k4mXWTwfQLS3RPwGr4xnfAEs1ysFfgYHvmmoUgv6Zxvmg@mail.gmail.com  

commit   : 9d8ef98800bd291de145fb1be41f0868546e02ab    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 3 Apr 2020 11:45:15 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 3 Apr 2020 11:45:15 +0900    

This option is similar to \gset, except that it is able to store all  
results from combined SQL queries into separate variables.  If a query  
returns multiple rows, the last result is stored and if a query returns  
no rows, nothing is stored.  
  
While on it, add a TAP test for \gset to check for a failure when a  
query returns multiple rows.  
  
Author: Fabien Coelho  
Reviewed-by: Ibrar Ahmed, Michael Paquier  
Discussion: https://postgr.es/m/alpine.DEB.2.21.1904081914200.2529@lancre  

commit   : ed7a5095716ee498ecc406e1b8d5ab92c7662d10    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Apr 2020 11:27:09 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Fri, 3 Apr 2020 11:27:09 +0900    

When BUFFERS option is enabled, EXPLAIN command includes the information  
on buffer usage during each plan node, in its output. In addition to that,  
this commit makes EXPLAIN command include also the information on  
buffer usage during planning phase, in its output. This feature makes it  
easier to discern the cases where lots of buffer access happen during  
planning.  
  
Author: Julien Rouhaud, slightly revised by Fujii Masao  
Reviewed-by: Justin Pryzby  
Discussion: https://postgr.es/m/16109-26a1a88651e90608@postgresql.org  

commit   : ac44367efbef198c57a18b96dbc6a39191720994    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Thu, 2 Apr 2020 20:25:04 -0400    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Thu, 2 Apr 2020 20:25:04 -0400    

The primary motivation for this change is that it will be used by the  
upcoming patch to add backup manifests, but it also seems to have some  
potential more general use.  
  
Andres Freund and Robert Haas  
  
Discussion: http://postgr.es/m/20200330020814.nspra4mvby42yoa4@alap3.anarazel.de  

commit   : 7cb0a423f914af6936d13a8c7f2e35c0a4e4bd14    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Apr 2020 19:43:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Apr 2020 19:43:48 -0400    

Instead of disabling autovacuum on these test tables, adjust the  
partition boundaries so that the child partitions are not all the  
same size.  That should cause the planner to use a predictable  
ordering of the per-partition scan nodes even in cases where  
autovacuum causes the rowcount estimates to be off a bit.  
Moreover, this also lets these tests show that the planner does  
properly order the tables in descending size order, something  
that wasn't being proven before.  
  
The pagg_tab1 and pagg_tab2 partitions are still all the same  
size, but that should be fine, because those tables are so small  
that (1) autovacuum won't fire on them, and (2) even if it did,  
it couldn't change the reltuples value --- with only one page,  
it can't see just part of the relation.  
  
Discussion: https://postgr.es/m/24467.1585838693@sss.pgh.pa.us  

commit   : 8da1538b39f2803fdc75de8505dd096e29e65a52    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 2 Apr 2020 17:42:09 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 2 Apr 2020 17:42:09 -0400    

A join that was added in commit 9b2009c4cf that did not use the INNER  
keyword but the existing query used it.  It was cleaner to remove the  
existing INNER keyword.  
  
Reported-by: Peter Eisentraut  
  
Discussion: https://postgr.es/m/a1ffbfda-59d2-5732-e5fb-3df8582b6434@2ndquadrant.com  
  
Backpatch-through: 9.5  

commit   : c713dc2f7be314ee541f0abd170b69c90d8bfb14    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 2 Apr 2020 17:27:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 2 Apr 2020 17:27:43 -0400    

Reported-by: Peter Eisentraut  
  
Discussion: https://postgr.es/m/750b8832-d123-7f9b-931e-43ce8321b2d7@2ndquadrant.com  
  
Backpatch-through: 9.5  

commit   : 0b34e7d307e6a142ee94800e6d5f3e73449eeffd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Apr 2020 15:04:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 2 Apr 2020 15:04:51 -0400    

This patch replaces the boolean GUC log_parameters_on_error introduced  
by commit ba79cb5dc with an integer log_parameter_max_length_on_error,  
adding the ability to specify how many bytes to trim each logged  
parameter value to.  (The previous coding hard-wired that choice at  
64 bytes.)  
  
In addition, add a new parameter log_parameter_max_length that provides  
similar control over truncation of query parameters that are logged in  
response to statement-logging options, as opposed to errors.  Previous  
releases always logged such parameters in full, possibly causing log  
bloat.  
  
For backwards compatibility with prior releases,  
log_parameter_max_length defaults to -1 (log in full), while  
log_parameter_max_length_on_error defaults to 0 (no logging).  
  
Per discussion, log_parameter_max_length is SUSET since the DBA should  
control routine logging behavior, but log_parameter_max_length_on_error  
is USERSET because it also affects errcontext data sent back to the  
client.  
  
Alexey Bashtanov, editorialized a little by me  
  
Discussion: https://postgr.es/m/b10493cc-a399-a03a-67c7-068f2791ee50@imap.cc  

commit   : 2c220ca46f3f6de0611367312bec0daef99b29eb    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 2 Apr 2020 14:26:27 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 2 Apr 2020 14:26:27 +0200    

Author: Noriyoshi Shinoda  
Discussion: https://www.postgresql.org/message-id/flat/20200119143707.gyinppnigokesjok@development  

commit   : cefb82d49e2152e844af148a95d4072999dc3c6b    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Thu, 2 Apr 2020 21:26:54 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Thu, 2 Apr 2020 21:26:54 +1300    

In b07642dbc, we added code to trigger autovacuums based on the number of  
INSERTs into a table. This seems to have cause some destabilization of  
the regression tests. Likely this is due to an autovacuum triggering  
mid-test and (per theory from Tom Lane) one of the test's queries causes  
autovacuum to skip some number of pages, resulting in the reltuples  
estimate changing.  
  
The failure that this is attempting to fix is around the order of subnodes  
in an Append. Since the planner orders these according to the subnode  
cost, then it's possible that a small change in the reltuples value changes  
the subnode's cost enough that it swaps position with one of its fellow  
subnodes.  
  
The failure here only seems to occur on slower buildfarm machines. In this  
case, lousyjack, which seems have taken over 8 minutes to run just  
the partitionwise_aggregate test. Such a slow run would increase the  
chances that the autovacuum launcher would trigger a vacuum mid-test.  
Faster machines run this test in sub second time, so have a much smaller  
window for an autovacuum to trigger.  
  
Here we fix this by disabling autovacuum on all tables created in the test.  
  
Additionally, this reverts the change made in the  
partitionwise_aggregate test in 2dc16efed.  
  
Discussion: https://postgr.es/m/22297.1585797192@sss.pgh.pa.us  

commit   : 2991ac5fc9b3904ca4582be6d323497d7c3d17c9    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Mar 2020 08:14:00 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Mar 2020 08:14:00 +0100    

This adds SQL expressions NORMALIZE() and IS NORMALIZED to convert and  
check Unicode normal forms, per SQL standard.  
  
To support fast IS NORMALIZED tests, we pull in a new data file  
DerivedNormalizationProps.txt from Unicode and build a lookup table  
from that, using techniques similar to ones already used for other  
Unicode data.  make update-unicode will keep it up to date.  We only  
build and use these tables for the NFC and NFKC forms, because they  
are too big for NFD and NFKD and the improvement is not significant  
enough there.  
  
Reviewed-by: Daniel Verite <daniel@manitou-mail.org>  
Reviewed-by: Andreas Karlsson <andreas@proxel.se>  
Discussion: https://www.postgresql.org/message-id/flat/c1909f27-c269-2ed9-12f8-3ab72c8caf7a@2ndquadrant.com  

commit   : 070c3d3937e75e04d36405287353b7eca516555d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 2 Apr 2020 08:56:12 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 2 Apr 2020 08:56:12 +0200    

commit   : 580a446c21f83bcddbaf3ce5f1bab72239c11eb6    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 2 Apr 2020 08:01:30 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 2 Apr 2020 08:01:30 +0200    

Update the documentation to reflect that Unix-domain sockets are now  
usable on Windows.  

commit   : c6e0edad465e3774401b7f09ad70bd22e5421858    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 2 Apr 2020 07:52:20 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 2 Apr 2020 07:52:20 +0200    

Otherwise, it could be confusing to a reader that some of these  
well-publicized features are simply listed as unsupported without  
further explanation.  

commit   : 37b3794dfcfb9d55f7ea83693f50b1484caab21c    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 2 Apr 2020 16:44:11 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Thu, 2 Apr 2020 16:44:11 +1300    

New GUC from commit fc34b0d9.  

commit   : 3a5e22138a8d014590834eb808c99a436c246aab    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 2 Apr 2020 08:04:58 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 2 Apr 2020 08:04:58 +0530    

Commit 40d964ec99 allowed vacuum command to process indexes in parallel but  
forgot to accumulate the buffer usage stats of parallel workers.  This  
allows leader backend to accumulate buffer usage stats of all the parallel  
workers.  
  
Reported-by: Julien Rouhaud  
Author: Sawada Masahiko  
Reviewed-by: Dilip Kumar, Amit Kapila and Julien Rouhaud  
Discussion: https://postgr.es/m/20200328151721.GB12854@nol  

commit   : 17e03282241c6ac58a714eb0c3b6a8018cf6167a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 2 Apr 2020 11:20:19 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 2 Apr 2020 11:20:19 +0900    

This commit makes pg_stat_statements support new GUC  
pg_stat_statements.track_planning. If this option is enabled,  
pg_stat_statements tracks the planning statistics of the statements,  
e.g., the number of times the statement was planned, the total time  
spent planning the statement, etc. This feature is useful to check  
the statements that it takes a long time to plan. Previously since  
pg_stat_statements tracked only the execution statistics, we could  
not use that for the purpose.  
  
The planning and execution statistics are stored at the end of  
each phase separately. So there are not always one-to-one relationship  
between them. For example, if the statement is successfully planned  
but fails in the execution phase, only its planning statistics are stored.  
This may cause the users to be able to see different pg_stat_statements  
results from the previous version. To avoid this,  
pg_stat_statements.track_planning needs to be disabled.  
  
This commit bumps the version of pg_stat_statements to 1.8  
since it changes the definition of pg_stat_statements function.  
  
Author: Julien Rouhaud, Pascal Legrand, Thomas Munro, Fujii Masao  
Reviewed-by: Sergei Kornilov, Tomas Vondra, Yoshikazu Imai, Haribabu Kommi, Tom Lane  
Discussion: https://postgr.es/m/CAHGQGwFx_=DO-Gu-MfPW3VQ4qC7TfVdH2zHmvZfrGv6fQ3D-Tw@mail.gmail.com  
Discussion: https://postgr.es/m/CAEepm=0e59Y_6Q_YXYCTHZkqOc6H2pJ54C_Xe=VFu50Aqqp_sA@mail.gmail.com  
Discussion: https://postgr.es/m/DB6PR0301MB21352F6210E3B11934B0DCC790B00@DB6PR0301MB2135.eurprd03.prod.outlook.com  

commit   : 28cac71bd368788d1ab22f048eef211641fb1283    
  
author   : Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 2 Apr 2020 02:11:38 +0200    
  
committer: Tomas Vondra <tomas.vondra@postgresql.org>    
date     : Thu, 2 Apr 2020 02:11:38 +0200    

There's a number of SLRU caches used to access important data like clog,  
commit timestamps, multixact, asynchronous notifications, etc. Until now  
we had no easy way to monitor these shared caches, compute hit ratios,  
number of reads/writes etc.  
  
This commit extends the statistics collector to track this information  
for a predefined list of SLRUs, and also introduces a new system view  
pg_stat_slru displaying the data.  
  
The list of built-in SLRUs is fixed, but additional SLRUs may be defined  
in extensions. Unfortunately, there's no suitable registry of SLRUs, so  
this patch simply defines a fixed list of SLRUs with entries for the  
built-in ones and one entry for all additional SLRUs. Extensions adding  
their own SLRU are fairly rare, so this seems acceptable.  
  
This patch only allows monitoring of SLRUs, not tuning. The SLRU sizes  
are still fixed (hard-coded in the code) and it's not entirely clear  
which of the SLRUs might need a GUC to tune size. In a way, allowing us  
to determine that is one of the goals of this patch.  
  
Bump catversion as the patch introduces new functions and system view.  
  
Author: Tomas Vondra  
Reviewed-by: Alvaro Herrera  
Discussion: https://www.postgresql.org/message-id/flat/20200119143707.gyinppnigokesjok@development  

commit   : 17ca067995114ee40749d9138ba85fdd68518052    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Apr 2020 19:44:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Apr 2020 19:44:17 -0400    

Fix lquery parsing to handle repeated flag characters correctly,  
and to enforce the max label length correctly in some cases where  
it did not before, and to detect empty labels in some cases where  
it did not before.  
  
In a more cosmetic vein, use a switch rather than if-then chains to  
handle the different states, and avoid unnecessary checks on charlen  
when looking for ASCII characters, and factor out multiple copies of  
the label length checking code.  
  
Tom Lane and Dmitry Belyavsky  
  
Discussion: https://postgr.es/m/CADqLbzLVkBuPX0812o+z=c3i6honszsZZ6VQOSKR3VPbB56P3w@mail.gmail.com  

commit   : 949a9f043eb70a4986041b47513579f9a13d6a33    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Apr 2020 17:31:29 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Apr 2020 17:31:29 -0400    

Not much to say here --- does what it says on the tin.  The "binary"  
representation in each case is really just the same as the text format,  
though we prefix a version-number byte in case anyone ever feels  
motivated to change that.  Thus, there's not any expectation of improved  
speed or reduced space; the point here is just to allow clients to use  
binary format for all columns of a query result or COPY data.  
  
This makes use of the recently added ALTER TYPE support to add binary  
I/O functions to an existing data type.  As in commit a80818605,  
we can piggy-back on there already being a new-for-v13 version of the  
ltree extension, so we don't need a new update script file.  
  
Nino Floris, reviewed by Alexander Korotkov and myself  
  
Discussion: https://postgr.es/m/CANmj9Vxx50jOo1L7iSRxd142NyTz6Bdcgg7u9P3Z8o0=HGkYyQ@mail.gmail.com  

commit   : 501b0187998c24d4a950459d9bf5e67f9f3e4a25    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Apr 2020 14:49:49 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Apr 2020 14:49:49 -0400    

We require the partition key to be a subset of the set of columns  
being made unique, so that physically-separate indexes on the different  
partitions are sufficient to enforce the uniqueness constraint.  
  
The existing code checked that the listed columns appear, but did not  
inquire into the index semantics, which is a serious oversight given  
that different index opclasses might enforce completely different  
notions of uniqueness.  
  
Ideally, perhaps, we'd just match the partition key opfamily to the  
index opfamily.  But hash partitioning uses hash opfamilies which we  
can't directly match to btree opfamilies.  Hence, look up the equality  
operator in each family, and accept if it's the same operator.  This  
should be okay in a fairly general sense, since the equality operator  
ought to precisely represent the opfamily's notion of uniqueness.  
  
A remaining weak spot is that we don't have a cross-index-AM notion of  
which opfamily member is "equality".  But we know which one to use for  
hash and btree AMs, and those are the only two that are relevant here  
at present.  (Any non-core AMs that know how to enforce equality are  
out of luck, for now.)  
  
Back-patch to v11 where this feature was introduced.  
  
Guancheng Luo, revised a bit by me  
  
Discussion: https://postgr.es/m/D9C3CEF7-04E8-47A1-8300-CA1DCD5ED40D@gmail.com  

commit   : a80818605e5447b9b846590c3d3fab99060cb53e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Apr 2020 10:32:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 1 Apr 2020 10:32:33 -0400    

Quite a few matching operators such as JSONB's @> used "contsel" and  
"contjoinsel" as their selectivity estimators.  That was a bad idea,  
because (a) contsel is only a stub, yielding a fixed default estimate,  
and (b) that default is 0.001, meaning we estimate these operators as  
five times more selective than equality, which is surely pretty silly.  
  
There's a good model for improving this in ltree's ltreeparentsel():  
for any "var OP constant" query, we can try applying the operator  
to all of the column's MCV and histogram values, taking the latter  
as being a random sample of the non-MCV values.  That code is  
actually 100% generic, except for the question of exactly what  
default selectivity ought to be plugged in when we don't have stats.  
  
Hence, migrate the guts of ltreeparentsel() into the core code, provide  
wrappers "matchingsel" and "matchingjoinsel" with a more-appropriate  
default estimate, and use those for the non-geometric operators that  
formerly used contsel (mostly JSONB containment operators and tsquery  
matching).  
  
Also apply this code to some match-like operators in hstore, ltree, and  
pg_trgm, including the former users of ltreeparentsel as well as ones  
that improperly used contsel.  Since commit 911e70207 just created new  
versions of those extensions that we haven't released yet, we can sneak  
this change into those new versions instead of having to create an  
additional generation of update scripts.  
  
Patch by me, reviewed by Alexey Bashtanov  
  
Discussion: https://postgr.es/m/12237.1582833074@sss.pgh.pa.us  

commit   : d8653f468789a75627c2fc82e73e2755ad8d1fb4    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 1 Apr 2020 15:31:47 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 1 Apr 2020 15:31:47 +0200    

This unifies some duplicate code.  
  
Author: Amit Langote <amitlangote09@gmail.com>  
Discussion: https://www.postgresql.org/message-id/CA+HiwqFjYE5anArxvkjr37AQMd52L-LZtz9Ld2QrLQ3YfcYhTw@mail.gmail.com  

commit   : 369623492d08703c6e6269c995ce73b73d187416    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 1 Apr 2020 14:43:45 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 1 Apr 2020 14:43:45 +0200    

The previously listed total of 179 does not appear to be correct for  
SQL:2016 anymore.  (Previous SQL versions had slightly different  
feature sets, so it's plausible that it was once correct.)  The  
currently correct count is the number of rows in the respective tables  
in appendix F in SQL parts 2 and 11, minus 2 features that are listed  
twice.  Thus the correct count is currently 177.  This also matches  
the number of Core entries the built documentation currently shows, so  
it's internally consistent.  

commit   : 4d276ba94fd9b19457aeb5b6d9af00589fe184a0    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 1 Apr 2020 15:07:53 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 1 Apr 2020 15:07:53 +0300    

Reported-by: Erik Rijkers  
Discussion: https://postgr.es/m/82529ecf9bcc58d5b5cf9f3ffb699881%40xs4all.nl  

commit   : 3eabc62312ef9da7885d2d3380986e0592a0ee5d    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 1 Apr 2020 15:01:26 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 1 Apr 2020 15:01:26 +0300    

Old versions of opclass parameters patch supported ability to specify DEFAULT  
as the opclass name in CREATE INDEX command.  This ability was removed in the  
final version, but 911e702077 still mentions that in the documentation.  

commit   : 3f1802e1fdb74a33db176291be27a2ec243511c6    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 1 Apr 2020 14:42:17 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Wed, 1 Apr 2020 14:42:17 +0300    

Discussion: https://postgr.es/m/20200331024419.GB14618%40telsasoft.com  
Author: Justin Pryzby  

commit   : 8d84dd00123985e739233fa67c9b1d555f33ed03    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Apr 2020 14:45:45 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Apr 2020 14:45:45 +0900    

In a psql session, if the connection to the server is abruptly cut, the  
referenced connection would become NULL as of CheckConnection().  This  
could cause a hard crash with psql if attempting to connect by reusing  
the past connection's data because of a null-pointer dereference with  
either PQhost() or PQdb().  This issue is fixed by making sure that no  
reuse of the past connection is done if it does not exist.  
  
Issue has been introduced by 6e5f8d4, so backpatch down to 12.  
  
Reported-by: Hugh Wang  
Author: Michael Paquier  
Reviewed-by: Álvaro Herrera, Tom Lane  
Discussion: https://postgr.es/m/16330-b34835d83619e25d@postgresql.org  
Backpatch-through: 12  

commit   : 2401d93718310237b3cb1ff914abc1bcbdd8e1dc    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Wed, 1 Apr 2020 09:28:13 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Wed, 1 Apr 2020 09:28:13 +0530    

The coverity complained that dividing integer expressions and then  
converting the integer quotient to type "double" would lose fractional  
part.  Typecasting one of the arguments of expression with double should  
fix the report.  
  
Author: Mahendra Singh Thalor  
Reviewed-by: Amit Kapila  
Discussion: https://postgr.es/m/20200329224818.6phnhv7o2q2rfovf@alap3.anarazel.de  

commit   : 08481eedd186ea5c22eef86e85cacacbc715f995    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 23:01:34 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 23:01:34 -0400    

This was missed when the feature was added.  
  
Reported-by: Vik Fearing  
  
Discussion: https://postgr.es/m/eca20529-0b06-b493-ee38-f071a75dcd5b@postgresfriends.org  
  
Backpatch-through: 10  

commit   : a7e8ece41cf7a96d8a9c4c037cdfef304d950831    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Apr 2020 10:57:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 1 Apr 2020 10:57:03 +0900    

pg_rewind needs to copy from the source cluster to the target cluster a  
set of relation blocks changed from the previous checkpoint where WAL  
forked up to the end of WAL on the target.  Building this list of  
relation blocks requires a range of WAL segments that may not be present  
anymore on the target's pg_wal, causing pg_rewind to fail.  It is  
possible to work around this issue by copying manually the WAL segments  
needed but this may lead to some extra and actually useless work.  
  
This commit introduces a new option allowing pg_rewind to use a  
restore_command while doing the rewind by grabbing the parameter value  
of restore_command from the target cluster configuration.  This allows  
the rewind operation to be more reliable, so as only the WAL segments  
needed by the rewind are restored from the archives.  
  
In order to be able to do that, a new routine is added to src/common/ to  
allow frontend tools to restore files from archives using an  
already-built restore command.  This version is more simple than the  
backend equivalent as there is no need to handle the non-recovery case.  
  
Author: Alexey Kondratov  
Reviewed-by: Andrey Borodin, Andres Freund, Alvaro Herrera, Alexander  
Korotkov, Michael Paquier  
Discussion: https://postgr.es/m/a3acff50-5a0d-9a2c-b3b2-ee36168955c1@postgrespro.ru  

commit   : 92d31085e926253aa650b9d1e1f2f09934d0ddfc    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 18:44:29 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 18:44:29 -0400    

There are other operators that have limited number data type support, so  
just remove the sentence.  
  
Reported-by: Sergei Agalakov  
  
Discussion: https://postgr.es/m/158032651854.19851.16261832706661813796@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 009e422c1b6854870b6b7f6ba0b7e2816395d933    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 18:10:39 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 18:10:39 -0400    

The previous wording was confusing because it wasn't in decreasing order  
and had to backtrack.  Also clarify role/user wording.  
  
Reported-by: jbird@nuna.com  
  
Discussion: https://postgr.es/m/158057750885.1123.2806779262588618988@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 046fd4f364157fca85eadfddb0f0e8e5d7ceef26    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 17:57:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 17:57:44 -0400    

They are released just like table-level locks.  Also clean up wording.  
(Uses wording "rolled back to".)  
  
Reported-by: me@sillymon.ch  
  
Discussion: https://postgr.es/m/158074944048.1095.4309647363871637715@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : 7dbe290da446544a04ace7d342841070f062a0ed    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 31 Mar 2020 14:38:39 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 31 Mar 2020 14:38:39 -0700    

Add two assertions that verify the assumptions about posting list tuple  
space accounting and suffix truncation made within nbtsort.c.  

commit   : c2da793fd28073603c39d7abfffbc203a9bd4ac0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 17:32:00 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 17:32:00 -0400    

Backpatch-through: master  

commit   : 834b80464d653c976787f5b5849fa0595678d0a0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 12 Mar 2020 15:42:35 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 12 Mar 2020 15:42:35 -0400    

commit   : 9b2009c4cfe1450228b941aba52e00e6bb938282    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 17:16:33 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 17:16:33 -0400    

Without the namespace, the table name could be ambiguous.  
  
Reported-by: adunham@arbormetrix.com  
  
Discussion: https://postgr.es/m/158155175140.23798.2189464781144503491@wrigleys.postgresql.org  
  
Backpatch-through: 9.5  

commit   : d97d55460bbda698a8d3ca100bee5485255b888f    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 17:07:43 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 17:07:43 -0400    

Previously people might assume that the partition syntax version of  
CREATE TABLE is to be used for the inheritance partition table example;  
mention that the non-partitioned version should be used.  
  
Reported-by: mib@nic.at  
  
Discussion: https://postgr.es/m/158089540905.1098.15071165437284409576@wrigleys.postgresql.org  
  
Backpatch-through: 10  

commit   : fe3036527a1ff715bceb22ff5cba919001262a71    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Mar 2020 17:06:22 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Mar 2020 17:06:22 -0400    

Must hold some lock on the pg_statistic_ext_data catalog *before*  
we look up the tuple we aim to replace.  Otherwise a concurrent  
VACUUM FULL or similar operation could move it to a different TID,  
leaving us trying to replace the wrong tuple.  
  
Back-patch to v12 where this got broken.  
  
Credit goes to Dean Rasheed; I'm just doing the clerical work.  
  
Discussion: https://postgr.es/m/CAEZATCU0zHMDiQV0g8P2U+YSP9C1idUPrn79DajsbonwkN0xvQ@mail.gmail.com  

commit   : 33cd0e5ea65d1fad0a579fa7ef0bab337246c231    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 16:31:44 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 16:31:44 -0400    

Previously the syntax and wording were unclear.  
  
Reported-by: Alexey Bashtanov  
  
Discussion: https://postgr.es/m/968d4724-8e58-788f-7c45-f7b1813824cc@imap.cc  
  
Backpatch-through: 9.5  

commit   : 0936d1b6ffc6d59b4d17f3d6e53c036110c02b44    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Mar 2020 16:09:17 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Mar 2020 16:09:17 -0400    

The stats_ext test is not expecting that autovacuum will touch  
any of its tables; an expectation falsified by commit b07642dbc.  
Although I'm suspicious that there's something else going on that  
makes extended stats estimates not 100% reproducible, it's pretty  
easy to demonstrate that there are places in this test that fail  
if an autovacuum updates the table's stats unexpectedly.  
  
Hence, revert the band-aid changes made by 2dc16efed and 24566b359  
in favor of summarily disabling autovacuum for all the tables that  
this test checks estimated rowcounts for.  
  
Also remove an evidently obsolete comment at the head of the test.  
  
Discussion: https://postgr.es/m/15012.1585623298@sss.pgh.pa.us  

commit   : 69360b34589bd6dbc7bc58dec718f938167f1071    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 31 Mar 2020 16:37:24 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Tue, 31 Mar 2020 16:37:24 -0300    

Use psql's expanded output to avoid a pointless header.  
  
Kyotaro Horiguchi, after an idea of Michael Paquier  
  
Discussion: https://postgr.es/m/20181120050744.GJ4400@paquier.xyz  

commit   : b0236508d3589a45e574284cd3303b689111765d    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Wed, 1 Apr 2020 03:35:13 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Wed, 1 Apr 2020 03:35:13 +0900    

When recovery target is reached and recovery is paused because of  
recovery_target_action=pause, executing pg_wal_replay_resume() causes  
the standby to promote, i.e., the recovery to end. So, in this case,  
the previous message "Execute pg_wal_replay_resume() to continue"  
logged was confusing because pg_wal_replay_resume() doesn't cause  
the recovery to continue.  
  
This commit improves the message logged when recovery is paused,  
and the proper message is output based on what (pg_wal_replay_pause  
or recovery_target_action) causes recovery to be paused.  
  
Author: Sergei Kornilov, revised by Fujii Masao  
Reviewed-by: Robert Haas  
Discussion: https://postgr.es/m/19168211580382043@myt5-b646bde4b8f3.qloud-c.yandex.net  

commit   : 051fd5e0f99b14d7bd76fb800bd077bf394fecd5    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 14:17:32 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 31 Mar 2020 14:17:32 -0400    

This change defines SHLIB_PREREQS for the libpgport dependency, rather  
than using a makefile rule.  This was broken in PG 12.  
  
Reported-by: Filip Janus  
  
Discussion: https://postgr.es/m/E5Dc85EGUY4wyG8cjAU0qoEdCJxGK_qhW1s9qSuYq9A@mail.gmail.com  
  
Author: Dagfinn Ilmari Mannsåker (for libpq)  
  
Backpatch-through: 12  

commit   : 82e801852274e46492b0e160624a850157c677e4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Mar 2020 12:57:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Mar 2020 12:57:55 -0400    

Buildfarm experience shows that this function can fail with ENOENT  
if some other process unlinks a file between when we read the directory  
entry and when we try to stat() it.  The problem is old but we had  
not noticed it until 085b6b667 added regression test coverage.  
  
To fix, just ignore ENOENT failures.  There is one other case that  
this might hide: a symlink that points to nowhere.  That seems okay  
though, at least better than erroring.  
  
Back-patch to v10 where this function was added, since the regression  
test cases were too.  
  
Discussion: https://postgr.es/m/20200308173103.GC1357@telsasoft.com  

commit   : 70dc4c509b330fdd965d795e8d7f41f09d56c9ae    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Mar 2020 11:14:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Mar 2020 11:14:30 -0400    

The existing implementation of the ltree ~ lquery match operator is  
sufficiently complex and undocumented that it's hard to tell exactly  
what it does.  But one thing it clearly gets wrong is the combination  
of NOT symbols (!) and '*' symbols.  A pattern such as '*.!foo.*'  
should, by any ordinary understanding of regular expression behavior,  
match any ltree that has at least one label that's not "foo".  As best  
we can tell by experimentation, what it's actually matching is any  
ltree in which *no* label is "foo".  That's surprising, and not at all  
what the documentation says.  
  
Now, that's arguably a useful behavior, so if we rewrite to fix the  
bug we should provide some other way to get it.  To do so, add the  
ability to attach lquery quantifiers to non-'*' items as well as '*'s.  
Then the pattern '!foo{,}' expresses "any ltree in which no label is  
foo".  For backwards compatibility, the default quantifier for non-'*'  
items has to be "{1}", although the default for '*' items is '{,}'.  
I wouldn't have done it like that in a green field, but it's not  
totally horrible.  
  
Armed with that, rewrite checkCond() from scratch.  Treating '*' and  
non-'*' items alike makes it simpler, not more complicated, so that  
the function actually gets a lot shorter than it was.  
  
Filip Rembiałkowski, Tom Lane, Nikita Glukhov, per a very  
ancient bug report from M. Palm  
  
Discussion: https://postgr.es/m/CAP_rww=waX2Oo6q+MbMSiZ9ktdj6eaJj0cQzNu=Ry2cCDij5fw@mail.gmail.com  

commit   : e07e2a40bd0c3c02a9baf2e5ddccf665e73208fb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Mar 2020 10:30:59 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 31 Mar 2020 10:30:59 -0400    

Ensure that the type name is mentioned in all cases (bare "syntax error"  
isn't that helpful).  Avoid using the term "level", since that's not  
used in the documentation.  Phrase error position reports as "at  
character N" not "in position N"; the latter seems ambiguous, and it's  
certainly not how we say it elsewhere.  For the same reason, make the  
character position values be 1-based not 0-based.  Provide a position  
in more cases.  (I continued to leave that out of messages complaining  
about end-of-input, where it seemed pointless, as well as messages  
complaining about overall input complexity, where fingering any one part  
of the input would be arbitrary.)  
  
Discussion: https://postgr.es/m/15582.1585529626@sss.pgh.pa.us  

commit   : 02a5786df24b12c6379ef1b0375b70b8a9fb4925    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 31 Mar 2020 17:51:57 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 31 Mar 2020 17:51:57 +0300    

This commit improves error reporting introduced by 911e702077.  It puts  
argument of errmsg() to the single line for easier grepping source for error  
text.  Also it improves wording of errhint().  

commit   : 087d3d0583cf292146a7385746d1f5b53eeeaee6    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 31 Mar 2020 16:00:06 +0200    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 31 Mar 2020 16:00:06 +0200    

Author: Daniel Gustafsson <daniel@yesql.se>  

commit   : de3bbfcc962f24c1a20a17b76c604e5973a05817    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 31 Mar 2020 08:40:32 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 31 Mar 2020 08:40:32 +0200    

The original implementation disallowed using OVERRIDING USER VALUE on  
identity columns defined as GENERATED ALWAYS, which is not per  
standard.  So allow that now.  
  
Expand documentation and tests around this.  
  
Author: Dean Rasheed <dean.a.rasheed@gmail.com>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Reviewed-by: Vik Fearing <vik@postgresfriends.org>  
Discussion: https://www.postgresql.org/message-id/flat/CAEZATCVrh2ufCwmzzM%3Dk_OfuLhTTPBJCdFkimst2kry4oHepuQ%40mail.gmail.com  

commit   : 616ae3d2b0566e91b49f301bf08410a9972fed93    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 31 Mar 2020 15:33:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 31 Mar 2020 15:33:04 +0900    

The definitions of the routines defined in xlogarchive.c have been part  
of xlog_internal.h which is included by several frontend tools, but all  
those routines are only called by the backend.  More cleanup could be  
done within xlog_internal.h, but that's already a nice cut.  
  
This will help a follow-up patch for pg_rewind where handling of  
restore_command is added for frontends.  
  
Author: Alexey Kondratov, Michael Paquier  
Reviewed-by: Álvaro Herrera, Alexander Korotkov  
Discussion: https://postgr.es/m/a3acff50-5a0d-9a2c-b3b2-ee36168955c1@postgrespro.ru  

commit   : fc8c3bdde20c4045659f082910cfcbb2b8c9fa4a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 31 Mar 2020 08:25:03 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 31 Mar 2020 08:25:03 +0200    

Set T653 to supported.  This has always been possible.  

commit   : ef75140fe756e6460524b067e063beac109853ec    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Tue, 31 Mar 2020 09:34:49 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Tue, 31 Mar 2020 09:34:49 +0530    

After commit b61d161c14, during vacuum, we cache the information of  
relation name and relation namespace in local structure LVRelStats so that  
we can use it in an error callback function.  We can use the cached  
information to avoid the calls to RelationGetRelationName(),  
RelationGetNamespace() and get_namespace_name().  This is mainly for the  
consistent in vacuum code path but it will avoid the extra syscache lookup  
we do in get_namespace_name().  
  
Author: Justin Pryzby  
Reviewed-by: Amit Kapila  
Discussion: https://www.postgresql.org/message-id/20191120210600.GC30362@telsasoft.com  

commit   : f01157e2ac8ac4dff8ba159c36edf2fdb7d6704e    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 30 Mar 2020 17:34:12 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 30 Mar 2020 17:34:12 -0700    

Commit 7c2dbc69 reorganized _bt_truncate() in a way that enables a  
further simplification that I (pgeoghegan) missed:  Since we mark the  
tuple that is returned to the caller as a pivot tuple before the point  
where its heap TID is set as of 7c2dbc69, it is possible to use the high  
level BTreeTupleGetHeapTID() inline function to get an item pointer.  Do  
it that way now.  This approach is clearer and more maintainable.  

commit   : dd9ac7d5d80608a640bb82cffb6a805ce84cf112    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 31 Mar 2020 08:27:47 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 31 Mar 2020 08:27:47 +0900    

This reverts commit 2aa6e33, that added a fast path to skip  
anti-wraparound and non-aggressive autovacuum jobs (these have no sense  
as anti-wraparound implies aggressive).  With a cluster using a high  
amount of relations with a portion of them being heavily updated, this  
could cause autovacuum to lock down, with autovacuum workers attempting  
repeatedly those jobs on the same relations for the same database, that  
just kept being skipped.  This lock down can be solved with a manual  
VACUUM FREEZE.  
  
Justin King has reported one environment where the issue happened, and  
Julien Rouhaud and I have been able to reproduce it in a second  
environment.  With a very aggressive autovacuum_freeze_max_age,  
triggering those jobs with pgbench is a matter of minutes, and hitting  
the lock down is a lot harder (my local tests failed to do that).  
  
Note that anti-wraparound and non-aggressive jobs can only be triggered  
on a subset of shared catalogs:  
- pg_auth_members  
- pg_authid  
- pg_database  
- pg_replication_origin  
- pg_shseclabel  
- pg_subscription  
- pg_tablespace  
While the lock down was possible down to v12, the root cause of those  
jobs is a much older issue, which needs more analysis.  
  
Bonus thanks to Andres Freund for the discussion.  
  
Reported-by: Justin King  
Discussion: https://postgr.es/m/CAE39h22zPLrkH17GrkDgAYL3kbjvySYD1io+rtnAUFnaJJVS4g@mail.gmail.com  
Backpatch-through: 12  

commit   : 7c2dbc691c3e19b7d33c78f6c8aacc6e0cab510b    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 30 Mar 2020 15:52:39 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 30 Mar 2020 15:52:39 -0700    

Simplify _bt_truncate(), the routine that generates truncated leaf page  
high keys.  Remove a micro-optimization that avoided a second palloc0()  
call (this was used when a heap TID was needed in the final pivot tuple,  
though only when the index happened to not be an INCLUDE index).  
  
Removing this dubious micro-optimization allows _bt_truncate() to use  
the index_truncate_tuple() indextuple.c utility routine in all cases.  
This was already the common case.  
  
This commit is a HEAD-only follow up to bugfix commit 4b42a899.  

commit   : d4b34f60c54904bb3647911dfd9d79d8a4fab430    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 30 Mar 2020 13:51:12 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 30 Mar 2020 13:51:12 -0700    

The recheck isn't needed anymore, as RelationGetBufferForTuple() now  
extends the relation with RBM_ZERO_AND_LOCK. Previously we needed to  
handle the fact that relation extension extended the relation and then  
separately acquired a lock on the page - while expecting that the page  
is empty.  
  
Reported-By: Ranier Vilela  
Discussion: https://postgr.es/m/CAEudQArA_=J0D5T258xsCY6Xtf6wiH4b=QDPDgVS+WZUN10WDw@mail.gmail.com  

commit   : 364bdd0b411343747aeca17708ff7817d7fe0b00    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 30 Mar 2020 23:45:03 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 30 Mar 2020 23:45:03 +0300    

911e702077 misses setting of amoptsprocnum for SP-GiST.  This commit fixes  
that.  

commit   : 851b14b0c69b3773753a3c202bff42c3e4425d8d    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 30 Mar 2020 23:40:22 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 30 Mar 2020 23:40:22 +0300    

Early versions of opclass options patch uses zero support procedure as opclass  
options procedure.  This commit removes rudiments of it, which were committed  
in 911e702077.  Also, it implements correct handling of amoptsprocnum == 0.  

commit   : 4b42a89938ac9d2ec06e9d831356407040e9094c    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 30 Mar 2020 12:03:59 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Mon, 30 Mar 2020 12:03:59 -0700    

INCLUDE indexes failed to have their non-key attributes physically  
truncated away in certain rare cases.  This led to physically larger  
pivot tuples that contained useless non-key attribute values.  The  
impact on users should be negligible, but this is still clearly a  
regression (Postgres 11 supports INCLUDE indexes, and yet was not  
affected).  
  
The bug appeared in commit dd299df8, which introduced "true" suffix  
truncation of key attributes.  
  
Discussion: https://postgr.es/m/CAH2-Wz=E8pkV9ivRSFHtv812H5ckf8s1-yhx61_WrJbKccGcrQ@mail.gmail.com  
Backpatch: 12-, where "true" suffix truncation was introduced.  

commit   : 911e70207703799605f5a0e8aad9f06cff067c63    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 30 Mar 2020 19:17:11 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Mon, 30 Mar 2020 19:17:11 +0300    

PostgreSQL provides set of template index access methods, where opclasses have  
much freedom in the semantics of indexing.  These index AMs are GiST, GIN,  
SP-GiST and BRIN.  There opclasses define representation of keys, operations on  
them and supported search strategies.  So, it's natural that opclasses may be  
faced some tradeoffs, which require user-side decision.  This commit implements  
opclass parameters allowing users to set some values, which tell opclass how to  
index the particular dataset.  
  
This commit doesn't introduce new storage in system catalog.  Instead it uses  
pg_attribute.attoptions, which is used for table column storage options but  
unused for index attributes.  
  
In order to evade changing signature of each opclass support function, we  
implement unified way to pass options to opclass support functions.  Options  
are set to fn_expr as the constant bytea expression.  It's possible due to the  
fact that opclass support functions are executed outside of expressions, so  
fn_expr is unused for them.  
  
This commit comes with some examples of opclass options usage.  We parametrize  
signature length in GiST.  That applies to multiple opclasses: tsvector_ops,  
gist__intbig_ops, gist_ltree_ops, gist__ltree_ops, gist_trgm_ops and  
gist_hstore_ops.  Also we parametrize maximum number of integer ranges for  
gist__int_ops.  However, the main future usage of this feature is expected  
to be json, where users would be able to specify which way to index particular  
json parts.  
  
Catversion is bumped.  
  
Discussion: https://postgr.es/m/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru  
Author: Nikita Glukhov, revised by me  
Reviwed-by: Nikolay Shaplov, Robert Haas, Tom Lane, Tomas Vondra, Alvaro Herrera  

commit   : 1d53432ff940b789c2431ba476a2a6e2db3edf84    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Mar 2020 17:30:44 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Mar 2020 17:30:44 +0200    

The test suites currently don't use Unix-domain sockets on Windows.  
This optionally allows enabling that by setting the environment  
variable PG_TEST_USE_UNIX_SOCKETS.  
  
This should currently be considered experimental.  In particular,  
pg_regress.c contains some comments that the cleanup code for  
Unix-domain sockets doesn't work correctly under Windows, which hasn't  
been an problem until now.  But it's good enough for locally  
supervised testing of the functionality.  
  
Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/54bde68c-d134-4eb8-5bd3-8af33b72a010@2ndquadrant.com  

commit   : 8c49454caa636a02aa37e10b8941b7e67b6954bb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Mar 2020 11:14:58 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Mar 2020 11:14:58 -0400    

GetLocaleInfoEx() can fail on strings that setlocale() was perfectly  
happy with.  A common way for that to happen is if the locale string  
is actually a Unix-style string, say "et_EE.UTF-8".  In that case,  
what's after the dot is an encoding name, not a Windows codepage number;  
blindly treating it as a codepage number led to failure, with a fairly  
silly error message.  Hence, check to see if what's after the dot is  
all digits, and if not, treat it as a literal encoding name rather than  
a codepage number.  This will do the right thing with many Unix-style  
locale strings, and produce a more sensible error message otherwise.  
  
Somewhat independently of that, treat a zero (CP_ACP) result from  
GetLocaleInfoEx() as meaning that we must use UTF-8 encoding.  
  
Back-patch to all supported branches.  
  
Juan José Santamaría Flecha  
  
Discussion: https://postgr.es/m/24905.1585445371@sss.pgh.pa.us  

commit   : 24566b359d095c3800c2a326d88a595722813f58    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Mon, 30 Mar 2020 23:41:11 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Mon, 30 Mar 2020 23:41:11 +1300    

Following up on 2dc16efed, petalura has suffered some additional  
failures in stats_ext which again appear to be around the timing of an  
autovacuum during the test, causing instability in the row estimates.  
  
Again, let's fix this by explicitly performing a VACUUM on the table  
and not leave it to happen by chance of an autovacuum pass.  
  
Discussion: https://postgr.es/m/CAApHDvok5hmXr%2BbUbJe7%2B2sQzWo4B_QzSk7RKFR9fP6BjYXx5g%40mail.gmail.com  

commit   : 64638ccba3a659d8b8a3a4bc5b47307685a64a8a    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Mar 2020 17:35:03 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Mar 2020 17:35:03 +0900    

Previously while the startup process was waiting for the recovery conflict  
with snapshot, tablespace or lock to be resolved, waiting was reported in  
PS display, but not in the case of recovery conflict with buffer pin.  
This commit makes the startup process in hot standby report waiting via PS  
while waiting for the conflicts with other backends holding buffer pins to  
be resolved.  
  
Author: Masahiko Sawada  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/CA+fd4k4mXWTwfQLS3RPwGr4xnfAEs1ysFfgYHvmmoUgv6Zxvmg@mail.gmail.com  

commit   : 246f136e76ecd26844840f2b2057e2c87ec9868d    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Mar 2020 09:19:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Mar 2020 09:19:40 +0200    

When certain parameters are changed on a physical replication primary,  
this is communicated to standbys using the XLOG_PARAMETER_CHANGE WAL  
record.  The standby then checks whether its own settings are at least  
as big as the ones on the primary.  If not, the standby shuts down  
with a fatal error.  
  
The correspondence of settings between primary and standby is required  
because those settings influence certain shared memory sizings that  
are required for processing WAL records that the primary might send.  
For example, if the primary sends a prepared transaction, the standby  
must have had max_prepared_transaction set appropriately or it won't  
be able to process those WAL records.  
  
However, fatally shutting down the standby immediately upon receipt of  
the parameter change record might be a bit of an overreaction.  The  
resources related to those settings are not required immediately at  
that point, and might never be required if the activity on the primary  
does not exhaust all those resources.  If we just let the standby roll  
on with recovery, it will eventually produce an appropriate error when  
those resources are used.  
  
So this patch relaxes this a bit.  Upon receipt of  
XLOG_PARAMETER_CHANGE, we still check the settings but only issue a  
warning and set a global flag if there is a problem.  Then when we  
actually hit the resource issue and the flag was set, we issue another  
warning message with relevant information.  At that point we pause  
recovery, so a hot standby remains usable.  We also repeat the last  
warning message once a minute so it is harder to miss or ignore.  
  
Reviewed-by: Sergei Kornilov <sk@zsrv.org>  
Reviewed-by: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>  
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>  
Discussion: https://www.postgresql.org/message-id/flat/4ad69a4c-cc9b-0dfe-0352-8b1b0cd36c7b@2ndquadrant.com  

commit   : a01e1b8b9d937894a916465643d9707861ffb838    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Mar 2020 08:55:55 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 30 Mar 2020 08:55:55 +0200    

commit   : 6aba63ef3e606db71beb596210dd95fa73c44ce2    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Mar 2020 13:51:05 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Mar 2020 13:51:05 +0900    

This commit adds query_string argument into the planner-related functions  
and hook and allows us to pass the query string to them.  
  
Currently there is no user of the query string passed. But the upcoming patch  
for the planning counters will add the planning hook function into  
pg_stat_statements and the function will need the query string. So this change  
will be necessary for that patch.  
  
Also this change is useful for some extensions that want to use the query  
string in their planner hook function.  
  
Author: Pascal Legrand, Julien Rouhaud  
Reviewed-by: Yoshikazu Imai, Tom Lane, Fujii Masao  
Discussion: https://postgr.es/m/CAOBaU_bU1m3_XF5qKYtSj1ua4dxd=FWDyh2SH4rSJAUUfsGmAQ@mail.gmail.com  
Discussion: https://postgr.es/m/1583789487074-0.post@n3.nabble.com  

commit   : 4a539a25ebfc48329fd656a95f3c1eb2cda38af3    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Mar 2020 12:15:26 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Mon, 30 Mar 2020 12:15:26 +0900    

Previously pg_stat_statements calculated the difference of buffer counters  
by its own code even while BufferUsageAccumDiff() had the same code.  
This commit expose BufferUsageAccumDiff() and makes pg_stat_statements  
use it for the calculation, in order to simply the code.  
  
This change also would be useful for the upcoming patch for the planning  
counters in pg_stat_statements because the patch will add one more code  
for the calculation of difference of buffer counters and that can easily be  
done by using BufferUsageAccumDiff().  
  
Author: Julien Rouhaud  
Reviewed-by: Fujii Masao  
Discussion: https://postgr.es/m/bdfee4e0-a304-2498-8da5-3cb52c0a193e@oss.nttdata.com  

commit   : b61d161c146328ae6ba9ed937862d66e5c8b035a    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 30 Mar 2020 07:33:38 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 30 Mar 2020 07:33:38 +0530    

The additional information displayed will be block number for error  
occurring while processing heap and index name for error occurring  
while processing the index.  
  
This will help us in diagnosing the problems that occur during a vacuum.  
For ex. due to corruption (either caused by bad hardware or by some bug)  
if we get some error while vacuuming, it can help us identify the block  
in heap and or additional index information.  
  
It sets up an error context callback to display additional information  
with the error.  During different phases of vacuum (heap scan, heap  
vacuum, index vacuum, index clean up, heap truncate), we update the error  
context callback to display appropriate information.  We can extend it to  
a bit more granular level like adding the phases for FSM operations or for  
prefetching the blocks while truncating. However, I felt that it requires  
adding many more error callback function calls and can make the code a bit  
complex, so left those for now.  
  
Author: Justin Pryzby, with few changes by Amit Kapila  
Reviewed-by: Alvaro Herrera, Amit Kapila, Andres Freund, Michael Paquier  
and Sawada Masahiko  
Discussion: https://www.postgresql.org/message-id/20191120210600.GC30362@telsasoft.com  

commit   : 2743d9ae4a490a7d96b5c19d50694bd101a87dc8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Mar 2020 19:14:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Mar 2020 19:14:15 -0400    

Add more comments in ltree.h, and correct a misstatement or two.  
  
Use a symbol, rather than hardwired constants, for the maximum length  
of an ltree label.  The max length is still hardwired in the associated  
error messages, but I want to clean that up as part of a separate patch  
to improve the error messages.  

commit   : 122b0ccfef068b0c0c3716c83a93173866e454aa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Mar 2020 18:54:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 29 Mar 2020 18:54:19 -0400    

The documentation says that the max length is 255 bytes, but  
code inspection says it's actually 255 characters; and relevant  
lengths are stored as uint16 so that that works.  

commit   : e1ff780485ca9ff0d2db3cd716b63557fc6ae5e5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Mar 2020 11:13:27 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Mar 2020 11:13:27 +0200    

Add a documentation appendix that explains the PG_COLOR and PG_COLORS  
environment variables.  
  
Discussion: https://www.postgresql.org/message-id/flat/bbdcce43-bd2e-5599-641b-9b44b9e0add4@2ndquadrant.com  

commit   : 9cedb1666051516c2763bb0ae4ace583cd26b141    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Mar 2020 09:25:40 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Mar 2020 09:25:40 +0200    

Put the temporary socket directory under TMPDIR, if that environment  
variable is set, instead of the hardcoded /tmp.  
  
This allows running the tests if there is no /tmp at all (for example  
on Windows, although running the tests with Unix-domain sockets is not  
enabled on Windows yet).  We also use TMPDIR everywhere else /tmp is  
hardcoded, so this makes the behavior consistent.  
  
Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/54bde68c-d134-4eb8-5bd3-8af33b72a010@2ndquadrant.com  

commit   : b79911dc8c0dc3b864999b9a17333716d602c6a0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Mar 2020 08:56:41 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sun, 29 Mar 2020 08:56:41 +0200    

Change F181 to supported.  It requires that an embedded C program can  
be split across multiple files, which ECPG easily supports.  

commit   : 2dc16efedc767aec38368d215eb7695b87a054b5    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sun, 29 Mar 2020 19:36:20 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sun, 29 Mar 2020 19:36:20 +1300    

b07642dbc added code to trigger autovacuums based on the number of  
inserts into a table. This seems to have caused some regression test  
results to destabilize. I suspect this is due to autovacuum triggering a  
vacuum sometime after the test's ANALYZE run and perhaps reltuples is  
ending up being set to a slightly different value as a result.  
  
Attempt to resolve this by running a VACUUM ANALYZE on the affected table  
instead of just ANALYZE. pg_class.reltuples will still get set to whatever  
ANALYZE chooses but we should no longer get the proceeding autovacuum  
overriding that.  
  
The overhead this adds to each test's runtime seems small enough not to  
worry about. I measure 3-4% on stats_ext and can't measure any change in  
partition_aggregate.  
  
I'm unable to recreate the issue locally, so this is a bit of a blind  
fix.  
  
Discussion: https://postgr.es/m/CAApHDvpWmpqYrKwwDQyeDq8dAyK7GMNaxDhrG69CkSuXoEg%2BVg%40mail.gmail.com  

commit   : a7b9d24e4e00048bf9d99b197996476dcf9492de    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 28 Mar 2020 20:25:03 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Sat, 28 Mar 2020 20:25:03 -0700    

Use IndexRelationGetNumberOfKeyAttributes() rather than  
IndexRelationGetNumberOfAttributes() when determining whether or not two  
index tuples are suitable for merging together into a single posting  
list tuple.  This is a little bit tidier.  It brings affected code in  
nbtdedup.c a little closer to similar, related code in nbtsplitloc.c.  

commit   : 9950c8aadf0edd31baec74a729d47d94af636c06    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Mar 2020 18:31:05 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Mar 2020 18:31:05 -0400    

Something like "*{2}.*{3}" should presumably mean the same as  
"*{5}", but it didn't.  Improve that.  
  
Get rid of an undocumented and remarkably ugly (though not, as far as  
I can tell, actually unsafe) static variable in favor of passing more  
arguments to checkCond().  
  
Reverse-engineer some commentary.  This function, like all of ltree,  
is still far short of what I would consider the minimum acceptable  
level of internal documentation, but at least now it has more than  
zero comments.  
  
Although this certainly seems like a bug fix, people might not  
thank us for changing query behavior in stable branches, so  
no back-patch.  
  
Nikita Glukhov, with cosmetic improvements by me  
  
Discussion: https://postgr.es/m/CAP_rww=waX2Oo6q+MbMSiZ9ktdj6eaJj0cQzNu=Ry2cCDij5fw@mail.gmail.com  

commit   : 95f7ddfdad99c5ea0500d90ce52075814e10ed8c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Mar 2020 17:09:51 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 28 Mar 2020 17:09:51 -0400    

These uint16 fields could be overflowed by excessively long input,  
producing strange results.  Complain for invalid input.  
  
Likewise check for out-of-range values of the repeat counts in lquery.  
(We don't try too hard on that one, notably not bothering to detect  
if atoi's result has overflowed.)  
  
Also detect length overflow in ltree_concat.  
  
In passing, be more consistent about whether "syntax error" messages  
include the type name.  Also, clarify the documentation about what  
the size limit is.  
  
This has been broken for a long time, so back-patch to all supported  
branches.  
  
Nikita Glukhov, reviewed by Benjie Gillam and Tomas Vondra  
  
Discussion: https://postgr.es/m/CAP_rww=waX2Oo6q+MbMSiZ9ktdj6eaJj0cQzNu=Ry2cCDij5fw@mail.gmail.com  

commit   : 42750b08d946e2a5048454d7b4e127f0e1df3c65    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Sat, 28 Mar 2020 11:52:11 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Sat, 28 Mar 2020 11:52:11 -0700    

In 9.4 I added support to use a historical snapshot in  
ScanPgRelation(), while adding logical decoding. Unfortunately a  
conflict with the concurrent removal of SnapshotNow was incorrectly  
resolved, leading to an unregistered snapshot being used.  
  
It is not correct to use an unregistered (or non-active) snapshot for  
anything non-trivial, because catalog invalidations can cause the  
snapshot to be invalidated.  
  
Luckily it seems unlikely to actively cause problems in practice, as  
ScanPgRelation() requires that we already have a lock on the relation,  
we only look for a single row, and we don't appear to rely on the  
result's tid to be correct. It however is clearly wrong and potential  
negative consequences would likely be hard to find. So it seems worth  
backpatching the fix, even without a concrete hazard.  
  
Discussion: https://postgr.es/m/20200229052459.wzhqnbhrriezg4v2@alap3.anarazel.de  
Backpatch: 9.5-  

commit   : 7351bfeda33b60b69c15791c7eb77a127546df26    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Sat, 28 Mar 2020 10:53:01 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Sat, 28 Mar 2020 10:53:01 -0700    

Report and suggestions from Richard Guo and Tomas Vondra.  
  
Discussion: https://postgr.es/m/CAMbWs4_W8fYbAn8KxgidAaZHON_Oo08OYn9ze=7remJymLqo5g@mail.gmail.com  

commit   : 4083f445c0cbda2eacb6b17297f9d555397e5eaa    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 28 Mar 2020 14:37:53 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 28 Mar 2020 14:37:53 +0000    

Instead of using Newton's method to compute numeric square roots, use  
the Karatsuba square root algorithm, which performs better for numbers  
of all sizes. In practice, this is 3-5 times faster for inputs with  
just a few digits and up to around 10 times faster for larger inputs.  
  
Also, the new algorithm guarantees that the final digit of the result  
is correctly rounded, since it computes an integer square root with  
truncation, containing at least 1 extra decimal digit before rounding.  
The former algorithm would occasionally round the wrong way because  
it rounded both the intermediate and final results.  
  
In addition, arrange for sqrt_var() to explicitly support negative  
rscale values (rounding before the decimal point). This allows the  
argument reduction phase of ln_var() to be optimised for large inputs,  
since it only needs to compute square roots with a few more digits  
than the final ln() result, rather than computing all the digits  
before the decimal point. For very large inputs, this can be many  
thousands of times faster.  
  
In passing, optimise div_var_fast() in a couple of places where it was  
doing unnecessary work.  
  
Patch be me, reviewed by Tom Lane and Tels.  
  
Discussion: https://postgr.es/m/CAEZATCV1A7+jD3P30Zu31KjaxeSEyOn3v9d6tYegpxcq3cQu-g@mail.gmail.com  

commit   : 8f3ec75de4060d86176ad4ac998eeb87a39748c2    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Mar 2020 13:01:42 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Mar 2020 13:01:42 +0100    

As of Windows 10 version 1803, Unix-domain sockets are supported on  
Windows.  But it's not automatically detected by configure because it  
looks for struct sockaddr_un and Windows doesn't define that.  So we  
just make our own definition on Windows and override the configure  
result.  
  
Set DEFAULT_PGSOCKET_DIR to empty on Windows so by default no  
Unix-domain socket is used, because there is no good standard  
location.  
  
In pg_upgrade, we have to do some extra tweaking to preserve the  
existing behavior of not using Unix-domain sockets on Windows.  Adding  
support would be desirable, but it needs further work, in particular a  
way to select whether to use Unix-domain sockets from the command-line  
or with a run-time test.  
  
The pg_upgrade test script needs a fix.  The previous code passed  
"localhost" to postgres -k, which only happened to work because  
Windows used to ignore the -k argument value altogether.  We instead  
need to pass an empty string to get the desired effect.  
  
The test suites will continue to not use Unix-domain sockets on  
Windows.  This requires a small tweak in pg_regress.c.  The TAP tests  
don't need to be changed because they decide by the operating system  
rather than HAVE_UNIX_SOCKETS.  
  
Reviewed-by: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/54bde68c-d134-4eb8-5bd3-8af33b72a010@2ndquadrant.com  

commit   : 87779aa47463d0fb3b4743a7d5c9534994bf7c98    
  
author   : Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 28 Mar 2020 12:48:34 +0000    
  
committer: Dean Rasheed <dean.a.rasheed@gmail.com>    
date     : Sat, 28 Mar 2020 12:48:34 +0000    

Formerly we applied a functional dependency "a => b with dependency  
degree f" using the formula  
  
  P(a,b) = P(a) * [f + (1-f)*P(b)]  
  
This leads to the possibility that the combined selectivity P(a,b)  
could exceed P(b), which is not ideal. The addition of support for IN  
and OR clauses (commits 8f321bd16c and ccaa3569f5) would seem to make  
this more likely, since the user-supplied values in such clauses are  
not necessarily compatible with the functional dependency.  
  
Mitigate this by using the formula  
  
  P(a,b) = f * Min(P(a), P(b)) + (1-f) * P(a) * P(b)  
  
instead, which guarantees that the combined selectivity is less than  
each column's individual selectivity. Logically, this is modifies the  
part of the formula that accounts for dependent rows to handle cases  
where P(a) > P(b), whilst not changing the second term which accounts  
for independent rows.  
  
Additionally, this refactors the way that functional dependencies are  
applied, so now dependencies_clauselist_selectivity() estimates both  
the implying clauses and the implied clauses for each functional  
dependency (formerly only the implied clauses were estimated), and now  
all clauses for each attribute are taken into account (formerly only  
one clause for each implied attribute was estimated). This removes the  
previously built-in assumption that only equality clauses will be  
seen, which is no longer true, and opens up the possibility of  
applying functional dependencies to more general clauses.  
  
Patch by me, reviewed by Tomas Vondra.  
  
Discussion: https://postgr.es/m/CAEZATCXaNFZyOhR4XXAfkvj1tibRBEjje6ZbXwqWUB_tqbH%3Drw%40mail.gmail.com  
Discussion: https://postgr.es/m/20200318002946.6dvblukm3cfmgir2%40development  

commit   : 145cb16d3bd7d20dbf14507905404aa8153ebf2a    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Mar 2020 08:46:18 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Sat, 28 Mar 2020 08:46:18 +0100    

Feature C011 was still listed in sql_feature_packages.txt but had been  
removed from sql_features.txt, so also remove from the former.  

commit   : b07642dbcd8d5de05f0ee1dbb72dd6760dd30436    
  
author   : David Rowley <drowley@postgresql.org>    
date     : Sat, 28 Mar 2020 19:20:12 +1300    
  
committer: David Rowley <drowley@postgresql.org>    
date     : Sat, 28 Mar 2020 19:20:12 +1300    

Traditionally autovacuum has only ever invoked a worker based on the  
estimated number of dead tuples in a table and for anti-wraparound  
purposes. For the latter, with certain classes of tables such as  
insert-only tables, anti-wraparound vacuums could be the first vacuum that  
the table ever receives. This could often lead to autovacuum workers being  
busy for extended periods of time due to having to potentially freeze  
every page in the table. This could be particularly bad for very large  
tables. New clusters, or recently pg_restored clusters could suffer even  
more as many large tables may have the same relfrozenxid, which could  
result in large numbers of tables requiring an anti-wraparound vacuum all  
at once.  
  
Here we aim to reduce the work required by anti-wraparound and aggressive  
vacuums in general, by triggering autovacuum when the table has received  
enough INSERTs. This is controlled by adding two new GUCs and reloptions;  
autovacuum_vacuum_insert_threshold and  
autovacuum_vacuum_insert_scale_factor. These work exactly the same as the  
existing scale factor and threshold controls, only base themselves off the  
number of inserts since the last vacuum, rather than the number of dead  
tuples. New controls were added rather than reusing the existing  
controls, to allow these new vacuums to be tuned independently and perhaps  
even completely disabled altogether, which can be done by setting  
autovacuum_vacuum_insert_threshold to -1.  
  
We make no attempt to skip index cleanup operations on these vacuums as  
they may trigger for an insert-mostly table which continually doesn't have  
enough dead tuples to trigger an autovacuum for the purpose of removing  
those dead tuples. If we were to skip cleaning the indexes in this case,  
then it is possible for the index(es) to become bloated over time.  
  
There are additional benefits to triggering autovacuums based on inserts,  
as tables which never contain enough dead tuples to trigger an autovacuum  
are now more likely to receive a vacuum, which can mark more of the table  
as "allvisible" and encourage the query planner to make use of Index Only  
Scans.  
  
Currently, we still obey vacuum_freeze_min_age when triggering these new  
autovacuums based on INSERTs. For large insert-only tables, it may be  
beneficial to lower the table's autovacuum_freeze_min_age so that tuples  
are eligible to be frozen sooner. Here we've opted not to zero that for  
these types of vacuums, since the table may just be insert-mostly and we  
may otherwise freeze tuples that are still destined to be updated or  
removed in the near future.  
  
There was some debate to what exactly the new scale factor and threshold  
should default to. For now, these are set to 0.2 and 1000, respectively.  
There may be some motivation to adjust these before the release.  
  
Author: Laurenz Albe, Darafei Praliaskouski  
Reviewed-by: Alvaro Herrera, Masahiko Sawada, Chris Travers, Andres Freund, Justin Pryzby  
Discussion: https://postgr.es/m/CAC8Q8t%2Bj36G_bLF%3D%2B0iMo6jGNWnLnWb1tujXuJr-%2Bx8ZCCTqoQ%40mail.gmail.com  

commit   : 9945ad6e904041be1567a89916ddc64087ed1edc    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 27 Mar 2020 16:44:52 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Fri, 27 Mar 2020 16:44:52 -0700    

Delaying unlocking the right child page until after the point that the  
left child's parent page has been refound is no longer truly necessary.  
Commit 40dae7ec made nbtree tolerant of interrupted page splits.  VACUUM  
was taught to avoid deleting a page that happens to be the right half of  
an incomplete split.  As long as page splits don't unlock the left child  
page until the end of the second/final phase, it should be safe to  
unlock the right child page earlier (at the end of the first phase).  
  
It probably isn't actually useful to release the right child's lock  
earlier like this (it probably won't improve performance).  Even still,  
pointing out that it ought to be safe to do so should make it easier to  
understand the overall design.  

commit   : 1e6148032e4d27aec75c49264b47ad193405a919    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Mar 2020 19:43:41 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Mar 2020 19:43:41 -0300    

The parameters primary_conninfo, primary_slot_name and  
wal_receiver_create_temp_slot can now be changed with a simple "reload"  
signal, no longer requiring a server restart.  This is achieved by  
signalling the walreceiver process to terminate and having it start  
again with the new values.  
  
Thanks to Andres Freund, Kyotaro Horiguchi, Fujii Masao for discussion.  
  
Author: Sergei Kornilov <sk@zsrv.org>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/19513901543181143@sas1-19a94364928d.qloud-c.yandex.net  

commit   : 092c6936de49effe63daad94855bcd8ef26a09dd    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Mar 2020 16:04:52 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 27 Mar 2020 16:04:52 -0300    

Commit 329730827848 gave walreceiver the ability to create and use a  
temporary replication slot, and made it controllable by a GUC (enabled  
by default) that can be changed with SIGHUP.  That's useful but has two  
problems: one, it's possible to cause the origin server to fill its disk  
if the slot doesn't advance in time; and also there's a disconnect  
between state passed down via the startup process and GUCs that  
walreceiver reads directly.  
  
We handle the first problem by setting the option to disabled by  
default.  If the user enables it, its on their head to make sure that  
disk doesn't fill up.  
  
We handle the second problem by passing the flag via startup rather than  
having walreceiver acquire it directly, and making it PGC_POSTMASTER  
(which ensures a walreceiver always has the fresh value).  A future  
commit can relax this (to PGC_SIGHUP again) by having the startup  
process signal walreceiver to shutdown whenever the value changes.  
  
Author: Sergei Kornilov <sk@zsrv.org>  
Reviewed-by: Michael Paquier <michael@paquier.xyz>  
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>  
Discussion: https://postgr.es/m/20200122055510.GH174860@paquier.xyz  

commit   : fbc7a716084ebccd2a996cc415187c269ea54b3e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Mar 2020 14:47:34 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 27 Mar 2020 14:47:34 -0400    

Buildfarm experience shows what probably should've occurred to me before:  
if a cache flush occurs partway through building a generic plan, then  
the plansource may have is_valid = false even though the plan is valid.  
We need to accept this case, use the generated plan, and then try to  
replan the next time.  We can't try to replan immediately, because that  
would produce an infinite loop in CLOBBER_CACHE_ALWAYS builds; moreover  
it's really overkill.  (We can assume that the plan is valid, it's just  
possibly a bit stale.  Note that the pre-existing code behaved this way,  
and the non-simple-expression code paths do too.)  Conversely, not using  
the generated plan would drop us into the not-a-simple-expression code  
path, which is bad for performance and would also cause regression-test  
failures due to visibly different error-reporting behavior.  
  
Hence, refactor the validity-check functions so that the initial check  
and recheck cases can react differently to plansource->is_valid.  
This makes their usage a bit simpler, too.  
  
Discussion: https://postgr.es/m/7072.1585332104@sss.pgh.pa.us  

commit   : 8d1b9648c5861dd14773e551f0b0f37f7ff22820    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 27 Mar 2020 08:36:08 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Fri, 27 Mar 2020 08:36:08 +0100    

Change F311 to supported.  This was already accomplished when  
subfeature F311-04 (WITH CHECK OPTION) was added, but the top-level  
feature wasn't updated at the time.  

commit   : 8f59f6b9c0376173a072e4fb7de1edd6a26e6b52    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Mar 2020 18:58:57 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Mar 2020 18:58:57 -0400    

For relatively simple expressions (say, "x + 1" or "x > 0"), plpgsql's  
management overhead exceeds the cost of evaluating the expression.  
This patch substantially improves that situation, providing roughly  
2X speedup for such trivial expressions.  
  
First, add infrastructure in the plancache to allow fast re-validation  
of cached plans that contain no table access, and hence need no locks.  
Teach plpgsql to use this infrastructure for expressions that it's  
already deemed "simple" (which in particular will never contain table  
references).  
  
The fast path still requires checking that search_path hasn't changed,  
so provide a fast path for OverrideSearchPathMatchesCurrent by  
counting changes that have occurred to the active search path in the  
current session.  This is simplistic but seems enough for now, seeing  
that PushOverrideSearchPath is not used in any performance-critical  
cases.  
  
Second, manage the refcounts on simple expressions' cached plans using  
a transaction-lifespan resource owner, so that we only need to take  
and release an expression's refcount once per transaction not once per  
expression evaluation.  The management of this resource owner exactly  
parallels the existing management of plpgsql's simple-expression EState.  
  
Add some regression tests covering this area, in particular verifying  
that expression caching doesn't break semantics for search_path changes.  
  
Patch by me, but it owes something to previous work by Amit Langote,  
who recognized that getting rid of plancache-related overhead would  
be a useful thing to do here.  Also thanks to Andres Freund for review.  
  
Discussion: https://postgr.es/m/CAFj8pRDRVfLdAxsWeVLzCAbkLFZhW549K+67tpOc-faC8uH8zw@mail.gmail.com  

commit   : 86e5badd22d9ae131a2badb87acdbb20e41811a2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Mar 2020 18:06:55 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 26 Mar 2020 18:06:55 -0400    

plpgsql_xact_cb ought to treat events XACT_EVENT_PARALLEL_COMMIT and  
XACT_EVENT_PARALLEL_ABORT like XACT_EVENT_COMMIT and XACT_EVENT_ABORT  
respectively, since its goal is to do process-local cleanup.  This  
oversight caused plpgsql's end-of-transaction cleanup to not get done  
in parallel workers.  Since a parallel worker will exit just after the  
transaction cleanup, the effects of this are limited.  I couldn't find  
any case in the core code with user-visible effects, but perhaps there  
are some in extensions.  In any case it's wrong, so let's fix it before  
it bites us not after.  
  
In passing, add some comments around the handling of expression  
evaluation resources in DO blocks.  There's no live bug there, but it's  
quite unobvious what's happening; at least I thought so.  This isn't  
related to the other issue, except that I found both things while poking  
at expression-evaluation performance.  
  
Back-patch the plpgsql_xact_cb fix to 9.5 where those event types  
were introduced, and the DO-block commentary to v11 where DO blocks  
gained the ability to issue COMMIT/ROLLBACK.  
  
Discussion: https://postgr.es/m/10353.1585247879@sss.pgh.pa.us  

commit   : eff5b245df259c73d8342e2f04dba5a832d2ea0a    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Thu, 26 Mar 2020 15:05:54 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Thu, 26 Mar 2020 15:05:54 +0100    

Author: Daniel Gustafsson <daniel@yesql.se>  

commit   : 49bf81536e242f079bfbce6e8f95f53f18207dd5    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Mar 2020 11:51:39 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Thu, 26 Mar 2020 11:51:39 +0100    

When SaveSlotToPath() is called with elevel=LOG, the early exits didn't  
release the slot's io_in_progress_lock.  
  
This could result in a walsender being stuck on the lock forever.  A  
possible way to get into this situation is if the offending code paths  
are triggered in a low disk space situation.  
  
Author: Pavan Deolasee <pavan.deolasee@2ndquadrant.com>  
Reported-by: Craig Ringer <craig@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/56a138c5-de61-f553-7e8f-6789296de785%402ndquadrant.com  

commit   : 958aa438aaa473d580f60154786ffd716a28faf2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Mar 2020 22:05:19 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Mar 2020 22:05:19 -0400    

The Makefile should set TAP_TESTS = 1, not implement the infrastructure  
for itself.  For one thing, it missed the appropriate "make clean"  
steps.  For another, the buildfarm isn't running this test because  
it wasn't hooked into "make installcheck" either.  

commit   : e984fb341f293ab21c7d63897357ffca08280268    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 25 Mar 2020 21:14:14 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 25 Mar 2020 21:14:14 -0400    

Commit 896fcdb230 contained an unnecessary setting that listened to  
localhost. Since the test doesn't actually try to make an SSL connection  
to the database this isn't required. Moreover, it's a security hole.  
  
Per gripe from Tom Lane.  

commit   : 13c98bdfc41eefb75da24fd2a886b0ef5314b7f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Mar 2020 19:37:30 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Mar 2020 19:37:30 -0400    

Some platforms require libssl to be linked explicitly in the new  
SSL test module.  Borrow contrib/sslinfo's code for that.  
  
Since src/test/modules/Makefile now has a variable SUBDIRS list,  
it needs to follow the ALWAYS_SUBDIRS protocol for that (cf.  
comments in Makefile.global.in).  
  
Blindly try to fix MSVC build failures by adding PGDLLIMPORT.  

commit   : 896fcdb230e729652d37270c8606ccdc45212f0d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 25 Mar 2020 17:13:17 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Wed, 25 Mar 2020 17:13:17 -0400    

The default hook function sets the default password callback function.  
In order to allow preloaded libraries to have an opportunity to override  
the default, TLS initialization if now delayed slightly until after  
shared preloaded libraries have been loaded.  
  
A test module is provided which contains a trivial example that decodes  
an obfuscated password for an SSL certificate.  
  
Author: Andrew Dunstan  
Reviewed By: Andreas Karlsson, Asaba Takanori  
Discussion: https://postgr.es/m/04116472-818b-5859-1d74-3d995aab2252@2ndQuadrant.com  

commit   : ffd398021c296e55b59ab848ac71a1769ddff93f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Mar 2020 15:14:14 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Mar 2020 15:14:14 -0300    

Some getopt_long implementations don't like to have a non-option  
argument before option arguments, so put the database name as the  
last switch.  
  
Per buildfarm member hoverfly.  

commit   : 2f9eb31320948b968e5f744b73032405e1f25225    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Mar 2020 13:19:31 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 25 Mar 2020 13:19:31 -0300    

The new command-line switch --include-foreign-data=PATTERN lets the user  
specify foreign servers from which to dump foreign table data.  This can  
be refined by further inclusion/exclusion switches, so that the user has  
full control over which tables to dump.  
  
A limitation is that this doesn't work in combination with parallel  
dumps, for implementation reasons.  This might be lifted in the future,  
but requires shuffling some code around.  
  
Author: Luis Carril <luis.carril@swarm64.com>  
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>  
Reviewed-by: Surafel Temesgen <surafel3000@gmail.com>  
Reviewed-by: vignesh C <vignesh21@gmail.com>  
Reviewed-by: Álvaro Herrera <alvherre@2ndQuadrant.com>  
Discussion: https://postgr.es/m/LEJPR01MB0185483C0079D2F651B16231E7FC0@LEJPR01MB0185.DEUPRD01.PROD.OUTLOOK.DE  

commit   : bda6dedbea599209048bc51115ecb2062ceb976c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Mar 2020 11:57:36 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 25 Mar 2020 11:57:36 -0400    

This reverts the parts of commit 17a28b03645e27d73bf69a95d7569b61e58f06eb  
that changed ereport's auxiliary functions from returning dummy integer  
values to returning void.  It turns out that a minority of compilers  
complain (not entirely unreasonably) about constructs such as  
  
	(condition) ? errdetail(...) : 0  
  
if errdetail() returns void rather than int.  We could update those  
call sites to say "(void) 0" perhaps, but the expectation for this  
patch set was that ereport callers would not have to change anything.  
And this aspect of the patch set was already the most invasive and  
least compelling part of it, so let's just drop it.  
  
Per buildfarm.  
  
Discussion: https://postgr.es/m/CA+fd4k6N8EjNvZpM8nme+y+05mz-SM8Z_BgkixzkA34R+ej0Kw@mail.gmail.com  

commit   : f5817595a7f194d25bc9be5b035eb1f7f60cd1fa    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Mar 2020 14:23:25 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Mar 2020 14:23:25 +0100    

It was for unclear reasons defined in a separate location, which makes  
it more cumbersome to override for testing, and it also did not have  
any prominent documentation.  Move to pg_config_manual.h, where  
similar things are already collected.  
  
The previous definition on the command-line had the effect of defining  
it to the value 1, but now that we don't need that anymore we just  
define it to empty, to simplify manual editing a bit.  
  
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>  
Discussion: https://www.postgresql.org/message-id/flat/b7053ba8-b008-5335-31de-2fe4fe41ef0f%402ndquadrant.com  

commit   : e8b1774fc288d7f789a539ef0a768aff2deef600    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Mar 2020 08:46:41 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Wed, 25 Mar 2020 08:46:41 +0100    

The name of E182 was changed in SQL:2011.  
  
Also, we can change it to supported because all it requires is one  
embedded language to be supported, which we do.  

commit   : 352f6f2df60f8725cf6e81141985977d76c169d3    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Mar 2020 15:56:00 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Mar 2020 15:56:00 +1300    

On Vista and later, use GetNLSVersionEx() to request collation version  
information.  
  
Reviewed-by: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>  
Discussion: https://postgr.es/m/CA%2BhUKGJvqup3s%2BJowVTcacZADO6dOhfdBmvOPHLS3KXUJu41Jw%40mail.gmail.com  

commit   : 382a821907e76bf6068492a164fdfc57578391f4    
  
author   : Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Mar 2020 15:53:24 +1300    
  
committer: Thomas Munro <tmunro@postgresql.org>    
date     : Wed, 25 Mar 2020 15:53:24 +1300    

Remove the documented restriction that collation providers must either  
return NULL for all collations or non-NULL for all collations.  
  
Use NULL for glibc collations like "C.UTF-8", which might otherwise lead  
future proposed commits to force unnecessary index rebuilds.  
  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Discussion: https://postgr.es/m/CA%2BhUKGJvqup3s%2BJowVTcacZADO6dOhfdBmvOPHLS3KXUJu41Jw%40mail.gmail.com  

commit   : dd8e19132acfbb28d579288a412ed6c0a5ea338b    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 24 Mar 2020 18:19:51 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 24 Mar 2020 18:19:51 -0700    

Correct oversight in 1f39bce0. If enable_hashagg_disk=true, we should  
consider hash aggregation for DISTINCT when applicable.  

commit   : 3649133b147638f25933c93e3d4f6b920da50332    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 24 Mar 2020 18:19:34 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Tue, 24 Mar 2020 18:19:34 -0700    

If there are no aggregates, there is no need to allocate an array of  
zero AggStatePerGroupData elements.  

commit   : b150a76793109b00ea43c26e0006b3cad9030096    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 24 Mar 2020 14:58:27 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Tue, 24 Mar 2020 14:58:27 -0700    

Descriptions of some aspects of how deduplication works were unclear in  
a couple of places.  

commit   : 112b006fe79b6fe84647df84a07c201e5a7b1635    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Tue, 24 Mar 2020 12:14:18 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Tue, 24 Mar 2020 12:14:18 -0700    

Measurements show, and intuition agrees, that there's currently no  
known cases where adding a fastpath to avoid allocating / ordering a  
heap for a single transaction is worthwhile.  
  
Author: Dilip Kumar  
Discussion: https://postgr.es/m/CAFiTN-sp701wvzvnLQJGk7JDqrFM8f--97-ihbwkU8qvn=p8nw@mail.gmail.com  

commit   : f15ace793578d96d70dad1e613293ae3eab92503    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 19:29:34 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 19:29:34 +0100    

bf68b79e50e3359accc85c94fa23cc03abb9350a introduced an unused variable  
compiler warning on Cygwin.  

commit   : 17a28b03645e27d73bf69a95d7569b61e58f06eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2020 12:08:48 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2020 12:08:48 -0400    

Change all the auxiliary error-reporting routines to return void,  
now that we no longer need to pretend they are passing something  
useful to errfinish().  While this probably doesn't save anything  
significant at the machine-code level, it allows detection of some  
additional types of mistakes.  
  
Pass the error location details (__FILE__, __LINE__, PG_FUNCNAME_MACRO)  
to errfinish not errstart.  This shaves a few cycles off the case where  
errstart decides we're not going to emit anything.  
  
Re-implement elog() as a trivial wrapper around ereport(), removing  
the separate support infrastructure it used to have.  Aside from  
getting rid of some now-surplus code, this means that elog() now  
really does have exactly the same semantics as ereport(), in particular  
that it can skip evaluation work if the message is not to be emitted.  
  
Andres Freund and Tom Lane  
  
Discussion: https://postgr.es/m/CA+fd4k6N8EjNvZpM8nme+y+05mz-SM8Z_BgkixzkA34R+ej0Kw@mail.gmail.com  

commit   : e3a87b4991cc2d00b7a3082abb54c5f12baedfd1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2020 11:48:33 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2020 11:48:33 -0400    

Now that we require C99, we can depend on __VA_ARGS__ to work, and  
revising ereport() to use it has several significant benefits:  
  
* The extra parentheses around the auxiliary function calls are now  
optional.  Aside from being a bit less ugly, this removes a common  
gotcha for new contributors, because in some cases the compiler errors  
you got from forgetting them were unintelligible.  
  
* The auxiliary function calls are now evaluated as a comma expression  
list rather than as extra arguments to errfinish().  This means that  
compilers can be expected to warn about no-op expressions in the list,  
allowing detection of several other common mistakes such as forgetting  
to add errmsg(...) when converting an elog() call to ereport().  
  
* Unlike the situation with extra function arguments, comma expressions  
are guaranteed to be evaluated left-to-right, so this removes platform  
dependency in the order of the auxiliary function calls.  While that  
dependency hasn't caused us big problems in the past, this change does  
allow dropping some rather shaky assumptions around errcontext() domain  
handling.  
  
There's no intention to make wholesale changes of existing ereport  
calls, but as proof-of-concept this patch removes the extra parens  
from a couple of calls in postgres.c.  
  
While new code can be written either way, code intended to be  
back-patched will need to use extra parens for awhile yet.  It seems  
worth back-patching this change into v12, so as to reduce the window  
where we have to be careful about that by one year.  Hence, this patch  
is careful to preserve ABI compatibility; a followup HEAD-only patch  
will make some additional simplifications.  
  
Andres Freund and Tom Lane  
  
Discussion: https://postgr.es/m/CA+fd4k6N8EjNvZpM8nme+y+05mz-SM8Z_BgkixzkA34R+ej0Kw@mail.gmail.com  

commit   : cef27ae01ac872355b2bd56c0882aafe5c6f08de    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 16:01:06 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 16:01:06 +0100    

A variable was unused in non-assert builds.  Simplify the code to  
avoid the issue.  
  
Reported-by: Erik Rijkers <er@xs4all.nl>  

commit   : ab3e4fbd5421e9b3203de9ebf6a741eebab2ab94    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2020 10:27:02 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 24 Mar 2020 10:27:02 -0400    

Sloppiness in commit cedffbdb8, noted by Erikjan Rijkers.  
(It's fairly unfortunate that xmllint doesn't catch this.)  
  
Discussion: https://postgr.es/m/2e3dc9e4bfa4802d2c9f5fe15bde44de@xs4all.nl  

commit   : 97ee604d9bcedf0066986521a7ee15e3aa87be34    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 14:00:58 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 14:00:58 +0100    

This moves the main operations of apply_handle_{insert|update|delete},  
that of inserting, updating, deleting a tuple into/from a given  
relation, into corresponding  
apply_handle_{insert|update|delete}_internal functions.  This allows  
performing those operations on relations that are not directly the  
targets of replication, which is something a later patch will use for  
targeting partitioned tables.  
  
Author: Amit Langote <amitlangote09@gmail.com>  
Reviewed-by: Rafia Sabih <rafia.pghackers@gmail.com>  
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>  
Discussion: https://www.postgresql.org/message-id/flat/CA+HiwqH=Y85vRK3mOdjEkqFK+E=ST=eQiHdpj43L=_eJMOOznQ@mail.gmail.com  

commit   : d40d564c5a920e1121b28463dfed74441cbae5c0    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 08:49:52 +0100    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Tue, 24 Mar 2020 08:49:52 +0100    

It previously only supported NFKC, for use by SASLprep.  This expands  
the API to offer the choice of all four normalization forms.  Right  
now, there are no internal users of the forms other than NFKC.  
  
Reviewed-by: Daniel Verite <daniel@manitou-mail.org>  
Reviewed-by: Andreas Karlsson <andreas@proxel.se>  
Discussion: https://www.postgresql.org/message-id/flat/c1909f27-c269-2ed9-12f8-3ab72c8caf7a@2ndquadrant.com  

commit   : cedffbdb8b137325a79e07a976457bc2314adf9b    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Mar 2020 22:19:56 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Mar 2020 22:19:56 -0700    

Author: Justin Pryzby  
Discussion: https://postgr.es/m/20200321040750.GD13662@telsasoft.com  

commit   : 496ee647ecd2917369ffcf1eaa0b2cdca07c8730    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Mar 2020 12:46:48 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Mar 2020 12:46:48 +0900    

Previously if a promotion was triggered while recovery was paused,  
the paused state continued. Also recovery could be paused by executing  
pg_wal_replay_pause() even while a promotion was ongoing. That is,  
recovery pause had higher priority over a standby promotion.  
But this behavior was not desirable because most users basically wanted  
the recovery to complete as soon as possible and the server to become  
the master when they requested a promotion.  
  
This commit changes recovery so that it prefers a promotion over  
recovery pause. That is, if a promotion is triggered while recovery  
is paused, the paused state ends and a promotion continues. Also  
this commit makes recovery pause functions like pg_wal_replay_pause()  
throw an error if they are executed while a promotion is ongoing.  
  
Internally, this commit adds new internal function PromoteIsTriggered()  
that returns true if a promotion is triggered. Since the name of  
this function and the existing function IsPromoteTriggered() are  
confusingly similar, the commit changes the name of IsPromoteTriggered()  
to IsPromoteSignaled, as more appropriate name.  
  
Author: Fujii Masao  
Reviewed-by: Atsushi Torikoshi, Sergei Kornilov  
Discussion: https://postgr.es/m/00c194b2-dbbb-2e8a-5b39-13f14048ef0a@oss.nttdata.com  

commit   : e09ad07b21a244c3cbcdbe3048e9ab0834ac6d41    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 24 Mar 2020 12:13:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 24 Mar 2020 12:13:36 +0900    

restore_command has only been used until now by the backend, but there  
is a pending patch for pg_rewind to make use of that in the frontend.  
  
Author: Alexey Kondratov  
Reviewed-by: Andrey Borodin, Andres Freund, Alvaro Herrera, Alexander  
Korotkov, Michael Paquier  
Discussion: https://postgr.es/m/a3acff50-5a0d-9a2c-b3b2-ee36168955c1@postgrespro.ru  

commit   : b8e20d6dabdafbe905b62910dc0236037c7881e1    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Mar 2020 11:12:21 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Mar 2020 11:12:21 +0900    

This commit introduces new wait events BackupWaitWalArchive and  
RecoveryPause. The former is reported while waiting for the WAL files  
required for the backup to be successfully archived. The latter is  
reported while waiting for recovery in pause state to be resumed.  
  
Author: Fujii Masao  
Reviewed-by: Michael Paquier, Atsushi Torikoshi, Robert Haas  
Discussion: https://postgr.es/m/f0651f8c-9c96-9f29-0ff9-80414a15308a@oss.nttdata.com  

commit   : 76df765e88fd9016e4b4f75dc69bcd9a1f335f72    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 23 Mar 2020 18:55:12 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 23 Mar 2020 18:55:12 -0700    

Discussion: https://postgr.es/m/23196.1584943506@sss.pgh.pa.us  

commit   : 67e0adfb3f98f1e4a89a32b6f2e59774ce579146    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Mar 2020 10:43:41 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Tue, 24 Mar 2020 10:43:41 +0900    

Previously 0 was reported in pg_stat_progress_basebackup.total_backup  
if the total backup size was not estimated. Per discussion, our consensus  
is that NULL is better choise as the value in total_backup in that case.  
So this commit makes pg_stat_progress_basebackup view report NULL  
in total_backup column if the estimation is disabled.  
  
Bump catversion.  
  
Author: Fujii Masao  
Reviewed-by: Amit Langote, Magnus Hagander, Alvaro Herrera  
Discussion: https://postgr.es/m/CABUevExnhOD89zBDuPvfAAh243RzNpwCPEWNLtMYpKHMB8gbAQ@mail.gmail.com  

commit   : 64fe6022790920ef6edee475bfa162a961f148d8    
  
author   : Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 23 Mar 2020 13:56:28 -0700    
  
committer: Jeff Davis <jdavis@postgresql.org>    
date     : Mon, 23 Mar 2020 13:56:28 -0700    

Justin Pryzby raised a couple issues with commit 1f39bce0. Fixed.  
  
Also, tweak the way the size of a hash entry is estimated and the  
number of buckets is estimated when calling BuildTupleHashTableExt().  
  
Discussion: https://www.postgresql.org/message-id/20200319064222.GR26184@telsasoft.com  

commit   : 0830d21f5b01064837dc8bd910ab31a5b7a1101a    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Mon, 23 Mar 2020 18:38:42 -0400    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Mon, 23 Mar 2020 18:38:42 -0400    

backend_type was added to the CVS log output in commit 70a7b4776b.  
  
Reported-by: Fabrízio de Royes Mello  
  
Discussion: https://postgr.es/m/CAFcNs+ruvRks3BV1j7yQ-MvxsswmKJa0cVh2yK5Dd-xXVM8wPw@mail.gmail.com  
  
Backpatch-through: master  

commit   : f801ceb696b4a865ef80fd29c9df880280472e03    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Mar 2020 14:48:19 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Mon, 23 Mar 2020 14:48:19 -0700    

While #16293 only applied to 11 (and 10 to some degree), it seems best  
to add tests to all branches with partitioning support.  
  
Reported-By: Daniel WM  
Author: Andres Freund  
Bug: #16293  
Discussion: https://postgr.es/m/16293-26f5777d10143a66@postgresql.org  
Backpatch: 10-  

commit   : 0df94beb362e0ebc812170fbabd1aaf75136831a    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 24 Mar 2020 00:54:33 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Tue, 24 Mar 2020 00:54:33 +0300    

commit   : fe604800681aed8228fbe67d2e175d6822c66ea2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Mar 2020 12:42:15 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Mar 2020 12:42:15 -0400    

This wasn't stated anywhere, and it's perhaps not that obvious,  
since we get questions about it from time to time.  Also undocumented  
was that the parser actually translates these into operators.  
  
Discussion: https://postgr.es/m/CAFj8pRBkvZ71BqGKZnBBG4=0cKG+s50Dy+DYmrizUKEpAtdc+w@mail.gmail.com  

commit   : 980a70b9763e330dab6d0eb994c96a007876e40e    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Mar 2020 11:58:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Mar 2020 11:58:00 -0400    

src/port/getopt_long.c failed on such an argument, always seeing it  
as an unrecognized switch.  This is unhelpful; better is to treat such  
an item as a non-switch argument.  That behavior is what we find in  
GNU's getopt_long(); it's what src/port/getopt.c does; and it is  
required by POSIX for getopt(), which getopt_long() ought to be  
generally a superset of.  Moreover, it's expected by ecpg, which  
intends an argument of "-" to mean "read from stdin".  So fix it.  
  
Also add some documentation about ecpg's behavior in this area, since  
that was miserably underdocumented.  I had to reverse-engineer it  
from the code.  
  
Per bug #16304 from James Gray.  Back-patch to all supported branches,  
since this has been broken forever.  
  
Discussion: https://postgr.es/m/16304-c662b00a1322db7f@postgresql.org  

commit   : c81bd3b9a5e99315148f4f5714c32e633af30123    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Mar 2020 13:38:03 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Mar 2020 13:38:03 +0900    

autovacuum_vacuum_scale_factor and autovacuum_analyze_scale_factor have  
been documented as "float4", but "floating type" is used in this case  
for GUCs and relation options in the documentation.  
  
Author: Atsushi Torikoshi  
Discussion: https://postgr.es/m/CACZ0uYFf_p9BpbjLccx3CA=eM1Hk2Te=ULY4iptGLUhL-JxCPA@mail.gmail.com  
Backpatch-through: 9.5  

commit   : faa650a99b4bfbe95e88f44070ae0df1818944a7    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Mar 2020 12:52:37 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Mar 2020 12:52:37 +0900    

This reverts commit b7f64c6, which broke the fallback implementation for  
C++.  We have discussed a couple of alternatives to reduce the number of  
implementations for those asserts, but nothing allowing to reduce the  
number of implementations down to three instead of four, so there is no  
benefit in keeping this patch.  
  
Thanks to Tom Lane for the discussion.  
  
Discussion: https://postgr.es/m/20200313115033.GA183471@paquier.xyz  

commit   : 33753ac9d7bc83dd9ccee9d5e678ed78a0725b4e    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Mon, 23 Mar 2020 08:09:15 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Mon, 23 Mar 2020 08:09:15 +0530    

All errors of SQLSTATE class 23 should include the name of an object  
associated with the error in separate fields of the error report message.  
We do this so that applications need not try to extract them from the  
possibly-localized human-readable text of the message.  
  
Reported-by: Chris Bandy  
Author: Chris Bandy  
Reviewed-by: Amit Kapila and Amit Langote  
Discussion: https://postgr.es/m/0aa113a3-3c7f-db48-bcd8-f9290b2269ae@gmail.com  

commit   : 79dfa8afb296e1b0dcffbe674e04c5f25cc13dfd    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Mar 2020 11:01:41 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 23 Mar 2020 11:01:41 +0900    

Mixing incorrect bounds in the SSL context leads to confusing error  
messages generated by OpenSSL which are hard to act on.  New range  
checks are added when both min/max parameters are loaded in the context  
of a SSL reload to improve the error reporting.  Note that this does not  
make use of the GUC hook machinery contrary to 41aadee, as there is no  
way to ensure a consistent range check (except if there is a way one day  
to define range types for GUC parameters?).  Hence, this patch applies  
only to OpenSSL, and uses a logic similar to other parameters to trigger  
an error when reloading the SSL context in a session.  
  
Author: Michael Paquier  
Reviewed-by: Daniel Gustafsson  
Discussion: https://postgr.es/m/20200114035420.GE1515@paquier.xyz  

commit   : de9396326edcbe5cafc06a72016f9d715c350e0e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sun, 22 Mar 2020 09:24:09 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sun, 22 Mar 2020 09:24:09 -0700    

This reverts commit cb2fd7eac285b1b0a24eeb2b8ed4456b66c5a09f.  Per  
numerous buildfarm members, it was incompatible with parallel query, and  
a test case assumed LP64.  Back-patch to 9.5 (all supported versions).  
  
Discussion: https://postgr.es/m/20200321224920.GB1763544@rfd.leadboat.com  

commit   : d0587f52b3bb898db3c0011954de6ae9adc076c8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Mar 2020 18:28:44 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 21 Mar 2020 18:28:44 -0400    

headerscheck and cpluspluscheck should skip the recently-added  
cmdtaglist.h header, since (like kwlist.h and some other similarly-  
designed headers) it's not meant to be included standalone.  
  
evtcache.h was missing an #include to support its usage of Bitmapset.  
  
typecmds.h was missing an #include to support its usage of ParseState.  
  
The first two of these were evidently oversights in commit 2f9661311.  
I didn't track down exactly which change broke typecmds.h, but it  
must have been some rearrangement in one of its existing inclusions,  
because it's referenced ParseState for quite a long time and there  
were not complaints from these checking programs before.  

commit   : cb2fd7eac285b1b0a24eeb2b8ed4456b66c5a09f    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    

Until now, only selected bulk operations (e.g. COPY) did this.  If a  
given relfilenode received both a WAL-skipping COPY and a WAL-logged  
operation (e.g. INSERT), recovery could lose tuples from the COPY.  See  
src/backend/access/transam/README section "Skipping WAL for New  
RelFileNode" for the new coding rules.  Maintainers of table access  
methods should examine that section.  
  
To maintain data durability, just before commit, we choose between an  
fsync of the relfilenode and copying its contents to WAL.  A new GUC,  
wal_skip_threshold, guides that choice.  If this change slows a workload  
that creates small, permanent relfilenodes under wal_level=minimal, try  
adjusting wal_skip_threshold.  Users setting a timeout on COMMIT may  
need to adjust that timeout, and log_min_duration_statement analysis  
will reflect time consumption moving to COMMIT from commands like COPY.  
  
Internally, this requires a reliable determination of whether  
RollbackAndReleaseCurrentSubTransaction() would unlink a relation's  
current relfilenode.  Introduce rd_firstRelfilenodeSubid.  Amend the  
specification of rd_createSubid such that the field is zero when a new  
rel has an old rd_node.  Make relcache.c retain entries for certain  
dropped relations until end of transaction.  
  
Back-patch to 9.5 (all supported versions).  This introduces a new WAL  
record type, XLOG_GIST_ASSIGN_LSN, without bumping XLOG_PAGE_MAGIC.  As  
always, update standby systems before master systems.  This changes  
sizeof(RelationData) and sizeof(IndexStmt), breaking binary  
compatibility for affected extensions.  (The most recent commit to  
affect the same class of extensions was  
089e4d405d0f3b94c74a2c6a54357a84a681754b.)  
  
Kyotaro Horiguchi, reviewed (in earlier, similar versions) by Robert  
Haas.  Heikki Linnakangas and Michael Paquier implemented earlier  
designs that materially clarified the problem.  Reviewed, in earlier  
designs, by Andrew Dunstan, Andres Freund, Alvaro Herrera, Tom Lane,  
Fujii Masao, and Simon Riggs.  Reported by Martijn van Oosterhout.  
  
Discussion: https://postgr.es/m/20150702220524.GA9392@svana.org  

commit   : d3e572855be1e15c7e0a6adc8db52b9fd4f71be0    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    

The function assumed forkNum=MAIN_FORKNUM and page_std=true, ignoring  
the actual arguments.  Existing callers passed exactly those values, so  
there's no live bug.  Back-patch to v12, where the function first  
appeared, because another fix needs this.  
  
Discussion: https://postgr.es/m/20191118045434.GA1173436@rfd.leadboat.com  

commit   : e629a01f6973688f77ecff964d9d6bea9bc4b374    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Sat, 21 Mar 2020 09:38:26 -0700    

swap_relation_files() calls toast_get_valid_index() to find and lock  
this index, just before swapping with the rebuilt TOAST index.  The  
latter function releases the lock before returning.  Potential for  
mischief is low; a concurrent session can issue ALTER INDEX ... SET  
(fillfactor = ...), which is not alarming.  Nonetheless, changing  
pg_class.relfilenode without a lock is unconventional.  Back-patch to  
9.5 (all supported versions), because another fix needs this.  
  
Discussion: https://postgr.es/m/20191226001521.GA1772687@rfd.leadboat.com