PostgreSQL 10.11 (upcoming) commit log

For PowerPC instruction "addi", use constraint "b".

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

Click here for diff

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

M src/include/storage/s_lock.h

Fix failure of archive recovery with recovery_min_apply_delay enabled.

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

Click here for diff

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

M src/backend/access/transam/xlog.c

Fix timeout handling in logical replication worker

commit   : 47698b4b62e3b7aad7e35d86b7ccdaa62799b435    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 18 Oct 2019 14:27:04 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 18 Oct 2019 14:27:04 +0900    

Click here for diff

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

M src/backend/replication/logical/worker.c

Fix minor bug in logical-replication walsender shutdown

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

Click here for diff

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

M src/backend/replication/walsender.c

When restoring GUCs in parallel workers, show an error context.

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

Click here for diff

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

M src/backend/utils/misc/guc.c

Fix bug that could try to freeze running multixacts.

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

Click here for diff

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

M src/backend/commands/vacuum.c

Improve the check for pg_catalog.unknown data type in pg_upgrade

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

Click here for diff

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

M src/bin/pg_upgrade/version.c

Improve the check for pg_catalog.line data type in pg_upgrade

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

Click here for diff

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

M src/bin/pg_upgrade/version.c

Doc: Fix various inconsistencies

commit   : c0e5df9b2595eef89a756e76d742fc06b3469524    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 16 Oct 2019 13:10:49 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 16 Oct 2019 13:10:49 +0900    

Click here for diff

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

M doc/src/sgml/extend.sgml
M doc/src/sgml/ref/copy.sgml
M doc/src/sgml/ref/set_role.sgml

AIX: Stop adding option -qsrcmsg.

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

Click here for diff

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

M src/template/aix

Flush logical mapping files with fd opened for read/write at checkpoint

commit   : fbfc835b463af02c70ba19eae8897780ee807055    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Oct 2019 13:31:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 9 Oct 2019 13:31:22 +0900    

Click here for diff

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

M src/backend/access/heap/rewriteheap.c

docs: Improve A?synchronous Multimaster Replication descr.

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

Click here for diff

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

M doc/src/sgml/high-availability.sgml

docs: clarify that today/tomorrow/yesterday is at 00:00

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

Click here for diff

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

M doc/src/sgml/datatype.sgml

doc: move mention of log_min_error_statement in a better spot

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

Click here for diff

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

M doc/src/sgml/config.sgml

Check for too many postmaster children before spawning a bgworker.

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

Click here for diff

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

M src/backend/postmaster/postmaster.c

Report test_atomic_ops() failures consistently, via macros.

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

Click here for diff

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

M src/test/regress/regress.c

Avoid use of wildcard in pg_waldump's .gitignore.

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

Click here for diff

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

M src/bin/pg_waldump/.gitignore

Disable one more set of tests from c8841199509.

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

Click here for diff

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

M src/test/isolation/expected/eval-plan-qual-trigger.out
M src/test/isolation/specs/eval-plan-qual-trigger.spec

Disable one set of tests from c8841199509.

commit   : 81b8cd5ed7c067089db214ee0fe6e756af398def    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 4 Oct 2019 21:38:08 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 4 Oct 2019 21:38:08 -0700    

Click here for diff

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

M src/test/isolation/expected/eval-plan-qual-trigger.out
M src/test/isolation/specs/eval-plan-qual-trigger.spec

Add isolation tests for the combination of EPQ and triggers.

commit   : 95266e64c5b7aff3c7151d2875446eae94e467b7    
  
author   : Andres Freund <andres@anarazel.de>    
date     : Fri, 4 Oct 2019 14:01:35 -0700    
  
committer: Andres Freund <andres@anarazel.de>    
date     : Fri, 4 Oct 2019 14:01:35 -0700    

Click here for diff

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

A src/test/isolation/expected/eval-plan-qual-trigger.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/eval-plan-qual-trigger.spec

Handle spaces in OpenSSL install location for MSVC

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

Click here for diff

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

M src/tools/msvc/Project.pm
M src/tools/msvc/Solution.pm

Fix bitshiftright()'s zero-padding some more.

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

Click here for diff

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

M src/backend/utils/adt/varbit.c
M src/test/regress/expected/bit.out
M src/test/regress/sql/bit.sql

Avoid unnecessary out-of-memory errors during encoding conversion.

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

Click here for diff

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

M src/backend/utils/mb/mbutils.c

Allow repalloc() to give back space when a large chunk is downsized.

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

Click here for diff

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

M src/backend/utils/mmgr/aset.c

