PostgreSQL 9.4.25 commit log

commit   : 6cd154923526141ee65548513324fa66c72e83d4    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2019 17:13:41 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2019 17:13:41 -0500    

commit   : 84aad60b9cdade0a9d55f938bec92d788e2c54e9    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2019 14:39:55 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 11 Nov 2019 14:39:55 -0500    

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

commit   : c86e0dc37f7ff0fc1306d694d5e3e4b3ba95c6bc    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 11 Nov 2019 10:20:03 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 11 Nov 2019 10:20:03 +0100    

Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git  
Source-Git-Hash: 0b30fe39819568078943f4fb97f99e8c9421194c  

commit   : 8a2e037a150743b134462687d6f776ea2ee35afe    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 10 Nov 2019 18:31:13 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 10 Nov 2019 18:31:13 -0500    

commit   : 18622caa3763f1a0b2c3abe93a9ec5d4aa3f55d2    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 9 Nov 2019 15:50:16 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 9 Nov 2019 15:50:16 -0500    

Commits a7145f6bc et al. added a test to verify integer overflow  
detection in interval_mul.  That only applies with integer timestamps,  
of course, so it's problematic in pre-v10 branches where we supported  
float timestamps.  The test was only marginally worth the trouble to  
begin with, so just remove it in those branches.  Per buildfarm.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : 1bd67d5358435e4441961d250a408979f0c4f484    
  
author   : Etsuro Fujita <[email protected]>    
date     : Fri, 8 Nov 2019 17:00:38 +0900    
  
committer: Etsuro Fujita <[email protected]>    
date     : Fri, 8 Nov 2019 17:00:38 +0900    

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

commit   : 87477b67713300a89b3088812142ccae239c1d75    
  
author   : Bruce Momjian <[email protected]>    
date     : Thu, 7 Nov 2019 15:49:59 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Thu, 7 Nov 2019 15:49:59 -0500    

The point is that DELETE triggers cannot modify any values.  
  
Reported-by: Eugen Konkov  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.4  

commit   : b20233aac74302d20f9ea6fae9b3b90155f7a373    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 7 Nov 2019 14:21:52 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 7 Nov 2019 14:21:52 -0500    

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

commit   : 8d380864a523362777d325872997ae706d1d34e1    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 7 Nov 2019 11:22:52 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 7 Nov 2019 11:22:52 -0500    

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

commit   : 1accf997482122d69493f942a6aa89cf34b3fd75    
  
author   : Fujii Masao <[email protected]>    
date     : Thu, 7 Nov 2019 16:31:36 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Thu, 7 Nov 2019 16:31:36 +0900    

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

commit   : 15d90a02a0cefbc89d9533287f904f2aea7034ed    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 6 Nov 2019 16:12:56 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 6 Nov 2019 16:12:56 +0900    

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

commit   : 00ac1eced6204656ae393a719063fbef99a2cf4b    
  
author   : Bruce Momjian <[email protected]>    
date     : Tue, 5 Nov 2019 20:54:04 -0500    
  
committer: Bruce Momjian <[email protected]>    
date     : Tue, 5 Nov 2019 20:54:04 -0500    

Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.4  

commit   : 762b25653808897f013390ef55b9c7f80864a790    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 5 Nov 2019 14:27:38 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 5 Nov 2019 14:27:38 -0500    

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

commit   : 9fb25fda6d56524562fb32316335133b6ba0e544    
  
author   : Alvaro Herrera <[email protected]>    
date     : Mon, 4 Nov 2019 15:50:57 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Mon, 4 Nov 2019 15:50:57 -0300    

Starting with PostgreSQL 12, pg_restore refuses to run when neither -d  
nor -f are specified (c.f. commit 413ccaa74d9a), and it also makes "-f -"  
mean the old implicit behavior of dumping to stdout.  However, older  
branches write to a file called ./- when invoked like that, making it  
impossible to write pg_restore scripts that work across versions.  This  
is a partial backpatch of the aforementioned commit to all older  
supported branches, providing an upgrade path.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : da5cd7a68a3394ad4d22258dee39546615ddff7e    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 4 Nov 2019 16:25:05 -0500    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 4 Nov 2019 16:25:05 -0500    

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

