PostgreSQL 11.15 (upcoming) commit log

Move into separate file all the SQL queries used in pg_upgrade tests

commit   : 0e603b75c43417673b2b2a5ebdb5326bb9fc6a5b    
author   : Michael Paquier <>    
date     : Thu, 2 Dec 2021 10:31:43 +0900    
committer: Michael Paquier <>    
date     : Thu, 2 Dec 2021 10:31:43 +0900    

Click here for diff

The existing pg_upgrade/ and the buildfarm code have been holding  
the same set of SQL queries when doing cross-version upgrade tests to  
adapt the objects created by the regression tests before the upgrade  
(mostly, incompatible or non-existing objects need to be dropped from  
the origin, perhaps re-created).  
This moves all those SQL queries into a new, separate, file with a set  
of \if clauses to handle the version checks depending on the old version  
of the cluster to-be-upgraded.  
The long-term plan is to make the buildfarm code re-use this new SQL  
file, so as committers are able to fix any compatibility issues in the  
tests of pg_upgrade with a refresh of the core code, without having to  
poke at the buildfarm client.  Note that this is only able to handle the  
main regression test suite, and that nothing is done yet for contrib  
modules yet (these have more issues like their database names).  
A backpatch down to 10 is done, adapting the version checks as this  
script needs to be only backward-compatible, so as it becomes possible  
to clean up a maximum amount of code within the buildfarm client.  
Author: Justin Pryzby, Michael Paquier  
Backpatch-through: 10  

M src/bin/pg_upgrade/
A src/bin/pg_upgrade/upgrade_adapt.sql

Avoid leaking memory during large-scale REASSIGN OWNED BY operations.

commit   : 82d354411749ac9756974c789bec4f78f2dafbf7    
author   : Tom Lane <>    
date     : Wed, 1 Dec 2021 13:44:47 -0500    
committer: Tom Lane <>    
date     : Wed, 1 Dec 2021 13:44:47 -0500    

Click here for diff

The various ALTER OWNER routines tend to leak memory in  
CurrentMemoryContext.  That's not a problem when they're only called  
once per command; but in this usage where we might be touching many  
objects, it can amount to a serious memory leak.  Fix that by running  
each call in a short-lived context.  
(DROP OWNED BY likely has a similar issue, except that you'll probably  
run out of lock table space before noticing.  REASSIGN is worth fixing  
since for most non-table object types, it won't take any lock.)  
Back-patch to all supported branches.  Unfortunately, in the back  
branches this helps to only a limited extent, since the sinval message  
queue bloats quite a lot in this usage before commit 3aafc030a,  
consuming memory more or less comparable to what's actually leaked.  
Still, it's clearly a leak with a simple fix, so we might as well fix it.  
Justin Pryzby, per report from Guillaume Lelarge  

M src/backend/catalog/pg_shdepend.c

Doc: improve documentation about ORDER BY in matviews.

commit   : 3f43dcc1c6868aac1f22861e6363577a431772cf    
author   : Tom Lane <>    
date     : Mon, 29 Nov 2021 12:13:13 -0500    
committer: Tom Lane <>    
date     : Mon, 29 Nov 2021 12:13:13 -0500    

Click here for diff

Remove the confusing use of ORDER BY in an example materialized  
view.  It adds nothing to the example, but might encourage  
people to follow bad practice.  Clarify REFRESH MATERIALIZED  
VIEW's note about whether view ordering is retained (it isn't).  
Maciek Sakrejda  

M doc/src/sgml/ref/refresh_materialized_view.sgml
M doc/src/sgml/rules.sgml

Fix determination of broken LSN in OVERWRITTEN_CONTRECORD

commit   : 2c3fddcbbd8aa542beec8e3abf3369168517174e    
author   : Alvaro Herrera <>    
date     : Fri, 26 Nov 2021 11:14:27 -0300    
committer: Alvaro Herrera <>    
date     : Fri, 26 Nov 2021 11:14:27 -0300    