Selectively include window frames in expression walks/mutates.

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

Click here for diff

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

M src/backend/catalog/dependency.c
M src/backend/nodes/nodeFuncs.c
M src/include/nodes/nodeFuncs.h
M src/test/regress/expected/window.out
M src/test/regress/sql/window.sql

Remove temporary WAL and history files at the end of archive recovery

commit   : 7ca35472cbf36bb822fe56b40cd5af1031e5081a    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Oct 2019 15:54:01 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 2 Oct 2019 15:54:01 +0900    

Click here for diff

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

M src/backend/access/transam/xlog.c
M src/test/recovery/t/002_archiving.pl

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

Click here for diff

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

M doc/src/sgml/func.sgml

Fix oversight in commit 4429f6a9e3e12bb4af6e3677fbc78cd80f160252.

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

Click here for diff

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

M src/test/regress/expected/rangetypes.out
M src/test/regress/sql/rangetypes.sql

Fix failure with lock mode used for custom relation options

commit   : d4816800378452e125d4e1ca7dfdb598609ab992    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 10:08:36 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 25 Sep 2019 10:08:36 +0900    

Click here for diff

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

M contrib/bloom/expected/bloom.out
M contrib/bloom/sql/bloom.sql
M src/backend/access/common/reloptions.c

Doc: clarify handling of duplicate elements in array containment tests.

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

Click here for diff

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

M doc/src/sgml/func.sgml

Fix failure to zero-pad the result of bitshiftright().

commit   : 096d34c3ba78fa56eb3ceb766f159b0fbf11adec    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Sep 2019 17:46:00 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 22 Sep 2019 17:46:00 -0400    

Click here for diff

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

M src/backend/utils/adt/varbit.c
M src/include/utils/varbit.h
M src/test/regress/expected/bit.out
M src/test/regress/sql/bit.sql

Update time zone data files to tzdata release 2019c.

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

Click here for diff

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

M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt

Fix typo in commit 82fa3ff8672.

commit   : fea48c57b86584760a1e92bb773e082b7171d231    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Fri, 20 Sep 2019 08:05:54 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Fri, 20 Sep 2019 08:05:54 +0530    

Click here for diff

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

M doc/src/sgml/maintenance.sgml

Fix oversight in backpatch of 6cae9d2c10

commit   : 2f0434e8e96f8850705fbd46a12fb5286cf8922a    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 19 Sep 2019 23:36:01 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 19 Sep 2019 23:36:01 +0300    

Click here for diff

During backpatch of 6cae9d2c10 Float8GetDatum() was accidentally removed.  This  
commit turns it back.  
  
Reported-by: Erik Rijkers  
Discussion: https://postgr.es/m/6d51305e1159241cabee132f7efc7eff%40xs4all.nl  
Author: Tom Lane  
Backpatch-through: from 11 to 9.5  

M src/backend/access/gist/gistget.c

Improve handling of NULLs in KNN-GiST and KNN-SP-GiST

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

Click here for diff

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

M src/backend/access/gist/gistget.c
M src/backend/access/gist/gistscan.c
M src/include/access/genam.h
M src/include/access/gist_private.h
M src/tools/pgindent/typedefs.list

Doc: Fix incorrect mention to connection_object in CONNECT command of ECPG

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

Click here for diff

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

M doc/src/sgml/ecpg.sgml

Doc: document autovacuum interruption.

commit   : 4a9b83e1cdaf811d659dffcbe7dff7ddb479e014    
  
author   : Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Sep 2019 08:41:05 +0530    
  
committer: Amit Kapila <akapila@postgresql.org>    
date     : Thu, 19 Sep 2019 08:41:05 +0530    

Click here for diff

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

M doc/src/sgml/maintenance.sgml

pg_upgrade/test.sh: Quote sed(1) argument

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

Click here for diff

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

M src/bin/pg_upgrade/test.sh

Doc: Update FDW documentation about direct foreign table modification.

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

Click here for diff

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

M doc/src/sgml/fdwhandler.sgml

Replace xlc __fetch_and_add() with inline asm.

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

Click here for diff

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

M src/include/port/atomics/generic-xlc.h

Test pg_atomic_fetch_add_ with variable addend and 16-bit edge cases.

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

Click here for diff

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

M src/test/regress/regress.c

logical decoding: process ASSIGNMENT during snapshot build

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

Click here for diff

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

M src/backend/replication/logical/decode.c

Fix under-parenthesized macro definitions

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

Click here for diff

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

M src/include/nodes/parsenodes.h