commit   : 7ab7c5c685f7752a0d7476910b98fe318ae85a04    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 4 Nov 2019 09:54:47 +0100    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 4 Nov 2019 09:54:47 +0100    

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

commit   : f88f7206edbfe9d06655e3885219d812b0362251    
  
author   : Michael Paquier <[email protected]>    
date     : Fri, 1 Nov 2019 22:39:09 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Fri, 1 Nov 2019 22:39:09 +0900    

When a backend exits, it gets deleted from the syncrep queue if present.  
The queue was checked without SyncRepLock taken in exclusive mode, so it  
would have been possible for a backend to remove itself after a WAL  
sender already did the job.  Fix this issue based on a suggestion from  
Fujii Masao, by first checking the queue without the lock.  Then, if the  
backend is present in the queue, take the lock and perform an additional  
lookup check before doing the element deletion.  
  
Author: Dongming Liu  
Reviewed-by: Kyotaro Horiguchi, Fujii Masao, Michael Paquier  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : ddcc582a4fa5bc86dfedfc94378ffe859c7dd1d0    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 26 Oct 2019 17:37:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 26 Oct 2019 17:37:20 -0400    

This is a back-patch of the v10 commit d8c05aff5.  The motivation for  
doing this now is that we received a complaint that a view with a  
circular dependency is dumped with an extra bogus command "ALTER TABLE  
ONLY myview REPLICA IDENTITY NOTHING", because pg_dump forgets that it's  
a view not a table, and the relreplident value stored for a view is that.  
So you'll get an error message during restore even if not using --clean;  
this would break pg_upgrade for example.  While that could be handled  
with a one-line patch, it seems better to back-patch d8c05aff5, since that  
produces cleaner more future-proof output and fixes an additional bug.  
  