Click here for diff

In commit ff9f111bce24 I mixed up inconsistent definitions of the LSN of  
the first record in a page, when the previous record ends exactly at the  
page boundary.  The correct LSN is adjusted to skip the WAL page header;  
I failed to use that when setting XLogReaderState->overwrittenRecPtr,  
so at WAL replay time VerifyOverwriteContrecord would refuse to let  
replay continue past that record.  
Backpatch to 10.  9.6 also contains this bug, but it's no longer being  

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

Remove unneeded Python includes

commit   : a83b1bab0bdb341f952fc982899be70284c11bdc    
author   : Peter Eisentraut <>    
date     : Thu, 25 Nov 2021 14:19:22 +0100    
committer: Peter Eisentraut <>    
date     : Thu, 25 Nov 2021 14:19:22 +0100    

Click here for diff

Inluding <compile.h> and <eval.h> has not been necessary since Python  
2.4, since they are included via <Python.h>.  Morever, <eval.h> is  
being removed in Python 3.11.  So remove these includes.  
Reviewed-by: Tom Lane <>  

M src/pl/plpython/plpython.h

Block ALTER TABLE .. DROP NOT NULL on columns in replica identity index

commit   : dffe80e5500dc116d39929d8f91f906621bd2d9c    
author   : Michael Paquier <>    
date     : Thu, 25 Nov 2021 15:05:34 +0900    
committer: Michael Paquier <>    
date     : Thu, 25 Nov 2021 15:05:34 +0900    

Click here for diff

Replica identities that depend directly on an index rely on a set of  
properties, one of them being that all the columns defined in this index  
have to be marked as NOT NULL.  There was a hole in the logic with ALTER  
TABLE DROP NOT NULL, where it was possible to remove the NOT NULL  
property of a column part of an index used as replica identity, so block  
it to avoid problems with logical decoding down the road.  
The same check was already done columns part of a primary key, so the  
fix is straight-forward.  
Author: Haiying Tang, Hou Zhijie  
Reviewed-by: Dilip Kumar, Michael Paquier  
Backpatch-through: 10  

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

Doc: improve documentation about nextval()/setval().

commit   : b0a7161c564089d4119bbcd5e874a1f4430de1bc    
author   : Tom Lane <>    
date     : Wed, 24 Nov 2021 13:37:12 -0500    
committer: Tom Lane <>    
date     : Wed, 24 Nov 2021 13:37:12 -0500    

Click here for diff

Clarify that the results of nextval and setval are not guaranteed  
persistent until the calling transaction commits.  Some people  
seem to have drawn the opposite conclusion from the statement that  
these functions are never rolled back, so re-word to avoid saying  
it quite that way.  

M doc/src/sgml/func.sgml

Fix missing space in docs.

commit   : a00bd7aa17f652d88c8c0fe52286ef93bb4ec3cc    
author   : Heikki Linnakangas <>    
date     : Wed, 24 Nov 2021 18:32:56 +0200    
committer: Heikki Linnakangas <>    
date     : Wed, 24 Nov 2021 18:32:56 +0200    

Click here for diff

Author: Japin Li  

M doc/src/sgml/arch-dev.sgml

Add support for Visual Studio 2022 in build scripts

commit   : 1061e41ff9ae204d1e0097e8a95d0c2d8a7d4201    
author   : Michael Paquier <>    
date     : Wed, 24 Nov 2021 13:04:07 +0900    
committer: Michael Paquier <>    
date     : Wed, 24 Nov 2021 13:04:07 +0900    

Click here for diff

Documentation and any code paths related to VS are updated to keep the  
whole consistent.  Similarly to 2017 and 2019, the version of VS and the  
version of nmake that we use to determine which code paths to use for  
the build are still inconsistent in their own way.  
Backpatch down to 10, so as buildfarm members are able to use this new  
version of Visual Studio on all the stable branches supported.  
Author: Hans Buschmann  
Backpatch-through: 10  