Fix nbtree page split rmgr desc routine.

commit   : 09b236af90befd9e0342040a1503776cee76eccc    
  
author   : Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 15:45:03 -0700    
  
committer: Peter Geoghegan <pg@bowt.ie>    
date     : Thu, 12 Sep 2019 15:45:03 -0700    

Click here for diff

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

M src/backend/access/rmgrdesc/nbtdesc.c
M src/include/access/nbtxlog.h

Fix usage of whole-row variables in WCO and RLS policy expressions.

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

Click here for diff

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

M src/backend/executor/nodeModifyTable.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/rowsecurity.sql

Improve documentation about our XML functionality

commit   : 603a28b4497347bc0a4ff1dbea3bb6d1e04d740c    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Sep 2019 16:52:03 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 12 Sep 2019 16:52:03 -0300    

Click here for diff

Add a section explaining how our XML features depart from current  
versions of the SQL standard.  Update and clarify the descriptions  
of some XML functions.  
  
This is a backpatch for branches 10 and 11, taken from Tom's commit  
12d46ac392d0 for 12, then edited to correctly describe behaviors that  
are fixed in 12 but still broken in 10 and 11.  
  
Chapman Flack, reviewed by Ryan Lambert  
  
Discussion: https://postgr.es/m/5BD1284C.1010305@anastigmatix.net  
Discussion: https://postgr.es/m/5C81F8C0.6090901@anastigmatix.net  
Discussion: https://postgr.es/m/CAN-V+g-6JqUQEQZ55Q3toXEN6d5Ez5uvzL4VR+8KtvJKj31taw@mail.gmail.com  

M doc/src/sgml/datatype.sgml
M doc/src/sgml/features.sgml
M doc/src/sgml/func.sgml
M src/backend/catalog/sql_features.txt

Remove pg_trgm.strict_word_similarity_threshold doc from 9.6 and 10

commit   : 0a8cd4c2962404f167547e79768db79f5f710f81    
  
author   : Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 12 Sep 2019 16:15:08 +0300    
  
committer: Alexander Korotkov <akorotkov@postgresql.org>    
date     : Thu, 12 Sep 2019 16:15:08 +0300    

Click here for diff

9ee98cc3f added missing doc for pg_trgm.strict_word_similarity_threshold GUC.  
But it was accidentally backpatched to 9.6, while this GUC was introduced only  
in 11.  This patch removes extra doc from 9.6 and 10.  
  
Discussion: https://postgr.es/m/CAHE3wghn%3DRyPWY-nxX1SiYAfkuwLHMd9Z4r8v9ww_jSs1jF5pg%40mail.gmail.com  
Author: Euler Taveira  
Backpatch-through: 9.6 and 10  

M doc/src/sgml/pgtrgm.sgml

Doc: Update PL/pgSQL sample function in plpgsql.sgml.

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

Click here for diff

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

M doc/src/sgml/plpgsql.sgml

Expand properly list of TAP tests used for prove in vcregress.pl

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

Click here for diff

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

M src/tools/msvc/vcregress.pl

Sync isolationtester's handling of notice/warning messages with HEAD.

commit   : 2e6f972674780d202971c1bf98448fdee9e39a81    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Sep 2019 12:45:32 -0400    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Sep 2019 12:45:32 -0400    

Click here for diff

Back-patch relevant parts of these commits:  
30717637c Fix isolationtester race condition for notices sent before blocking  
ebd499282 Don't drop NOTICE messages in isolation tests  
a28e10e82 Indicate session name in isolationtester notices  
  
This ensures that older versions of the isolationtester will handle  
NOTICE/WARNING messages the same way as HEAD and v12 do.  While this  
isn't fixing any critical problem right now, it seems like a prudent  
change to prevent surprises (like we had yesterday...) with  
back-patches of future isolation test changes.  
  
Back-patch as far as 9.6.  Due to the significant changes we made in  
isolationtester in 9.6, back-patching isolation tests further than  
that is going to be risky anyway; besides, this patch doesn't apply  
cleanly before that.  
  
Discussion: https://postgr.es/m/E1i7IqC-0000Uc-5H@gemulon.postgresql.org  

M src/test/isolation/expected/insert-conflict-specconflict.out
M src/test/isolation/isolationtester.c

Prevent msys2 conversion of "cmd /c" switch to a file path

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

Click here for diff

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

M src/bin/pg_upgrade/test.sh

Always skip recovery SysV shared memory tests on Windows

