Stamp 11.14.
commit : 7f05af399052dab32c28c253fa891dc1e8b4224b
author : Tom Lane <[email protected]>
date : Mon, 8 Nov 2021 17:04:02 -0500
committer: Tom Lane <[email protected]>
date : Mon, 8 Nov 2021 17:04:02 -0500
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
Last-minute updates for release notes.
commit : 965e7b1e8531341fed3ade7d03d9ee85fa7793d4
author : Tom Lane <[email protected]>
date : Mon, 8 Nov 2021 14:02:16 -0500
committer: Tom Lane <[email protected]>
date : Mon, 8 Nov 2021 14:02:16 -0500
Security: CVE-2021-23214, CVE-2021-23222
M doc/src/sgml/release-11.sgml
libpq: reject extraneous data after SSL or GSS encryption handshake.
commit : a021a1d2aeba8ce3391f56a070f01db00468da27
author : Tom Lane <[email protected]>
date : Mon, 8 Nov 2021 11:14:56 -0500
committer: Tom Lane <[email protected]>
date : Mon, 8 Nov 2021 11:14:56 -0500
libpq collects up to a bufferload of data whenever it reads data from
the socket. When SSL or GSS encryption is requested during startup,
any additional data received with the server's yes-or-no reply
remained in the buffer, and would be treated as already-decrypted data
once the encryption handshake completed. Thus, a man-in-the-middle
with the ability to inject data into the TCP connection could stuff
some cleartext data into the start of a supposedly encryption-protected
database session.
This could probably be abused to inject faked responses to the
client's first few queries, although other details of libpq's behavior
make that harder than it sounds. A different line of attack is to
exfiltrate the client's password, or other sensitive data that might
be sent early in the session. That has been shown to be possible with
a server vulnerable to CVE-2021-23214.
To fix, throw a protocol-violation error if the internal buffer
is not empty after the encryption handshake.
Our thanks to Jacob Champion for reporting this problem.
Security: CVE-2021-23222
M doc/src/sgml/protocol.sgml
M src/interfaces/libpq/fe-connect.c
Reject extraneous data after SSL or GSS encryption handshake.
commit : 9394fb828998b4e71e4ef95eac6b80acac742835
author : Tom Lane <[email protected]>
date : Mon, 8 Nov 2021 11:01:43 -0500
committer: Tom Lane <[email protected]>
date : Mon, 8 Nov 2021 11:01:43 -0500
The server collects up to a bufferload of data whenever it reads data
from the client socket. When SSL or GSS encryption is requested
during startup, any additional data received with the initial
request message remained in the buffer, and would be treated as
already-decrypted data once the encryption handshake completed.
Thus, a man-in-the-middle with the ability to inject data into the
TCP connection could stuff some cleartext data into the start of
a supposedly encryption-protected database session.
This could be abused to send faked SQL commands to the server,
although that would only work if the server did not demand any
authentication data. (However, a server relying on SSL certificate
authentication might well not do so.)
To fix, throw a protocol-violation error if the internal buffer
is not empty after the encryption handshake.
Our thanks to Jacob Champion for reporting this problem.
Security: CVE-2021-23214
M src/backend/libpq/pqcomm.c
M src/backend/postmaster/postmaster.c
M src/include/libpq/libpq.h
Fix typo
commit : 3aa572b8b296986fca85388b23af80589fc09790
author : Alvaro Herrera <[email protected]>
date : Mon, 8 Nov 2021 09:17:24 -0300
committer: Alvaro Herrera <[email protected]>
date : Mon, 8 Nov 2021 09:17:24 -0300
Introduced in 1d97d3d0867f.
Co-authored-by: Alexander Lakhin <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/transam/xlog.c
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/test/recovery/t/026_overwrite_contrecord.pl
Translation updates
commit : e8fd18bab6d0403370b4b3e32dcbebce788142fd
author : Peter Eisentraut <[email protected]>
date : Mon, 8 Nov 2021 10:09:20 +0100
committer: Peter Eisentraut <[email protected]>
date : Mon, 8 Nov 2021 10:09:20 +0100
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: d9c080c90df1920d1b9f5a9f760f189689a647fd
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/ru.po
M src/bin/initdb/po/sv.po
M src/bin/pg_archivecleanup/po/fr.po
M src/bin/pg_archivecleanup/po/sv.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_config/po/fr.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_config/po/sv.po
M src/bin/pg_controldata/po/fr.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_controldata/po/sv.po
M src/bin/pg_ctl/po/fr.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_ctl/po/sv.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_resetwal/po/fr.po
M src/bin/pg_resetwal/po/ru.po
M src/bin/pg_resetwal/po/sv.po
M src/bin/pg_rewind/po/fr.po
M src/bin/pg_rewind/po/ru.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_test_fsync/po/ru.po
M src/bin/pg_test_fsync/po/sv.po
M src/bin/pg_test_timing/po/ru.po
M src/bin/pg_test_timing/po/sv.po
M src/bin/pg_upgrade/po/fr.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_verify_checksums/po/fr.po
M src/bin/pg_verify_checksums/po/sv.po
M src/bin/pg_waldump/po/fr.po
M src/bin/pg_waldump/po/ru.po
M src/bin/pg_waldump/po/sv.po
M src/bin/psql/po/de.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/sv.po
M src/bin/scripts/po/de.po
M src/bin/scripts/po/fr.po
M src/bin/scripts/po/ru.po
M src/bin/scripts/po/sv.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/ecpglib/po/sv.po
M src/interfaces/ecpg/preproc/po/fr.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/ecpg/preproc/po/sv.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/ru.po
M src/interfaces/libpq/po/sv.po
M src/pl/plperl/po/fr.po
M src/pl/plperl/po/sv.po
M src/pl/plpgsql/src/po/fr.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpgsql/src/po/sv.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/sv.po
M src/pl/tcl/po/fr.po
M src/pl/tcl/po/sv.po
Release notes for 14.1, 13.5, 12.9, 11.14, 10.19, 9.6.24.
commit : 5fb3ee544c5ad3bb5a6f0f8fba258300995f4822
author : Tom Lane <[email protected]>
date : Sun, 7 Nov 2021 14:21:51 -0500
committer: Tom Lane <[email protected]>
date : Sun, 7 Nov 2021 14:21:51 -0500
M doc/src/sgml/release-11.sgml
Reset lastOverflowedXid on standby when needed
commit : 691c0df73a74786b1704b806132006a5754dff32
author : Alexander Korotkov <[email protected]>
date : Sat, 6 Nov 2021 18:31:21 +0300
committer: Alexander Korotkov <[email protected]>
date : Sat, 6 Nov 2021 18:31:21 +0300
Currently, lastOverflowedXid is never reset. It's just adjusted on new
transactions known to be overflowed. But if there are no overflowed
transactions for a long time, snapshots could be mistakenly marked as
suboverflowed due to wraparound.
This commit fixes this issue by resetting lastOverflowedXid when needed
altogether with KnownAssignedXids.
Backpatch to all supported versions.
Reported-by: Stan Hu
Discussion: https://postgr.es/m/CAMBWrQ%3DFp5UAsU_nATY7EMY7NHczG4-DTDU%3DmCvBQZAQ6wa2xQ%40mail.gmail.com
Author: Kyotaro Horiguchi, Alexander Korotkov
Reviewed-by: Stan Hu, Simon Riggs, Nikolay Samokhvalov, Andrey Borodin, Dmitry Dolgov
M src/backend/storage/ipc/procarray.c
Avoid crash in rare case of concurrent DROP
commit : 92224e470c830e73636de20689690f28037cd019
author : Alvaro Herrera <[email protected]>
date : Fri, 5 Nov 2021 12:29:34 -0300
committer: Alvaro Herrera <[email protected]>
date : Fri, 5 Nov 2021 12:29:34 -0300
When a role being dropped contains is referenced by catalog objects that
are concurrently also being dropped, a crash can result while trying to
construct the string that describes the objects. Suppress that by
ignoring objects whose descriptions are returned as NULL.
The majority of relevant codesites were already cautious about this
already; we had just missed a couple.
This is an old bug, so backpatch all the way back.
Reported-by: Alexander Lakhin <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/catalog/dependency.c
M src/backend/catalog/pg_shdepend.c
Update alternative expected output file.
commit : b110af5f7c9fbfdef3451cd8878342757deef89d
author : Heikki Linnakangas <[email protected]>
date : Wed, 3 Nov 2021 19:38:17 +0200
committer: Heikki Linnakangas <[email protected]>
date : Wed, 3 Nov 2021 19:38:17 +0200
Previous commit added a test to 'largeobject', but neglected the
alternative expected output file 'largeobject_1.source'. Per failure
on buildfarm animal 'hamerkop'.
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/test/regress/output/largeobject_1.source
Fix snapshot reference leak if lo_export fails.
commit : 6bf00da1153607c223cb4cd1be92355233b090ca
author : Heikki Linnakangas <[email protected]>
date : Wed, 3 Nov 2021 10:28:52 +0200
committer: Heikki Linnakangas <[email protected]>
date : Wed, 3 Nov 2021 10:28:52 +0200
If lo_export() fails to open the target file or to write to it, it leaks
the created LargeObjectDesc and its snapshot in the top-transaction
context and resource owner. That's pretty harmless, it's a small leak
after all, but it gives the user a "Snapshot reference leak" warning.
Fix by using a short-lived memory context and no resource owner for
transient LargeObjectDescs that are opened and closed within one function
call. The leak is easiest to reproduce with lo_export() on a directory
that doesn't exist, but in principle the other lo_* functions could also
fail.
Backpatch to all supported versions.
Reported-by: Andrew B
Reviewed-by: Alvaro Herrera
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/backend/libpq/be-fsstubs.c
M src/backend/storage/large_object/inv_api.c
M src/test/regress/input/largeobject.source
M src/test/regress/output/largeobject.source
Handle XLOG_OVERWRITE_CONTRECORD in DecodeXLogOp
commit : 5ef21004750588e39e853baeeeca8b0a9792b391
author : Alvaro Herrera <[email protected]>
date : Mon, 1 Nov 2021 13:07:23 -0300
committer: Alvaro Herrera <[email protected]>
date : Mon, 1 Nov 2021 13:07:23 -0300
Failing to do so results in inability of logical decoding to process the
WAL stream. Handle it by doing nothing.
Backpatch all the way back.
Reported-by: Petr Jelínek <[email protected]>
M src/backend/replication/logical/decode.c
Don't try to read a multi-GB pg_stat_statements file in one call.
commit : 5dd067430b9d888196b7d69de7faba9db9bb006d
author : Tom Lane <[email protected]>
date : Sun, 31 Oct 2021 19:13:48 -0400
committer: Tom Lane <[email protected]>
date : Sun, 31 Oct 2021 19:13:48 -0400
Windows fails on a request to read() more than INT_MAX bytes,
and perhaps other platforms could have similar issues. Let's
adjust this code to read at most 1GB per call.
(One would not have thought the file could get that big, but now
we have a field report of trouble, so it can. We likely ought to
add some mechanism to limit the size of the query-texts file
separately from the size of the hash table. That is not this
patch, though.)
Per bug #17254 from Yusuke Egashira. It's been like this for
awhile, so back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M contrib/pg_stat_statements/pg_stat_statements.c
Update time zone data files to tzdata release 2021e.
commit : 91455f7c6d594ec31556ebc27acab841ed1ae208
author : Tom Lane <[email protected]>
date : Fri, 29 Oct 2021 11:38:18 -0400
committer: Tom Lane <[email protected]>
date : Fri, 29 Oct 2021 11:38:18 -0400
DST law changes in Fiji, Jordan, Palestine, and Samoa. Historical
corrections for Barbados, Cook Islands, Guyana, Niue, Portugal, and
Tonga.
Also, the Pacific/Enderbury zone has been renamed to Pacific/Kanton.
The following zones have been merged into nearby, more-populous zones
whose clocks have agreed since 1970: Africa/Accra, America/Atikokan,
America/Blanc-Sablon, America/Creston, America/Curacao,
America/Nassau, America/Port_of_Spain, Antarctica/DumontDUrville,
and Antarctica/Syowa.
M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt
doc: Fix link to SELinux user guide in sepgsql page
commit : c7ddbc351d9cff4f8a63155f6f1a524b41f6f23c
author : Michael Paquier <[email protected]>
date : Thu, 28 Oct 2021 09:26:25 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 28 Oct 2021 09:26:25 +0900
Reported-by: Anton Voloshin
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 10
M doc/src/sgml/sepgsql.sgml
Clarify that --system reindexes system catalogs *only*
commit : fc92bb94af9fcb0629a7a05c0859210b37aca919
author : Magnus Hagander <[email protected]>
date : Wed, 27 Oct 2021 16:20:02 +0200
committer: Magnus Hagander <[email protected]>
date : Wed, 27 Oct 2021 16:20:02 +0200
Make this more clear both in the help message and docs.
Reviewed-By: Michael Paquier
Backpatch-through: 9.6
Discussion: https://postgr.es/m/CABUevEw6Je0WUFTLhPKOk4+BoBuDrE-fKw3N4ckqgDBMFu4paA@mail.gmail.com
M doc/src/sgml/ref/reindexdb.sgml
M src/bin/scripts/reindexdb.c
Back-patch "Stop requiring an explicit return from perl subroutines"
commit : 31d99bc794a634e3f1b648cf3e71cdbc39eb2fa1
author : Noah Misch <[email protected]>
date : Sat, 23 Oct 2021 19:36:26 -0700
committer: Noah Misch <[email protected]>
date : Sat, 23 Oct 2021 19:36:26 -0700
Back-patch commit 0516f94d18c57cc5dce72ff8fb84a05d24a67063 to v12 and
v11. Other back-patches will bring in code written to later standards.
Per buildfarm member crake.
M src/tools/perlcheck/perlcriticrc
Fix CREATE INDEX CONCURRENTLY for the newest prepared transactions.
commit : df6158139f646f71ca5159d5ce173c11b06bb29d
author : Noah Misch <[email protected]>
date : Sat, 23 Oct 2021 18:36:38 -0700
committer: Noah Misch <[email protected]>
date : Sat, 23 Oct 2021 18:36:38 -0700
The purpose of commit 8a54e12a38d1545d249f1402f66c8cde2837d97c was to
fix this, and it sufficed when the PREPARE TRANSACTION completed before
the CIC looked for lock conflicts. Otherwise, things still broke. As
before, in a cluster having used CIC while having enabled prepared
transactions, queries that use the resulting index can silently fail to
find rows. It may be necessary to reindex to recover from past
occurrences; REINDEX CONCURRENTLY suffices. Fix this for future index
builds by making CIC wait for arbitrarily-recent prepared transactions
and for ordinary transactions that may yet PREPARE TRANSACTION. As part
of that, have PREPARE TRANSACTION transfer locks to its dummy PGPROC
before it calls ProcArrayClearTransaction(). Back-patch to 9.6 (all
supported versions).
Andrey Borodin, reviewed (in earlier versions) by Andres Freund.
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/storage/lmgr/lmgr.c
M src/backend/storage/lmgr/lock.c
M src/backend/utils/cache/inval.c
A src/bin/pgbench/t/023_cic_2pc.pl
M src/include/access/twophase.h
M src/include/storage/lock.h
M src/test/perl/PostgresNode.pm
Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.
commit : 5141e471b36add19fe9d6b461f9ea11c0ca6b373
author : Noah Misch <[email protected]>
date : Sat, 23 Oct 2021 18:36:38 -0700
committer: Noah Misch <[email protected]>
date : Sat, 23 Oct 2021 18:36:38 -0700
CIC and REINDEX CONCURRENTLY assume backends see their catalog changes
no later than each backend's next transaction start. That failed to
hold when a backend absorbed a relevant invalidation in the middle of
running RelationBuildDesc() on the CIC index. Queries that use the
resulting index can silently fail to find rows. Fix this for future
index builds by making RelationBuildDesc() loop until it finishes
without accepting a relevant invalidation. It may be necessary to
reindex to recover from past occurrences; REINDEX CONCURRENTLY suffices.
Back-patch to 9.6 (all supported versions).
Noah Misch and Andrey Borodin, reviewed (in earlier versions) by Andres
Freund.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/cache/inval.c
M src/backend/utils/cache/relcache.c
A src/bin/pgbench/t/022_cic.pl
M src/include/utils/inval.h
M src/include/utils/relcache.h
M src/test/perl/PostgresNode.pm
M src/tools/pgindent/typedefs.list
doc: Describe calculation method of streaming start for pg_receivewal
commit : e6c5f1b452655a20b687b3e39d8eb816d8f8cbf7
author : Michael Paquier <[email protected]>
date : Sat, 23 Oct 2021 14:43:51 +0900
committer: Michael Paquier <[email protected]>
date : Sat, 23 Oct 2021 14:43:51 +0900
The documentation was imprecise about the starting LSN used for WAL
streaming if nothing can be found in the local archive directory
defined with the pg_receivewal command, so be more talkative on this
matter.
Extracted from a larger patch by the same author.
Author: Ronan Dunklau, Michael Paquier
Discussion: https://postgr.es/m/18708360.4lzOvYHigE@aivenronan
Backpatch-through: 10
M doc/src/sgml/ref/pg_receivewal.sgml
pg_dump: fix mis-dumping of non-global default privileges.
commit : 871dfe4b7270aa33d0ed8c05abd59d3c2653bd1e
author : Tom Lane <[email protected]>
date : Fri, 22 Oct 2021 15:22:26 -0400
committer: Tom Lane <[email protected]>
date : Fri, 22 Oct 2021 15:22:26 -0400
Non-global default privilege entries should be dumped as-is,
not made relative to the default ACL for their object type.
This would typically only matter if one had revoked some
on-by-default privileges in a global entry, and then wanted
to grant them again in a non-global entry.
Per report from Boris Korzun. This is an old bug, so back-patch
to all supported branches.
Neil Chen, test case by Masahiko Sawada
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/CAA3qoJnr2+1dVJObNtfec=qW4Z0nz=A9+r5bZKoTSy5RDjskMw@mail.gmail.com
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl
Back-patch "Add parent table name in an error in reorderbuffer.c."
commit : d61cdad0b52465934703500fe3c22aa6f0bb0018
author : Amit Kapila <[email protected]>
date : Thu, 21 Oct 2021 09:59:33 +0530
committer: Amit Kapila <[email protected]>
date : Thu, 21 Oct 2021 09:59:33 +0530
This was originally done in commit 5e77625b26 for 15 only, as a
troubleshooting aid but multiple people showed interest in back-patching
this.
Author: Jeremy Schneider
Reviewed-by: Amit Kapila
Backpatch-through: 9.6
Discussion: https://postgr.es/m/[email protected]
M src/backend/replication/logical/reorderbuffer.c
Fix build of MSVC with OpenSSL 3.0.0
commit : e00d45fea15fe3c06981e3ce05718234177babf1
author : Michael Paquier <[email protected]>
date : Wed, 20 Oct 2021 16:49:06 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 20 Oct 2021 16:49:06 +0900
The build scripts of Visual Studio would fail to detect properly a 3.0.0
build as the check on the second digit was failing. This is adjusted
where needed, allowing the builds to complete. Note that the MSIs of
OpenSSL mentioned in the documentation have not changed any library
names for Win32 and Win64, making this change straight-forward.
Reported-by: htalaco, via github
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M src/tools/msvc/Solution.pm
Adapt src/test/ldap/t/001_auth.pl to work with openldap 2.5.
commit : 4589c903599dc602f7d1e6facf161cc177adec9d
author : Andres Freund <[email protected]>
date : Tue, 19 Oct 2021 10:14:49 -0700
committer: Andres Freund <[email protected]>
date : Tue, 19 Oct 2021 10:14:49 -0700
ldapsearch's deprecated -h/-p arguments were removed, need to use -H now -
which has been around for over 20 years.
As perltidy insists on reflowing the parameters anyway, change order and
"phrasing" to yield a less confusing layout (per suggestion from Tom Lane).
Discussion: https://postgr.es/m/[email protected]
Backpatch: 11-, where the tests were added.
M src/test/ldap/t/001_auth.pl
Fix assignment to array of domain over composite.
commit : 0d08c279b0072fb0754ddc2b65eac0d61bade1d3
author : Tom Lane <[email protected]>
date : Tue, 19 Oct 2021 13:54:46 -0400
committer: Tom Lane <[email protected]>
date : Tue, 19 Oct 2021 13:54:46 -0400
An update such as "UPDATE ... SET fld[n].subfld = whatever"
failed if the array elements were domains rather than plain
composites. That's because isAssignmentIndirectionExpr()
failed to cope with the CoerceToDomain node that would appear
in the expression tree in this case. The result would typically
be a crash, and even if we accidentally didn't crash, we'd not
correctly preserve other fields of the same array element.
Per report from Onder Kalaci. Back-patch to v11 where arrays of
domains came in.
Discussion: https://postgr.es/m/PH0PR21MB132823A46AA36F0685B7A29AD8BD9@PH0PR21MB1328.namprd21.prod.outlook.com
M src/backend/executor/execExpr.c
M src/test/regress/expected/domain.out
M src/test/regress/sql/domain.sql
Remove bogus assertion in transformExpressionList().
commit : cf47dc6befe386d16a3f36df6452f07e7910d6b6
author : Tom Lane <[email protected]>
date : Tue, 19 Oct 2021 11:35:15 -0400
committer: Tom Lane <[email protected]>
date : Tue, 19 Oct 2021 11:35:15 -0400
I think when I added this assertion (in commit 8f889b108), I was only
thinking of the use of transformExpressionList at top level of INSERT
and VALUES. But it's also called by transformRowExpr(), which can
certainly occur in an UPDATE targetlist, so it's inappropriate to
suppose that p_multiassign_exprs must be empty. Besides, since the
input is not expected to contain ResTargets, there's no reason it
should contain MultiAssignRefs either. Hence this code need not
be concerned about the state of p_multiassign_exprs, and we should
just drop the assertion.
Per bug #17236 from ocean_li_996. It's been wrong for years,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/parser/parse_target.c
Fix bug in TOC file error message printing
commit : 038892c8101845b6b4364cf2f5773207c4a4525c
author : Daniel Gustafsson <[email protected]>
date : Tue, 19 Oct 2021 12:59:54 +0200
committer: Daniel Gustafsson <[email protected]>
date : Tue, 19 Oct 2021 12:59:54 +0200
If the blob TOC file cannot be parsed, the error message was failing
to print the filename as the variable holding it was shadowed by the
destination buffer for parsing. When the filename fails to parse,
the error will print an empty string:
./pg_restore -d foo -F d dump
pg_restore: error: invalid line in large object TOC file "": ..
..instead of the intended error message:
./pg_restore -d foo -F d dump
pg_restore: error: invalid line in large object TOC file "dump/blobs.toc": ..
Fix by renaming both variables as the shared name was too generic to
store either and still convey what the variable held.
Backpatch all the way down to 9.6.
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M src/bin/pg_dump/pg_backup_directory.c
Fix sscanf limits in pg_basebackup and pg_dump
commit : 931f3926a9f69e8de4a673b05b8e7a1fffc1d0d9
author : Daniel Gustafsson <[email protected]>
date : Tue, 19 Oct 2021 12:59:50 +0200
committer: Daniel Gustafsson <[email protected]>
date : Tue, 19 Oct 2021 12:59:50 +0200
Make sure that the string parsing is limited by the size of the
destination buffer.
In pg_basebackup the available values sent from the server
is limited to two characters so there was no risk of overflow.
In pg_dump the buffer is bounded by MAXPGPATH, and thus the limit
must be inserted via preprocessor expansion and the buffer increased
by one to account for the terminator. There is no risk of overflow
here, since in this case, the buffer scanned is smaller than the
destination buffer.
Backpatch the pg_basebackup fix to 11 where it was introduced, and
the pg_dump fix all the way down to 9.6.
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 11 and 9.6
M src/bin/pg_basebackup/streamutil.c
M src/bin/pg_dump/pg_backup_directory.c
Invalidate partitions of table being attached/detached
commit : b703b7d312a75ce3994c82dc71bf04eabb60c49c
author : Alvaro Herrera <[email protected]>
date : Mon, 18 Oct 2021 19:08:25 -0300
committer: Alvaro Herrera <[email protected]>
date : Mon, 18 Oct 2021 19:08:25 -0300
Failing to do that, any direct inserts/updates of those partitions
would fail to enforce the correct constraint, that is, one that
considers the new partition constraint of their parent table.
Backpatch to 10.
Reported by: Hou Zhijie <[email protected]>
Author: Amit Langote <[email protected]>
Author: Álvaro Herrera <[email protected]>
Reviewed-by: Nitin Jadhav <[email protected]>
Reviewed-by: Pavel Borisov <[email protected]>
Discussion: https://postgr.es/m/OS3PR01MB5718DA1C4609A25186D1FBF194089%40OS3PR01MB5718.jpnprd01.prod.outlook.com
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Reset properly snapshot export state during transaction abort
commit : 506aa1f71a984564332e3bad5ea450d1a22a5576
author : Michael Paquier <[email protected]>
date : Mon, 18 Oct 2021 11:56:57 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 18 Oct 2021 11:56:57 +0900
During a replication slot creation, an ERROR generated in the same
transaction as the one creating a to-be-exported snapshot would have
left the backend in an inconsistent state, as the associated static
export snapshot state was not being reset on transaction abort, but only
on the follow-up command received by the WAL sender that created this
snapshot on replication slot creation. This would trigger inconsistency
failures if this session tried to export again a snapshot, like during
the creation of a replication slot.
Note that a snapshot export cannot happen in a transaction block, so
there is no need to worry resetting this state for subtransaction
aborts. Also, this inconsistent state would very unlikely show up to
users. For example, one case where this could happen is an
out-of-memory error when building the initial snapshot to-be-exported.
Dilip found this problem while poking at a different patch, that caused
an error in this code path for reasons unrelated to HEAD.
Author: Dilip Kumar
Reviewed-by: Michael Paquier, Zhihong Yu
Discussion: https://postgr.es/m/CAFiTN-s0zA1Kj0ozGHwkYkHwa5U0zUE94RSc_g81WrpcETB5=w@mail.gmail.com
Backpatch-through: 9.6
M src/backend/access/transam/xact.c
M src/backend/replication/logical/snapbuild.c
M src/include/replication/snapbuild.h
Avoid core dump in pg_dump when dumping from pre-8.3 server.
commit : 58955c84f365ac629bc8a17931dc2ae45e35154c
author : Tom Lane <[email protected]>
date : Sat, 16 Oct 2021 15:02:55 -0400
committer: Tom Lane <[email protected]>
date : Sat, 16 Oct 2021 15:02:55 -0400
Commit f0e21f2f6 missed adding a tgisinternal output column
to getTriggers' query for pre-8.3 servers. Back-patch to v11,
like that commit.
M src/bin/pg_dump/pg_dump.c
Make pg_dump acquire lock on partitioned tables that are to be dumped.
commit : ca7a4ce5835a5b88d9171a1215782a43696ee46c
author : Tom Lane <[email protected]>
date : Sat, 16 Oct 2021 12:23:57 -0400
committer: Tom Lane <[email protected]>
date : Sat, 16 Oct 2021 12:23:57 -0400
It was clearly the intent to do so all along, but the original coding
fat-fingered this by checking the wrong array element. We fixed it
in passing in 403a3d91c, but that later got reverted, and we forgot
to keep this bug fix.
Most of the time this'd be relatively harmless, since once we lock
any of the partitioned table's leaf partitions, that would suffice
to prevent major DDL on the partitioned table itself. However, a
childless partitioned table would get dumped with no relevant lock
whatsoever, possibly allowing dump failure or inconsistent output.
Unlike 403a3d91c, there are no versioning concerns, since every server
version that has partitioned tables will allow you to lock one.
Back-patch to v10 where partitioned tables were introduced.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_dump/pg_dump.c
Check criticalSharedRelcachesBuilt in GetSharedSecurityLabel().
commit : 3f5d481ef5725494f8737db6f300a2c42afa915d
author : Jeff Davis <[email protected]>
date : Thu, 14 Oct 2021 12:25:30 -0700
committer: Jeff Davis <[email protected]>
date : Thu, 14 Oct 2021 12:25:30 -0700
An extension may want to call GetSecurityLabel() on a shared object
before the shared relcaches are fully initialized. For instance, a
ClientAuthentication_hook might want to retrieve the security label on
a role.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M src/backend/commands/seclabel.c
Change recently added test code for stability
commit : 6287b8e195f37b09dacf9de89cf5c8ee925a3716
author : Alvaro Herrera <[email protected]>
date : Wed, 13 Oct 2021 18:49:27 -0300
committer: Alvaro Herrera <[email protected]>
date : Wed, 13 Oct 2021 18:49:27 -0300
The test code added with ff9f111bce24 fails under valgrind, and probably
other slow cases too, because if (say) autovacuum runs in between and
produces WAL of its own, the large INSERT fails to account for that in
the LSN calculations. Rewrite to use a DO loop.
Per complaint from Andres Freund
Backpatch to all branches.
Discussion: https://postgr.es/m/[email protected]
M src/test/recovery/t/026_overwrite_contrecord.pl
postgres_fdw: Move comments about elog level in (sub)abort cleanup.
commit : c5b2d9c2a4d893a1a4488e9263bf70a444ba5847
author : Etsuro Fujita <[email protected]>
date : Wed, 13 Oct 2021 19:00:06 +0900
committer: Etsuro Fujita <[email protected]>
date : Wed, 13 Oct 2021 19:00:06 +0900
The comments were misplaced when adding postgres_fdw. Fix that by
moving the comments to more appropriate functions.
Author: Etsuro Fujita
Backpatch-through: 9.6
Discussion: https://postgr.es/m/CAPmGK164sAXQtC46mDFyu6d-T25Mzvh5qaRNkit06VMmecYnOA%40mail.gmail.com
M contrib/postgres_fdw/connection.c
Fix null-pointer crash in postgres_fdw's conversion_error_callback.
commit : 88807757d7409fa655458679a78a52b4406cf601
author : Tom Lane <[email protected]>
date : Wed, 6 Oct 2021 15:50:24 -0400
committer: Tom Lane <[email protected]>
date : Wed, 6 Oct 2021 15:50:24 -0400
Commit c7b7311f6 adjusted conversion_error_callback to always use
information from the query's rangetable, to avoid doing catalog lookups
in an already-failed transaction. However, as a result of the utterly
inadequate documentation for make_tuple_from_result_row, I failed to
realize that fsstate could be NULL in some contexts. That led to a
crash if we got a conversion error in such a context. Fix by falling
back to the previous coding when fsstate is NULL. Improve the
commentary, too.
Per report from Andrey Borodin. Back-patch to 9.6, like the previous
patch.
Discussion: https://postgr.es/m/[email protected]
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql
Fix corner-case loss of precision in numeric_power().
commit : b2a0f1673371fd0156685b44b06a818609ed7c95
author : Dean Rasheed <[email protected]>
date : Wed, 6 Oct 2021 13:22:33 +0100
committer: Dean Rasheed <[email protected]>
date : Wed, 6 Oct 2021 13:22:33 +0100
This fixes a loss of precision that occurs when the first input is
very close to 1, so that its logarithm is very small.
Formerly, during the initial low-precision calculation to estimate the
result weight, the logarithm was computed to a local rscale that was
capped to NUMERIC_MAX_DISPLAY_SCALE (1000). However, the base may be
as close as 1e-16383 to 1, hence its logarithm may be as small as
1e-16383, and so the local rscale needs to be allowed to exceed 16383,
otherwise all precision is lost, leading to a poor choice of rscale
for the full-precision calculation.
Fix this by removing the cap on the local rscale during the initial
low-precision calculation, as we already do in the full-precision
calculation. This doesn't change the fact that the initial calculation
is a low-precision approximation, computing the logarithm to around 8
significant digits, which is very fast, especially when the base is
very close to 1.
Patch by me, reviewed by Alvaro Herrera.
Discussion: https://postgr.es/m/CAEZATCV-Ceu%2BHpRMf416yUe4KKFv%3DtdgXQAe5-7S9tD%3D5E-T1g%40mail.gmail.com
M src/backend/utils/adt/numeric.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
Doc: improve description of UNION/INTERSECT/EXCEPT syntax.
commit : abc037b65882396e4655ac6a95388ad33199ccef
author : Tom Lane <[email protected]>
date : Tue, 5 Oct 2021 10:24:15 -0400
committer: Tom Lane <[email protected]>
date : Tue, 5 Oct 2021 10:24:15 -0400
queries.sgml failed to mention the rather important point that
INTERSECT binds more tightly than UNION or EXCEPT. I thought
it could also use more discussion of the role of parentheses
in these constructs.
Per gripe from Christopher Painter-Wakefield.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/queries.sgml
doc: remove URL for ICU explorer/locexp
commit : e1242068537f304dc4c6daa52dca1d62fcdbf45a
author : Bruce Momjian <[email protected]>
date : Mon, 4 Oct 2021 17:10:59 -0400
committer: Bruce Momjian <[email protected]>
date : Mon, 4 Oct 2021 17:10:59 -0400
The old URL was HTTP 404 and the git link didn't build. Also update two
other ICU links. If we ever get a good link we will add it back.
Reported-by: Anton Voloshin
Author: Laurenz Albe
Backpatch-through: 10
M doc/src/sgml/charset.sgml
Fix TestLib::slurp_file() with offset on windows.
commit : 0a134c860fc116a3f1eed71fbdcf48b66221b456
author : Andres Freund <[email protected]>
date : Mon, 4 Oct 2021 13:28:06 -0700
committer: Andres Freund <[email protected]>
date : Mon, 4 Oct 2021 13:28:06 -0700
3c5b0685b921 used setFilePointer() to set the position of the filehandle, but
passed the wrong filehandle, always leaving the position at 0. Instead of just
fixing that, remove use of setFilePointer(), we have a perl fd at this point,
so we can just use perl's seek().
Additionally, the perl filehandle wasn't closed, just the windows filehandle.
Reviewed-By: Andrew Dunstan <[email protected]>
Author: Andres Freund <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch: 9.6-, like 3c5b0685b921
M src/test/perl/TestLib.pm
Update our mapping of Windows time zone names some more.
commit : d0b0b70dc2a60d68f97af5264fe432e245eea3a5
author : Tom Lane <[email protected]>
date : Mon, 4 Oct 2021 14:52:17 -0400
committer: Tom Lane <[email protected]>
date : Mon, 4 Oct 2021 14:52:17 -0400
Per discussion, let's just follow CLDR's default zone mappings
faithfully. There are two changes here that are clear improvements:
* Mapping "Greenwich Standard Time" to Atlantic/Reykjavik is actually
a better fit than using London, because Iceland hasn't observed DST
since 1968, so this is more nearly what people might expect.
* Since the "Samoa" zone is specified to be UTC+13:00, we must map
it to Pacific/Apia not Pacific/Samoa; the latter refers to American
Samoa which is now on the other side of the date line.
The rest of these changes look like they're choosing the most populous
IANA zone as representative. Whatever the details, we're just going
to say "if you don't like this mapping, complain to CLDR".
Discussion: https://postgr.es/m/[email protected]
M src/bin/initdb/findtimezone.c
Fix snapshot builds during promotion of hot standby node with 2PC
commit : 0a561d4d00166b2171579017e2cd8e57dcf83d6a
author : Michael Paquier <[email protected]>
date : Mon, 4 Oct 2021 14:05:59 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 4 Oct 2021 14:05:59 +0900
Some specific logic is done at the end of recovery when involving 2PC
transactions:
1) Call RecoverPreparedTransactions(), to recover the state of 2PC
transactions into memory (re-acquire locks, etc.).
2) ShutdownRecoveryTransactionEnvironment(), to move back to normal
operations, mainly cleaning up recovery locks and KnownAssignedXids
(including any 2PC transaction tracked previously).
3) Switch XLogCtl->SharedRecoveryState to RECOVERY_STATE_DONE, which is
the tipping point for any process calling RecoveryInProgress() to check
if the cluster is still in recovery or not.
Any snapshot taken between steps 2) and 3) would be empty, causing any
transaction relying on a snapshot at this point to potentially corrupt
data as there could still be some 2PC transactions to track, with
RecentXmin moving backwards on successive calls to GetSnapshotData() in
the same transaction.
As SharedRecoveryState is the point to take into account to know if it
is safe to discard KnownAssignedXids, this commit moves step 2) after
step 3), so as we can never finish with empty snapshots.
This exists since the introduction of hot standby, so backpatch all the
way down. The window with incorrect snapshots is extremely small, but I
have seen it when running 023_pitr_prepared_xact.pl, as did buildfarm
member fairywren. Thomas Munro also found it independently. Special
thanks to Andres Freund for taking the time to analyze this issue.
Reported-by: Thomas Munro, Michael Paquier
Analyzed-by: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M src/backend/access/transam/xlog.c
Update our mapping of Windows time zone names using CLDR info.
commit : 9cc919b518553e5c85fa980221463f3a5e54e514
author : Tom Lane <[email protected]>
date : Sat, 2 Oct 2021 16:05:42 -0400
committer: Tom Lane <[email protected]>
date : Sat, 2 Oct 2021 16:05:42 -0400
This corrects a bunch of entries in win32_tzmap[], and adds a few
new ones, based on the CLDR project's windowsZones.xml file.
Non-cosmetic changes fall into four main categories:
* Flat-out errors:
US/Aleutan doesn't exist
America/Salvador doesn't exist
Asia/Baku is wrong for Yerevan
Asia/Dhaka (Bangladesh) is wrong for Astana (Kazakhstan)
Europe/Bucharest is wrong for Chisinau
America/Mexico_City is wrong for Chetumal
America/Buenos_Aires is wrong for Cayenne
America/Caracas has its own zone, so poor fit for La Paz
US/Eastern is wrong for Haiti
US/Eastern is wrong for Indiana (East)
Asia/Karachi is wrong for Tashkent
Etc/UTC+12 doesn't exist
Signs of Etc/GMT zones were backwards
* Judgment calls:
(These changes follow CLDR's choices, except for the first one)
Use Europe/London for "Greenwich Standard Time", since that seems much
more likely than Africa/Casablanca to be what people will think that
zone name means. CLDR has Atlantic/Reykjavik here, but that's no better.
Asia/Shanghai seems a better fit than Hong Kong for "China Standard
Time".
Europe/Sarajevo is now a link to Belgrade, ie "Central Europe Standard
Time"; so use Warsaw for "Central European Standard Time".
America/Sao_Paulo seems more representative than Araguaina for
"E. South America Standard Time".
Africa/Johannesburg seems more representative than Harare for
"South Africa Standard Time".
* New Windows zone names:
"Israel Standard Time"
"Kaliningrad Standard Time"
"Russia Time Zone N" for various N
"Singapore Standard Time"
"South Sudan Standard Time"
"W. Central Africa Standard Time"
"West Bank Standard Time"
"Yukon Standard Time"
Some of these replace older spellings, but I kept the older spellings
too in case our code runs on a machine with the older data.
* Replace aliases (tzdb Links) with underlying city-named zones:
(This tracks tzdb's longstanding practice, and reduces inconsistency
with the rest of the entries, as well as with CLDR.)
US/Alaska
Asia/Kuwait
Asia/Muscat
Canada/Atlantic
Australia/Canberra
Canada/Saskatchewan
US/Central
US/Eastern
US/Hawaii
US/Mountain
Canada/Newfoundland
US/Pacific
Back-patch to all supported branches, as is our usual practice for
time zone data updates.
Discussion: https://postgr.es/m/[email protected]
M src/bin/initdb/findtimezone.c
Re-alphabetize the win32_tzmap[] array.
commit : bb6d426699a68c5b0e7a540c1b0e170b42ca386c
author : Tom Lane <[email protected]>
date : Sat, 2 Oct 2021 16:05:10 -0400
committer: Tom Lane <[email protected]>
date : Sat, 2 Oct 2021 16:05:10 -0400
The original intent seems to have been to sort case-insensitively
by the Windows zone name, but various changes over the years did
not get that memo. This commit just moves a few entries to
restore exact alphabetic order, to ease comparison to the outputs
of processing scripts.
Back-patch to all supported branches, as is our usual practice for
time zone data updates.
Discussion: https://postgr.es/m/[email protected]
M src/bin/initdb/findtimezone.c
Avoid believing incomplete MCV-only stats in get_variable_range().
commit : 5863d348a22f9b9e014cfcd36a705238b078b253
author : Tom Lane <[email protected]>
date : Fri, 1 Oct 2021 14:59:35 -0400
committer: Tom Lane <[email protected]>
date : Fri, 1 Oct 2021 14:59:35 -0400
get_variable_range() would incautiously believe that statistics
containing only an MCV list are sufficient to derive a range estimate.
That's okay for an enum-like column that contains only MCVs, but
otherwise the estimate could be pretty bad. Make it report that the
range is indeterminate unless the MCVs plus nullfrac account for
the whole table.
I don't think this needs a dedicated test case, since a quick code
coverage check verifies that the existing regression tests traverse
all the alternatives. There is room to doubt that a future-proof
test case could be built anyway, given that the submitted example
accidentally doesn't fail before v11.
Per bug #17207 from Simon Perepelitsa. Back-patch to v10.
In principle this has been broken all along, but I'm hesitant to
make such changes in 9.6, since if anyone is unhappy with 9.6.24's
behavior there will be no second chance to fix it.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/selfuncs.c
Fix Portal snapshot tracking to handle subtransactions properly.
commit : 5abbda98594d2cd1f7687577030dbb7a3d1e3d13
author : Tom Lane <[email protected]>
date : Fri, 1 Oct 2021 11:10:12 -0400
committer: Tom Lane <[email protected]>
date : Fri, 1 Oct 2021 11:10:12 -0400
Commit 84f5c2908 forgot to consider the possibility that
EnsurePortalSnapshotExists could run inside a subtransaction with
lifespan shorter than the Portal's. In that case, the new active
snapshot would be popped at the end of the subtransaction, leaving
a dangling pointer in the Portal, with mayhem ensuing.
To fix, make sure the ActiveSnapshot stack entry is marked with
the same subtransaction nesting level as the associated Portal.
It's certainly safe to do so since we won't be here at all unless
the stack is empty; hence we can't create an out-of-order stack.
Let's also apply this logic in the case where PortalRunUtility
sets portalSnapshot, just to be sure that path can't cause similar
problems. It's slightly less clear that that path can't create
an out-of-order stack, so add an assertion guarding it.
Report and patch by Bertrand Drouvot (with kibitzing by me).
Back-patch to v11, like the previous commit.
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/transam/xact.c
M src/backend/tcop/pquery.c
M src/backend/utils/mmgr/portalmem.c
M src/backend/utils/time/snapmgr.c
M src/include/utils/portal.h
M src/include/utils/snapmgr.h
M src/pl/plpgsql/src/expected/plpgsql_transaction.out
M src/pl/plpgsql/src/sql/plpgsql_transaction.sql
Remove gratuitous environment dependency in 002_types.pl test.
commit : b46710dadf0c61912bb41997b1c653789acd2336
author : Tom Lane <[email protected]>
date : Thu, 30 Sep 2021 16:23:10 -0400
committer: Tom Lane <[email protected]>
date : Thu, 30 Sep 2021 16:23:10 -0400
Computing related timestamps by subtracting "N days" is sensitive
to the prevailing timezone, since we interpret that as "same local
time on the N'th prior day". Even though the intervals in question
are only two to four days, through remarkable bad luck they managed
to cross the end of Ramadan in 2014, causing the test's output to
change if timezone is set to Africa/Casablanca. (Maybe in other
Muslim areas as well; I didn't check.) There's absolutely no reason
for this test to exercise interval subtraction, so just get rid of
that and use plain timestamptz constants representing the intended
values.
Per report from Andres Freund. Back-patch to v10 where this test
script came in.
Discussion: https://postgr.es/m/[email protected]
M src/test/subscription/t/002_types.pl
Fix WAL replay in presence of an incomplete record
commit : cfedb279a6b88e4b44de5f66592bd6f12352c4e1
author : Alvaro Herrera <[email protected]>
date : Wed, 29 Sep 2021 11:21:51 -0300
committer: Alvaro Herrera <[email protected]>
date : Wed, 29 Sep 2021 11:21:51 -0300
Physical replication always ships WAL segment files to replicas once
they are complete. This is a problem if one WAL record is split across
a segment boundary and the primary server crashes before writing down
the segment with the next portion of the WAL record: WAL writing after
crash recovery would happily resume at the point where the broken record
started, overwriting that record ... but any standby or backup may have
already received a copy of that segment, and they are not rewinding.
This causes standbys to stop following the primary after the latter
crashes:
LOG: invalid contrecord length 7262 at A8/D9FFFBC8
because the standby is still trying to read the continuation record
(contrecord) for the original long WAL record, but it is not there and
it will never be. A workaround is to stop the replica, delete the WAL
file, and restart it -- at which point a fresh copy is brought over from
the primary. But that's pretty labor intensive, and I bet many users
would just give up and re-clone the standby instead.
A fix for this problem was already attempted in commit 515e3d84a0b5, but
it only addressed the case for the scenario of WAL archiving, so
streaming replication would still be a problem (as well as other things
such as taking a filesystem-level backup while the server is down after
having crashed), and it had performance scalability problems too; so it
had to be reverted.
This commit fixes the problem using an approach suggested by Andres
Freund, whereby the initial portion(s) of the split-up WAL record are
kept, and a special type of WAL record is written where the contrecord
was lost, so that WAL replay in the replica knows to skip the broken
parts. With this approach, we can continue to stream/archive segment
files as soon as they are complete, and replay of the broken records
will proceed across the crash point without a hitch.
Because a new type of WAL record is added, users should be careful to
upgrade standbys first, primaries later. Otherwise they risk the standby
being unable to start if the primary happens to write such a record.
A new TAP test that exercises this is added, but the portability of it
is yet to be seen.
This has been wrong since the introduction of physical replication, so
backpatch all the way back. In stable branches, keep the new
XLogReaderState members at the end of the struct, to avoid an ABI
break.
Author: Álvaro Herrera <[email protected]>
Reviewed-by: Kyotaro Horiguchi <[email protected]>
Reviewed-by: Nathan Bossart <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/rmgrdesc/xlogdesc.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogreader.c
M src/include/access/xlog_internal.h
M src/include/access/xlogreader.h
M src/include/catalog/pg_control.h
A src/test/recovery/t/026_overwrite_contrecord.pl
M src/tools/pgindent/typedefs.list
Fix typos in docs
commit : 23e83c35ad32ec17a38794f6be8289094f8d51fe
author : Michael Paquier <[email protected]>
date : Sun, 26 Sep 2021 19:18:34 +0900
committer: Michael Paquier <[email protected]>
date : Sun, 26 Sep 2021 19:18:34 +0900
Author: Justin Pryzby
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/datatype.sgml
Doc: extend warnings about collation-mismatch hazards in postgres_fdw.
commit : b274c982db67e6b9b43066b2a63d5c0a3dc2c5b5
author : Tom Lane <[email protected]>
date : Sat, 25 Sep 2021 10:53:54 -0400
committer: Tom Lane <[email protected]>
date : Sat, 25 Sep 2021 10:53:54 -0400
Be a little more vocal about the risks of remote collations not
matching local ones. Actually fixing these risks seems hard,
and I've given up on the idea that it might be back-patchable.
So the best we can do for the back branches is add documentation.
Per discussion of bug #16583 from Jiří Fejfar.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/postgres-fdw.sgml
Add alternative output for OpenSSL 3 without legacy loaded
commit : 19e91a40bf26530788d1dae39fa3e7e5a52ca7b2
author : Daniel Gustafsson <[email protected]>
date : Sat, 25 Sep 2021 11:27:28 +0200
committer: Daniel Gustafsson <[email protected]>
date : Sat, 25 Sep 2021 11:27:28 +0200
OpenSSL 3 introduced the concept of providers to support modularization,
and moved the outdated ciphers to the new legacy provider. In case it's
not loaded in the users openssl.cnf file there will be a lot of regress
test failures, so add alternative outputs covering those.
Also document the need to load the legacy provider in order to use older
ciphers with OpenSSL-enabled pgcrypto.
This will be backpatched to all supported version once there is sufficient
testing in the buildfarm of OpenSSL 3.
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
A contrib/pgcrypto/expected/blowfish_1.out
A contrib/pgcrypto/expected/cast5_1.out
A contrib/pgcrypto/expected/des_1.out
A contrib/pgcrypto/expected/pgp-decrypt_2.out
A contrib/pgcrypto/expected/pgp-pubkey-decrypt_1.out
M doc/src/sgml/pgcrypto.sgml
Disable OpenSSL EVP digest padding in pgcrypto
commit : 11901cd9628bf4e3b26d9aba21e6287f2cde3a8a
author : Daniel Gustafsson <[email protected]>
date : Sat, 25 Sep 2021 11:27:20 +0200
committer: Daniel Gustafsson <[email protected]>
date : Sat, 25 Sep 2021 11:27:20 +0200
The PX layer in pgcrypto is handling digest padding on its own uniformly
for all backend implementations. Starting with OpenSSL 3.0.0, DecryptUpdate
doesn't flush the last block in case padding is enabled so explicitly
disable it as we don't use it.
This will be backpatched to all supported version once there is sufficient
testing in the buildfarm of OpenSSL 3.
Reviewed-by: Peter Eisentraut, Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M contrib/pgcrypto/openssl.c
pgcrypto: Check for error return of px_cipher_decrypt()
commit : 0f28d267c7e0936b55307d88644070248a718bd7
author : Daniel Gustafsson <[email protected]>
date : Sat, 25 Sep 2021 11:25:48 +0200
committer: Daniel Gustafsson <[email protected]>
date : Sat, 25 Sep 2021 11:25:48 +0200
This has previously not been a problem (that anyone ever reported),
but in future OpenSSL versions (3.0.0), where legacy ciphers are/can
be disabled, this is the place where this is reported. So we need to
catch the error here, otherwise the higher-level functions would
return garbage. The nearby encryption code already handled errors
similarly.
Author: Peter Eisentraut <[email protected]>
Reviewed-by: Daniel Gustafsson <[email protected]>
Discussion: https://www.postgresql.org/message-id/[email protected]
Backpatch-through: 9.6
M contrib/pgcrypto/px.c
doc: Improve description of index vacuuming with GUCs
commit : 26928441cbb4995fa1474c861d26d3318c8923f3
author : Michael Paquier <[email protected]>
date : Sat, 25 Sep 2021 15:12:07 +0900
committer: Michael Paquier <[email protected]>
date : Sat, 25 Sep 2021 15:12:07 +0900
Index vacuums may happen multiple times depending on the number of dead
tuples stored, as of maintenance_work_mem for a manual VACUUM. For
autovacuum, this is controlled by autovacuum_work_mem instead, if set.
The documentation mentioned the former, but not the latter in the
context of autovacuum.
Reported-by: Nikolai Berkoff
Author: Laurenz Albe, Euler Taveira
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M doc/src/sgml/monitoring.sgml
doc: Add missing markup in CREATE EVENT TRIGGER page
commit : 63b5b4a9a1a8e5a5a16c043bf1503e321debe1df
author : Michael Paquier <[email protected]>
date : Sat, 25 Sep 2021 14:48:20 +0900
committer: Michael Paquier <[email protected]>
date : Sat, 25 Sep 2021 14:48:20 +0900
Reported-by: rir
Discussion: https://postgr.es/m/20210924183658.3syyitp3yuxjv2fp@localhost
Backpatch-through: 9.6
M doc/src/sgml/ref/create_event_trigger.sgml
Release memory allocated by dependency_degree
commit : 4487a7def3ae6efa79c545c3edc03ea97f446e36
author : Tomas Vondra <[email protected]>
date : Tue, 21 Sep 2021 01:13:11 +0200
committer: Tomas Vondra <[email protected]>
date : Tue, 21 Sep 2021 01:13:11 +0200
Calculating degree of a functional dependency may allocate a lot of
memory - we have released mot of the explicitly allocated memory, but
e.g. detoasted varlena values were left behind. That may be an issue,
because we consider a lot of dependencies (all combinations), and the
detoasting may happen for each one again.
Fixed by calling dependency_degree() in a dedicated context, and
resetting it after each call. We only need the calculated dependency
degree, so we don't need to copy anything.
Backpatch to PostgreSQL 10, where extended statistics were introduced.
Backpatch-through: 10
Discussion: https://www.postgresql.org/message-id/20210915200928.GP831%40telsasoft.com
M src/backend/statistics/dependencies.c
Free memory after building each statistics object
commit : ac7290a20ec52fa95316e30191827594b60470d3
author : Tomas Vondra <[email protected]>
date : Tue, 21 Sep 2021 01:14:11 +0200
committer: Tomas Vondra <[email protected]>
date : Tue, 21 Sep 2021 01:14:11 +0200
Until now, all extended statistics on a given relation were built in the
same memory context, without resetting. Some of the memory was released
explicitly, but not all of it - for example memory allocated while
detoasting values is hard to free. This is how it worked since extended
statistics were introduced in PostgreSQL 10, but adding support for
extended stats on expressions made the issue somewhat worse as it
increases the number of statistics to build.
Fixed by adding a memory context which gets reset after building each
statistics object (all the statistics kinds included in it). Resetting
it after building each statistics kind would be even better, but it
would require more invasive changes and copying of results, making it
harder to backpatch.
Backpatch to PostgreSQL 10, where extended statistics were introduced.
Author: Justin Pryzby
Reported-by: Justin Pryzby
Reviewed-by: Tomas Vondra
Backpatch-through: 10
Discussion: https://www.postgresql.org/message-id/20210915200928.GP831%40telsasoft.com
M src/backend/statistics/extended_stats.c
Fix places in TestLib.pm in need of adaptation to the output of Msys perl
commit : 1b6d1ead3bfbf1771d2cf8fd975f980a16211348
author : Michael Paquier <[email protected]>
date : Wed, 22 Sep 2021 08:43:30 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 22 Sep 2021 08:43:30 +0900
Contrary to the output of native perl, Msys perl generates outputs with
CRLFs characters. There are already places in the TAP code where CRLFs
(\r\n) are automatically converted to LF (\n) on Msys, but we missed a
couple of places when running commands and using their output for
comparison, that would lead to failures.
This problem has been found thanks to the test added in 5adb067 using
TestLib::command_checks_all(), but after a closer look more code paths
were missing a filter.
This is backpatched all the way down to prevent any surprises if a new
test is introduced in stable branches.
Reviewed-by: Andrew Dunstan, Álvaro Herrera
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M src/test/perl/TestLib.pm
Fix misevaluation of STABLE parameters in CALL within plpgsql.
commit : 13921c5112667063c3d59de601a9ff521eda2860
author : Tom Lane <[email protected]>
date : Tue, 21 Sep 2021 19:06:33 -0400
committer: Tom Lane <[email protected]>
date : Tue, 21 Sep 2021 19:06:33 -0400
Before commit 84f5c2908, a STABLE function in a plpgsql CALL
statement's argument list would see an up-to-date snapshot,
because exec_stmt_call would push a new snapshot. I got rid of
that because the possibility of the snapshot disappearing within
COMMIT made it too hard to manage a snapshot across the CALL
statement. That's fine so far as the procedure itself goes,
but I forgot to think about the possibility of STABLE functions
within the CALL argument list. As things now stand, those'll
be executed with the Portal's snapshot as ActiveSnapshot,
keeping them from seeing updates more recent than Portal startup.
(VOLATILE functions don't have a problem because they take their
own snapshots; which indeed is also why the procedure itself
doesn't have a problem. There are no STABLE procedures.)
We can fix this by pushing a new snapshot transiently within
ExecuteCallStmt itself. Popping the snapshot before we get
into the procedure proper eliminates the management problem.
The possibly-useless extra snapshot-grab is slightly annoying,
but it's no worse than what happened before 84f5c2908.
Per bug #17199 from Alexander Nawratil. Back-patch to v11,
like the previous patch.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/functioncmds.c
M src/pl/plpgsql/src/expected/plpgsql_transaction.out
M src/pl/plpgsql/src/sql/plpgsql_transaction.sql
Don't elide casting to typmod -1.
commit : 914e54501bccc1bca35984c64dd6a15c1b20e492
author : Tom Lane <[email protected]>
date : Mon, 20 Sep 2021 11:48:52 -0400
committer: Tom Lane <[email protected]>
date : Mon, 20 Sep 2021 11:48:52 -0400
Casting a value that's already of a type with a specific typmod
to an unspecified typmod doesn't do anything so far as run-time
behavior is concerned. However, it really ought to change the
exposed type of the expression to match. Up to now,
coerce_type_typmod hasn't bothered with that, which creates gotchas
in contexts such as recursive unions. If for example one side of
the union is numeric(18,3), but it needs to be plain numeric to
match the other side, there's no direct way to express that.
This is easy enough to fix, by inserting a RelabelType to update the
exposed type of the expression. However, it's a bit nervous-making
to change this behavior, because it's stood for a really long time.
But no complaints have emerged about 14beta3, so go ahead and
back-patch.
Back-patch of 5c056b0c2 into previous supported branches.
Discussion: https://postgr.es/m/CABNQVagu3bZGqiTjb31a8D5Od3fUMs7Oh3gmZMQZVHZ=uWWWfQ@mail.gmail.com
Discussion: https://postgr.es/m/[email protected]
M src/backend/parser/parse_coerce.c
M src/test/regress/expected/expressions.out
M src/test/regress/sql/expressions.sql
Doc: fix typos.
commit : 4a6647e11863d425f4d04c173c909c80186fe0e5
author : Tom Lane <[email protected]>
date : Sun, 19 Sep 2021 11:36:53 -0400
committer: Tom Lane <[email protected]>
date : Sun, 19 Sep 2021 11:36:53 -0400
"PGcon" should be "PGconn". Noted by D. Frey.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/lobj.sgml
Fix variable shadowing in procarray.c.
commit : 8d28ec21f0c3b2defb94afd168efa0a1c60b1a2d
author : Fujii Masao <[email protected]>
date : Thu, 16 Sep 2021 13:07:29 +0900
committer: Fujii Masao <[email protected]>
date : Thu, 16 Sep 2021 13:07:29 +0900
ProcArrayGroupClearXid function has a parameter named "proc",
but the same name was used for its local variables. This commit fixes
this variable shadowing, to improve code readability.
Back-patch to all supported versions, to make future back-patching
easy though this patch is classified as refactoring only.
Reported-by: Ranier Vilela
Author: Ranier Vilela, Aleksander Alekseev
https://postgr.es/m/CAEudQAqyoTZC670xWi6w-Oe2_Bk1bfu2JzXz6xRfiOUzm7xbyQ@mail.gmail.com
M src/backend/storage/ipc/procarray.c
jit: Do not try to shut down LLVM state in case of LLVM triggered errors.
commit : dccffd9a274dfbf343008c4da8029ed8b1f35ea2
author : Andres Freund <[email protected]>
date : Mon, 13 Sep 2021 18:07:19 -0700
committer: Andres Freund <[email protected]>
date : Mon, 13 Sep 2021 18:07:19 -0700
If an allocation failed within LLVM it is not safe to call back into LLVM as
LLVM is not generally safe against exceptions / stack-unwinding. Thus errors
while in LLVM code are promoted to FATAL. However llvm_shutdown() did call
back into LLVM even in such cases, while llvm_release_context() was careful
not to do so.
We cannot generally skip shutting down LLVM, as that can break profiling. But
it's OK to do so if there was an error from within LLVM.
Reported-By: Jelte Fennema <[email protected]>
Author: Andres Freund <[email protected]>
Author: Justin Pryzby <[email protected]>
Discussion: https://postgr.es/m/AM5PR83MB0178C52CCA0A8DEA0207DC14F7FF9@AM5PR83MB0178.EURPRD83.prod.outlook.com
Backpatch: 11-, where jit was introduced
M src/backend/jit/llvm/llvmjit.c
M src/backend/jit/llvm/llvmjit_error.cpp
M src/include/jit/llvmjit.h
Fix EXIT out of outermost block in plpgsql.
commit : bdd6ce48d0356fbfaa0fe4a1fee20068f99abb70
author : Tom Lane <[email protected]>
date : Mon, 13 Sep 2021 12:42:03 -0400
committer: Tom Lane <[email protected]>
date : Mon, 13 Sep 2021 12:42:03 -0400
Ordinarily, using EXIT this way would draw "control reached end of
function without RETURN". However, if the function is one where we
don't require an explicit RETURN (such as a DO block), that should
not happen. It did anyway, because add_dummy_return() neglected to
account for the case.
Per report from Herwig Goemans. Back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/pl/plpgsql/src/expected/plpgsql_control.out
M src/pl/plpgsql/src/pl_comp.c
M src/pl/plpgsql/src/sql/plpgsql_control.sql
Fix error handling with threads on OOM in ECPG connection logic
commit : b6a10ff4abe9538f16d9f52bda6bc04f90b77d0d
author : Michael Paquier <[email protected]>
date : Mon, 13 Sep 2021 13:24:35 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 13 Sep 2021 13:24:35 +0900
An out-of-memory failure happening when allocating the structures to
store the connection parameter keywords and values would mess up with
the set of connections saved, as on failure the pthread mutex would
still be hold with the new connection object listed but free()'d.
Rather than just unlocking the mutex, which would leave the static list
of connections into an inconsistent state, move the allocation for the
structures of the connection parameters before beginning the test
manipulation. This ensures that the list of connections and the
connection mutex remain consistent all the time in this code path.
This error is unlikely going to happen, but this could mess up badly
with ECPG clients in surprising ways, so backpatch all the way down.
Reported-by: ryancaicse
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M src/interfaces/ecpg/ecpglib/connect.c
Make pg_regexec() robust against out-of-range search_start.
commit : 3be381a900df75de6a085cc3a465d85ec8bf39cd
author : Tom Lane <[email protected]>
date : Sat, 11 Sep 2021 15:19:31 -0400
committer: Tom Lane <[email protected]>
date : Sat, 11 Sep 2021 15:19:31 -0400
If search_start is greater than the length of the string, we should just
return REG_NOMATCH immediately. (Note that the equality case should
*not* be rejected, since the pattern might be able to match zero
characters.) This guards various internal assumptions that the min of a
range of string positions is not more than the max. Violation of those
assumptions could allow an attempt to fetch string[search_start-1],
possibly causing a crash.
Jaime Casanova pointed out that this situation is reachable with the
new regexp_xxx functions that accept a user-specified start position.
I don't believe it's reachable via any in-core call site in v14 and
below. However, extensions could possibly call pg_regexec with an
out-of-range search_start, so let's back-patch the fix anyway.
Discussion: https://postgr.es/m/20210911180357.GA6870@ahch-to
M src/backend/regex/regexec.c
Fix some anomalies with NO SCROLL cursors.
commit : 9ea8d3d24a9fb2bbe99cb17f6ee08747f662aabd
author : Tom Lane <[email protected]>
date : Fri, 10 Sep 2021 13:18:32 -0400
committer: Tom Lane <[email protected]>
date : Fri, 10 Sep 2021 13:18:32 -0400
We have long forbidden fetching backwards from a NO SCROLL cursor,
but the prohibition didn't extend to cases in which we rewind the
query altogether and then re-fetch forwards. I think the reason is
that this logic was mainly meant to protect plan nodes that can't
be run in the reverse direction. However, re-reading the query output
is problematic if the query is volatile (which includes SELECT FOR
UPDATE, not just queries with volatile functions): the re-read can
produce different results, which confuses the cursor navigation logic
completely. Another reason for disliking this approach is that some
code paths will either fetch backwards or rewind-and-fetch-forwards
depending on the distance to the target row; so that seemingly
identical use-cases may or may not draw the "cursor can only scan
forward" error. Hence, let's clean things up by disallowing rewind
as well as fetch-backwards in a NO SCROLL cursor.
Ordinarily we'd only make such a definitional change in HEAD, but
there is a third reason to consider this change now. Commit ba2c6d6ce
created some new user-visible anomalies for non-scrollable cursors
WITH HOLD, in that navigation in the cursor result got confused if the
cursor had been partially read before committing. The only good way
to resolve those anomalies is to forbid rewinding such a cursor, which
allows removal of the incorrect cursor state manipulations that
ba2c6d6ce added to PersistHoldablePortal.
To minimize the behavioral change in the back branches (including
v14), refuse to rewind a NO SCROLL cursor only when it has a holdStore,
ie has been held over from a previous transaction due to WITH HOLD.
This should avoid breaking most applications that have been sloppy
about whether to declare cursors as scrollable. We'll enforce the
prohibition across-the-board beginning in v15.
Back-patch to v11, as ba2c6d6ce was.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/portalcmds.c
M src/backend/tcop/pquery.c
M src/test/regress/expected/portals.out
M src/test/regress/sql/portals.sql
Avoid fetching from an already-terminated plan.
commit : 7813451c20c3b341c8af542d80bb941c9c893825
author : Tom Lane <[email protected]>
date : Thu, 9 Sep 2021 13:36:31 -0400
committer: Tom Lane <[email protected]>
date : Thu, 9 Sep 2021 13:36:31 -0400
Some plan node types don't react well to being called again after
they've already returned NULL. PortalRunSelect() has long dealt
with this by calling the executor with NoMovementScanDirection
if it sees that we've already run the portal to the end. However,
commit ba2c6d6ce overlooked this point, so that persisting an
already-fully-fetched cursor would fail if it had such a plan.
Per report from Tomas Barton. Back-patch to v11, as the faulty
commit was. (I've omitted a test case because the type of plan
that causes a problem isn't all that stable.)
Discussion: https://postgr.es/m/CAPV2KRjd=ErgVGbvO2Ty20tKTEZZr6cYsYLxgN_W3eAo9pf5sw@mail.gmail.com
M src/backend/commands/portalcmds.c
Check for relation length overrun soon enough.
commit : 1a23b669db576460a42b257379335a447229ffa6
author : Tom Lane <[email protected]>
date : Thu, 9 Sep 2021 11:45:48 -0400
committer: Tom Lane <[email protected]>
date : Thu, 9 Sep 2021 11:45:48 -0400
We don't allow relations to exceed 2^32-1 blocks, because block
numbers are 32 bits and the last possible block number is reserved
to mean InvalidBlockNumber. There is a check for this in mdextend,
but that's really way too late, because the smgr API requires us to
create a buffer for the block-to-be-added, and we do not want to
have any buffer with blocknum InvalidBlockNumber. (Such a case
can trigger assertions in bufmgr.c, plus I think it might confuse
ReadBuffer's logic for data-past-EOF later on.) So put the check
into ReadBuffer.
Per report from Christoph Berg. It's been like this forever,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/smgr/md.c
Fix issue with WAL archiving in standby.
commit : aacb3cfaf5e8b69da19446ad6a8e7ce426edb898
author : Fujii Masao <[email protected]>
date : Thu, 9 Sep 2021 23:58:54 +0900
committer: Fujii Masao <[email protected]>
date : Thu, 9 Sep 2021 23:58:54 +0900
Previously, walreceiver always closed the currently-opened WAL segment
and created its archive notification file, after it finished writing
the current segment up and received any WAL data that should be
written into the next segment. If walreceiver exited just before
any WAL data in the next segment arrived at standby, it did not
create the archive notification file of the current segment
even though that's known completed. This behavior could cause
WAL archiving of the segment to be delayed until subsequent
restartpoints or checkpoints created its notification file.
To fix the issue, this commit changes walreceiver so that it creates
an archive notification file of a current WAL segment immediately
if that's known completed before receiving next WAL data.
Back-patch to all supported branches.
Reported-by: Kyotaro Horiguchi
Author: Fujii Masao
Reviewed-by: Kyotaro Horiguchi
Discussion: https://postgr.es/m/[email protected]
M src/backend/replication/walreceiver.c
Avoid useless malloc/free traffic around getFormattedTypeName().
commit : 4559c161cb5db350690c2b942fa6fecb3a3e79d3
author : Tom Lane <[email protected]>
date : Wed, 8 Sep 2021 15:09:43 -0400
committer: Tom Lane <[email protected]>
date : Wed, 8 Sep 2021 15:09:43 -0400
Coverity complained that one caller of getFormattedTypeName() failed
to free the returned string. Which is true, but rather than fixing
that one, let's get rid of this tedious and error-prone requirement.
Now that getFormattedTypeName() caches its result, strdup'ing that
result and expecting the caller to free it accomplishes little except
to waste cycles. We do create a leak in the case where getTypes didn't
make a TypeInfo for the type, but that basically shouldn't ever happen.
Back-patch, as commit 6c450a861 was. This isn't a particularly
interesting bug fix, but the API change seems like a hazard for
future back-patching activity if we don't back-patch it.
M src/bin/pg_dump/pg_dump.c
Fix rewriter to set hasModifyingCTE correctly on rewritten queries.
commit : 882b7e7288353ad07e9419ffe62743c552b8008d
author : Tom Lane <[email protected]>
date : Wed, 8 Sep 2021 12:05:43 -0400
committer: Tom Lane <[email protected]>
date : Wed, 8 Sep 2021 12:05:43 -0400
If we copy data-modifying CTEs from the original query to a replacement
query (from a DO INSTEAD rule), we must set hasModifyingCTE properly
in the replacement query. Failure to do this can cause various
unpleasantness, such as unsafe usage of parallel plans. The code also
neglected to propagate hasRecursive, though that's only cosmetic at
the moment.
A difficulty arises if the rule action is an INSERT...SELECT. We
attach the original query's RTEs and CTEs to the sub-SELECT Query, but
data-modifying CTEs are only allowed to appear in the topmost Query.
For the moment, throw an error in such cases. It would probably be
possible to avoid this error by attaching the CTEs to the top INSERT
Query instead; but that would require a bunch of new code to adjust
ctelevelsup references. Given the narrowness of the use-case, and
the need to back-patch this fix, it does not seem worth the trouble
for now. We can revisit this if we get field complaints.
Per report from Greg Nancarrow. Back-patch to all supported branches.
(The test case added here does not fail before v10, but there are
plenty of places checking top-level hasModifyingCTE in 9.6, so I have
no doubt that this code change is necessary there too.)
Greg Nancarrow and Tom Lane
Discussion: https://postgr.es/m/CAJcOf-f68DT=26YAMz_i0+Au3TcLO5oiHY5=fL6Sfuits6r+_w@mail.gmail.com
Discussion: https://postgr.es/m/CAJcOf-fAdj=nDKMsRhQzndm-O13NY4dL6xGcEvdX5Xvbbi0V7g@mail.gmail.com
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/with.out
M src/test/regress/sql/with.sql
Invalidate relcache for publications defined for all tables.
commit : 96e38fa5e549e9891b0f0dc3baf41e273ad3ede5
author : Amit Kapila <[email protected]>
date : Wed, 8 Sep 2021 10:59:21 +0530
committer: Amit Kapila <[email protected]>
date : Wed, 8 Sep 2021 10:59:21 +0530
Updates/Deletes on a relation were allowed even without replica identity
after we define the publication for all tables. This would later lead to
an error on subscribers. The reason was that for such publications we were
not invalidating the relcache and the publication information for
relations was not getting rebuilt. Similarly, we were not invalidating the
relcache after dropping of such publications which will prohibit
Updates/Deletes without replica identity even without any publication.
Author: Vignesh C and Hou Zhijie
Reviewed-by: Hou Zhijie, Kyotaro Horiguchi, Amit Kapila
Backpatch-through: 10, where it was introduced
Discussion: https://postgr.es/m/CALDaNm0pF6zeWqCA8TCe2sDuwFAy8fCqba=nHampCKag-qLixg@mail.gmail.com
M src/backend/commands/publicationcmds.c
M src/test/regress/expected/publication.out
M src/test/regress/sql/publication.sql
Fix bogus timetz_zone() results for DYNTZ abbreviations.
commit : 90b4647f63dae68181557d244717a7615831243d
author : Tom Lane <[email protected]>
date : Mon, 6 Sep 2021 11:29:52 -0400
committer: Tom Lane <[email protected]>
date : Mon, 6 Sep 2021 11:29:52 -0400
timetz_zone() delivered completely wrong answers if the zone was
specified by a dynamic TZ abbreviation, because it failed to account
for the difference between the POSIX conventions for field values in
struct pg_tm and the conventions used in PG-specific datetime code.
As a stopgap fix, just adjust the tm_year and tm_mon fields to match
PG conventions. This is fixed in a different way in HEAD (388e71af8)
but I don't want to back-patch the change of reference point.
Discussion: https://postgr.es/m/CAJ7c6TOMG8zSNEZtCn5SPe+cCk3Lfxb71ZaQwT2F4T7PJ_t=KA@mail.gmail.com
M src/backend/utils/adt/date.c
Further portability tweaks for float4/float8 hash functions.
commit : 8782a84529035baca1639c3680458e2062ef9b44
author : Tom Lane <[email protected]>
date : Sat, 4 Sep 2021 16:29:08 -0400
committer: Tom Lane <[email protected]>
date : Sat, 4 Sep 2021 16:29:08 -0400
Attempting to make hashfloat4() look as much as possible like
hashfloat8(), I'd figured I could replace NaNs with get_float4_nan()
before widening to float8. However, results from protosciurus
and topminnow show that on some platforms that produces a different
bit-pattern from get_float8_nan(), breaking the intent of ce773f230.
Rearrange so that we use the result of get_float8_nan() for all NaN
cases. As before, back-patch.
M src/backend/access/hash/hashfunc.c
Revert "Avoid creating archive status ".ready" files too early"
commit : c801c3a1ff73c34fcc7ab22b2dd6a85041e6cef3
author : Alvaro Herrera <[email protected]>
date : Sat, 4 Sep 2021 12:14:30 -0400
committer: Alvaro Herrera <[email protected]>
date : Sat, 4 Sep 2021 12:14:30 -0400
This reverts commit 515e3d84a0b5 and equivalent commits in back
branches. This solution to the problem has a number of problems, so
we'll try again with a different approach.
Per note from Andres Freund
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/transam/xlog.c
M src/backend/postmaster/walwriter.c
M src/include/access/xlog.h
M src/include/access/xlogdefs.h
Remove arbitrary MAXPGPATH limit on command lengths in pg_ctl.
commit : beb404d3b165ab1cc0dae56b71a6929b4742a10b
author : Tom Lane <[email protected]>
date : Fri, 3 Sep 2021 21:04:44 -0400
committer: Tom Lane <[email protected]>
date : Fri, 3 Sep 2021 21:04:44 -0400
Replace fixed-length command buffers with psprintf() calls. We didn't
have anything as convenient as psprintf() when this code was written,
but now that we do, there's little reason for the limitation to
stand. Removing it eliminates some corner cases where (for example)
starting the postmaster with a whole lot of options fails.
Most individual file names that pg_ctl deals with are still restricted
to MAXPGPATH, but we've seldom had complaints about that limitation
so long as it only applies to one filename.
Back-patch to all supported branches.
Phil Krylov
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_ctl/pg_ctl.c
Disallow creating an ICU collation if the DB encoding won't support it.
commit : 9ebe2852e5435d88d5e3d655b05887b66059cc4d
author : Tom Lane <[email protected]>
date : Fri, 3 Sep 2021 16:38:55 -0400
committer: Tom Lane <[email protected]>
date : Fri, 3 Sep 2021 16:38:55 -0400
Previously this was allowed, but the collation effectively vanished
into the ether because of the way lookup_collation() works: you could
not use the collation, nor even drop it. Seems better to give an
error up front than to leave the user wondering why it doesn't work.
(Because this test is in DefineCollation not CreateCollation, it does
not prevent pg_import_system_collations from creating ICU collations,
regardless of the initially-chosen encoding.)
Per bug #17170 from Andrew Bille. Back-patch to v10 where ICU support
was added.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/collationcmds.c
Fix portability issue in tests from commit ce773f230.
commit : 2836d57e44c67cc30453c83a33fbcf745f5d87ef
author : Tom Lane <[email protected]>
date : Fri, 3 Sep 2021 10:01:02 -0400
committer: Tom Lane <[email protected]>
date : Fri, 3 Sep 2021 10:01:02 -0400
Modern POSIX seems to require strtod() to accept "-NaN", but there's
nothing about NaN in SUSv2, and some of our oldest buildfarm members
don't like it. Let's try writing it as -'NaN' instead; that seems
to produce the same result, at least on Intel hardware.
Per buildfarm.
M src/test/regress/expected/hash_func.out
M src/test/regress/sql/hash_func.sql
Fix float4/float8 hash functions to produce uniform results for NaNs.
commit : ad66373ead6db1b54cfb0af5cda6c24e4cfcaa6b
author : Tom Lane <[email protected]>
date : Thu, 2 Sep 2021 17:24:42 -0400
committer: Tom Lane <[email protected]>
date : Thu, 2 Sep 2021 17:24:42 -0400
The IEEE 754 standard allows a wide variety of bit patterns for NaNs,
of which at least two ("NaN" and "-NaN") are pretty easy to produce
from SQL on most machines. This is problematic because our btree
comparison functions deem all NaNs to be equal, but our float hash
functions know nothing about NaNs and will happily produce varying
hash codes for them. That causes unexpected results from queries
that hash a column containing different NaN values. It could also
produce unexpected lookup failures when using a hash index on a
float column, i.e. "WHERE x = 'NaN'" will not find all the rows
it should.
To fix, special-case NaN in the float hash functions, not too much
unlike the existing special case that forces zero and minus zero
to hash the same. I arranged for the most vanilla sort of NaN
(that coming from the C99 NAN constant) to still have the same
hash code as before, to reduce the risk to existing hash indexes.
I dithered about whether to back-patch this into stable branches,
but ultimately decided to do so. It's a clear improvement for
queries that hash internally. If there is anybody who has -NaN
in a hash index, they'd be well advised to re-index after applying
this patch ... but the misbehavior if they don't will not be much
worse than the misbehavior they had before.
Per bug #17172 from Ma Liangzhu.
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/hash/hashfunc.c
M src/test/regress/expected/hash_func.out
M src/test/regress/sql/hash_func.sql
doc: Replace some uses of "which" by "that" in parallel.sgml
commit : 6eadfd485f56cb28606adf4f112c83cd98f7a2b3
author : Michael Paquier <[email protected]>
date : Thu, 2 Sep 2021 11:36:11 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 2 Sep 2021 11:36:11 +0900
This makes the documentation more accurate grammatically.
Author: Elena Indrupskaya
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6
M doc/src/sgml/parallel.sgml
Fix the random test failure in 001_rep_changes.
commit : 56683e1684efc07faefb6dc932305d8077588791
author : Amit Kapila <[email protected]>
date : Wed, 1 Sep 2021 09:36:50 +0530
committer: Amit Kapila <[email protected]>
date : Wed, 1 Sep 2021 09:36:50 +0530
The check to test whether the subscription workers were restarting after a
change in the subscription was failing. The reason was that the test was
assuming the walsender started before it reaches the 'streaming' state and
the walsender was exiting due to an error before that. Now, the walsender
was erroring out before reaching the 'streaming' state because it tries to
acquire the slot before the previous walsender has exited.
In passing, improve the die messages so that it is easier to investigate
the failures in the future if any.
Reported-by: Michael Paquier, as per buildfarm
Author: Ajin Cherian
Reviewed-by: Masahiko Sawada, Amit Kapila
Backpatch-through: 10, where this test was introduced
Discussion: https://postgr.es/m/[email protected]
M src/test/subscription/t/001_rep_changes.pl
In pg_dump, avoid doing per-table queries for RLS policies.
commit : a60860ff33fbd41685943e1c59a199fe95ee96bd
author : Tom Lane <[email protected]>
date : Tue, 31 Aug 2021 15:04:05 -0400
committer: Tom Lane <[email protected]>
date : Tue, 31 Aug 2021 15:04:05 -0400
For no particularly good reason, getPolicies() queried pg_policy
separately for each table. We can collect all the policies in
a single query instead, and attach them to the correct TableInfo
objects using findTableByOid() lookups. On the regression
database, this reduces the number of queries substantially, and
provides a visible savings even when running against a local
server.
Per complaint from Hubert Depesz Lubaczewski. Since this is such
a simple fix and can have a visible performance benefit, back-patch
to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_dump/pg_dump.c
Cache the results of format_type() queries in pg_dump.
commit : c4b298ee15aa67a953e65c8efa1a33eeea721446
author : Tom Lane <[email protected]>
date : Tue, 31 Aug 2021 13:53:33 -0400
committer: Tom Lane <[email protected]>
date : Tue, 31 Aug 2021 13:53:33 -0400
There's long been a "TODO: there might be some value in caching
the results" annotation on pg_dump's getFormattedTypeName function;
but we hadn't gotten around to checking what it was costing us to
repetitively look up type names. It turns out that when dumping the
current regression database, about 10% of the total number of queries
issued are duplicative format_type() queries. However, Hubert Depesz
Lubaczewski reported a not-unusual case where these account for over
half of the queries issued by pg_dump. Individually these queries
aren't expensive, but when network lag is a factor, they add up to a
problem. We can very easily add some caching to getFormattedTypeName
to solve it.
Since this is such a simple fix and can have a visible performance
benefit, back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
Rename the role in stats_ext to have regress_ prefix
commit : bce24d1edbcf9b3034a6976b4fa2c46c5c85e260
author : Tomas Vondra <[email protected]>
date : Tue, 31 Aug 2021 19:21:29 +0200
committer: Tomas Vondra <[email protected]>
date : Tue, 31 Aug 2021 19:21:29 +0200
Commit 5be8ce82e8 added a new role to the stats_ext regression suite,
but the role name did not start with regress_ causing failures when
running with ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS. Fixed by
renaming the role to start with the expected regress_ prefix.
Backpatch-through: 10, same as the new regression test
Discussion: https://postgr.es/m/1F238937-7CC2-4703-A1B1-6DC225B8978A%40enterprisedb.com
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Fix lookup error in extended stats ownership check
commit : b46ff4b50f449e01fd1646c4a65c182e7519a48b
author : Tomas Vondra <[email protected]>
date : Tue, 31 Aug 2021 18:03:05 +0200
committer: Tomas Vondra <[email protected]>
date : Tue, 31 Aug 2021 18:03:05 +0200
When an ownership check on extended statistics object failed, the code
was calling aclcheck_error_type to report the failure, which is clearly
wrong, resulting in cache lookup errors. Fix by calling aclcheck_error.
This issue exists since the introduction of extended statistics, so
backpatch all the way back to PostgreSQL 10. It went unnoticed because
there were no tests triggering the error, so add one.
Reported-by: Mark Dilger
Backpatch-through: 10, where extended stats were introduced
Discussion: https://postgr.es/m/1F238937-7CC2-4703-A1B1-6DC225B8978A%40enterprisedb.com
M src/backend/catalog/objectaddress.c
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Report tuple address in data-corruption error message
commit : 0105b7aaa3f4c020934790311b2587fce54a9afd
author : Alvaro Herrera <[email protected]>
date : Mon, 30 Aug 2021 16:29:12 -0400
committer: Alvaro Herrera <[email protected]>
date : Mon, 30 Aug 2021 16:29:12 -0400
Most data-corruption reports mention the location of the problem, but
this one failed to. Add it.
Backpatch all the way back. In 12 and older, also assign the
ERRCODE_DATA_CORRUPTED error code as was done in commit fd6ec93bf890 for
13 and later.
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/execMain.c
Fix incorrect error code in StartupReplicationOrigin().
commit : a8e7eb159c38d33a90574d0409c556c554c5967c
author : Amit Kapila <[email protected]>
date : Mon, 30 Aug 2021 09:48:56 +0530
committer: Amit Kapila <[email protected]>
date : Mon, 30 Aug 2021 09:48:56 +0530
ERRCODE_CONFIGURATION_LIMIT_EXCEEDED was used for checksum failure, use
ERRCODE_DATA_CORRUPTED instead.
Reported-by: Tatsuhito Kasahara
Author: Tatsuhito Kasahara
Backpatch-through: 9.6, where it was introduced
Discussion: https://postgr.es/m/CAP0=ZVLHtYffs8SOWcFJWrBGoRzT9QQbk+_aP+E5AHLNXiOorA@mail.gmail.com
M src/backend/replication/logical/origin.c
Fix data loss in wal_level=minimal crash recovery of CREATE TABLESPACE.
commit : 6ebd2426bda2260fc9bc33555da81dfc8c623f32
author : Noah Misch <[email protected]>
date : Fri, 27 Aug 2021 23:33:23 -0700
committer: Noah Misch <[email protected]>
date : Fri, 27 Aug 2021 23:33:23 -0700
If the system crashed between CREATE TABLESPACE and the next checkpoint,
the result could be some files in the tablespace unexpectedly containing
no rows. Affected files would be those for which the system did not
write WAL; see the wal_skip_threshold documentation. Before v13, a
different set of conditions governed the writing of WAL; see v12's
<sect2 id="populate-pitr">. (The v12 conditions were broader in some
ways and narrower in others.) Users may want to audit non-default
tablespaces for unexpected short files. The bug could have truncated an
index without affecting the associated table, and reindexing the index
would fix that particular problem.
This fixes the bug by making create_tablespace_directories() more like
TablespaceCreateDbspace(). create_tablespace_directories() was
recursively removing tablespace contents, reasoning that WAL redo would
recreate everything removed that way. That assumption holds for other
wal_level values. Under wal_level=minimal, the old approach could
delete files for which no other copy existed. Back-patch to 9.6 (all
supported versions).
Reviewed by Robert Haas and Prabhat Sahu. Reported by Robert Haas.
Discussion: https://postgr.es/m/CA+TgmoaLO9ncuwvr2nN-J4VEP5XyAcy=zKiHxQzBbFRxxGxm0w@mail.gmail.com
M src/backend/commands/tablespace.c
Count SP-GiST index scans in pg_stat statistics.
commit : 7c1b0f4c35354edf5460cf6e87c63a4a65be1e00
author : Tom Lane <[email protected]>
date : Fri, 27 Aug 2021 19:42:42 -0400
committer: Tom Lane <[email protected]>
date : Fri, 27 Aug 2021 19:42:42 -0400
Somehow, spgist overlooked the need to call pgstat_count_index_scan().
Hence, pg_stat_all_indexes.idx_scan and equivalent columns never
became nonzero for an SP-GiST index, although the related per-tuple
counters worked fine.
This fix works a bit differently from other index AMs, in that the
counter increment occurs in spgrescan not spggettuple/spggetbitmap.
It looks like this won't make the user-visible semantics noticeably
different, so I won't go to the trouble of introducing an is-this-
the-first-call flag just to make the counter bumps happen in the
same places.
Per bug #17163 from Christian Quest. Back-patch to all supported
versions.
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/spgist/spgscan.c
docs: clarify bgw_restart_time documentation
commit : 05fec0b74facdc7a0f96fd1bc18e5d402f497f7c
author : Daniel Gustafsson <[email protected]>
date : Fri, 27 Aug 2021 22:50:19 +0200
committer: Daniel Gustafsson <[email protected]>
date : Fri, 27 Aug 2021 22:50:19 +0200
Author: Dave Cramer <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/CADK3HHLZmqAQZ2ByPDQQ9yhGqax36kksq6sDkV0yYzsxw6ipvQ@mail.gmail.com
M doc/src/sgml/bgworker.sgml
Fix broken snapshot handling in parallel workers.
commit : 198cf81e2c64bdf2d4fa3c24d54c1eacf47a3d38
author : Robert Haas <[email protected]>
date : Wed, 25 Aug 2021 08:32:04 -0400
committer: Robert Haas <[email protected]>
date : Wed, 25 Aug 2021 08:32:04 -0400
Pengchengliu reported an assertion failure in a parallel woker while
performing a parallel scan using an overflowed snapshot. The proximate
cause is that TransactionXmin was set to an incorrect value. The
underlying cause is incorrect snapshot handling in parallel.c.
In particular, InitializeParallelDSM() was unconditionally calling
GetTransactionSnapshot(), because I (rhaas) mistakenly thought that
was always retrieving an existing snapshot whereas, at isolation
levels less than REPEATABLE READ, it's actually taking a new one. So
instead do this only at higher isolation levels where there actually
is a single snapshot for the whole transaction.
By itself, this is not a sufficient fix, because we still need to
guarantee that TransactionXmin gets set properly in the workers. The
easiest way to do that seems to be to install the leader's active
snapshot as the transaction snapshot if the leader did not serialize a
transaction snapshot. This doesn't affect the results of future
GetTrasnactionSnapshot() calls since those have to take a new snapshot
anyway; what we care about is the side effect of setting TransactionXmin.
Report by Pengchengliu. Patch by Greg Nancarrow, except for some comment
text which I supplied.
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/transam/parallel.c
Fix toast rewrites in logical decoding.
commit : bfdbda24b9aa5fc335f370414e904daccc35a370
author : Amit Kapila <[email protected]>
date : Wed, 25 Aug 2021 09:43:33 +0530
committer: Amit Kapila <[email protected]>
date : Wed, 25 Aug 2021 09:43:33 +0530
Commit 325f2ec555 introduced pg_class.relwrite to skip operations on
tables created as part of a heap rewrite during DDL. It links such
transient heaps to the original relation OID via this new field in
pg_class but forgot to do anything about toast tables. So, logical
decoding was not able to skip operations on internally created toast
tables. This leads to an error when we tried to decode the WAL for the
next operation for which it appeared that there is a toast data where
actually it didn't have any toast data.
To fix this, we set pg_class.relwrite for internally created toast tables
as well which allowed skipping operations on them during logical decoding.
Author: Bertrand Drouvot
Reviewed-by: David Zhang, Amit Kapila
Backpatch-through: 11, where it was introduced
Discussion: https://postgr.es/m/[email protected]
M contrib/test_decoding/expected/toast.out
M contrib/test_decoding/sql/toast.sql
M src/backend/catalog/toasting.c
M src/backend/commands/cluster.c
M src/backend/commands/tablecmds.c
M src/include/catalog/toasting.h
M src/include/commands/tablecmds.h
Avoid using ambiguous word "positive" in error message.
commit : f23b2a488b062563fe09fe3552979f18055e8f53
author : Fujii Masao <[email protected]>
date : Wed, 25 Aug 2021 11:46:25 +0900
committer: Fujii Masao <[email protected]>
date : Wed, 25 Aug 2021 11:46:25 +0900
There are two identical error messages about valid value of modulus for
hash partition, in PostgreSQL source code. Commit 0e1275fb07 improved
only one of them so that ambiguous word "positive" was avoided there,
and forgot to improve the other. This commit improves the other.
Which would reduce translator burden.
Back-pach to v11 where the error message exists.
Author: Kyotaro Horiguchi
Reviewed-by: Fujii Masao
Discussion: https://postgr.es/m/[email protected]
M src/backend/parser/parse_utilcmd.c
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/create_table.out
Improve error message about valid value for distance in phrase operator.
commit : 3095dc1c47ca4ab198ce0817da39637f616df679
author : Fujii Masao <[email protected]>
date : Wed, 25 Aug 2021 11:43:56 +0900
committer: Fujii Masao <[email protected]>
date : Wed, 25 Aug 2021 11:43:56 +0900
The distance in phrase operator must be an integer value between zero
and MAXENTRYPOS inclusive. But previously the error message about
its valid value included the information about its upper limit
but not lower limit (i.e., zero). This commit improves the error message
so that it also includes the information about its lower limit.
Back-patch to v9.6 where full-text phrase search was supported.
Author: Kyotaro Horiguchi
Reviewed-by: Fujii Masao
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/tsquery.c
Fix regexp misbehavior with capturing parens inside "{0}".
commit : 3ebd32e70c09d7c35072a1ebff0783e5596eec91
author : Tom Lane <[email protected]>
date : Tue, 24 Aug 2021 16:37:27 -0400
committer: Tom Lane <[email protected]>
date : Tue, 24 Aug 2021 16:37:27 -0400
Regexps like "(.){0}...\1" drew an "invalid backreference number".
That's not unreasonable on its face, since the capture group will
never be matched if it's iterated zero times. However, other engines
such as Perl's don't complain about this, nor do we throw an error for
related cases such as "(.)|\1", even though that backref can never
succeed either. Also, if the zero-iterations case happens at runtime
rather than compile time --- say, "(x)*...\1" when there's no "x" to
be found --- that's not an error, we just deem the backref to not
match. Making this even less defensible, no error was thrown for
nested cases such as "((.)){0}...\2"; and to add insult to injury,
those cases could result in assertion failures instead. (It seems
that nothing especially bad happened in non-assert builds, though.)
Let's just fix it so that no error is thrown and instead the backref
is deemed to never match, so that compile-time detection of no
iterations behaves the same as run-time detection.
Per report from Mark Dilger. This appears to be an aboriginal error
in Spencer's library, so back-patch to all supported versions.
Pre-v14, it turns out to also be necessary to back-patch one aspect of
commits cb76fbd7e/00116dee5, namely to create capture-node subREs with
the begin/end states of their subexpressions, not the current lp/rp
of the outer parseqatom invocation. Otherwise delsub complains that
we're trying to disconnect a state from itself. This is a bit scary
but code examination shows that it's safe: in the pre-v14 code, if we
want to wrap iteration around the subexpression, the first thing we do
is overwrite the atom's begin/end fields with new states. So the
bogus values didn't survive long enough to be used for anything, except
if no iteration is required, in which case it doesn't matter.
Discussion: https://postgr.es/m/[email protected]
M src/backend/regex/regcomp.c
M src/test/regress/expected/regex.out
M src/test/regress/sql/regex.sql
Prevent regexp back-refs from sometimes matching when they shouldn't.
commit : 08e080756d11c4466b878832f27d741f0507be5a
author : Tom Lane <[email protected]>
date : Mon, 23 Aug 2021 17:41:07 -0400
committer: Tom Lane <[email protected]>
date : Mon, 23 Aug 2021 17:41:07 -0400
The recursion in cdissect() was careless about clearing match data
for capturing parentheses after rejecting a partial match. This
could allow a later back-reference to succeed when by rights it
should fail for lack of a defined referent.
To fix, think a little more rigorously about what the contract
between different levels of cdissect's recursion needs to be.
With the right spec, we can fix this using fewer rather than more
resets of the match data; the key decision being that a failed
sub-match is now explicitly responsible for clearing any matches
it may have set.
There are enough other cross-checks and optimizations in the code
that it's not especially easy to exhibit this problem; usually, the
match will fail as-expected. Plus, regexps that are even potentially
vulnerable are most likely user errors, since there's just not much
point in writing a back-ref that doesn't always have a referent.
These facts perhaps explain why the issue hasn't been detected,
even though it's almost certainly a couple of decades old.
Discussion: https://postgr.es/m/[email protected]
M src/backend/regex/regexec.c
M src/test/regress/expected/regex.out
M src/test/regress/sql/regex.sql
Avoid creating archive status ".ready" files too early
commit : cf69f7109cd8bd5908c2c23190e39ec3d69be309
author : Alvaro Herrera <[email protected]>
date : Mon, 23 Aug 2021 15:50:35 -0400
committer: Alvaro Herrera <[email protected]>
date : Mon, 23 Aug 2021 15:50:35 -0400
WAL records may span multiple segments, but XLogWrite() does not
wait for the entire record to be written out to disk before
creating archive status files. Instead, as soon as the last WAL page of
the segment is written, the archive status file is created, and the
archiver may process it. If PostgreSQL crashes before it is able to
write and flush the rest of the record (in the next WAL segment), the
wrong version of the first segment file lingers in the archive, which
causes operations such as point-in-time restores to fail.
To fix this, keep track of records that span across segments and ensure
that segments are only marked ready-for-archival once such records have
been completely written to disk.
This has always been wrong, so backpatch all the way back.
Author: Nathan Bossart <[email protected]>
Reviewed-by: Kyotaro Horiguchi <[email protected]>
Reviewed-by: Ryo Matsumura <[email protected]>
Reviewed-by: Andrey Borodin <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/transam/xlog.c
M src/backend/postmaster/walwriter.c
M src/include/access/xlog.h
M src/include/access/xlogdefs.h
Fix performance bug in regexp's citerdissect/creviterdissect.
commit : 9610852ab3a4b4309d8b0d0d3616b83033871a41
author : Tom Lane <[email protected]>
date : Fri, 20 Aug 2021 14:19:04 -0400
committer: Tom Lane <[email protected]>
date : Fri, 20 Aug 2021 14:19:04 -0400
After detecting a sub-match "dissect" failure (i.e., a backref match
failure) in the i'th sub-match of an iteration node, we should proceed
by adjusting the attempted length of the i'th submatch. As coded,
though, these functions changed the attempted length of the *last*
sub-match, and only after exhausting all possibilities for that would
they back up to adjust the next-to-last sub-match, and then the
second-from-last, etc; all of which is wasted effort, since only
changing the start or length of the i'th sub-match can possibly make
it succeed. This oversight creates the possibility for exponentially
bad performance. Fortunately the problem is masked in most cases by
optimizations or constraints applied elsewhere; which explains why
we'd not noticed it before. But it is possible to reach the problem
with fairly simple, if contrived, regexps.
Oversight in my commit 173e29aa5. That's pretty ancient now,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/regex/regexec.c
Avoid trying to lock OLD/NEW in a rule with FOR UPDATE.
commit : fbc1eed8a8dd3178de70de53a0e95786c80f9dbc
author : Tom Lane <[email protected]>
date : Thu, 19 Aug 2021 12:12:35 -0400
committer: Tom Lane <[email protected]>
date : Thu, 19 Aug 2021 12:12:35 -0400
transformLockingClause neglected to exclude the pseudo-RTEs for
OLD/NEW when processing a rule's query. This led to odd errors
or even crashes later on. This bug is very ancient, but it's
not terribly surprising that nobody noticed, since the use-case
for SELECT FOR UPDATE in a non-view rule is somewhere between
thin and non-existent. Still, crashing is not OK.
Per bug #17151 from Zhiyong Wu. Thanks to Masahiko Sawada
for analysis of the problem.
Discussion: https://postgr.es/m/[email protected]
M src/backend/parser/analyze.c
M src/include/nodes/parsenodes.h
M src/test/regress/expected/rules.out
M src/test/regress/sql/rules.sql
Fix check_agg_arguments' examination of aggregate FILTER clauses.
commit : a65319f093a61cecda7e27f94521704855861046
author : Tom Lane <[email protected]>
date : Wed, 18 Aug 2021 18:12:51 -0400
committer: Tom Lane <[email protected]>
date : Wed, 18 Aug 2021 18:12:51 -0400
Recursion into the FILTER clause was mis-implemented, such that a
relevant Var or Aggref at the very top of the FILTER clause would
be ignored. (Of course, that'd have to be a plain boolean Var or
boolean-returning aggregate.) The consequence would be
mis-identification of the correct semantic level of the aggregate,
which could lead to not-per-spec query behavior. If the FILTER
expression is an aggregate, this could also lead to failure to issue
an expected "aggregate function calls cannot be nested" error, which
would likely result in a core dump later on, since the planner and
executor aren't expecting such cases to appear.
The root cause is that commit b560ec1b0 blindly copied some code
that assumed it's recursing into a List, and thus didn't examine the
top-level node. To forestall questions about why this call doesn't
look like the others, as well as possible future copy-and-paste
mistakes, let's change all three check_agg_arguments_walker calls in
check_agg_arguments, even though only the one for the filter clause
is really broken.
Per bug #17152 from Zhiyong Wu. This has been wrong since we
implemented FILTER, so back-patch to all supported versions.
(Testing suggests that pre-v11 branches manage to avoid crashing
in the bad-Aggref case, thanks to "redundant" checks in ExecInitAgg.
But I'm not sure how thorough that protection is, and anyway the
wrong-behavior issue remains, so fix 9.6 and 10 too.)
Discussion: https://postgr.es/m/[email protected]
M src/backend/parser/parse_agg.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql
Set type identifier on BIO
commit : f1d5a94fc738a7de89664e0984766622a89d540d
author : Daniel Gustafsson <[email protected]>
date : Tue, 17 Aug 2021 14:27:37 +0200
committer: Daniel Gustafsson <[email protected]>
date : Tue, 17 Aug 2021 14:27:37 +0200
In OpenSSL there are two types of BIO's (I/O abstractions):
source/sink and filters. A source/sink BIO is a source and/or
sink of data, ie one acting on a socket or a file. A filter
BIO takes a stream of input from another BIO and transforms it.
In order for BIO_find_type() to be able to traverse the chain
of BIO's and correctly find all BIO's of a certain type they
shall have the type bit set accordingly, source/sink BIO's
(what PostgreSQL implements) use BIO_TYPE_SOURCE_SINK and
filter BIO's use BIO_TYPE_FILTER. In addition to these, file
descriptor based BIO's should have the descriptor bit set,
BIO_TYPE_DESCRIPTOR.
The PostgreSQL implementation didn't set the type bits, which
went unnoticed for a long time as it's only really relevant
for code auditing the OpenSSL installation, or doing similar
tasks. It is required by the API though, so this fixes it.
Backpatch through 9.6 as this has been wrong for a long time.
Author: Itamar Gafni
Discussion: https://postgr.es/m/SN6PR06MB39665EC10C34BB20956AE4578AF39@SN6PR06MB3966.namprd06.prod.outlook.com
Backpatch-through: 9.6
M src/backend/libpq/be-secure-openssl.c
M src/interfaces/libpq/fe-secure-openssl.c
doc: \123 and \x12 escapes in COPY are in database encoding.
commit : b889d6c7196d120c9e9a357dea5cd77d68018600
author : Heikki Linnakangas <[email protected]>
date : Tue, 17 Aug 2021 10:00:06 +0300
committer: Heikki Linnakangas <[email protected]>
date : Tue, 17 Aug 2021 10:00:06 +0300
The backslash sequences, including \123 and \x12 escapes, are interpreted
after encoding conversion. The docs failed to mention that.
Backpatch to all supported versions.
Reported-by: Andreas Grob
Discussion: https://www.postgresql.org/message-id/17142-9181542ca1df75ab%40postgresql.org
M doc/src/sgml/ref/copy.sgml
Refresh apply delay on reload of recovery_min_apply_delay at recovery
commit : d392e86fa9c4ef5170eebf700d81f77ede4363ad
author : Michael Paquier <[email protected]>
date : Mon, 16 Aug 2021 12:11:59 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 16 Aug 2021 12:11:59 +0900
This commit ensures that the wait interval in the replay delay loop
waiting for an amount of time defined by recovery_min_apply_delay is
correctly handled on reload, recalculating the delay if this GUC value
is updated, based on the timestamp of the commit record being replayed.
The previous behavior would be problematic for example with replay
still waiting even if the delay got reduced or just cancelled. If the
apply delay was increased to a larger value, the wait would have just
respected the old value set, finishing earlier.
Author: Soumyadeep Chakraborty, Ashwin Agrawal
Reviewed-by: Kyotaro Horiguchi, Michael Paquier
Discussion: https://postgr.es/m/CAE-ML+93zfr-HLN8OuxF0BjpWJ17O5dv1eMvSE5jsj9jpnAXZA@mail.gmail.com
Backpatch-through: 9.6
M src/backend/access/transam/xlog.c
Add RISC-V spinlock support in s_lock.h.
commit : 8024ff478ba7ef65dfe25594f36a02265faed133
author : Tom Lane <[email protected]>
date : Fri, 13 Aug 2021 13:58:47 -0400
committer: Tom Lane <[email protected]>
date : Fri, 13 Aug 2021 13:58:47 -0400
Like the ARM case, just use gcc's __sync_lock_test_and_set();
that will compile into AMOSWAP.W.AQ which does what we need.
At some point it might be worth doing some work on atomic ops
for RISC-V, but this should be enough for a creditable port.
Back-patch to all supported branches, just in case somebody
wants to try them on RISC-V.
Marek Szuba
Discussion: https://postgr.es/m/[email protected]
M src/include/storage/s_lock.h
Fix incorrect hash table resizing code in simplehash.h
commit : 5a6b0f21e67921118dfd290b1d005789ac006fb7
author : David Rowley <[email protected]>
date : Fri, 13 Aug 2021 16:43:46 +1200
committer: David Rowley <[email protected]>
date : Fri, 13 Aug 2021 16:43:46 +1200
This fixes a bug in simplehash.h which caused an incorrect size mask to be
used when the hash table grew to SH_MAX_SIZE (2^32). The code was
incorrectly setting the size mask to 0 when the hash tables reached the
maximum possible number of buckets. This would result always trying to
use the 0th bucket causing an infinite loop of trying to grow the hash
table due to there being too many collisions.
Seemingly it's not that common for simplehash tables to ever grow this big
as this bug dates back to v10 and nobody seems to have noticed it before.
However, probably the most likely place that people would notice it would
be doing a large in-memory Hash Aggregate with something close to at least
2^31 groups.
After this fix, the code now works correctly with up to within 98% of 2^32
groups and will fail with the following error when trying to insert any
more items into the hash table:
ERROR: hash table size exceeded
However, the work_mem (or hash_mem_multiplier in newer versions) settings
will generally cause Hash Aggregates to spill to disk long before reaching
that many groups. The minimal test case I did took a work_mem setting of
over 192GB to hit the bug.
simplehash hash tables are used in a few other places such as Bitmap Index
Scans, however, again the size that the hash table can become there is
also limited to work_mem and it would take a relation of around 16TB
(2^31) pages and a very large work_mem setting to hit this. With smaller
work_mem values the table would become lossy and never grow large enough
to hit the problem.
Author: Yura Sokolov
Reviewed-by: David Rowley, Ranier Vilela
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 10, where simplehash.h was added
M src/include/lib/simplehash.h
Make EXEC_BACKEND more convenient on macOS.
commit : 0bfefb7dafe0019715075b6e8bf58ed5de58bffa
author : Thomas Munro <[email protected]>
date : Fri, 13 Aug 2021 10:38:22 +1200
committer: Thomas Munro <[email protected]>
date : Fri, 13 Aug 2021 10:38:22 +1200
It's hard to disable ASLR on current macOS releases, for testing with
-DEXEC_BACKEND. You could already set the environment variable
PG_SHMEM_ADDR to something not likely to collide with mappings created
earlier in process startup. Let's also provide a default value that
works on current releases and architectures, for developer convenience.
As noted in the pre-existing comment, this is a horrible hack, but
-DEXEC_BACKEND is only used by Unix-based PostgreSQL developers for
testing some otherwise Windows-only code paths, so it seems excusable.
Back-patch to all supported branches.
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/20210806032944.m4tz7j2w47mant26%40alap3.anarazel.de
M src/backend/port/sysv_shmem.c
Fix failure of btree_gin indexscans with "char" type and </<= operators.
commit : eefa4c2b5ed647fed9795f79ed4287898fae9ce6
author : Tom Lane <[email protected]>
date : Tue, 10 Aug 2021 18:10:30 -0400
committer: Tom Lane <[email protected]>
date : Tue, 10 Aug 2021 18:10:30 -0400
As a result of confusion about whether the "char" type is signed or
unsigned, scans for index searches like "col < 'x'" or "col <= 'x'"
would start at the middle of the index not the left end, thus missing
many or all of the entries they should find. Fortunately, this
is not a symptom of index corruption. It's only the search logic
that is broken, and we can fix it without unpleasant side-effects.
Per report from Jason Kim. This has been wrong since btree_gin's
beginning, so back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M contrib/btree_gin/btree_gin.c
M contrib/btree_gin/expected/char.out