M doc/src/sgml/install-windows.sgml
M src/tools/msvc/
M src/tools/msvc/README
M src/tools/msvc/
M src/tools/msvc/

Adjust pg_dump's priority ordering for casts.

commit   : 54619a25df7c849d652a75ad990591a7821d9f2f    
author   : Tom Lane <>    
date     : Mon, 22 Nov 2021 17:16:29 -0500    
committer: Tom Lane <>    
date     : Mon, 22 Nov 2021 17:16:29 -0500    

Click here for diff

When a stored expression depends on a user-defined cast, the backend  
records the dependency as being on the cast's implementation function  
--- or indeed, if there's no cast function involved but just  
RelabelType or CoerceViaIO, no dependency is recorded at all.  This  
is problematic for pg_dump, which is at risk of dumping things in the  
wrong order leading to restore failures.  Given the lack of previous  
reports, the risk isn't that high, but it can be demonstrated if the  
cast is used in some view whose rowtype is then used as an input or  
result type for some other function.  (That results in the view  
getting hoisted into the functions portion of the dump, ahead of  
the cast.)  
A logically bulletproof fix for this would require including the  
cast's OID in the parsed form of the expression, whence it could be  
extracted by dependency.c, and then the stored dependency would force  
pg_dump to do the right thing.  Such a change would be fairly invasive,  
and certainly not back-patchable.  Moreover, since we'd prefer that  
an expression using cast syntax be equal() to one doing the same  
thing by explicit function call, the cast OID field would have to  
have special ignored-by-comparisons semantics, making things messy.  
So, let's instead fix this by a very simple hack in pg_dump: change  
the object-type priority order so that casts are initially sorted  
before functions, immediately after types.  This fixes the problem  
in a fairly direct way for casts that have no implementation function.  
For those that do, the implementation function will be hoisted to just  
before the cast by the dependency sorting step, so that we still have  
a valid dump order.  (I'm not sure that this provides a full guarantee  
of no problems; but since it's been like this for many years without  
any previous reports, this is probably enough to fix it in practice.)  
Per report from Дмитрий Иванов.  
Back-patch to all supported branches.  

M src/bin/pg_dump/pg_dump_sort.c

Pacify perlcritic.

commit   : 22d2b6611caa4d191131b5d933369181b5e4a03f    
author   : Tom Lane <>    
date     : Mon, 22 Nov 2021 15:57:31 -0500    
committer: Tom Lane <>    
date     : Mon, 22 Nov 2021 15:57:31 -0500    

Click here for diff

Per buildfarm.  

M config/

Probe $PROVE not $PERL while checking for modules needed by TAP tests.

commit   : ead5c367d32e08a5779617a6f8adf97082dde557    
author   : Tom Lane <>    
date     : Mon, 22 Nov 2021 12:54:52 -0500    
committer: Tom Lane <>    
date     : Mon, 22 Nov 2021 12:54:52 -0500    

Click here for diff

Normally "prove" and "perl" come from the same Perl installation,  
but we support the case where they don't (mainly because the MSys  
buildfarm animals need this).  In that case, AX_PROG_PERL_MODULES  
is completely the wrong thing to use, because it's checking what  
"perl" has.  Instead, make a little TAP test script including the  
required modules, and run that under "prove".  
We don't need ax_prog_perl_modules.m4 at all after this change,  
so remove it.  
Back-patch to all supported branches, for the buildfarm's benefit.  
(In v10, this also back-patches the effects of commit 264eb03aa.)  
Andrew Dunstan and Tom Lane, per an observation by Noah Misch  

M aclocal.m4
D config/ax_prog_perl_modules.m4
A config/
M configure

pg_receivewal, pg_recvlogical: allow canceling initial password prompt.