Per gripe from Alex Williams.  Back-patch to 9.4-9.6 (even if 9.3 were  
still in support, it hasn't got REPLICA IDENTITY so no bug).  
  
Discussion: https://postgr.es/m/NFqxoEi7-8Rw9OW0f-GwHcjvS2I4YQXov4g9OoWv3i7lVOZdLWkAWl9jQQqwEaUq6WV0vdobromhW82e8y5I0_59yZTXcZnXsrmFuldlmZc=@protonmail.com  
  
Original commit message follows:  
  
pg_dump's traditional solution for breaking a circular dependency involving  
a view was to create the view with CREATE TABLE and then later issue CREATE  
RULE "_RETURN" ... to convert the table to a view, relying on the backend's  
very very ancient code that supports making views that way.  We've wanted  
to get rid of that kluge for a long time, but the thing that finally  
motivates doing something about it is the recognition that this method  
fails with the --clean option, because it leads to issuing DROP RULE  
"_RETURN" followed by DROP TABLE --- and the backend won't let you drop a  
view's _RETURN rule.  
  
Instead, let's break circular dependencies by initially creating the view  
using CREATE VIEW AS SELECT NULL::columntype AS columnname, ... (so that  
it has the right column names and types to support external references,  
but no dependencies beyond the column data types), and then later dumping  
the ON SELECT rule using the spelling CREATE OR REPLACE VIEW.  This method  
wasn't available when this code was originally written, but it's been  
possible since PG 7.3, so it seems fine to start relying on it now.  
  
To solve the --clean problem, make the dropStmt for an ON SELECT rule  
be CREATE OR REPLACE VIEW with the same dummy target list as above.  
In this way, during the DROP phase, we first reduce the view to have  
no extra dependencies, and then we can drop it entirely when we've  
gotten rid of whatever had a circular dependency on it.  
  
(Note: this should work adequately well with the --if-exists option, since  
the CREATE OR REPLACE VIEW will go through whether the view exists or not.  
It could fail if the view exists with a conflicting column set, but we  
don't really support --clean against a non-matching database anyway.)  
  
This allows cleaning up some other kluges inside pg_dump, notably that  
we don't need a notion of reloptions attached to a rule anymore.  
  
Although this is a bug fix, commit to HEAD only for now.  The problem's  
existed for a long time and we've had relatively few complaints, so it  
doesn't really seem worth taking risks to fix it in the back branches.  
We might revisit that choice if no problems emerge.  
  
Discussion: <[email protected]>  

commit   : 7db36510906329e0b375921ceb4969b13a1e2242    
  
author   : Bruce Momjian <[email protected]>    
date     : Wed, 23 Oct 2019 20:29:02 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Wed, 23 Oct 2019 20:29:02 -0400    

Reported-by: Asim / [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.4  

commit   : 02f7f246b57e6047480816208150abaa216632fd    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 23 Oct 2019 10:26:28 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 23 Oct 2019 10:26:28 +0900    

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

commit   : fedcab352355e57eafcec9b99a048b86a865a528    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 14:18:01 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 14:18:01 -0400    

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

commit   : 6d2b18d0701ba5637a149467478a4c68af0a0a43    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 13:52:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 13:52:26 -0400    

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

commit   : 727c2ccfefb5d8b77316902bce2427b7864be997    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 12:32:36 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 21 Oct 2019 12:32:36 -0400    

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

commit   : 930787c7fab98f14f1e4a98a201a7f7cef2e55bc    
  
author   : Noah Misch <[email protected]>    
date     : Fri, 18 Oct 2019 20:20:28 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Fri, 18 Oct 2019 20:20:28 -0700    

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

commit   : 14c59185b24dfcf17fa268810799cd5101d6254e    
  
author   : Fujii Masao <[email protected]>    
date     : Fri, 18 Oct 2019 22:32:18 +0900    
  
committer: Fujii Masao <[email protected]>    
date     : Fri, 18 Oct 2019 22:32:18 +0900    

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

commit   : abd5071d216336e1d6451f009fce6d170c61673e    
  
author   : Alvaro Herrera <[email protected]>    
date     : Thu, 17 Oct 2019 15:06:05 +0200    
  
committer: Alvaro Herrera <[email protected]>    
date     : Thu, 17 Oct 2019 15:06:05 +0200    

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

commit   : 080cf32d22317591cd8891c797a4d925cf1dbda2    
  
author   : Thomas Munro <[email protected]>    
date     : Thu, 17 Oct 2019 09:59:21 +1300    
  
committer: Thomas Munro <[email protected]>    
date     : Thu, 17 Oct 2019 09:59:21 +1300    

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

commit   : bc3a94dc00059955aeb611d611d064faf66dc2f8    
  
author   : Tomas Vondra <[email protected]>    
date     : Wed, 16 Oct 2019 16:08:40 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Wed, 16 Oct 2019 16:08:40 +0200    

Commit 8d48e6a724 uses RELKIND_ constants when building the query, but  
did not include the header defining them. On 10+ this header is already  
included, but on 9.6 and earlier it was missing. It compiles just fine,  
but then fails during execution  
  
  ERROR:  column "relkind_relation" does not exist  
  
Fix by adding the necessary header file, and backpatch to 9.4-.  
  
Backpatch-to: 9.4-  
Discussion: https://postgr.es/m/16045-673e8fa6b5ace196%40postgresql.org  

commit   : 235a52ca0f260169521f47c9ae340e511f77023c    
  
author   : Tomas Vondra <[email protected]>    
date     : Wed, 16 Oct 2019 13:31:00 +0200    
  
committer: Tomas Vondra <[email protected]>    
date     : Wed, 16 Oct 2019 13:31:00 +0200    

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

commit   : 952af2476f88d25cc532bd8db79e0737059b5421    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 16 Oct 2019 13:11:01 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 16 Oct 2019 13:11:01 +0900    

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

commit   : b705582b480054348cdc34c106340be00450720a    
  
author   : Noah Misch <[email protected]>    
date     : Sat, 12 Oct 2019 00:21:47 -0700    
  
committer: Noah Misch <[email protected]>    
date     : Sat, 12 Oct 2019 00:21:47 -0700    

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

commit   : 59800f7cef558da424a98ee4b9c74a0dd2758ea5    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 9 Oct 2019 13:31:38 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 9 Oct 2019 13:31:38 +0900    

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

commit   : 7ae8a9959c9bc37ca564db7283a400bc89bcc5c9    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2019 18:06:07 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2019 18:06:07 -0400    

The docs for sync and async multimaster replication were unclear about  
when to use it, and when it has benefits;  this change clarifies that.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.4  

commit   : 630a8f5e2da6d6fe5997e0aba46554d916e114b1    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2019 17:26:46 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2019 17:26:46 -0400    

This should help people clearly know that these days start at midnight.  
  
Reported-by: David Harper  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.4  

commit   : 873cd4f60616f4e698944da958165ce6c68bb21f    
  
author   : Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2019 14:33:31 -0400    
  
committer: Bruce Momjian <[email protected]>    
date     : Mon, 7 Oct 2019 14:33:31 -0400    

Previously it was mentioned in the lock_timeout docs in a confusing  
location.  
  
Reported-by: [email protected]  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch-through: 9.4  

commit   : 8f88090914431b946892069add6949812bb53610    
  
author   : Andrew Dunstan <[email protected]>    
date     : Fri, 4 Oct 2019 15:34:40 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Fri, 4 Oct 2019 15:34:40 -0400    

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

commit   : b6a6c129fca493da4fb289b9cbd757699e51af5b    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 4 Oct 2019 10:34:21 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 4 Oct 2019 10:34:21 -0400    

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

commit   : 6899be28908ac7a63838f651d425ce6dd80b67d5    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 3 Oct 2019 17:34:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 3 Oct 2019 17:34:26 -0400    

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

commit   : 4829576ba44b13504448d05f469af15ffc5793b7    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 3 Oct 2019 13:56:27 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 3 Oct 2019 13:56:27 -0400    

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

commit   : 3473f81dd2a3491ad61be7d7f2917d2af70c423e    
  
author   : Andrew Gierth <[email protected]>    
date     : Thu, 3 Oct 2019 10:54:52 +0100    
  
committer: Andrew Gierth <[email protected]>    
date     : Thu, 3 Oct 2019 10:54:52 +0100    

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

commit   : 668918ff1378e60665db314c2774bbf7459036ff    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 18 Sep 2019 09:14:26 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 18 Sep 2019 09:14:26 +0530    

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

commit   : 70c12450641bed8ab510f0fea2f97b6b747837b7    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 23 Sep 2019 12:37:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 23 Sep 2019 12:37:04 -0400    

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

commit   : 8a17afe84be6fefe76d0d2f4d26c5ee075e64487    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 22 Sep 2019 17:46:00 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 22 Sep 2019 17:46:00 -0400    

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

commit   : 29e47f83caf38ca7967655a4a71d64f30a6461b5    
  
author   : Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2019 19:53:33 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Fri, 20 Sep 2019 19:53:33 -0400    

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

commit   : c16eb2d530b7c2987a948c7ed070ad607f58ff43    
  
author   : Amit Kapila <[email protected]>    
date     : Fri, 20 Sep 2019 08:05:54 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Fri, 20 Sep 2019 08:05:54 +0530    

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

commit   : 332eda5bd3d275fc14b721905b93c2b983a000d3    
  
author   : Alexander Korotkov <[email protected]>    
date     : Thu, 19 Sep 2019 21:30:19 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Thu, 19 Sep 2019 21:30:19 +0300    

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

commit   : 27b41213119a54f5cf2ab45a1cc910d0755774d2    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 19 Sep 2019 13:19:23 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 19 Sep 2019 13:19:23 +0900    

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

commit   : 3698c4480b22d4008bf22799804e93aec72d30a3    
  
author   : Amit Kapila <[email protected]>    
date     : Thu, 19 Sep 2019 09:26:33 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Thu, 19 Sep 2019 09:26:33 +0530    

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

commit   : e8c7f40a1f8ad2a017ff646f19ef42b07bf4ab51    
  
author   : Alvaro Herrera <[email protected]>    
date     : Fri, 13 Sep 2019 16:36:28 -0300    
  
committer: Alvaro Herrera <[email protected]>    
date     : Fri, 13 Sep 2019 16:36:28 -0300    

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

commit   : ca08ea52bfbc0e02eb7e866bb05bf166f15c9b75    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 12 Sep 2019 18:29:18 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 12 Sep 2019 18:29:18 -0400    

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

commit   : 1f705e68ee4fcff5787723bbee256139ce05e1b7    
  
author   : Amit Kapila <[email protected]>    
date     : Wed, 11 Sep 2019 09:55:38 +0530    
  
committer: Amit Kapila <[email protected]>    
date     : Wed, 11 Sep 2019 09:55:38 +0530    

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

commit   : 3d12829ccb16c582140d515a3a558d8aa5692ed0    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 11 Sep 2019 11:08:48 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 11 Sep 2019 11:08:48 +0900    

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

commit   : 3e5cf72f96681fecac88d892978c36c7a834ca02    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 9 Sep 2019 08:56:33 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 9 Sep 2019 08:56:33 -0400    

Modern versions of msys2 have changed the treatment of "cmd /c" so that  
the runtime will try to convert the switch to a native file path. This  
patch adds a setting to inhibit that behaviour.  
  
Discussion: https://postgr.es/m/[email protected]  
  
Backpatch to all live branches.  

commit   : 5f73d7294d9fbaa36a0167e7aa6fa693c9c724e6    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 8 Sep 2019 17:00:30 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 8 Sep 2019 17:00:30 -0400    

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

commit   : 1df4123048c49dda878bbe3b49616b0ff3b3dbe5    
  
author   : Alexander Korotkov <[email protected]>    
date     : Sun, 8 Sep 2019 21:13:40 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Sun, 8 Sep 2019 21:13:40 +0300    

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

commit   : 111fb7e42e335bbe104939418ec44c903d3b2329    
  
author   : Alexander Korotkov <[email protected]>    
date     : Sun, 8 Sep 2019 21:07:30 +0300    
  
committer: Alexander Korotkov <[email protected]>    
date     : Sun, 8 Sep 2019 21:07:30 +0300    

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

commit   : 96db9d5e2b49a4c73108d448adc8f1a485530f5c    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 8 Sep 2019 13:45:13 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 8 Sep 2019 13:45:13 -0400    

Some systems don't ship with "python" by default anymore, only  
"python3" or "python2" or some combination, so include those in the  
configure search.  
  
Back-patch of commit 7291733ac.  At the time that was only pushed  
back as far as v10, because of concerns about interactions with  
commit b21c569ce.  Closer analysis shows that if we just  
s/AC_PATH_PROG/AC_PATH_PROGS/, there is no effect on the older  
branches' behavior when PYTHON is explicitly specified, so it should  
be okay to back-patch: this will not break any configuration that  
worked before.  And the need to support platforms with only a  
"python3" or "python2" executable is getting ever more urgent.  
  
Original patch by Peter Eisentraut, back-patch analysis by me  
  
Discussion: https://www.postgresql.org/message-id/flat/1457.1543184081%40sss.pgh.pa.us#c9cc1199338fd6a257589c6dcea6cf8d  

commit   : 603a53431fd1d272f331c609f62264831fd679c1    
  
author   : Peter Eisentraut <[email protected]>    
date     : Fri, 6 Sep 2019 22:19:53 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Fri, 6 Sep 2019 22:19:53 +0200    

commit   : fbe897134801504a3f1240d61cb78a69bc0850a5    
  
author   : Robert Haas <[email protected]>    
date     : Fri, 6 Sep 2019 08:22:32 -0400    
  
committer: Robert Haas <[email protected]>    
date     : Fri, 6 Sep 2019 08:22:32 -0400    

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

commit   : 89535db970b0fff47d8d0f40a0d45be440e205f6    
  
author   : Tom Lane <[email protected]>    
date     : Mon, 2 Sep 2019 14:02:46 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Mon, 2 Sep 2019 14:02:46 -0400    

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

commit   : bea87c02cee7c22afd1ea7122db85146760bc5b6    
  
author   : Tom Lane <[email protected]>    
date     : Sat, 31 Aug 2019 14:05:32 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sat, 31 Aug 2019 14:05:32 -0400    

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

commit   : 6292cde1c55715a46fec95e1162602d961e08b59    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 28 Aug 2019 12:55:33 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 28 Aug 2019 12:55:33 +0300    

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

commit   : fe50481899e890d5d2587fbd4748b658667dc71a    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 27 Aug 2019 16:37:22 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 27 Aug 2019 16:37:22 -0400    

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

commit   : a5364a3df57845af2a2d40938347b555899a0502    
  
author   : Andrew Dunstan <[email protected]>    
date     : Mon, 26 Aug 2019 07:44:34 -0400    
  
committer: Andrew Dunstan <[email protected]>    
date     : Mon, 26 Aug 2019 07:44:34 -0400    

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

commit   : c693c5c4904d9afdd97cbe414248583d57b59ce4    
  
author   : Tom Lane <[email protected]>    
date     : Sun, 25 Aug 2019 15:04:04 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Sun, 25 Aug 2019 15:04:04 -0400    

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

commit   : 157b233c44e40a66b187b5d1cb84e13ed07eaae0    
  
author   : Michael Paquier <[email protected]>    
date     : Thu, 22 Aug 2019 09:59:49 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Thu, 22 Aug 2019 09:59:49 +0900    

The "Express" flavor of Visual Studio exists up to 2017, and the  
documentation referred to "Express" for Visual Studio 2019.  
  
Author: Takuma Hoshiai  
Discussion: https://postgr.es/m/[email protected]  
Backpatch-through: 9.4  

commit   : 637dac906bf81e063f44afe46283e37dfe27019c    
  
author   : Alvaro Herrera <[email protected]>    
date     : Tue, 20 Aug 2019 16:04:09 -0400    
  
committer: Alvaro Herrera <[email protected]>    
date     : Tue, 20 Aug 2019 16:04:09 -0400    

Author: Alexander Lakhin  
Discussion: https://postgr.es/m/[email protected]  

commit   : fbfa2bba869236f4a9cf08b23e12f81387a65ded    
  
author   : Michael Paquier <[email protected]>    
date     : Tue, 20 Aug 2019 13:46:23 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Tue, 20 Aug 2019 13:46:23 +0900    

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  

commit   : afa71d9152a270e2bb930eb285dd2e1a835baf87    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 15 Aug 2019 20:04:19 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 15 Aug 2019 20:04:19 -0400    

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

commit   : 57980bdf62f4f6c4047a061acd2ce705dc69a4a0    
  
author   : Tom Lane <[email protected]>    
date     : Thu, 15 Aug 2019 11:14:26 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Thu, 15 Aug 2019 11:14:26 -0400    

Clarify what external tools can do to this file, and add a bit  
of detail about what ALTER SYSTEM itself does.  
  
Discussion: https://postgr.es/m/[email protected]  

commit   : a4b0d955bd23bf82d461417d084d7d7abb397cb8    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 14 Aug 2019 15:09:20 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 14 Aug 2019 15:09:20 -0400    

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

commit   : 63ae888a96433cf2abcdcf6be77d74f0157290a6    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 13 Aug 2019 16:57:59 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 13 Aug 2019 16:57:59 -0400    

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

commit   : f02bd634a68c732b4a6eb7cae572d35835a50518    
  
author   : Peter Eisentraut <[email protected]>    
date     : Mon, 12 Aug 2019 21:20:14 +0200    
  
committer: Peter Eisentraut <[email protected]>    
date     : Mon, 12 Aug 2019 21:20:14 +0200    

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.  

commit   : b7c1c33d901cce6ab15a51a88e49cfb7586ca880    
  
author   : Tom Lane <[email protected]>    
date     : Wed, 7 Aug 2019 18:09:28 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Wed, 7 Aug 2019 18:09:28 -0400    

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

commit   : 54c98fa71ac10cbdd07008921ceea23d9f47bcee    
  
author   : Heikki Linnakangas <[email protected]>    
date     : Wed, 7 Aug 2019 12:40:49 +0300    
  
committer: Heikki Linnakangas <[email protected]>    
date     : Wed, 7 Aug 2019 12:40:49 +0300    

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

commit   : 1f7943698182cb368974596251dce334171ea354    
  
author   : Michael Paquier <[email protected]>    
date     : Wed, 7 Aug 2019 18:18:04 +0900    
  
committer: Michael Paquier <[email protected]>    
date     : Wed, 7 Aug 2019 18:18:04 +0900    

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

commit   : 614119d003068b776459a1283d790f035b1f79a6    
  
author   : Tom Lane <[email protected]>    
date     : Tue, 6 Aug 2019 18:04:52 -0400    
  
committer: Tom Lane <[email protected]>    
date     : Tue, 6 Aug 2019 18:04:52 -0400    

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