commit   : d0a98e1ae26c46d6949e06136bfcbd7fb4cdb111    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Sep 2019 08:42:06 -0400    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 9 Sep 2019 08:42:06 -0400    

Click here for diff

These tests were disabled on git master in commit 8e5ce1c3f8. This does  
the same thing on the back branches.  
  
Discussion: https://postgr.es/m/a1c40fab-a38c-cb42-6879-125f834e837b@2ndQuadrant.com  

M src/test/recovery/t/017_shm.pl

Fix RelationIdGetRelation calls that weren't bothering with error checks.

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

Click here for diff

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

M src/backend/access/heap/heapam.c
M src/backend/replication/logical/reorderbuffer.c

Fix handling of NULL distances in KNN-GiST

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

Click here for diff

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

M src/backend/access/gist/gistget.c
M src/backend/access/gist/gistscan.c
M src/include/access/gist_private.h

Fix handling Inf and Nan values in GiST pairing heap comparator

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

Click here for diff

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

M src/backend/access/gist/gistscan.c

doc: Fix awkward markup

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

Click here for diff

M doc/src/sgml/ref/pg_dumpall.sgml

When performing a base backup, check for read errors.

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

Click here for diff

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

M src/backend/replication/basebackup.c

Fix thinko when ending progress report for a backend

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

Click here for diff

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

M src/backend/postmaster/pgstat.c

Delay fsyncs of pg_basebackup until the end of backup

commit   : dbbae33bcd3357f4dd880f9214c18e0ed2c92c49    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 13:24:12 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 4 Sep 2019 13:24:12 +0900    

Click here for diff

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

M src/bin/pg_basebackup/pg_basebackup.c

Fix memory leak with lower, upper and initcap with ICU-provided collations

commit   : 604d20679e20c72a36ba267e67bec356a79d8448    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Sep 2019 12:31:14 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 3 Sep 2019 12:31:14 +0900    

Click here for diff

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

M src/backend/utils/adt/formatting.c

Handle corner cases correctly in psql's reconnection logic.

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

Click here for diff

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

M src/bin/psql/command.c
M src/bin/psql/common.c

Doc: describe the "options" allowed in an ECPG connection target string.

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

Click here for diff

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

M doc/src/sgml/ecpg.sgml

Fix overflow check and comment in GIN posting list encoding.

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

Click here for diff

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

M src/backend/access/gin/ginpostinglist.c

Avoid catalog lookups in RelationAllowsEarlyPruning().

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

Click here for diff

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

M src/backend/utils/cache/relcache.c
M src/include/utils/rel.h
M src/include/utils/snapmgr.h

Disable timeouts when running pg_rewind with online source cluster

commit   : 19bfa15a8274a8429883d08ab4c5b3881ac65f07    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Aug 2019 11:48:23 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 28 Aug 2019 11:48:23 +0900    

Click here for diff

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

M src/bin/pg_rewind/libpq_fetch.c

Doc: improve documentation of pg_signal_backend default role.

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

Click here for diff

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

M doc/src/sgml/user-manag.sgml

Doc: clarify behavior of standard aggregates for null inputs.

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

Click here for diff

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

M doc/src/sgml/func.sgml

Reject empty names and recursion in config-file include directives.

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

Click here for diff

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

M src/backend/utils/misc/guc-file.l
M src/backend/utils/misc/postgresql.conf.sample

Fix failure of --jobs with vacuumdb on Windows

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

Click here for diff

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

M src/bin/scripts/vacuumdb.c

Adjust to latest Msys2 kernel release number

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

Click here for diff

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

M src/bin/pg_dump/t/010_dump_connstr.pl

Treat MINGW and MSYS the same in pg_upgrade test script

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

Click here for diff

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

M src/bin/pg_upgrade/test.sh

Fix error handling of vacuumdb when running out of fds

commit   : 4fca1460099eb2269d63c05b85e07f79e6efa1a6    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Aug 2019 11:14:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Mon, 26 Aug 2019 11:14:33 +0900    

Click here for diff

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

M src/bin/scripts/vacuumdb.c

Avoid platform-specific null pointer dereference in psql.

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

Click here for diff

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

M src/bin/psql/startup.c

Improve documentation of pageinspect

commit   : 1fb2d78cb94672f4cfc0c1a2da9e0a534e3698f2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Aug 2019 20:41:22 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Fri, 23 Aug 2019 20:41:22 +0900    

Click here for diff

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

M doc/src/sgml/pageinspect.sgml

Doc: Remove mention to "Visual Studio Express 2019"