commit   : c2242d3640eadbe42556aad2f37eae393e84a4df    
author   : Tom Lane <>    
date     : Sun, 21 Nov 2021 14:13:35 -0500    
committer: Tom Lane <>    
date     : Sun, 21 Nov 2021 14:13:35 -0500    

Click here for diff

Previously it was impossible to terminate these programs via control-C  
while they were prompting for a password.  We can fix that trivially  
for their initial password prompts, by moving setup of the SIGINT  
handler from just before to just after their initial GetConnection()  
This fix doesn't permit escaping out of later re-prompts, but those  
should be exceedingly rare, since the user's password or the server's  
authentication setup would have to have changed meanwhile.  We  
considered applying a fix similar to commit 46d665bc2, but that  
seemed more complicated than it'd be worth.  Moreover, this way is  
back-patchable, which that wasn't.  
The misbehavior exists in all supported versions, so back-patch to all.  
Tom Lane and Nathan Bossart  

M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_basebackup/pg_recvlogical.c

Use appropriate -Wno-warning switches when compiling bitcode.

commit   : dff01e40496122a9a4b3fb5a47ed5d124d32aff9    
author   : Tom Lane <>    
date     : Thu, 18 Nov 2021 14:50:13 -0500    
committer: Tom Lane <>    
date     : Thu, 18 Nov 2021 14:50:13 -0500    

Click here for diff

We use "clang" to compile bitcode files for LLVM inlining.  That might  
be different from the build's main C compiler, so it needs its own set  
of compiler flags.  To simplify configure, we don't bother adding any  
-W switches to that flag set; there's little need since the main build  
will show us any warnings.  However, if we don't want to see unwanted  
warnings, we still have to add any -Wno-warning switches we'd normally  
use with clang.  
This escaped notice before commit 9ff47ea41, which tried to add  
-Wno-compound-token-split-by-macro; buildfarm animals using mismatched  
CC and CLANG still showed those warnings.  I'm not sure why we never  
saw any effects from the lack of -Wno-unused-command-line-argument  
(maybe that's only activated by -Wall?).  clang does not currently  
support -Wno-format-truncation or -Wno-stringop-truncation, although  
in the interests of future-proofing and consistency I included tests  
for those.  
Back-patch to v11 where we started building bitcode files.  

M configure

Clean up error handling in pg_basebackup's walmethods.c.

commit   : a414eb850dd8cf9337dd5e8000e2f4e68b61769f    
author   : Tom Lane <>    
date     : Wed, 17 Nov 2021 14:16:34 -0500    
committer: Tom Lane <>    
date     : Wed, 17 Nov 2021 14:16:34 -0500    

Click here for diff

The error handling here was a mess, as a result of a fundamentally  
bad design (relying on errno to keep its value much longer than is  
safe to assume) as well as a lot of just plain sloppiness, both as  
to noticing errors at all and as to reporting the correct errno.  
Moreover, the recent addition of LZ4 compression broke things  
completely, because liblz4 doesn't use errno to report errors.  
To improve matters, keep the error state in the DirectoryMethodData or  
TarMethodData struct, and add a string field so we can handle cases  
that don't set errno.  (The tar methods already had a version of this,  
but it can be done more efficiently since all these cases use a  
constant error string.)  Make the dir and tar methods handle errors  
in basically identical ways, which they didn't before.  
This requires copying errno into the state struct in a lot of places,  
which is a bit tedious, but it has the virtue that we can get rid of  
ad-hoc code to save and restore errno in a number of places ... not  
to mention that it fixes other places that should've saved/restored  
errno but neglected to.  
In passing, fix some pointlessly static buffers to be ordinary  
local variables.  
There remains an issue about exactly how to handle errors from  
fsync(), but that seems like material for its own patch.  
While the LZ4 problems are new, all the rest of this is fixes for  
old bugs, so backpatch to v10 where walmethods.c was introduced.  
Patch by me; thanks to Michael Paquier for review.  

M src/bin/pg_basebackup/walmethods.c

Doc: add see-also references to CREATE PUBLICATION.

commit   : 6ecaefa95aca44673b1a28b5b132182ebd583f7a    
author   : Daniel Gustafsson <>    
date     : Wed, 17 Nov 2021 13:34:41 +0100    
committer: Daniel Gustafsson <>    
date     : Wed, 17 Nov 2021 13:34:41 +0100    

Click here for diff

The "See also" section on the reference page for CREATE PUBLICATION  
didn't match the cross references on CREATE SUBSCRIPTION and their  
ALTER counterparts. Fixed by adding an xref to the CREATE and ALTER  
SUBSCRIPTION pages.  Backpatch down to v10 where CREATE PUBLICATION  
was introduced.  
Author: Peter Smith <>  
Reviewed-by: Masahiko Sawada <>  
Backpatch-through: 10  

M doc/src/sgml/ref/create_publication.sgml

Invalidate relcache when changing REPLICA IDENTITY index.

commit   : 40fb634b1a7be5cf27e0d6c391a6f8f0eb4de412    
author   : Amit Kapila <>    
date     : Tue, 16 Nov 2021 09:25:04 +0530    
committer: Amit Kapila <>    
date     : Tue, 16 Nov 2021 09:25:04 +0530    

Click here for diff

When changing REPLICA IDENTITY INDEX to another one, the target table's  
relcache was not being invalidated. This leads to skipping update/delete  
operations during apply on the subscriber side as the columns required to  
search corresponding rows won't get logged.  
Author: Tang Haiying, Hou Zhijie  
Reviewed-by: Euler Taveira, Amit Kapila  
Backpatch-through: 10  

M src/backend/commands/tablecmds.c
M src/test/subscription/t/

Make psql's \password default to CURRENT_USER, not PQuser(conn).

commit   : b062ca508cd4ab701fffc892afd59e07cb7f0c9f    
author   : Tom Lane <>    
date     : Fri, 12 Nov 2021 14:55:32 -0500    
committer: Tom Lane <>    
date     : Fri, 12 Nov 2021 14:55:32 -0500    

Click here for diff

The documentation says plainly that \password acts on "the current user"  
by default.  What it actually acted on, or tried to, was the username  
used to log into the current session.  This is not the same thing if  
one has since done SET ROLE or SET SESSION AUTHENTICATION.  Aside from  
the possible surprise factor, it's quite likely that the current role  
doesn't have permissions to set the password of the original role.  
To fix, use "SELECT CURRENT_USER" to get the role name to act on.  
(This syntax works with servers at least back to 7.0.)  Also, in  
hopes of reducing confusion, include the role name that will be  
acted on in the password prompt.  
The discrepancy from the documentation makes this a bug, so  
back-patch to all supported branches.  
Patch by me; thanks to Nathan Bossart for review.  

M src/bin/psql/command.c

Report any XLogReadRecord() error in XlogReadTwoPhaseData().

commit   : cae393f0f9fc036241931744b4b812632529fdf1    
author   : Noah Misch <>    
date     : Thu, 11 Nov 2021 17:10:18 -0800    
committer: Noah Misch <>    
date     : Thu, 11 Nov 2021 17:10:18 -0800    

Click here for diff