commit   : 73ef3df16dfa8d8a85dc16bcc515ce131fef9540    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Aug 2019 09:59:33 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Thu, 22 Aug 2019 09:59:33 +0900    

Click here for diff

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

M doc/src/sgml/install-windows.sgml

Fix typo

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

Click here for diff

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

M src/backend/replication/logical/origin.c
M src/include/catalog/pg_proc.h

Fix bogus comment

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

Click here for diff

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

M src/backend/access/heap/heapam.c

Doc: Fix various typos

commit   : 15ae1a31b433cff340b14a11268a0c9746e4a19d    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 13:46:08 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 20 Aug 2019 13:46:08 +0900    

Click here for diff

All those fixes are already included on HEAD thanks to for example  
c96581a and 66bde49, and have gone missing on back-branches.  
  
Author: Alexander Lakhin, Liudmila Mantrova  
Discussion: https://postgr.es/m/CAEkD-mDJHV3bhgezu3MUafJLoAKsOOT86+wHukKU8_NeiJYhLQ@mail.gmail.com  
Backpatch-through: 9.4  

M doc/src/sgml/custom-scan.sgml
M doc/src/sgml/ecpg.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/gist.sgml
M doc/src/sgml/libpq.sgml
M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/problems.sgml
M doc/src/sgml/ref/create_aggregate.sgml
M doc/src/sgml/ref/set_role.sgml
M doc/src/sgml/sources.sgml
M doc/src/sgml/sslinfo.sgml
M doc/src/sgml/xplang.sgml

Disallow changing an inherited column's type if not all parents changed.

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

Click here for diff

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

M src/backend/commands/tablecmds.c
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql

Prevent possible double-free when update trigger returns old tuple.

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

Click here for diff

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

M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql

Doc: improve documentation about postgresql.auto.conf.

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

Click here for diff

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

M doc/src/sgml/config.sgml

Fix ALTER SYSTEM to cope with duplicate entries in postgresql.auto.conf.

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

Click here for diff

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

M src/backend/utils/misc/guc.c

Un-break pg_dump for pre-8.3 source servers.

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

Click here for diff

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

M src/bin/pg_dump/pg_dump.c

Fix random regression failure in test case "temp"

commit   : fc8c6ae5fdebb8dc39b3d001aa332b80e0945fc2    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Aug 2019 10:56:07 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Tue, 13 Aug 2019 10:56:07 +0900    

Click here for diff

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

M src/test/regress/expected/temp.out
M src/test/regress/sql/temp.sql

amcheck: Skip unlogged relations during recovery.

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

Click here for diff

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

M contrib/amcheck/verify_nbtree.c

Fix compiler warning

commit   : 333a186dc52e32ce250c9d62d9dbaecbd359d651    
  
author   : Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Aug 2019 21:20:14 +0200    
  
committer: Peter Eisentraut <peter@eisentraut.org>    
date     : Mon, 12 Aug 2019 21:20:14 +0200    

Click here for diff

With some newer gcc versions (8 and 9) you get a -Wformat-overflow  
warning here.  In PG11 and later this was already fixed.  Since it's  
trivial, backport it to get the older branches building without  
warnings.  

M src/bin/pgbench/pgbench.c

Fix planner's test for case-foldable characters in ILIKE with ICU.

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

Click here for diff

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

M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/collate.icu.utf8.out
M src/test/regress/sql/collate.icu.utf8.sql

Doc: document permissions required for ANALYZE.

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

Click here for diff

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

M doc/src/sgml/ref/analyze.sgml

Fix typo in comment.

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

Click here for diff

M src/backend/catalog/partition.c

Fix predicate-locking of HOT updated rows.

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

Click here for diff

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

M src/backend/access/heap/heapam.c
A src/test/isolation/expected/predicate-lock-hot-tuple.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/predicate-lock-hot-tuple.spec

Fix some incorrect parsing of time with time zone strings

commit   : 1ba4d0fe463eaf16bc93024d0634cf224f07a0e8    
  
author   : Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Aug 2019 18:17:46 +0900    
  
committer: Michael Paquier <michael@paquier.xyz>    
date     : Wed, 7 Aug 2019 18:17:46 +0900    

Click here for diff

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

M src/backend/utils/adt/datetime.c
M src/test/regress/expected/timetz.out
M src/test/regress/sql/timetz.sql

Fix intarray's GiST opclasses to not fail for empty arrays with <@.

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

Click here for diff

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

M contrib/intarray/_int_gist.c
M contrib/intarray/_intbig_gist.c
M contrib/intarray/expected/_int.out
M contrib/intarray/sql/_int.sql