Buildfarm members kittiwake and tadarida have witnessed errors at this  
site.  The site discarded key facts.  Back-patch to v10 (all supported  
Reviewed by Michael Paquier and Tom Lane.  

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

Fix buffer overrun in unicode string normalization with empty input

commit   : 56c5a069e04b99835b6c179c37109ad4ff7ab236    
author   : Michael Paquier <>    
date     : Thu, 11 Nov 2021 15:02:01 +0900    
committer: Michael Paquier <>    
date     : Thu, 11 Nov 2021 15:02:01 +0900    

Click here for diff

PostgreSQL 13 and newer versions are directly impacted by that through  
the SQL function normalize(), which would cause a call of this function  
to write one byte past its allocation if using in input an empty  
string after recomposing the string with NFC and NFKC.  Older versions  
(v10~v12) are not directly affected by this problem as the only code  
path using normalization is SASLprep in SCRAM authentication that  
forbids the case of an empty string, but let's make the code more robust  
anyway there so as any out-of-core callers of this function are covered.  
The solution chosen to fix this issue is simple, with the addition of a  
fast-exit path if the decomposed string is found as empty.  This would  
only happen for an empty string as at its lowest level a codepoint would  
be decomposed as itself if it has no entry in the decomposition table or  
if it has a decomposition size of 0.  
Some tests are added to cover this issue in v13~.  Note that an empty  
string has always been considered as normalized (grammar "IS NF[K]{C,D}  
NORMALIZED", through the SQL function is_normalized()) for all the  
operations allowed (NFC, NFD, NFKC and NFKD) since this feature has been  
introduced as of 2991ac5.  This behavior is unchanged but some tests are  
added in v13~ to check after that.  
I have also checked "make normalization-check" in src/common/unicode/,  
while on it (works in 13~, and breaks in older stable branches  
independently of this commit).  
The release notes should just mention this commit for v13~.  
Reported-by: Matthijs van der Vleuten  
Backpatch-through: 10  

M src/common/unicode_norm.c

Clean up compilation warnings coming from PL/Perl with clang-12~

commit   : 5e8a0dc7295fd5c3d952a54f09881fb02eb94269    
author   : Michael Paquier <>    
date     : Thu, 11 Nov 2021 10:51:23 +0900    
committer: Michael Paquier <>    
date     : Thu, 11 Nov 2021 10:51:23 +0900    

Click here for diff

clang-12 has introduced -Wcompound-token-split-by-macro, that is causing  
a large amount of warnings when building PL/Perl because of its  
interactions with upstream Perl.  This commit adds one -Wno to CFLAGS at  
./configure time if the flag is supported by the compiler to silence all  
those warnings.  
Upstream perl has fixed this issue, but it is going to take some time  
before this is spread across the buildfarm, and we have noticed that  
some animals would be useful with an extra -Werror to help with the  
detection of incorrect placeholders (see b0cf544), dangomushi being  
Reviewed-by: Tom Lane  
Backpatch-through: 10  

M configure

Doc: improve protocol spec for logical replication Type messages.

commit   : f4ab856e5d5080da076125bcbb09679fc46510f2    
author   : Tom Lane <>    
date     : Wed, 10 Nov 2021 13:12:58 -0500    
committer: Tom Lane <>    
date     : Wed, 10 Nov 2021 13:12:58 -0500    

Click here for diff

protocol.sgml documented the layout for Type messages, but completely  
dropped the ball otherwise, failing to explain what they are, when  
they are sent, or what they're good for.  While at it, do a little  
copy-editing on the description of Relation messages.  
In passing, adjust the comment for apply_handle_type() to make it  
clearer that we choose not to do anything when receiving a Type  
message, not that we think it has no use whatsoever.  
Per question from Stefen Hillman.  

M doc/src/sgml/protocol.sgml
M src/backend/replication/logical/worker.c

Fix instability in test.

commit   : 4dc2cb74d00ed487ec785cdc66a5a5a0a9aa40b2    
author   : Tom Lane <>    
date     : Tue, 9 Nov 2021 18:40:19 -0500    
committer: Tom Lane <>    
date     : Tue, 9 Nov 2021 18:40:19 -0500    

Click here for diff

We've seen intermittent failures in this test on slower buildfarm  
machines, which I think can be explained by assuming that autovacuum  
emitted some additional WAL.  Disable autovacuum to stabilize it.  
In passing, use stringwise not numeric comparison to compare  
WAL file names.  Doesn't matter at present, but they are  
hex strings not decimal ...  

M src/test/recovery/t/