Update xml_1.out and xml_2.out
commit : 5139db55636bc39c06232ada1b195f7d5d6950e0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 May 2022 23:19:53 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 May 2022 23:19:53 +0200
Commit 0fbf01120023 should have updated them but didn't.
M src/test/regress/expected/xml_1.out
M src/test/regress/expected/xml_2.out
Check column list length in XMLTABLE/JSON_TABLE alias
commit : 80656f00f85668bb828c1eb878876e5bedcbf4c4
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 May 2022 20:28:31 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 May 2022 20:28:31 +0200
We weren't checking the length of the column list in the alias clause of
an XMLTABLE or JSON_TABLE function (a "tablefunc" RTE), and it was
possible to make the server crash by passing an overly long one. Fix it
by throwing an error in that case, like the other places that deal with
alias lists.
In passing, modify the equivalent test used for join RTEs to look like
the other ones, which was different for no apparent reason.
This bug came in when XMLTABLE was born in version 10; backpatch to all
stable versions.
Reported-by: Wang Ke <krking@zju.edu.cn>
Discussion: https://postgr.es/m/17480-1c9d73565bb28e90@postgresql.org
M src/backend/parser/parse_clause.c
M src/backend/parser/parse_relation.c
M src/test/regress/expected/int2.out
M src/test/regress/expected/join.out
M src/test/regress/expected/with.out
M src/test/regress/expected/xml.out
M src/test/regress/sql/int2.sql
M src/test/regress/sql/join.sql
M src/test/regress/sql/with.sql
M src/test/regress/sql/xml.sql
Fix control file update done in restartpoints still running after promotion
commit : 2e9559b30239ce3cf69383ced208a72a7eb99335
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 16 May 2022 11:26:26 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 16 May 2022 11:26:26 +0900
If a cluster is promoted (aka the control file shows a state different
than DB_IN_ARCHIVE_RECOVERY) while CreateRestartPoint() is still
processing, this function could miss an update of the control file for
"checkPoint" and "checkPointCopy" but still do the recycling and/or
removal of the past WAL segments, assuming that the to-be-updated LSN
values should be used as reference points for the cleanup. This causes
a follow-up restart attempting crash recovery to fail with a PANIC on a
missing checkpoint record if the end-of-recovery checkpoint triggered by
the promotion did not complete while the cluster abruptly stopped or
crashed before the completion of this checkpoint. The PANIC would be
caused by the redo LSN referred in the control file as located in a
segment already gone, recycled by the previous restartpoint with
"checkPoint" out-of-sync in the control file.
This commit fixes the update of the control file during restartpoints so
as "checkPoint" and "checkPointCopy" are updated even if the cluster has
been promoted while a restartpoint is running, to be on par with the set
of WAL segments actually recycled in the end of CreateRestartPoint().
7863ee4 has fixed this problem already on master, but the release timing
of the latest point versions did not let me enough time to study and fix
that on all the stable branches.
Reported-by: Fujii Masao, Rui Zhao
Author: Kyotaro Horiguchi
Reviewed-by: Nathan Bossart, Michael Paquier
Discussion: https://postgr.es/m/20220316.102444.2193181487576617583.horikyota.ntt@gmail.com
Backpatch-through: 10
M src/backend/access/transam/xlog.c
Make pull_var_clause() handle GroupingFuncs exactly like Aggrefs.
commit : b7579b25c8159bfda7b70c9ec005aae243017563
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 May 2022 11:31:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 May 2022 11:31:46 -0400
This follows in the footsteps of commit 2591ee8ec by removing one more
ill-advised shortcut from planning of GroupingFuncs. It's true that
we don't intend to execute the argument expression(s) at runtime, but
we still have to process any Vars appearing within them, or we risk
failure at setrefs.c time (or more fundamentally, in EXPLAIN trying
to print such an expression). Vars in upper plan nodes have to have
referents in the next plan level, whether we ever execute 'em or not.
Per bug #17479 from Michael J. Sullivan. Back-patch to all supported
branches.
Richard Guo
Discussion: https://postgr.es/m/17479-6260deceaf0ad304@postgresql.org
M src/backend/optimizer/util/var.c
M src/test/regress/expected/groupingsets.out
M src/test/regress/sql/groupingsets.sql
Fix the logical replication timeout during large transactions.
commit : 55558df2374167af38534df988ec3b9d0b0019f0
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 11 May 2022 10:41:24 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 11 May 2022 10:41:24 +0530
The problem is that we don't send keep-alive messages for a long time
while processing large transactions during logical replication where we
don't send any data of such transactions. This can happen when the table
modified in the transaction is not published or because all the changes
got filtered. We do try to send the keep_alive if necessary at the end of
the transaction (via WalSndWriteData()) but by that time the
subscriber-side can timeout and exit.
To fix this we try to send the keepalive message if required after
processing certain threshold of changes.
Reported-by: Fabrice Chapuis
Author: Wang wei and Amit Kapila
Reviewed By: Masahiko Sawada, Euler Taveira, Hou Zhijie, Hayato Kuroda
Backpatch-through: 10
Discussion: https://postgr.es/m/CAA5-nLARN7-3SLU_QUxfy510pmrYK6JJb=bk3hcgemAM_pAv+w@mail.gmail.com
M src/backend/replication/logical/logical.c
M src/backend/replication/pgoutput/pgoutput.c
M src/backend/replication/walsender.c
M src/include/replication/logical.h
Improve setup of environment values for commands in MSVC's vcregress.pl
commit : b9d70ef34b833fd63e3ff9f049dbbcdfda9dc9fe
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 11 May 2022 10:22:34 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 11 May 2022 10:22:34 +0900
The current setup assumes that commands for lz4, zstd and gzip always
exist by default if not enforced by a user's environment. However,
vcpkg, as one example, installs libraries but no binaries, so this
default setup to assume that a command should always be present would
cause failures. This commit improves the detection of such external
commands as follows:
* If a ENV value is available, trust the environment/user and use it.
* If a ENV value is not available, check its execution by looking in the
current PATH, by launching a simple "$command --version" (that should be
portable enough).
** On execution failure, ignore ENV{command}.
** On execution success, set ENV{command} = "$command".
Note that this new rule applies to gzip, lz4 and zstd but not tar that
we assume will always exist. Those commands are set up in the
environment only when using bincheck and taptest. The CI includes all
those commands and I have checked that their setup is correct there. I
have also tested this change in a MSVC environment where we have none of
those commands.
While on it, remove the references to lz4 from the documentation and
vcregress.pl in ~v13. --with-lz4 has been added in v14~ so there is no
point to have this information in these older branches.
Reported-by: Andrew Dunstan
Reviewed-by: Andrew Dunstan
Discussion: https://postgr.es/m/14402151-376b-a57a-6d0c-10ad12608e12@dunslane.net
Backpatch-through: 10
M doc/src/sgml/install-windows.sgml
M src/tools/msvc/vcregress.pl
configure: don't probe for libldap_r if libldap is 2.5 or newer.
commit : af9b967671533965debc9caf3e20fd65a3c71ae4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 May 2022 18:42:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 May 2022 18:42:02 -0400
In OpenLDAP 2.5 and later, libldap itself is always thread-safe and
there's never a libldap_r. Our existing coding dealt with that
by assuming it wouldn't find libldap_r if libldap is thread-safe.
But that rule fails to cope if there are multiple OpenLDAP versions
visible, as is likely to be the case on macOS in particular. We'd
end up using shiny new libldap in the backend and a hoary libldap_r
in libpq.
Instead, once we've found libldap, check if it's >= 2.5 (by
probing for a function introduced then) and don't bother looking
for libldap_r if so. While one can imagine library setups that
this'd still give the wrong answer for, they seem unlikely to
occur in practice.
Per report from Peter Eisentraut. Back-patch to all supported branches.
Discussion: https://postgr.es/m/fedacd7c-2a38-25c9-e7ff-dea549d0e979@enterprisedb.com
M configure
M configure.in
Stamp 13.7.
commit : 4695fdb40fbb1e977e7e62f7d9af1fa948230d6a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 17:16:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 17:16:30 -0400
M configure
M configure.in
Last-minute updates for release notes.
commit : 0c8215c7b6bdf528edab88943438f0db9afad49b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 14:29:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 14:29:53 -0400
Security: CVE-2022-1552
M doc/src/sgml/release-13.sgml
Fix core dump in transformValuesClause when there are no columns.
commit : 91a3a74c65f4094420b28c393ac1d38af8ae4c4a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 14:15:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 14:15:37 -0400
The parser code that transformed VALUES from row-oriented to
column-oriented lists failed if there were zero columns.
You can't write that straightforwardly (though probably you
should be able to), but the case can be reached by expanding
a "tab.*" reference to a zero-column table.
Per bug #17477 from Wang Ke. Back-patch to all supported branches.
Discussion: https://postgr.es/m/17477-0af3c6ac6b0a6ae0@postgresql.org
M src/backend/parser/analyze.c
M src/test/regress/expected/select.out
M src/test/regress/sql/select.sql
Revert "Disallow infinite endpoints in generate_series() for timestamps."
commit : 7f0754bc4c0a0abadcbe02e886e31305c37a7053
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 11:02:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 May 2022 11:02:37 -0400
This reverts commit eafdf9de06e9b60168f5e47cedcfceecdc6d4b5f
and its back-branch counterparts. Corey Huinker pointed out that
we'd discussed this exact change back in 2016 and rejected it,
on the grounds that there's at least one usage pattern with LIMIT
where an infinite endpoint can usefully be used. Perhaps that
argument needs to be re-litigated, but there's no time left before
our back-branch releases. To keep our options open, restore the
status quo ante; if we do end up deciding to change things, waiting
one more quarter won't hurt anything.
Rather than just doing a straight revert, I added a new test case
demonstrating the usage with LIMIT. That'll at least remind us of
the issue if we forget again.
Discussion: https://postgr.es/m/3603504.1652068977@sss.pgh.pa.us
Discussion: https://postgr.es/m/CADkLM=dzw0Pvdqp5yWKxMd+VmNkAMhG=4ku7GnCZxebWnzmz3Q@mail.gmail.com
M src/backend/utils/adt/timestamp.c
M src/test/regress/expected/timestamp.out
M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/timestamp.sql
M src/test/regress/sql/timestamptz.sql
In REFRESH MATERIALIZED VIEW, set user ID before running user code.
commit : 88743d581e1bdedc13e4ca33c5a6597a5d2dbdc4
author : Noah Misch <noah@leadboat.com>
date : Mon, 9 May 2022 08:35:08 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 9 May 2022 08:35:08 -0700
It intended to, but did not, achieve this. Adopt the new standard of
setting user ID just after locking the relation. Back-patch to v10 (all
supported versions).
Reviewed by Simon Riggs. Reported by Alvaro Herrera.
Security: CVE-2022-1552
M src/backend/commands/matview.c
M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql
Make relation-enumerating operations be security-restricted operations.
commit : 35edcc0cee7bf7d4746e3e5b7966b1f0ec509560
author : Noah Misch <noah@leadboat.com>
date : Mon, 9 May 2022 08:35:08 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 9 May 2022 08:35:08 -0700
When a feature enumerates relations and runs functions associated with
all found relations, the feature's user shall not need to trust every
user having permission to create objects. BRIN-specific functionality
in autovacuum neglected to account for this, as did pg_amcheck and
CLUSTER. An attacker having permission to create non-temp objects in at
least one schema could execute arbitrary SQL functions under the
identity of the bootstrap superuser. CREATE INDEX (not a
relation-enumerating operation) and REINDEX protected themselves too
late. This change extends to the non-enumerating amcheck interface.
Back-patch to v10 (all supported versions).
Sergey Shinderuk, reviewed (in earlier versions) by Alexander Lakhin.
Reported by Alexander Lakhin.
Security: CVE-2022-1552
M contrib/amcheck/expected/check_btree.out
M contrib/amcheck/sql/check_btree.sql
M contrib/amcheck/verify_nbtree.c
M src/backend/access/brin/brin.c
M src/backend/catalog/index.c
M src/backend/commands/cluster.c
M src/backend/commands/indexcmds.c
M src/backend/utils/init/miscinit.c
M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql
Translation updates
commit : 916463773c9b873c3537a735bd09183bb8488d0f
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 9 May 2022 12:27:22 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 9 May 2022 12:27:22 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 7c8dcb6669ccc6ae33090d02ed92f0bad6ada742
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/ru.po
M src/bin/initdb/po/sv.po
M src/bin/pg_archivecleanup/po/sv.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_checksums/po/sv.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_config/po/sv.po
M src/bin/pg_controldata/po/sv.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_ctl/po/sv.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_resetwal/po/sv.po
M src/bin/pg_rewind/po/de.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/sv.po
M src/bin/pg_test_timing/po/sv.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_verifybackup/po/sv.po
M src/bin/pg_waldump/po/ru.po
M src/bin/pg_waldump/po/sv.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/sv.po
M src/bin/scripts/po/ru.po
M src/bin/scripts/po/sv.po
M src/interfaces/ecpg/ecpglib/po/sv.po
M src/interfaces/ecpg/preproc/po/sv.po
M src/interfaces/libpq/po/de.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/ru.po
M src/pl/plperl/po/sv.po
M src/pl/plpgsql/src/po/sv.po
M src/pl/plpython/po/sv.po
M src/pl/tcl/po/sv.po
Disable 031_recovery_conflict.pl until after minor releases.
commit : 6348e46850681daf1e648fd11cafabbe4aba8597
author : Andres Freund <andres@anarazel.de>
date : Sun, 8 May 2022 17:59:30 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 8 May 2022 17:59:30 -0700
f40d362a667 disabled part of 031_recovery_conflict.pl due to instability
that's not trivial to fix in the back branches. That fixed most of the
issues. But there was one more failure (on lapwing / REL_10_STABLE).
That failure looks like it might be caused by a genuine problem. Disable the
test until after the set of releases, to avoid packagers etc potentially
having to fight with a test failure they can't do anything about.
Discussion: https://postgr.es/m/3447060.1652032749@sss.pgh.pa.us
Backpatch: 10-14
M src/test/recovery/t/031_recovery_conflict.pl
Release notes for 14.3, 13.7, 12.11, 11.16, 10.21.
commit : fdaaba15397a71786a8ddcd987e067ab94e2b45c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 May 2022 12:36:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 May 2022 12:36:38 -0400
M doc/src/sgml/release-13.sgml
Fix back-patch of "Under has_wal_read_bug, skip .../001_wal.pl."
commit : 4caa85e4f358c8c442fd5855fbc2d80237d3e857
author : Noah Misch <noah@leadboat.com>
date : Sat, 7 May 2022 09:12:56 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 7 May 2022 09:12:56 -0700
Per buildfarm members tadarida, snapper, and kittiwake. Back-patch to
v10 (all supported versions).
M contrib/bloom/t/001_wal.pl
Under has_wal_read_bug, skip contrib/bloom/t/001_wal.pl.
commit : 23213f53ba206f8104ccbac9934190fdbfbfc082
author : Noah Misch <noah@leadboat.com>
date : Sat, 7 May 2022 00:33:15 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 7 May 2022 00:33:15 -0700
Per buildfarm members snapper and kittiwake. Back-patch to v10 (all
supported versions).
Discussion: https://postgr.es/m/20220116210241.GC756210@rfd.leadboat.com
M contrib/bloom/t/001_wal.pl
Temporarily skip recovery deadlock test in back branches.
commit : 4e39957e6eb52887c2d631e9edf08a07c306ec9f
author : Andres Freund <andres@anarazel.de>
date : Fri, 6 May 2022 09:01:08 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 6 May 2022 09:01:08 -0700
The recovery deadlock test has a timing issue that was fixed in 5136967f1eb in
HEAD. Unfortunately the same fix doesn't quite work in the back branches: 1)
adjust_conf() doesn't exist, which is easy enough to work around 2) a restart
cleares the recovery conflict stats < 15.
These issues can be worked around, but given the upcoming set of minor
releases, skip the problematic test for now. The buildfarm doesn't show
failures in other parts of 031_recovery_conflict.pl.
Discussion: https://postgr.es/m/20220506155827.dfnaheq6ufylwrqf@alap3.anarazel.de
Backpatch: 10-14
M src/test/recovery/t/031_recovery_conflict.pl
Backpatch addition of pump_until() more completely.
commit : 6ab90d215afcec4c8d6583cb359ee0c1c1530a20
author : Andres Freund <andres@anarazel.de>
date : Fri, 6 May 2022 08:39:07 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 6 May 2022 08:39:07 -0700
In a2ab9c06ea1 I just backpatched the introduction of pump_until(), without
changing the existing local definitions (as 6da65a3f9a9). The necessary
changes seemed more verbose than desirable. However, that leads to warnings,
as I failed to realize...
Backpatch to all versions containing pump_until() calls before
f74496dd611 (there's none in 10).
Discussion: https://postgr.es/m/2808491.1651802860@sss.pgh.pa.us
Discussion: https://postgr.es/m/18b37361-b482-b9d8-f30d-6115cd5ce25c@enterprisedb.com
Backpatch: 11-14
M src/test/recovery/t/013_crash_restart.pl
Update time zone data files to tzdata release 2022a.
commit : e9735d1af176e73158931a14b5f304a42f94f7d6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 May 2022 14:54:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 May 2022 14:54:53 -0400
DST law changes in Palestine. Historical corrections for
Chile and Ukraine.
M src/timezone/data/tzdata.zi
Revert "Fix timing issue in deadlock recovery conflict test."
commit : 27e97d0747ad0b615fd05b468bf09b12de196e44
author : Andres Freund <andres@anarazel.de>
date : Wed, 4 May 2022 14:16:41 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 4 May 2022 14:16:41 -0700
This reverts commit 8a3a8d9f103e360fffc02089810a520e22521ae2.
M src/test/recovery/t/031_recovery_conflict.pl
Fix timing issue in deadlock recovery conflict test.
commit : 8a3a8d9f103e360fffc02089810a520e22521ae2
author : Andres Freund <andres@anarazel.de>
date : Wed, 4 May 2022 12:50:38 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 4 May 2022 12:50:38 -0700
Per buildfarm members longfin and skink.
Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de
Backpatch: 10-
M src/test/recovery/t/031_recovery_conflict.pl
Backpatch 031_recovery_conflict.pl.
commit : 0446d3bf3909247f06de9b8f08a739caf7cc72ca
author : Andres Freund <andres@anarazel.de>
date : Mon, 2 May 2022 18:29:35 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 2 May 2022 18:29:35 -0700
The prior commit showed that the introduction of recovery conflict tests was a
good idea. Without these tests it's hard to know that the fix didn't break
something...
031_recovery_conflict.pl was introduced in 9f8a050f68d and extended in
21e184403bf.
Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de
Backpatch: 10-14
A src/test/recovery/t/031_recovery_conflict.pl
Fix possibility of self-deadlock in ResolveRecoveryConflictWithBufferPin().
commit : 57c5ad168be1ce9a5e91adb4c576996921cd8627
author : Andres Freund <andres@anarazel.de>
date : Mon, 2 May 2022 18:25:00 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 2 May 2022 18:25:00 -0700
The tests added in 9f8a050f68d failed nearly reliably on FreeBSD in CI, and
occasionally on the buildfarm. That turns out to be caused not by a bug in the
test, but by a longstanding bug in recovery conflict handling.
The standby timeout handler, used by ResolveRecoveryConflictWithBufferPin(),
executed SendRecoveryConflictWithBufferPin() inside a signal handler. A bad
idea, because the deadlock timeout handler (or a spurious latch set) could
have interrupted ProcWaitForSignal(). If unlucky that could cause a
self-deadlock on ProcArrayLock, if the deadlock check is in
SendRecoveryConflictWithBufferPin()->CancelDBBackends().
To fix, set a flag in StandbyTimeoutHandler(), and check the flag in
ResolveRecoveryConflictWithBufferPin().
Subsequently the recovery conflict tests will be backpatched.
Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de
Backpatch: 10-
M src/backend/storage/ipc/standby.c
Backpatch addition of wait_for_log(), pump_until().
commit : 90abe1e17f9d3f725cf92a3ef43593ec56eaf671
author : Andres Freund <andres@anarazel.de>
date : Mon, 2 May 2022 18:09:43 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 2 May 2022 18:09:43 -0700
These were originally introduced in a2ab9c06ea1 and a2ab9c06ea1, as they are
needed by a about-to-be-backpatched test.
Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de
Backpatch: 10-14
M src/test/perl/PostgreSQL/Test/Utils.pm
M src/test/perl/PostgresNode.pm
M src/test/perl/TestLib.pm
Fix typo in comment.
commit : d85f2bfa09f64e52436e8f05a9e112e160bace65
author : Etsuro Fujita <efujita@postgresql.org>
date : Mon, 2 May 2022 16:45:04 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Mon, 2 May 2022 16:45:04 +0900
M src/backend/storage/ipc/latch.c
Inhibit mingw CRT's auto-globbing of command line arguments
commit : d9cede2c3bfd0739acf294e4e83b36ea9de36b83
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 25 Apr 2022 15:02:13 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 25 Apr 2022 15:02:13 -0400
For some reason by default the mingw C Runtime takes it upon itself to
expand program arguments that look like shell globbing characters. That
has caused much scratching of heads and mis-attribution of the causes of
some TAP test failures, so stop doing that.
This removes an inconsistency with Windows binaries built with MSVC,
which have no such behaviour.
Per suggestion from Noah Misch.
Backpatch to all live branches.
Discussion: https://postgr.es/m/20220423025927.GA1274057@rfd.leadboat.com
M src/common/exec.c
Remove inadequate assertion check in CTE inlining.
commit : e6440d5007aaa33f946ab63f2c1dfd1ee99e2050
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2022 17:58:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Apr 2022 17:58:52 -0400
inline_cte() expected to find exactly as many references to the
target CTE as its cterefcount indicates. While that should be
accurate for the tree as emitted by the parser, there are some
optimizations that occur upstream of here that could falsify it,
notably removal of unused subquery output expressions.
Trying to make the accounting 100% accurate seems expensive and
doomed to future breakage. It's not really worth it, because
all this code is protecting is downstream assumptions that every
referenced CTE has a plan. Let's convert those assertions to
regular test-and-elog just in case there's some actual problem,
and then drop the failing assertion.
Per report from Tomas Vondra (thanks also to Richard Guo for
analysis). Back-patch to v12 where the faulty code came in.
Discussion: https://postgr.es/m/29196a1e-ed47-c7ca-9be2-b1c636816183@enterprisedb.com
M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/subselect.c
M src/include/nodes/pathnodes.h
M src/test/regress/expected/with.out
M src/test/regress/sql/with.sql
Support new perl module namespace in stable branches
commit : 1c60a99dd9a2064125d503227d8f8b17d33dc4ed
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 21 Apr 2022 09:20:00 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 21 Apr 2022 09:20:00 -0400
Commit b3b4d8e68a moved our perl test modules to a better namespace
structure, but this has made life hard for people wishing to backpatch
improvements in the TAP tests. Here we alleviate much of that difficulty
by implementing the new module names on top of the old modules, mostly
by using a little perl typeglob aliasing magic, so that we don't have a
dual maintenance burden. This should work both for the case where a new
test is backpatched and the case where a fix to an existing test that
uses the new namespace is backpatched.
Reviewed by Michael Paquier
Per complaint from Andres Freund
Discussion: https://postgr.es/m/20220418141530.nfxtkohefvwnzncl@alap3.anarazel.de
Applied to branches 10 through 14
A src/test/perl/PostgreSQL/Test/Cluster.pm
A src/test/perl/PostgreSQL/Test/Utils.pm
M src/test/perl/PostgresNode.pm
M src/test/perl/TestLib.pm
Fix CLUSTER tuplesorts on abbreviated expressions.
commit : 1272630a249798a0fce6a00383c78f8129434523
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Apr 2022 17:17:39 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Apr 2022 17:17:39 -0700
CLUSTER sort won't use the datum1 SortTuple field when clustering
against an index whose leading key is an expression. This makes it
unsafe to use the abbreviated keys optimization, which was missed by the
logic that sets up SortSupport state. Affected tuplesorts output tuples
in a completely bogus order as a result (the wrong SortSupport based
comparator was used for the leading attribute).
This issue is similar to the bug fixed on the master branch by recent
commit cc58eecc5d. But it's a far older issue, that dates back to the
introduction of the abbreviated keys optimization by commit 4ea51cdfe8.
Backpatch to all supported versions.
Author: Peter Geoghegan <pg@bowt.ie>
Author: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/CA+hUKG+bA+bmwD36_oDxAoLrCwZjVtST2fqe=b4=qZcmU7u89A@mail.gmail.com
Backpatch: 10-
M src/backend/utils/sort/tuplesort.c
M src/test/regress/expected/cluster.out
M src/test/regress/sql/cluster.sql
Disallow infinite endpoints in generate_series() for timestamps.
commit : 8275ba773dfe3168115bb3d32728111d9c4becb6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Apr 2022 18:08:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Apr 2022 18:08:15 -0400
Such cases will lead to infinite loops, so they're of no practical
value. The numeric variant of generate_series() already threw error
for this, so borrow its message wording.
Per report from Richard Wesley. Back-patch to all supported branches.
Discussion: https://postgr.es/m/91B44E7B-68D5-448F-95C8-B4B3B0F5DEAF@duckdblabs.com
M src/backend/utils/adt/timestamp.c
M src/test/regress/expected/timestamp.out
M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/timestamp.sql
M src/test/regress/sql/timestamptz.sql
Fix breakage in AlterFunction().
commit : f583633bc130e8a572e5d29b9c8b2cc48885ecbf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Apr 2022 23:03:59 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Apr 2022 23:03:59 -0400
An ALTER FUNCTION command that tried to update both the function's
proparallel property and its proconfig list failed to do the former,
because it stored the new proparallel value into a tuple that was
no longer the interesting one. Carelessness in 7aea8e4f2.
(I did not bother with a regression test, because the only likely
future breakage would be for someone to ignore the comment I added
and add some other field update after the heap_modify_tuple step.
A test using existing function properties could not catch that.)
Per report from Bryn Llewellyn. Back-patch to all supported branches.
Discussion: https://postgr.es/m/8AC9A37F-99BD-446F-A2F7-B89AD0022774@yugabyte.com
M src/backend/commands/functioncmds.c
Fix the check to limit sync workers.
commit : 82d4a17a17508a4e6ff9038d81a7dfb9f19e104a
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 19 Apr 2022 09:08:05 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 19 Apr 2022 09:08:05 +0530
We don't allow to invoke more sync workers once we have reached the sync
worker limit per subscription. But the check to enforce this also doesn't
allow to launch an apply worker if it gets restarted.
This code was introduced by commit de43897122 but we caught the problem
only with the test added by recent commit c91f71b9dc which started failing
occasionally in the buildfarm.
As per buildfarm.
Diagnosed-by: Amit Kapila, Masahiko Sawada, Tomas Vondra
Author: Amit Kapila
Backpatch-through: 10
Discussion: https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektNRH8NJ1jf95g@mail.gmail.com
https://postgr.es/m/f90d2b03-4462-ce95-a524-d91464e797c8@enterprisedb.com
M src/backend/replication/logical/launcher.c
Avoid invalid array reference in transformAlterTableStmt().
commit : 69cefb3fb8377992bd2ad0dce1b33570b3e5244a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Apr 2022 12:16:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Apr 2022 12:16:45 -0400
Don't try to look at the attidentity field of system attributes,
because they're not there in the TupleDescAttr array. Sometimes
this is harmless because we accidentally pick up a zero, but
otherwise we'll report "no owned sequence found" from an attempt
to alter a system attribute. (It seems possible that a SIGSEGV
could occur, too, though I've not seen it in testing.)
It's not in this function's charter to complain that you can't
alter a system column, so instead just hard-wire an assumption
that system attributes aren't identities. I didn't bother with
a regression test because the appearance of the bug is very
erratic.
Per bug #17465 from Roman Zharkov. Back-patch to all supported
branches. (There's not actually a live bug before v12, because
before that get_attidentity() did the right thing anyway.
But for consistency I changed the test in the older branches too.)
Discussion: https://postgr.es/m/17465-f2a554a6cb5740d3@postgresql.org
M src/backend/parser/parse_utilcmd.c
Fix race in TAP test 002_archiving.pl when restoring history file
commit : a6fc64b9a85e279c5a284c21374edeb857df5252
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 18 Apr 2022 11:40:18 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 18 Apr 2022 11:40:18 +0900
This test, introduced in df86e52, uses a second standby to check that
it is able to remove correctly RECOVERYHISTORY and RECOVERYXLOG at the
end of recovery. This standby uses the archives of the primary to
restore its contents, with some of the archive's contents coming from
the first standby previously promoted. In slow environments, it was
possible that the test did not check what it should, as the history file
generated by the promotion of the first standby may not be stored yet on
the archives the second standby feeds on. So, it could be possible that
the second standby selects an incorrect timeline, without restoring a
history file at all.
This commits adds a wait phase to make sure that the history file
required by the second standby is archived before this cluster is
created. This relies on poll_query_until() with pg_stat_file() and an
absolute path, something not supported in REL_10_STABLE.
While on it, this adds a new test to check that the history file has
been restored by looking at the logs of the second standby. This
ensures that a RECOVERYHISTORY, whose removal needs to be checked,
is created in the first place. This should make the test more robust.
This test has been introduced by df86e52, but it came in light as an
effect of the bug fixed by acf1dd42, where the extra restore_command
calls made the test much slower.
Reported-by: Andres Freund
Discussion: https://postgr.es/m/YlT23IvsXkGuLzFi@paquier.xyz
Backpatch-through: 11
M src/test/recovery/t/002_archiving.pl
Add a temp-install prerequisite to src/interfaces/ecpg "checktcp".
commit : b404513de8579ce29ccb7becbb6e83587352263f
author : Noah Misch <noah@leadboat.com>
date : Sat, 16 Apr 2022 17:43:54 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 16 Apr 2022 17:43:54 -0700
The target failed, tested $PATH binaries, or tested a stale temporary
installation. Commit c66b438db62748000700c9b90b585e756dd54141 missed
this. Back-patch to v10 (all supported versions).
M src/interfaces/ecpg/Makefile
Rethink the delay-checkpoint-end mechanism in the back-branches.
commit : d18c913b786c5ea82f7372c88cf2055050e5176a
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 14 Apr 2022 11:10:11 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 14 Apr 2022 11:10:11 -0400
The back-patch of commit bbace5697df12398e87ffd9879171c39d27f5b33 had
the unfortunate effect of changing the layout of PGPROC in the
back-branches, which could break extensions. This happened because it
changed the delayChkpt from type bool to type int. So, change it back,
and add a new bool delayChkptEnd field instead. The new field should
fall within what used to be padding space within the struct, and so
hopefully won't cause any extensions to break.
Per report from Markus Wanner and discussion with Tom Lane and others.
Patch originally by me, somewhat revised by Markus Wanner per a
suggestion from Michael Paquier. A very similar patch was developed
by Kyotaro Horiguchi, but I failed to see the email in which that was
posted before writing one of my own.
Discussion: http://postgr.es/m/CA+Tgmoao-kUD9c5nG5sub3F7tbo39+cdr8jKaOVEs_1aBWcJ3Q@mail.gmail.com
Discussion: http://postgr.es/m/20220406.164521.17171257901083417.horikyota.ntt@gmail.com
M src/backend/access/transam/multixact.c
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xloginsert.c
M src/backend/catalog/storage.c
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/ipc/procarray.c
M src/include/storage/proc.h
M src/include/storage/procarray.h
pageinspect: Fix handling of all-zero pages
commit : 2275d044d0849251c5e0fa10ee16c73124731f5c
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 14 Apr 2022 15:09:36 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 14 Apr 2022 15:09:36 +0900
Getting from get_raw_page() an all-zero page is considered as a valid
case by the buffer manager and it can happen for example when finding a
corrupted page with zero_damaged_pages enabled (using zero_damaged_pages
to look at corrupted pages happens), or after a crash when a relation
file is extended before any WAL for its new data is generated (before a
vacuum or autovacuum job comes in to do some cleanup).
However, all the functions of pageinspect, as of the index AMs (except
hash that has its own idea of new pages), heap, the FSM or the page
header have never worked with all-zero pages, causing various crashes
when going through the page internals.
This commit changes all the pageinspect functions to be compliant with
all-zero pages, where the choice is made to return NULL or no rows for
SRFs when finding a new page. get_raw_page() still works the same way,
returning a batch of zeros in the bytea of the page retrieved. A hard
error could be used but NULL, while more invasive, is useful when
scanning relation files in full to get a batch of results for a single
relation in one query. Tests are added for all the code paths
impacted.
Reported-by: Daria Lepikhova
Author: Michael Paquier
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
M contrib/pageinspect/brinfuncs.c
M contrib/pageinspect/btreefuncs.c
M contrib/pageinspect/expected/brin.out
M contrib/pageinspect/expected/btree.out
M contrib/pageinspect/expected/gin.out
M contrib/pageinspect/expected/hash.out
M contrib/pageinspect/expected/page.out
M contrib/pageinspect/fsmfuncs.c
M contrib/pageinspect/ginfuncs.c
M contrib/pageinspect/rawpage.c
M contrib/pageinspect/sql/brin.sql
M contrib/pageinspect/sql/btree.sql
M contrib/pageinspect/sql/gin.sql
M contrib/pageinspect/sql/hash.sql
M contrib/pageinspect/sql/page.sql
Prevent access to no-longer-pinned buffer in heapam_tuple_lock().
commit : 44096c31eaf0e9d86053434de8fdce418609c01e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 13 Apr 2022 13:35:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 13 Apr 2022 13:35:02 -0400
heap_fetch() used to have a "keep_buf" parameter that told it to return
ownership of the buffer pin to the caller after finding that the
requested tuple TID exists but is invisible to the specified snapshot.
This was thoughtlessly removed in commit 5db6df0c0, which broke
heapam_tuple_lock() (formerly EvalPlanQualFetch) because that function
needs to do more accesses to the tuple even if it's invisible. The net
effect is that we would continue to touch the page for a microsecond or
two after releasing pin on the buffer. Usually no harm would result;
but if a different session decided to defragment the page concurrently,
we could see garbage data and mistakenly conclude that there's no newer
tuple version to chain up to. (It's hard to say whether this has
happened in the field. The bug was actually found thanks to a later
change that allowed valgrind to detect accesses to non-pinned buffers.)
The most reasonable way to fix this is to reintroduce keep_buf,
although I made it behave slightly differently: buffer ownership
is passed back only if there is a valid tuple at the requested TID.
In HEAD, we can just add the parameter back to heap_fetch().
To avoid an API break in the back branches, introduce an additional
function heap_fetch_extended() in those branches.
In HEAD there is an additional, less obvious API change: tuple->t_data
will be set to NULL in all cases where buffer ownership is not returned,
in particular when the tuple exists but fails the time qual (and
!keep_buf). This is to defend against any other callers attempting to
access non-pinned buffers. We concluded that making that change in back
branches would be more likely to introduce problems than cure any.
In passing, remove a comment about heap_fetch that was obsoleted by
9a8ee1dc6.
Per bug #17462 from Daniil Anisimov. Back-patch to v12 where the bug
was introduced.
Discussion: https://postgr.es/m/17462-9c98a0f00df9bd36@postgresql.org
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/include/access/heapam.h
Docs: adjust pg_upgrade syntax to mark -B as optional
commit : 9144fa27dd7f0ad3a5ef818adb819c5375519115
author : David Rowley <drowley@postgresql.org>
date : Wed, 13 Apr 2022 11:20:06 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 13 Apr 2022 11:20:06 +1200
This was made optional in 959f6d6a1.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411020336.GB26620@telsasoft.com
Backpatch-through: 13, where -B was made optional
M doc/src/sgml/ref/pgupgrade.sgml
Doc: tweak textsearch.sgml for SEO purposes.
commit : 71e0736b6577962874ef3becd09cd74a43ffd92f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Apr 2022 18:21:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Apr 2022 18:21:04 -0400
Google seems to like to return textsearch.html for queries about
GIN and GiST indexes, even though it's not a primary reference
for either. It seems likely that that's because those keywords
appear in the page title. Since "GIN and GiST Index Types" is
not a very apposite title for this material anyway, rename the
section in hopes of stopping that.
Also provide explicit links to the GIN and GiST chapters, to help
anyone who finds their way to this page regardless.
Per gripe from Jan Piotrowski. Back-patch to supported branches.
(Unfortunately Google is likely to continue returning the 9.1
version of this page, but improving that situation is a matter
for the www team.)
Discussion: https://postgr.es/m/164978902252.1276550.9330175733459697101@wrigleys.postgresql.org
M doc/src/sgml/textsearch.sgml
Docs: avoid confusing use of the word "synchronized"
commit : e22fd217ec5b5b454febd5c1a1cc3c3f1c4e3a63
author : David Rowley <drowley@postgresql.org>
date : Wed, 13 Apr 2022 09:17:17 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 13 Apr 2022 09:17:17 +1200
It's misleading to call the data directory the "synchronized data
directory" when discussing a crash scenario when using pg_rewind's
--no-sync option. Here we just remove the word "synchronized" to avoid
any possible confusion.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20220411020336.GB26620@telsasoft.com
Backpatch-through: 12, where --no-sync was added
M doc/src/sgml/ref/pg_rewind.sgml
Suppress "variable 'pagesaving' set but not used" warning.
commit : 87166d25a4569ac06dc3dcf44fa8c12f0263f836
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 6 Apr 2022 17:03:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 6 Apr 2022 17:03:35 -0400
With asserts disabled, late-model clang notices that this variable
is incremented but never otherwise read.
Discussion: https://postgr.es/m/3171401.1649275153@sss.pgh.pa.us
M src/backend/access/nbtree/nbtdedup.c
Remove obsolete comment
commit : 8f4b5b09096ae5e470c6410312c24581da319733
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 2 Apr 2022 07:27:26 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 2 Apr 2022 07:27:26 +0200
accidentally left behind by 4cb658af70027c3544fb843d77b2e84028762747
M src/include/utils/rel.h
Fix postgres_fdw to check shippability of sort clauses properly.
commit : 79df1d20c59c7fa21326f85be90f875fbe229ec6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 31 Mar 2022 14:29:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 31 Mar 2022 14:29:24 -0400
postgres_fdw would push ORDER BY clauses to the remote side without
verifying that the sort operator is safe to ship. Moreover, it failed
to print a suitable USING clause if the sort operator isn't default
for the sort expression's type. The net result of this is that the
remote sort might not have anywhere near the semantics we expect,
which'd be disastrous for locally-performed merge joins in particular.
We addressed similar issues in the context of ORDER BY within an
aggregate function call in commit 7012b132d, but failed to notice
that query-level ORDER BY was broken. Thus, much of the necessary
logic already existed, but it requires refactoring to be usable
in both cases.
Back-patch to all supported branches. In HEAD only, remove the
core code's copy of find_em_expr_for_rel, which is no longer used
and really should never have been pushed into equivclass.c in the
first place.
Ronan Dunklau, per report from David Rowley;
reviews by David Rowley, Ranier Vilela, and myself
Discussion: https://postgr.es/m/CAApHDvr4OeC2DBVY--zVP83-K=bYrTD7F8SZDhN4g+pj2f2S-A@mail.gmail.com
M contrib/postgres_fdw/deparse.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/postgres_fdw.h
M contrib/postgres_fdw/sql/postgres_fdw.sql
Add missing newline in one libpq error message.
commit : fb1d7f4519665f0a6a15a8fd6acc4bb5f86f5697
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 31 Mar 2022 11:24:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 31 Mar 2022 11:24:26 -0400
Oversight in commit a59c79564. Back-patch, as that was.
Noted by Peter Eisentraut.
Discussion: https://postgr.es/m/7f85ef6d-250b-f5ec-9867-89f0b16d019f@enterprisedb.com
M src/interfaces/libpq/fe-secure-openssl.c
doc: Fix typo in ANALYZE documentation
commit : 8421a99ca189120af67df08a6308a0c97ab115ec
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Thu, 31 Mar 2022 12:03:33 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Thu, 31 Mar 2022 12:03:33 +0200
Commit 61fa6ca79b3 accidentally wrote constrast instead of contrast.
Backpatch-through: 10
Discussion: https://postgr.es/m/88903179-5ce2-3d4d-af43-7830372bdcb6@enterprisedb.com
M doc/src/sgml/ref/analyze.sgml
Fix typo in comment.
commit : f042dc6a415decc4e2a9707de5f3fc737e42e1ed
author : Etsuro Fujita <efujita@postgresql.org>
date : Wed, 30 Mar 2022 19:00:04 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Wed, 30 Mar 2022 19:00:04 +0900
M src/backend/commands/copy.c
Revert "Fix replay of create database records on standby"
commit : a54ed2de80ec844e578e26f93ab008c814f56090
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 29 Mar 2022 15:36:21 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 29 Mar 2022 15:36:21 +0200
This reverts commit 49d9cfc68bf4. The approach taken by this patch has
problems, so we'll come up with a radically different fix.
Discussion: https://postgr.es/m/CA+TgmoYcUPL+WOJL2ZzhH=zmrhj0iOQ=iCFM0SuYqBbqZEamEg@mail.gmail.com
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogutils.c
M src/backend/commands/dbcommands.c
M src/backend/commands/tablespace.c
M src/include/access/xlogutils.h
M src/tools/pgindent/typedefs.list
Document autoanalyze limitations for partitioned tables
commit : 78ebfd885be563191d659d7a4ae230e199792e3f
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Mon, 28 Mar 2022 14:27:36 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Mon, 28 Mar 2022 14:27:36 +0200
When dealing with partitioned tables, counters for partitioned tables
are not updated when modifying child tables. This means autoanalyze may
not update optimizer statistics for the parent relations, which can
result in poor plans for some queries.
It's worth documenting this limitation, so that people are aware of it
and can take steps to mitigate it (e.g. by setting up a script executing
ANALYZE regularly).
Backpatch to v10. Older branches are affected too, of couse, but we no
longer maintain those.
Author: Justin Pryzby
Reviewed-by: Zhihong Yu, Tomas Vondra
Backpatch-through: 10
Discussion: https://postgr.es/m/20210913035409.GA10647%40telsasoft.com
M doc/src/sgml/maintenance.sgml
M doc/src/sgml/ref/analyze.sgml
waldump: fix use-after-free in search_directory().
commit : 344d89abf36b9ea559a4b25543bbc7d4206988f5
author : Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 16:38:43 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 16:38:43 -0700
After closedir() dirent->d_name is not valid anymore. As there alerady are a
few places relying on the limited lifetime of pg_waldump, do so here as well,
and just pg_strdup() the string.
The bug was introduced in fc49e24fa69a.
Found by UBSan, run locally.
Backpatch: 11-, like fc49e24fa69 itself.
M src/bin/pg_waldump/pg_waldump.c
Fix breakage of get_ps_display() in the PS_USE_NONE case.
commit : 9016a2a3dc4ee7e41ecda5a8b3a3d3481de94964
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 27 Mar 2022 12:57:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 27 Mar 2022 12:57:46 -0400
Commit 8c6d30f21 caused this function to fail to set *displen
in the PS_USE_NONE code path. If the variable's previous value
had been negative, that'd lead to a memory clobber at some call
sites. We'd managed not to notice due to very thin test coverage
of such configurations, but this appears to explain buildfarm member
lorikeet's recent struggles.
Credit to Andrew Dunstan for spotting the problem. Back-patch
to v13 where the bug was introduced.
Discussion: https://postgr.es/m/136102.1648320427@sss.pgh.pa.us
M src/backend/utils/misc/ps_status.c
pageinspect: Add more sanity checks to prevent out-of-bound reads
commit : 3d4d6dee07777ed2a0f0f7e5938879e07ad02a82
author : Michael Paquier <michael@paquier.xyz>
date : Sun, 27 Mar 2022 17:53:55 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sun, 27 Mar 2022 17:53:55 +0900
A couple of code paths use the special area on the page passed by the
function caller, expecting to find some data in it. However, feeding
an incorrect page can lead to out-of-bound reads when trying to access
the page special area (like a heap page that has no special area,
leading PageGetSpecialPointer() to grab a pointer outside the allocated
page).
The functions used for hash and btree indexes have some protection
already against that, while some other functions using a relation OID
as argument would make sure that the access method involved is correct,
but functions taking in input a raw page without knowing the relation
the page is attached to would run into problems.
This commit improves the set of checks used in the code paths of BRIN,
btree (including one check if a leaf page is found with a non-zero
level), GIN and GiST to verify that the page given in input has a
special area size that fits with each access method, which is done
though PageGetSpecialSize(), becore calling PageGetSpecialPointer().
The scope of the checks done is limited to work with pages that one
would pass after getting a block with get_raw_page(), as it is possible
to craft byteas that could bypass existing code paths. Having too many
checks would also impact the usability of pageinspect, as the existing
code is very useful to look at the content details in a corrupted page,
so the focus is really to avoid out-of-bound reads as this is never a
good thing even with functions whose execution is limited to
superusers.
The safest approach could be to rework the functions so as these fetch a
block using a relation OID and a block number, but there are also cases
where using a raw page is useful.
Tests are added to cover all the code paths that needed such checks, and
an error message for hash indexes is reworded to fit better with what
this commit adds.
Reported-By: Alexander Lakhin
Author: Julien Rouhaud, Michael Paquier
Discussion: https://postgr.es/m/16527-ef7606186f0610a1@postgresql.org
Discussion: https://postgr.es/m/561e187b-3549-c8d5-03f5-525c14e65bd0@postgrespro.ru
Backpatch-through: 10
M contrib/pageinspect/brinfuncs.c
M contrib/pageinspect/btreefuncs.c
M contrib/pageinspect/expected/brin.out
M contrib/pageinspect/expected/btree.out
M contrib/pageinspect/expected/gin.out
M contrib/pageinspect/expected/hash.out
M contrib/pageinspect/ginfuncs.c
M contrib/pageinspect/hashfuncs.c
M contrib/pageinspect/sql/brin.sql
M contrib/pageinspect/sql/btree.sql
M contrib/pageinspect/sql/gin.sql
M contrib/pageinspect/sql/hash.sql
Suppress compiler warning in relptr_store().
commit : 4fbbea2c1934092581662553fd4be9e84630fc5c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Mar 2022 14:29:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Mar 2022 14:29:29 -0400
clang 13 with -Wextra warns that "performing pointer subtraction with
a null pointer has undefined behavior" in the places where freepage.c
tries to set a relptr variable to constant NULL. This appears to be
a compiler bug, but it's unlikely to get fixed instantly. Fortunately,
we can work around it by introducing an inline support function, which
seems like a good change anyway because it removes the macro's existing
double-evaluation hazard.
Backpatch to v10 where this code was introduced.
Patch by me, based on an idea of Andres Freund's.
Discussion: https://postgr.es/m/48826.1648310694@sss.pgh.pa.us
M src/include/utils/relptr.h
Harden TAP tests that intentionally corrupt page checksums.
commit : 6e9ffcf13a4a0d56f03b4048231066cb5d061299
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Mar 2022 14:23:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Mar 2022 14:23:26 -0400
The previous method for doing that was to write zeroes into a
predetermined set of page locations. However, there's a roughly
1-in-64K chance that the existing checksum will match by chance,
and yesterday several buildfarm animals started to reproducibly
see that, resulting in test failures because no checksum mismatch
was reported.
Since the checksum includes the page LSN, test success depends on
the length of the installation's WAL history, which is affected by
(at least) the initial catalog contents, the set of locales installed
on the system, and the length of the pathname of the test directory.
Sooner or later we were going to hit a chance match, and today is
that day.
Harden these tests by specifically inverting the checksum field and
leaving all else alone, thereby guaranteeing that the checksum is
incorrect.
In passing, fix places that were using seek() to set up for syswrite(),
a combination that the Perl docs very explicitly warn against. We've
probably escaped problems because no regular buffered I/O is done on
these filehandles; but if it ever breaks, we wouldn't deserve or get
much sympathy.
Although we've only seen problems in HEAD, now that we recognize the
environmental dependencies it seems like it might be just a matter
of time until someone manages to hit this in back-branch testing.
Hence, back-patch to v11 where we started doing this kind of test.
Discussion: https://postgr.es/m/3192026.1648185780@sss.pgh.pa.us
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/bin/pg_checksums/t/002_actions.pl
M src/test/perl/PostgresNode.pm
Fix replay of create database records on standby
commit : 50e3ed8e9172fe3cb9bc20899acaa4a8a0fd2388
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 25 Mar 2022 13:16:21 +0100
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 25 Mar 2022 13:16:21 +0100
Crash recovery on standby may encounter missing directories when
replaying create database WAL records. Prior to this patch, the standby
would fail to recover in such a case. However, the directories could be
legitimately missing. Consider a sequence of WAL records as follows:
CREATE DATABASE
DROP DATABASE
DROP TABLESPACE
If, after replaying the last WAL record and removing the tablespace
directory, the standby crashes and has to replay the create database
record again, the crash recovery must be able to move on.
This patch adds a mechanism similar to invalid-page tracking, to keep a
tally of missing directories during crash recovery. If all the missing
directory references are matched with corresponding drop records at the
end of crash recovery, the standby can safely continue following the
primary.
Backpatch to 13, at least for now. The bug is older, but fixing it in
older branches requires more careful study of the interactions with
commit e6d8069522c8, which appeared in 13.
A new TAP test file is added to verify the condition. However, because
it depends on commit d6d317dbf615, it can only be added to branch
master. I (Álvaro) manually verified that the code behaves as expected
in branch 14. It's a bit nervous-making to leave the code uncovered by
tests in older branches, but leaving the bug unfixed is even worse.
Also, the main reason this fix took so long is precisely that we
couldn't agree on a good strategy to approach testing for the bug, so
perhaps this is the best we can do.
Diagnosed-by: Paul Guo <paulguo@gmail.com>
Author: Paul Guo <paulguo@gmail.com>
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Author: Asim R Praveen <apraveen@pivotal.io>
Discussion: https://postgr.es/m/CAEET0ZGx9AvioViLf7nbR_8tH9-=27DN5xWJ2P9-ROH16e4JUA@mail.gmail.com
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogutils.c
M src/backend/commands/dbcommands.c
M src/backend/commands/tablespace.c
M src/include/access/xlogutils.h
M src/tools/pgindent/typedefs.list
Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.
commit : 1ce14b6b2fe4af9ac7d7f90eb46c77b2e6deb2de
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 24 Mar 2022 14:36:06 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 24 Mar 2022 14:36:06 -0400
If TRUNCATE causes some buffers to be invalidated and thus the
checkpoint does not flush them, TRUNCATE must also ensure that the
corresponding files are truncated on disk. Otherwise, a replay
from the checkpoint might find that the buffers exist but have
the wrong contents, which may cause replay to fail.
Report by Teja Mupparti. Patch by Kyotaro Horiguchi, per a design
suggestion from Heikki Linnakangas, with some changes to the
comments by me. Review of this and a prior patch that approached
the issue differently by Heikki Linnakangas, Andres Freund, Álvaro
Herrera, Masahiko Sawada, and Tom Lane.
Discussion: http://postgr.es/m/BYAPR06MB6373BF50B469CA393C614257ABF00@BYAPR06MB6373.namprd06.prod.outlook.com
M src/backend/access/transam/multixact.c
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xloginsert.c
M src/backend/catalog/storage.c
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/ipc/procarray.c
M src/backend/storage/lmgr/proc.c
M src/include/storage/proc.h
M src/include/storage/procarray.h
Don't try to translate NULL in GetConfigOptionByNum().
commit : c0f99bb520da577f34cf7c10e1ea4aab727f08c7
author : Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 13:05:59 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 13:05:59 -0700
Noticed via -fsanitize=undefined. Introduced when a few columns in
GetConfigOptionByNum() / pg_settings started to be translated in 72be8c29a /
PG 12.
Backpatch to all affected branches, for the same reasons as 46ab07ffda9.
Discussion: https://postgr.es/m/20220323173537.ll7klrglnp4gn2um@alap3.anarazel.de
Backpatch: 12-
M src/backend/utils/misc/guc.c
Don't call fwrite() with len == 0 when writing out relcache init file.
commit : 8014c61ebda10d39ef8855b4826aeba5cacd36e1
author : Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 13:05:25 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 13:05:25 -0700
Noticed via -fsanitize=undefined.
Backpatch to all branches, for the same reasons as 46ab07ffda9.
Discussion: https://postgr.es/m/20220323173537.ll7klrglnp4gn2um@alap3.anarazel.de
Backpatch: 10-
M src/backend/utils/cache/relcache.c
configure: check for dlsym instead of dlopen.
commit : 7c163aa93fe6e37f231cef9ac08d5041855228fa
author : Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 12:43:14 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 23 Mar 2022 12:43:14 -0700
When building with sanitizers the sanitizer library provides dlopen, but not
dlsym(), making configure think that -ldl isn't needed. Just checking for
dlsym() ought to suffice, hard to see dlsym() being provided without dlopen()
also being provided.
Backpatch to all branches, for the same reasons as 46ab07ffda9.
Reviewed-By: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/20220323173537.ll7klrglnp4gn2um@alap3.anarazel.de
Backpatch: 10-
M configure
M configure.in
pg_upgrade: Upgrade an Assert to a real 'if' test
commit : ca26c64581b529b2191757dbb27b94c6b0c101be
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 23 Mar 2022 19:23:51 +0100
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 23 Mar 2022 19:23:51 +0100
It seems possible for the condition being tested to be true in
production, and nobody would never know (except when some data
eventually becomes corrupt?).
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m//202109040001.zky3wgv2qeqg@alvherre.pgsql
M src/bin/pg_rewind/parsexlog.c
Fix "missing continuation record" after standby promotion
commit : 98eb3e06ce3a628adabeb90584c002a3c4bcec8e
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 23 Mar 2022 18:22:10 +0100
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 23 Mar 2022 18:22:10 +0100
Invalidate abortedRecPtr and missingContrecPtr after a missing
continuation record is successfully skipped on a standby. This fixes a
PANIC caused when a recently promoted standby attempts to write an
OVERWRITE_RECORD with an LSN of the previously read aborted record.
Backpatch to 10 (all stable versions).
Author: Sami Imseih <simseih@amazon.com>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m/44D259DE-7542-49C4-8A52-2AB01534DCA9@amazon.com
M src/backend/access/transam/xlog.c
M src/test/recovery/t/026_overwrite_contrecord.pl
Try to stabilize vacuum test.
commit : f784fcdc44435597c52b41f97bfbdf082a783c82
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 23 Mar 2022 14:31:18 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 23 Mar 2022 14:31:18 +1300
As commits b700f96c and 3414099c did for the reloptions test, make
sure VACUUM can always truncate the table as expected.
Back-patch to 12, where vacuum_truncate arrived.
Discussion: https://postgr.es/m/CAD21AoCNoWjYkdEtr%2BVDoF9v__V905AedKZ9iF%3DArgCtrbxZqw%40mail.gmail.com
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
Add missing dependency of pg_dumpall to WIN32RES.
commit : f183e23cc8a9107b6a8ddc7f16b97da926fddf94
author : Andres Freund <andres@anarazel.de>
date : Tue, 22 Mar 2022 08:22:02 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 22 Mar 2022 08:22:02 -0700
When cross-building to windows, or building with mingw on windows, the build
could fail with
x86_64-w64-mingw32-gcc: error: win32ver.o: No such file or director
because pg_dumpall didn't depend on WIN32RES, but it's recipe references
it. The build nevertheless succeeded most of the time, due to
pg_dump/pg_restore having the required dependency, causing win32ver.o to be
built.
Reported-By: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/CA+hUKGJeekpUPWW6yCVdf9=oBAcCp86RrBivo4Y4cwazAzGPng@mail.gmail.com
Backpatch: 10-, omission present on all live branches
M src/bin/pg_dump/Makefile
Fix failures in SSL tests caused by out-of-tree keys and certificates
commit : f32be9938ca48d9658eaf29a30c78f855d36e97a
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 22 Mar 2022 13:21:39 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 22 Mar 2022 13:21:39 +0900
This issue is environment-sensitive, where the SSL tests could fail in
various way by feeding on defaults provided by sslcert, sslkey,
sslrootkey, sslrootcert, sslcrl and sslcrldir coming from a local setup,
as of ~/.postgresql/ by default. Horiguchi-san has reported two
failures, but more advanced testing from me (aka inclusion of garbage
SSL configuration in ~/.postgresql/ for all the configuration
parameters) has showed dozens of failures that can be triggered in the
whole test suite.
History has showed that we are not good when it comes to address such
issues, fixing them locally like in dd87799, and such problems keep
appearing. This commit strengthens the entire test suite to put an end
to this set of problems by embedding invalid default values in all the
connection strings used in the tests. The invalid values are prefixed
in each connection string, relying on the follow-up values passed in the
connection string to enforce any invalid value previously set. Note
that two tests related to CRLs are required to fail with certain pre-set
configurations, but we can rely on enforcing an empty value instead
after the invalid set of values.
Reported-by: Kyotaro Horiguchi
Reviewed-by: Andrew Dunstan, Daniel Gustafsson, Kyotaro Horiguchi
Discussion: https://postgr.es/m/20220316.163658.1122740600489097632.horikyota.ntt@gmail.com
backpatch-through: 10
M src/test/ssl/t/001_ssltests.pl
Fix assorted missing logic for GroupingFunc nodes.
commit : dfefe38fbea4c6f003319a9921f3fd6ded5e70aa
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Mar 2022 17:44:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Mar 2022 17:44:29 -0400
The planner needs to treat GroupingFunc like Aggref for many purposes,
in particular with respect to processing of the argument expressions,
which are not to be evaluated at runtime. A few places hadn't gotten
that memo, notably including subselect.c's processing of outer-level
aggregates. This resulted in assertion failures or wrong plans for
cases in which a GROUPING() construct references an outer aggregation
level.
Also fix missing special cases for GroupingFunc in cost_qual_eval
(resulting in wrong cost estimates for GROUPING(), although it's
not clear that that would affect plan shapes in practice) and in
ruleutils.c (resulting in excess parentheses in pretty-print mode).
Per bug #17088 from Yaoguang Chen. Back-patch to all supported
branches.
Richard Guo, Tom Lane
Discussion: https://postgr.es/m/17088-e33882b387de7f5c@postgresql.org
M src/backend/nodes/nodeFuncs.c
M src/backend/optimizer/path/costsize.c
M src/backend/optimizer/plan/subselect.c
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/groupingsets.out
M src/test/regress/sql/groupingsets.sql
Fix risk of deadlock failure while dropping a partitioned index.
commit : 2241e5ceda2febd90b06e6cbc02a8b51e9e070e4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Mar 2022 12:22:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Mar 2022 12:22:13 -0400
DROP INDEX needs to lock the index's table before the index itself,
else it will deadlock against ordinary queries that acquire the
relation locks in that order. This is correctly mechanized for
plain indexes by RangeVarCallbackForDropRelation; but in the case of
a partitioned index, we neglected to lock the child tables in advance
of locking the child indexes. We can fix that by traversing the
inheritance tree and acquiring the needed locks in RemoveRelations,
after we have acquired our locks on the parent partitioned table and
index.
While at it, do some refactoring to eliminate confusion between
the actual and expected relkind in RangeVarCallbackForDropRelation.
We can save a couple of syscache lookups too, by having that function
pass back info that RemoveRelations will need.
Back-patch to v11 where partitioned indexes were added.
Jimmy Yih, Gaurab Dey, Tom Lane
Discussion: https://postgr.es/m/BYAPR05MB645402330042E17D91A70C12BD5F9@BYAPR05MB6454.namprd05.prod.outlook.com
M src/backend/commands/tablecmds.c
A src/test/isolation/expected/partition-drop-index-locking.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/partition-drop-index-locking.spec
Doc: fix our example systemd script.
commit : 36c3acb397e15ee7f7d5545b4775eecc2ded917f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 20 Mar 2022 12:39:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 20 Mar 2022 12:39:40 -0400
The example used "TimeoutSec=0", but systemd's documented way to get
the desired effect is "TimeoutSec=infinity".
Discussion: https://postgr.es/m/164770078557.670.5467111518383664377@wrigleys.postgresql.org
M doc/src/sgml/runtime.sgml
doc: Mention SET TABLESPACE clause for ALTER MATERIALIZED VIEW
commit : fe14b0dd45a8d028d7ae49b68e445f78e8535015
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 19 Mar 2022 16:37:43 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 19 Mar 2022 16:37:43 +0900
This command flavor is supported, but there was nothing in the
documentation about it.
Author: Yugo Nagata
Discussion: https://postgr.es/m/20220316133337.5dc9740abfa24c25ec9f67f5@sraoss.co.jp
Backpatch-through: 10
M doc/src/sgml/ref/alter_materialized_view.sgml
Fix incorrect xmlschema output for types timetz and timestamptz.
commit : 88ae77588d9a891c492f8ba543b3c1064c7a8ef3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Mar 2022 16:01:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 18 Mar 2022 16:01:42 -0400
The output of table_to_xmlschema() and allied functions includes
a regex describing valid values for these types ... but the regex
was itself invalid, as it failed to escape a literal "+" sign.
Report and fix by Renan Soares Lopes. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/7f6fabaa-3f8f-49ab-89ca-59fbfe633105@me.com
M src/backend/utils/adt/xml.c
M src/test/regress/expected/xmlmap.out
M src/test/regress/expected/xmlmap_1.out
M src/test/regress/sql/xmlmap.sql
Revert applying column aliases to the output of whole-row Vars.
commit : 5e144cc89b468d845a2dbd7bdd1786c6efcdfd83
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Mar 2022 18:18:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Mar 2022 18:18:05 -0400
In commit bf7ca1587, I had the bright idea that we could make the
result of a whole-row Var (that is, foo.*) track any column aliases
that had been applied to the FROM entry the Var refers to. However,
that's not terribly logically consistent, because now the output of
the Var is no longer of the named composite type that the Var claims
to emit. bf7ca1587 tried to handle that by changing the output
tuple values to be labeled with a blessed RECORD type, but that's
really pretty disastrous: we can wind up storing such tuples onto
disk, whereupon they're not readable by other sessions.
The only practical fix I can see is to give up on what bf7ca1587
tried to do, and say that the column names of tuples produced by
a whole-row Var are always those of the underlying named composite
type, query aliases or no. While this introduces some inconsistencies,
it removes others, so it's not that awful in the abstract. What *is*
kind of awful is to make such a behavioral change in a back-patched
bug fix. But corrupt data is worse, so back-patched it will be.
(A workaround available to anyone who's unhappy about this is to
introduce an extra level of sub-SELECT, so that the whole-row Var is
referring to the sub-SELECT's output and not to a named table type.
Then the Var is of type RECORD to begin with and there's no issue.)
Per report from Miles Delahunty. The faulty commit dates to 9.5,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/2950001.1638729947@sss.pgh.pa.us
M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
M src/backend/executor/execTuples.c
M src/test/regress/expected/rowtypes.out
M src/test/regress/sql/rowtypes.sql
Fix publish_as_relid with multiple publications
commit : 27fafee72d1749cc530fc76220db400db2634fde
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 16 Mar 2022 16:42:47 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 16 Mar 2022 16:42:47 +0100
Commit 83fd4532a7 allowed publishing of changes via ancestors, for
publications defined with publish_via_partition_root. But the way
the ancestor was determined in get_rel_sync_entry() was incorrect,
simply updating the same variable. So with multiple publications,
replicating different ancestors, the outcome depended on the order
of publications in the list - the value from the last loop was used,
even if it wasn't the top-most ancestor.
This is a probably rare situation, as in most cases publications do
not overlap, so each partition has exactly one candidate ancestor
to replicate as and there's no ambiguity.
Fixed by tracking the "ancestor level" for each publication, and
picking the top-most ancestor. Adds a test case, verifying the
correct ancestor is used for publishing the changes and that this
does not depend on order of publications in the list.
Older releases have another bug in this loop - once all actions are
replicated, the loop is terminated, on the assumption that inspecting
additional publications is unecessary. But that misses the fact that
those additional applications may replicate different ancestors.
Fixed by removal of this break condition. We might still terminate the
loop in some cases (e.g. when replicating all actions and the ancestor
is the partition root).
Backpatch to 13, where publish_via_partition_root was introduced.
Initial report and fix by me, test added by Hou zj. Reviews and
improvements by Amit Kapila.
Author: Tomas Vondra, Hou zj, Amit Kapila
Reviewed-by: Amit Kapila, Hou zj
Discussion: https://postgr.es/m/d26d24dd-2fab-3c48-0162-2b7f84a9c893%40enterprisedb.com
M src/backend/replication/pgoutput/pgoutput.c
M src/test/subscription/t/013_partition.pl
Fix default signature length for gist_ltree_ops
commit : bad202c615c9f4ad41be18aa7d9ffe41ebfb86fa
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 16 Mar 2022 11:41:18 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 16 Mar 2022 11:41:18 +0300
911e702077 implemented operator class parameters including the signature length
in ltree. Previously, the signature length for gist_ltree_ops was 8. Because
of bug 911e702077 the default signature length for gist_ltree_ops became 28 for
ltree 1.1 (where options method is NOT provided) and 8 for ltree 1.2 (where
options method is provided). This commit changes the default signature length
for ltree 1.1 to 8.
Existing gist_ltree_ops indexes might be corrupted in various scenarios.
Thus, we have to recommend reindexing all the gist_ltree_ops indexes after
the upgrade.
Reported-by: Victor Yegorov
Reviewed-by: Tomas Vondra, Tom Lane, Andres Freund, Nikita Glukhov
Reviewed-by: Andrew Dunstan
Author: Tomas Vondra, Alexander Korotkov
Discussion: https://postgr.es/m/17406-71e02820ae79bb40%40postgresql.org
Discussion: https://postgr.es/m/d80e0a55-6c3e-5b26-53e3-3c4f973f737c%40enterprisedb.com
M contrib/ltree/ltree.h
M contrib/ltree/ltree_gist.c
Fix race between DROP TABLESPACE and checkpointing.
commit : 51e760e5a667e7fcc1660756d657121b778861bf
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 16 Mar 2022 17:20:24 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 16 Mar 2022 17:20:24 +1300
Commands like ALTER TABLE SET TABLESPACE may leave files for the next
checkpoint to clean up. If such files are not removed by the time DROP
TABLESPACE is called, we request a checkpoint so that they are deleted.
However, there is presently a window before checkpoint start where new
unlink requests won't be scheduled until the following checkpoint. This
means that the checkpoint forced by DROP TABLESPACE might not remove the
files we expect it to remove, and the following ERROR will be emitted:
ERROR: tablespace "mytblspc" is not empty
To fix, add a call to AbsorbSyncRequests() just before advancing the
unlink cycle counter. This ensures that any unlink requests forwarded
prior to checkpoint start (i.e., when ckpt_started is incremented) will
be processed by the current checkpoint. Since AbsorbSyncRequests()
performs memory allocations, it cannot be called within a critical
section, so we also need to move SyncPreCheckpoint() to before
CreateCheckPoint()'s critical section.
This is an old bug, so back-patch to all supported versions.
Author: Nathan Bossart <nathandbossart@gmail.com>
Reported-by: Nathan Bossart <nathandbossart@gmail.com>
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/20220215235845.GA2665318%40nathanxps13
M src/backend/access/transam/xlog.c
M src/backend/storage/sync/sync.c
pageinspect: Fix memory context allocation of page in brin_revmap_data()
commit : 028a3c6b1cb1933a17bab5bdf22d7431357763b7
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 16 Mar 2022 12:29:55 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 16 Mar 2022 12:29:55 +0900
This caused the function to fail, as the aligned copy of the raw page
given by the function caller was not saved in the correct memory
context, which needs to be multi_call_memory_ctx in this case.
Issue introduced by 076f4d9.
Per buildfarm members sifika, mylodon and longfin. I have reproduced
that locally with macos.
Discussion: https://postgr.es/m/YjFPOtfCW6yLXUeM@paquier.xyz
Backpatch-through: 10
M contrib/pageinspect/brinfuncs.c
Fix waiting in RegisterSyncRequest().
commit : cfdb303be756d846031ba1c1d1ff2cae39a62c15
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 16 Mar 2022 15:37:15 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 16 Mar 2022 15:37:15 +1300
If we run out of space in the checkpointer sync request queue (which is
hopefully rare on real systems, but common with very small buffer pool),
we wait for it to drain. While waiting, we should report that as a wait
event so that users know what is going on, and also handle postmaster
death, since otherwise the loop might never terminate if the
checkpointer has exited.
Back-patch to 12. Although the problem exists in earlier releases too,
the code is structured differently before 12 so I haven't gone any
further for now, in the absence of field complaints.
Reported-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/20220226213942.nb7uvb2pamyu26dj%40alap3.anarazel.de
M doc/src/sgml/monitoring.sgml
M src/backend/postmaster/pgstat.c
M src/backend/storage/sync/sync.c
M src/include/pgstat.h
pageinspect: Fix handling of page sizes and AM types
commit : d3a9b83c30b62898f6823d127c6b6ddef98f7cba
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 16 Mar 2022 11:20:51 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 16 Mar 2022 11:20:51 +0900
This commit fixes a set of issues related to the use of the SQL
functions in this module when the caller is able to pass down raw page
data as input argument:
- The page size check was fuzzy in a couple of places, sometimes
looking after only a sub-range, but what we are looking for is an exact
match on BLCKSZ. After considering a few options here, I have settled
down to do a generalization of get_page_from_raw(). Most of the SQL
functions already used that, and this is not strictly required if not
accessing an 8-byte-wide value from a raw page, but this feels safer in
the long run for alignment-picky environment, particularly if a code
path begins to access such values. This also reduces the number of
strings that need to be translated.
- The BRIN function brin_page_items() uses a Relation but it did not
check the access method of the opened index, potentially leading to
crashes. All the other functions in need of a Relation already did
that.
- Some code paths could fail on elog(), but we should to use ereport()
for failures that can be triggered by the user.
Tests are added to stress all the cases that are fixed as of this
commit, with some junk raw pages (\set VERBOSITY ensures that this works
across all page sizes) and unexpected index types when functions open
relations.
Author: Michael Paquier, Justin Prysby
Discussion: https://postgr.es/m/20220218030020.GA1137@telsasoft.com
Backpatch-through: 10
M contrib/pageinspect/brinfuncs.c
M contrib/pageinspect/btreefuncs.c
M contrib/pageinspect/expected/brin.out
M contrib/pageinspect/expected/btree.out
M contrib/pageinspect/expected/gin.out
M contrib/pageinspect/expected/hash.out
M contrib/pageinspect/expected/page.out
M contrib/pageinspect/fsmfuncs.c
M contrib/pageinspect/hashfuncs.c
M contrib/pageinspect/rawpage.c
M contrib/pageinspect/sql/brin.sql
M contrib/pageinspect/sql/btree.sql
M contrib/pageinspect/sql/gin.sql
M contrib/pageinspect/sql/hash.sql
M contrib/pageinspect/sql/page.sql
Back-patch LLVM 14 API changes.
commit : 5610411ac7b7d86b781aaaeed7f02b0e1005f8bb
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 16 Mar 2022 11:35:00 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 16 Mar 2022 11:35:00 +1300
Since LLVM 14 has stopped changing and is about to be released,
back-patch the following changes from the master branch:
e6a7600202105919bffd62b3dfd941f4a94e082b
807fee1a39de6bb8184082012e643951abb9ad1d
a56e7b66010f330782243de9e25ac2a6596be0e1
Back-patch to 11, where LLVM JIT support came in.
M src/backend/jit/llvm/Makefile
M src/backend/jit/llvm/llvmjit_error.cpp
M src/backend/jit/llvm/llvmjit_inline.cpp
doc: Add ALTER/DROP ROUTINE to the event trigger matrix
commit : ef00502a5a0a41ae2cab3dc9b06bd2278d29d5fd
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 9 Mar 2022 14:59:22 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 9 Mar 2022 14:59:22 +0900
ALTER ROUTINE triggers the events ddl_command_start and ddl_command_end,
and DROP ROUTINE triggers sql_drop, ddl_command_start and
ddl_command_end, but this was not mention on the matrix table.
Reported-by: Leslie Lemaire
Discussion: https://postgr.es/m/164647533363.646.5802968483136493025@wrigleys.postgresql.org
Backpatch-through: 11
M doc/src/sgml/event-trigger.sgml
Introduce PG_TEST_TIMEOUT_DEFAULT for TAP suite non-elapsing timeouts.
commit : 29ec94efd08b0b3f863db13f5978cdeab4f1c8dc
author : Noah Misch <noah@leadboat.com>
date : Fri, 4 Mar 2022 18:53:13 -0800
committer: Noah Misch <noah@leadboat.com>
date : Fri, 4 Mar 2022 18:53:13 -0800
Slow hosts may avoid load-induced, spurious failures by setting
environment variable PG_TEST_TIMEOUT_DEFAULT to some number of seconds
greater than 180. Developers may see faster failures by setting that
environment variable to some lesser number of seconds. In tests, write
$PostgreSQL::Test::Utils::timeout_default wherever the convention has
been to write 180. This change raises the default for some briefer
timeouts. Back-patch to v10 (all supported versions).
Discussion: https://postgr.es/m/20220218052842.GA3627003@rfd.leadboat.com
M contrib/amcheck/t/002_cic.pl
M contrib/amcheck/t/003_cic_2pc.pl
M src/bin/pg_ctl/t/004_logrotate.pl
M src/bin/pg_dump/t/002_pg_dump.pl
M src/bin/psql/t/010_tab_completion.pl
M src/bin/scripts/t/080_pg_isready.pl
M src/test/perl/PostgresNode.pm
M src/test/perl/TestLib.pm
M src/test/recovery/t/003_recovery_targets.pl
M src/test/recovery/t/006_logical_decoding.pl
M src/test/recovery/t/010_logical_decoding_timelines.pl
M src/test/recovery/t/013_crash_restart.pl
M src/test/recovery/t/017_shm.pl
M src/test/recovery/t/019_replslot_limit.pl
Fix pg_regress to print the correct postmaster address on Windows.
commit : 59392746cb3fd3c23b5f7bfa9568a71705ca30d1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Mar 2022 13:23:58 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Mar 2022 13:23:58 -0500
pg_regress reported "Unix socket" as the default location whenever
HAVE_UNIX_SOCKETS is defined. However, that's not been accurate
on Windows since 8f3ec75de. Update this logic to match what libpq
actually does now.
This is just cosmetic, but still it's potentially misleading.
Back-patch to v13 where 8f3ec75de came in.
Discussion: https://postgr.es/m/3894060.1646415641@sss.pgh.pa.us
M src/interfaces/libpq/fe-connect.c
M src/test/regress/pg_regress.c
Fix bogus casting in BlockIdGetBlockNumber().
commit : 97031f440485a01627cb1cc442c0fb10d27b97bd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Mar 2022 19:03:17 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Mar 2022 19:03:17 -0500
This macro cast the result to BlockNumber after shifting, not before,
which is the wrong thing. Per the C spec, the uint16 fields would
promote to int not unsigned int, so that (for 32-bit int) the shift
potentially shifts a nonzero bit into the sign position. I doubt
there are any production systems where this would actually end with
the wrong answer, but it is undefined behavior per the C spec, and
clang's -fsanitize=undefined option reputedly warns about it on some
platforms. (I can't reproduce that right now, but the code is
undeniably wrong per spec.) It's easy to fix by casting to
BlockNumber (uint32) in the proper places.
It's been wrong for ages, so back-patch to all supported branches.
Report and patch by Zhihong Yu (cosmetic tweaking by me)
Discussion: https://postgr.es/m/CALNJ-vT9r0DSsAOw9OXVJFxLENoVS_68kJ5x0p44atoYH+H4dg@mail.gmail.com
M src/include/storage/block.h
Clean up assorted failures under clang's -fsanitize=undefined checks.
commit : 1a027e6b7bdf06dc3bfe1e63a2493f13629cf44a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Mar 2022 18:13:24 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 3 Mar 2022 18:13:24 -0500
Most of these are cases where we could call memcpy() or other libc
functions with a NULL pointer and a zero count, which is forbidden
by POSIX even though every production version of libc allows it.
We've fixed such things before in a piecemeal way, but apparently
never made an effort to try to get them all. I don't claim that
this patch does so either, but it gets every failure I observe in
check-world, using clang 12.0.1 on current RHEL8.
numeric.c has a different issue that the sanitizer doesn't like:
"ln(-1.0)" will compute log10(0) and then try to assign the
resulting -Inf to an integer variable. We don't actually use the
result in such a case, so there's no live bug.
Back-patch to all supported branches, with the idea that we might
start running a buildfarm member that tests this case. This includes
back-patching c1132aae3 (Check the size in COPY_POINTER_FIELD),
which previously silenced some of these issues in copyfuncs.c.
Discussion: https://postgr.es/m/CALNJ-vT9r0DSsAOw9OXVJFxLENoVS_68kJ5x0p44atoYH+H4dg@mail.gmail.com
M contrib/pgcrypto/px.c
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_visibility.c
M src/backend/access/transam/clog.c
M src/backend/access/transam/xact.c
M src/backend/nodes/copyfuncs.c
M src/backend/storage/ipc/shm_mq.c
M src/backend/utils/adt/numeric.c
M src/backend/utils/time/snapmgr.c
M src/fe_utils/print.c
Allow root-owned SSL private keys in libpq, not only the backend.
commit : 6599d8f1264299ee595f2eaf4dc6a9aa2d7940d2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Mar 2022 11:57:02 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Mar 2022 11:57:02 -0500
This change makes libpq apply the same private-key-file ownership
and permissions checks that we have used in the backend since commit
9a83564c5. Namely, that the private key can be owned by either the
current user or root (with different file permissions allowed in the
two cases). This allows system-wide management of key files, which
is just as sensible on the client side as the server, particularly
when the client is itself some application daemon.
Sync the comments about this between libpq and the backend, too.
Back-patch of a59c79564 and 50f03473e into all supported branches.
David Steele
Discussion: https://postgr.es/m/f4b7bc55-97ac-9e69-7398-335e212f7743@pgmasters.net
M doc/src/sgml/libpq.sgml
M src/backend/libpq/be-secure-common.c
M src/interfaces/libpq/fe-secure-openssl.c
Disallow execution of SPI functions during plperl function compilation.
commit : 9b2d762a283dc65b2168c3555302e7a23bc377e1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Feb 2022 17:40:21 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Feb 2022 17:40:21 -0500
Perl can be convinced to execute user-defined code during compilation
of a plperl function (or at least a plperlu function). That's not
such a big problem as long as the activity is confined within the
Perl interpreter, and it's not clear we could do anything about that
anyway. However, if such code tries to use plperl's SPI functions,
we have a bigger problem. In the first place, those functions are
likely to crash because current_call_data->prodesc isn't set up yet.
In the second place, because it isn't set up, we lack critical info
such as whether the function is supposed to be read-only. And in
the third place, this path allows code execution during function
validation, which is strongly discouraged because of the potential
for security exploits. Hence, reject execution of the SPI functions
until compilation is finished.
While here, add check_spi_usage_allowed() calls to various functions
that hadn't gotten the memo about checking that. I think that perhaps
plperl_sv_to_literal may have been intentionally omitted on the grounds
that it was safe at the time; but if so, the addition of transforms
functionality changed that. The others are more recently added and
seem to be flat-out oversights.
Per report from Mark Murawski. Back-patch to all supported branches.
Discussion: https://postgr.es/m/9acdf918-7fff-4f40-f750-2ffa84f083d2@intellasoft.net
M src/pl/plperl/plperl.c
pg_waldump: Fix error message for WAL files smaller than XLOG_BLCKSZ.
commit : 0b1020a96d8e14ba5c5fe22f825c3093160aa83b
author : Andres Freund <andres@anarazel.de>
date : Fri, 25 Feb 2022 10:30:05 -0800
committer: Andres Freund <andres@anarazel.de>
date : Fri, 25 Feb 2022 10:30:05 -0800
When opening a WAL file smaller than XLOG_BLCKSZ (e.g. 0 bytes long) while
determining the wal_segment_size, pg_waldump checked errno, despite errno not
being set by the short read. Resulting in a bogus error message.
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://postgr.es/m/20220214.181847.775024684568733277.horikyota.ntt@gmail.com
Backpatch: 11-, the bug was introducedin fc49e24fa
M src/bin/pg_waldump/pg_waldump.c
Fix temporary object cleanup failing due to toast access without snapshot.
commit : c2551483e0f6855183ae43a74abb3e434803b907
author : Andres Freund <andres@anarazel.de>
date : Sat, 19 Feb 2022 12:27:20 -0800
committer: Andres Freund <andres@anarazel.de>
date : Sat, 19 Feb 2022 12:27:20 -0800
When cleaning up temporary objects during process exit the cleanup could fail
with:
FATAL: cannot fetch toast data without an active snapshot
The bug is caused by RemoveTempRelationsCallback() not setting up a
snapshot. If an object with toasted catalog data needs to be cleaned up,
init_toast_snapshot() could fail with the above error.
Most of the time however the the problem is masked due to cached catalog
snapshots being returned by GetOldestSnapshot(). But dropping an object can
cause catalog invalidations to be emitted. If no further catalog accesses are
necessary between the invalidation processing and the next toast datum
deletion, the bug becomes visible.
It's easy to miss this bug because it typically happens after clients
disconnect and the FATAL error just ends up in the log.
Luckily temporary table cleanup at the next use of the same temporary schema
or during DISCARD ALL does not have the same problem.
Fix the bug by pushing a snapshot in RemoveTempRelationsCallback(). Also add
isolation tests for temporary object cleanup, including objects with toasted
catalog data.
A future HEAD only commit will add more assertions.
Reported-By: Miles Delahunty
Author: Andres Freund
Discussion: https://postgr.es/m/CAOFAq3BU5Mf2TTvu8D9n_ZOoFAeQswuzk7yziAb7xuw_qyw5gw@mail.gmail.com
Backpatch: 10-
M src/backend/catalog/namespace.c
A src/test/isolation/expected/temp-schema-cleanup.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/temp-schema-cleanup.spec
Remove most msys special processing in TAP tests
commit : a5716baac00b68e6cf0720047dddfe8892c8033e
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 20 Feb 2022 11:49:33 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 20 Feb 2022 11:49:33 -0500
Following migration of Windows buildfarm members running TAP tests to
use of ucrt64 perl for those tests, special processing for msys perl is
no longer necessary and so is removed.
Backpatch to release 10
Discussion: https://postgr.es/m/c65a8781-77ac-ea95-d185-6db291e1baeb@dunslane.net
M src/bin/pg_ctl/t/001_start_stop.pl
M src/bin/pg_rewind/t/RewindTest.pm
M src/test/perl/PostgresNode.pm
M src/test/perl/TestLib.pm
M src/test/recovery/t/cp_history_files
Remove PostgreSQL::Test::Utils::perl2host completely
commit : c27aa21e0dc89484fec38cd4e2189c6c1a5cf251
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 20 Feb 2022 08:55:06 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 20 Feb 2022 08:55:06 -0500
Commit f1ac4a74de disabled this processing, and as nothing has broken (as
expected) here we proceed to remove the routine and adjust all the call
sites.
Backpatch to release 10
Discussion: https://postgr.es/m/0ba775a2-8aa0-0d56-d780-69427cf6f33d@dunslane.net
Discussion: https://postgr.es/m/20220125023609.5ohu3nslxgoygihl@alap3.anarazel.de
M src/bin/pg_checksums/t/002_actions.pl
M src/bin/pg_verifybackup/t/003_corruption.pl
M src/bin/pgbench/t/001_pgbench_with_server.pl
M src/test/perl/PostgresNode.pm
M src/test/perl/TestLib.pm
M src/test/recovery/t/014_unlogged_reinit.pl
M src/test/recovery/t/017_shm.pl
M src/test/recovery/t/018_wal_optimize.pl
M src/test/recovery/t/025_stuck_on_old_timeline.pl
Suppress warning about stack_base_ptr with late-model GCC.
commit : 46b738ffc2bf27c1c0bf0492f8c646c4496819dc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Feb 2022 22:45:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Feb 2022 22:45:34 -0500
GCC 12 complains that set_stack_base is storing the address of
a local variable in a long-lived pointer. This is an entirely
reasonable warning (indeed, it just helped us find a bug);
but that behavior is intentional here. We can work around it
by using __builtin_frame_address(0) instead of a specific local
variable; that produces an address a dozen or so bytes different,
in my testing, but we don't care about such a small difference.
Maybe someday a compiler lacking that function will start to issue
a similar warning, but we'll worry about that when it happens.
Patch by me, per a suggestion from Andres Freund. Back-patch to
v12, which is as far back as the patch will go without some pain.
(Recently-established project policy would permit a back-patch as
far as 9.2, but I'm disinclined to expend the work until GCC 12
is much more widespread.)
Discussion: https://postgr.es/m/3773792.1645141467@sss.pgh.pa.us
M config/c-compiler.m4
M configure
M configure.in
M src/backend/postmaster/postmaster.c
M src/backend/tcop/postgres.c
M src/backend/utils/init/miscinit.c
M src/include/pg_config.h.in
M src/tools/msvc/Solution.pm
Doc: Update documentation for modifying postgres_fdw foreign tables.
commit : 0dc0284ade4ade315982d1300cb87006b42e72c3
author : Etsuro Fujita <efujita@postgresql.org>
date : Wed, 16 Feb 2022 15:15:04 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Wed, 16 Feb 2022 15:15:04 +0900
Document that they can be modified using COPY as well.
Back-patch to v11 where commit 3d956d956 added support for COPY in
postgres_fdw.
M doc/src/sgml/postgres-fdw.sgml
WAL log unchanged toasted replica identity key attributes.
commit : caa231be97df3e4cb2667ea355562d5a5faa60c9
author : Amit Kapila <akapila@postgresql.org>
date : Mon, 14 Feb 2022 08:24:44 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Mon, 14 Feb 2022 08:24:44 +0530
Currently, during UPDATE, the unchanged replica identity key attributes
are not logged separately because they are getting logged as part of the
new tuple. But if they are stored externally then the untoasted values are
not getting logged as part of the new tuple and logical replication won't
be able to replicate such UPDATEs. So we need to log such attributes as
part of the old_key_tuple during UPDATE.
Reported-by: Haiying Tang
Author: Dilip Kumar and Amit Kapila
Reviewed-by: Alvaro Herrera, Haiying Tang, Andres Freund
Backpatch-through: 10
Discussion: https://postgr.es/m/OS0PR01MB611342D0A92D4F4BF26C0F47FB229@OS0PR01MB6113.jpnprd01.prod.outlook.com
M contrib/test_decoding/expected/toast.out
M doc/src/sgml/ref/alter_table.sgml
M src/backend/access/heap/heapam.c
Fix memory leak in IndexScan node with reordering
commit : ac2303aa0386d2fa26cc3e237076b49827b39d6a
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 14 Feb 2022 03:26:55 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 14 Feb 2022 03:26:55 +0300
Fix ExecReScanIndexScan() to free the referenced tuples while emptying the
priority queue. Backpatch to all supported versions.
Discussion: https://postgr.es/m/CAHqSB9gECMENBQmpbv5rvmT3HTaORmMK3Ukg73DsX5H7EJV7jw%40mail.gmail.com
Author: Aliaksandr Kalenik
Reviewed-by: Tom Lane, Alexander Korotkov
Backpatch-through: 10
M src/backend/executor/nodeIndexscan.c
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Fix thinko in PQisBusy().
commit : 51ee561f5671cd92f6dcaacf043985c497a82fc1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Feb 2022 13:23:20 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 12 Feb 2022 13:23:20 -0500
In commit 1f39a1c06 I made PQisBusy consider conn->write_failed, but
that is now looking like complete brain fade. In the first place, the
logic is quite wrong: it ought to be like "and not" rather than "or".
This meant that once we'd gotten into a write_failed state, PQisBusy
would always return true, probably causing the calling application to
iterate its loop until PQconsumeInput returns a hard failure thanks
to connection loss. That's not what we want: the intended behavior
is to return an error PGresult, which the application probably has
much cleaner support for.
But in the second place, checking write_failed here seems like the
wrong thing anyway. The idea of the write_failed mechanism is to
postpone handling of a write failure until we've read all we can from
the server; so that flag should not interfere with input-processing
behavior. (Compare 7247e243a.) What we *should* check for is
status = CONNECTION_BAD, ie, socket already closed. (Most places that
close the socket don't touch asyncStatus, but they do reset status.)
This primarily ensures that if PQisBusy() returns true then there is
an open socket, which is assumed by several call sites in our own
code, and probably other applications too.
While at it, fix a nearby thinko in libpq's my_sock_write: we should
only consult errno for res < 0, not res == 0. This is harmless since
pqsecure_raw_write would force errno to zero in such a case, but it
still could confuse readers.
Noted by Andres Freund. Backpatch to v12 where 1f39a1c06 came in.
Discussion: https://postgr.es/m/20220211011025.ek7exh6owpzjyudn@alap3.anarazel.de
M src/interfaces/libpq/fe-exec.c
M src/interfaces/libpq/fe-secure-openssl.c
Don't use_physical_tlist for an IOS with non-returnable columns.
commit : 0778b24ced8a873b432641001d046d1dde602466
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Feb 2022 15:23:52 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Feb 2022 15:23:52 -0500
createplan.c tries to save a runtime projection step by specifying
a scan plan node's output as being exactly the table's columns, or
index's columns in the case of an index-only scan, if there is not a
reason to do otherwise. This logic did not previously pay attention
to whether an index's columns are returnable. That worked, sort of
accidentally, until commit 9a3ddeb51 taught setrefs.c to reject plans
that try to read a non-returnable column. I have no desire to loosen
setrefs.c's new check, so instead adjust use_physical_tlist() to not
try to optimize this way when there are non-returnable column(s).
Per report from Ryan Kelly. Like the previous patch, back-patch
to all supported branches.
Discussion: https://postgr.es/m/CAHUie24ddN+pDNw7fkhNrjrwAX=fXXfGZZEHhRuofV_N_ftaSg@mail.gmail.com
M src/backend/optimizer/plan/createplan.c
M src/test/regress/expected/gist.out
M src/test/regress/sql/gist.sql
Make pg_ctl stop/restart/promote recheck postmaster aliveness.
commit : d0e1fd9587b3445904076fb7ba11b37138f0ac94
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Feb 2022 16:49:39 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Feb 2022 16:49:39 -0500
"pg_ctl stop/restart" checked that the postmaster PID is valid just
once, as a side-effect of sending the stop signal, and then would
wait-till-timeout for the postmaster.pid file to go away. This
neglects the case wherein the postmaster dies uncleanly after we
signal it. Similarly, once "pg_ctl promote" has sent the signal,
it'd wait for the corresponding on-disk state change to occur
even if the postmaster dies.
I'm not sure how we've managed not to notice this problem, but it
seems to explain slow execution of the 017_shm.pl test script on AIX
since commit 4fdbf9af5, which added a speculative "pg_ctl stop" with
the idea of making real sure that the postmaster isn't there. In the
test steps that kill-9 and then restart the postmaster, it's possible
to get past the initial signal attempt before kill() stops working
for the doomed postmaster. If that happens, pg_ctl waited till
PGCTLTIMEOUT before giving up ... and the buildfarm's AIX members
have that set very high.
To fix, include a "kill(pid, 0)" test (similar to what
postmaster_is_alive uses) in these wait loops, so that we'll
give up immediately if the postmaster PID disappears.
While here, I chose to refactor those loops out of where they were.
do_stop() and do_restart() can perfectly well share one copy of the
wait-for-stop loop, and it seems desirable to put a similar function
beside that for wait-for-promote.
Back-patch to all supported versions, since pg_ctl's wait logic
is substantially identical in all, and we're seeing the slow test
behavior in all branches.
Discussion: https://postgr.es/m/20220210023537.GA3222837@rfd.leadboat.com
M src/bin/pg_ctl/pg_ctl.c
Use gendef instead of pexports for building windows .def files
commit : eec7c640fe5022b19b2dd82f739dc0c2c54cdbb8
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 10 Feb 2022 13:44:05 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 10 Feb 2022 13:44:05 -0500
Modern msys systems lack pexports but have gendef instead, so use that.
Discussion: https://postgr.es/m/3ccde7a9-e4f9-e194-30e0-0936e6ad68ba@dunslane.net
Backpatch to release 9.4 to enable building with perl on older branches.
Before that pexports is not used for plperl.
M src/pl/plperl/GNUmakefile
M src/pl/plpython/Makefile
M src/pl/tcl/Makefile
Use Test::Builder::todo_start(), replacing $::TODO.
commit : b3558cc96cd9714d879774d13c5bab12ef027864
author : Noah Misch <noah@leadboat.com>
date : Wed, 9 Feb 2022 18:16:59 -0800
committer: Noah Misch <noah@leadboat.com>
date : Wed, 9 Feb 2022 18:16:59 -0800
Some pre-2017 Test::More versions need perfect $Test::Builder::Level
maintenance to find the variable. Buildfarm member snapper reported an
overall failure that the file intended to hide via the TODO construct.
That trouble was reachable in v11 and v10. For later branches, this
serves as defense in depth. Back-patch to v10 (all supported versions).
Discussion: https://postgr.es/m/20220202055556.GB2745933@rfd.leadboat.com
M contrib/amcheck/t/003_cic_2pc.pl
Fix back-patch of "Avoid race in RelationBuildDesc() ..."
commit : 1b8462bf1d097dfff2014b61d5d1ff6ca99d785d
author : Noah Misch <noah@leadboat.com>
date : Wed, 9 Feb 2022 18:16:56 -0800
committer: Noah Misch <noah@leadboat.com>
date : Wed, 9 Feb 2022 18:16:56 -0800
The back-patch of commit fdd965d074d46765c295223b119ca437dbcac973 broke
CLOBBER_CACHE_ALWAYS for v9.6 through v13. It updated the
InvalidateSystemCaches() call for CLOBBER_CACHE_RECURSIVELY, neglecting
the one for CLOBBER_CACHE_ALWAYS. Back-patch to v13, v12, v11, and v10.
Reviewed by Tomas Vondra. Reported by Tomas Vondra.
Discussion: https://postgr.es/m/df7b4c0b-7d92-f03f-75c4-9e08b269a716@enterprisedb.com
M src/backend/utils/cache/inval.c
Remove ppport.h's broken re-implementation of eval_pv().
commit : 5ea3b99de07bd1c1757effc9664d0786cb21c963
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Feb 2022 19:25:56 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Feb 2022 19:25:56 -0500
Recent versions of Devel::PPPort try to redefine eval_pv() to
dodge a bug in pre-5.31 Perl versions. Unfortunately the redefinition
fails on compilers that don't support statements nested within
expressions. However, we aren't actually interested in this bug fix,
since we always call eval_pv() with croak_on_error = FALSE.
So, until there's an upstream fix for this breakage, just comment
out the macro to revert to the older behavior.
Per report from Wei Sun, as well as previous buildfarm failure
on pademelon (which I'd unfortunately not looked at carefully
enough to understand the cause). Back-patch to all supported
versions, since we're using the same ppport.h in all.
Discussion: https://postgr.es/m/tencent_2EFCC8BA0107B6EC0F97179E019A8A43C806@qq.com
Report: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pademelon&dt=2022-02-02%2001%3A22%3A58
M src/pl/plperl/ppport.h
Stamp 13.6.
commit : d7db9572070a627bae9919fd1b4e16c8208d4fca
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Feb 2022 16:17:41 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Feb 2022 16:17:41 -0500
M configure
M configure.in
Translation updates
commit : 7f7148b72e2b63274d93da6ea43f1493f4e92aa8
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 7 Feb 2022 13:36:22 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 7 Feb 2022 13:36:22 +0100
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 9aa8bc576f9af5c61de4a6fc8119abfa36493d01
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/sv.po
M src/bin/pg_archivecleanup/po/sv.po
M src/bin/pg_basebackup/po/de.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_checksums/po/sv.po
M src/bin/pg_config/po/sv.po
M src/bin/pg_controldata/po/sv.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/sv.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_test_fsync/po/sv.po
M src/bin/pg_test_timing/po/sv.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_verifybackup/po/sv.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/ru.po
M src/bin/scripts/po/sv.po
M src/interfaces/ecpg/ecpglib/po/sv.po
M src/interfaces/ecpg/preproc/po/sv.po
M src/interfaces/libpq/po/de.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/ru.po
M src/pl/plperl/po/sv.po
M src/pl/plpgsql/src/po/sv.po
M src/pl/plpython/po/sv.po
M src/pl/tcl/po/sv.po
Release notes for 14.2, 13.6, 12.10, 11.15, 10.20.
commit : 763c7aac575101cb4d3b3a37bb9811a66ef052c8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 6 Feb 2022 14:24:55 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 6 Feb 2022 14:24:55 -0500
M doc/src/sgml/release-13.sgml
Doc: be clearer that foreign-table partitions need user-added constraints.
commit : 7d74ff82431ba8836f92ac33ed3f1ab276f51a92
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Feb 2022 12:55:44 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Feb 2022 12:55:44 -0500
A very well-informed user might deduce this from what we said already,
but I'd bet against it. Lay it out explicitly.
While here, rewrite the comment about tuple routing to be more
intelligible to an average SQL user.
Per bug #17395 from Alexander Lakhin. Back-patch to v11. (The text
in this area is different in v10 and I'm not sufficiently excited
about this point to adapt the patch.)
Discussion: https://postgr.es/m/17395-8c326292078d1a57@postgresql.org
M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/create_foreign_table.sgml
Test, don't just Assert, that mergejoin's inputs are in order.
commit : 9c7cf083f26e183e200395b3514061bb9d71cc7e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Feb 2022 11:59:30 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Feb 2022 11:59:30 -0500
There are two Asserts in nodeMergejoin.c that are reachable if
the input data is not in the expected order. This seems way too
fragile. Alexander Lakhin reported a case where the assertions
could be triggered with misconfigured foreign-table partitions,
and bitter experience with unstable operating system collation
definitions suggests another easy route to hitting them. Neither
Assert is in a place where we can't afford one more test-and-branch,
so replace 'em with plain test-and-elog logic.
Per bug #17395. While the reported symptom is relatively recent,
collation changes could happen anytime, so back-patch to all
supported branches.
Discussion: https://postgr.es/m/17395-8c326292078d1a57@postgresql.org
M src/backend/executor/nodeMergejoin.c
doc: clarify syntax notation, particularly parentheses
commit : 58e9d28091e76bfd4a2670bc9ca8ba44d958e57d
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 2 Feb 2022 21:53:51 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 2 Feb 2022 21:53:51 -0500
Also move TCL syntax to the PL/tcl section.
Reported-by: davs2rt@gmail.com
Discussion: https://postgr.es/m/164308146320.12460.3590769444508751574@wrigleys.postgresql.org
Backpatch-through: 10
M doc/src/sgml/notation.sgml
M doc/src/sgml/pltcl.sgml
doc: Fix mistake in PL/Python documentation
commit : 31c9712610c7eec1b2f376fd3bbf5839e4234d64
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 2 Feb 2022 09:14:26 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 2 Feb 2022 09:14:26 +0100
Small thinko introduced by 94aceed317730953476bec490ce0148b2af3c383
Reported-by: nassehk@gmail.com
M doc/src/sgml/plpython.sgml
Replace use of deprecated Python module distutils.sysconfig, take 2.
commit : 4d7d196ff69365041579024848f34ee57ac75223
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Feb 2022 19:03:41 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 1 Feb 2022 19:03:41 -0500
With Python 3.10, configure spits out warnings about the module
distutils.sysconfig being deprecated and scheduled for removal in
Python 3.12. Change the uses in configure to use the module sysconfig
instead. The logic stays largely the same, although we have to
rely on INCLUDEPY instead of the deprecated get_python_inc function.
Note that sysconfig exists since Python 2.7, so this moves the
minimum required version up from Python 2.6 (or 2.4, before v13).
Also, sysconfig didn't exist in Python 3.1, so the minimum 3.x
version is now 3.2.
Back-patch of commit bd233bdd8 into all supported branches.
In v10, this also includes back-patching v11's beff4bb9c, primarily
because this opinion is clearly out-of-date:
While at it, get rid of the code's assumption that both the major and
minor numbers contain exactly one digit. That will foreseeably be
broken by Python 3.10 in perhaps four or five years. That's far enough
out that we probably don't need to back-patch this.
Peter Eisentraut, Tom Lane, Andres Freund
Discussion: https://postgr.es/m/c74add3c-09c4-a9dd-1a03-a846e5b2fc52@enterprisedb.com
M config/python.m4
M configure
M doc/src/sgml/installation.sgml
Revert "plperl: Fix breakage of c89f409749c in back branches."
commit : ff86ee3d2175d0e53e114bdb24137f5dc2dbb73b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 31 Jan 2022 15:07:39 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 31 Jan 2022 15:07:39 -0500
This reverts commits d81cac47a et al. We shouldn't need that
hack after the preceding commits.
Discussion: https://postgr.es/m/20220131015130.shn6wr2fzuymerf6@alap3.anarazel.de
M src/pl/plperl/plperl.c
plperl: update ppport.h to Perl 5.34.0.
commit : bc89af248e04fc07c1c15eb2d3c743a22691c667
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 31 Jan 2022 15:01:05 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 31 Jan 2022 15:01:05 -0500
Also apply the changes suggested by running
perl ppport.h --compat-version=5.8.0
And remove some no-longer-required NEED_foo declarations.
Dagfinn Ilmari Mannsåker
Back-patch of commit 05798c9f7 into all supported branches.
At the time we thought this update was mostly cosmetic, but the
lack of it has caused trouble, while the patch itself hasn't.
Discussion: https://postgr.es/m/87y278s6iq.fsf@wibble.ilmari.org
Discussion: https://postgr.es/m/20220131015130.shn6wr2fzuymerf6@alap3.anarazel.de
M src/pl/plperl/plperl.c
M src/pl/plperl/plperl.h
M src/pl/plperl/ppport.h
plperl: Fix breakage of c89f409749c in back branches.
commit : 4afb5aeb9f1285bd3ff2b370671c7ad5a91445c9
author : Andres Freund <andres@anarazel.de>
date : Sun, 30 Jan 2022 17:53:53 -0800
committer: Andres Freund <andres@anarazel.de>
date : Sun, 30 Jan 2022 17:53:53 -0800
ppport.h was only updated in 05798c9f7f0 (master). Unfortunately my commit
c89f409749c uses PERL_VERSION_LT which came in with that update. Breaking most
buildfarm animals.
I should have noticed that...
We might want to backpatch the ppport update instead, but for now lets get the
buildfarm green again.
Discussion: https://postgr.es/m/20220131015130.shn6wr2fzuymerf6@alap3.anarazel.de
Backpatch: 10-14, master doesn't need it
M src/pl/plperl/plperl.c
plperl: windows: Use Perl_setlocale on 5.28+, fixing compile failure.
commit : 0dc0fe7b6c4583955f643c3ba7ea625767f300bb
author : Andres Freund <andres@anarazel.de>
date : Sun, 30 Jan 2022 14:29:04 -0800
committer: Andres Freund <andres@anarazel.de>
date : Sun, 30 Jan 2022 14:29:04 -0800
For older versions we need our own copy of perl's setlocale(), because it was
not exposed (why we need the setlocale in the first place is explained in
plperl_init_interp) . The copy stopped working in 5.28, as some of the used
macros are not public anymore. But Perl_setlocale is available in 5.28, so
use that.
Author: Victor Wagner <vitus@wagner.pp.ru>
Reviewed-By: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://postgr.es/m/20200501134711.08750c5f@antares.wagner.home
Backpatch: all versions
M src/pl/plperl/plperl.c
Fix failure to validate the result of select_common_type().
commit : 5ad70564f46a5fc782191eb8010d90aaca9a762e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Jan 2022 11:41:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Jan 2022 11:41:12 -0500
Although select_common_type() has a failure-return convention, an
apparent successful return just provides a type OID that *might* work
as a common supertype; we've not validated that the required casts
actually exist. In the mainstream use-cases that doesn't matter,
because we'll proceed to invoke coerce_to_common_type() on each input,
which will fail appropriately if the proposed common type doesn't
actually work. However, a few callers didn't read the (nonexistent)
fine print, and thought that if they got back a nonzero OID then the
coercions were sure to work.
This affects in particular the recently-added "anycompatible"
polymorphic types; we might think that a function/operator using
such types matches cases it really doesn't. A likely end result
of that is unexpected "ambiguous operator" errors, as for example
in bug #17387 from James Inform. Another, much older, case is that
the parser might try to transform an "x IN (list)" construct to
a ScalarArrayOpExpr even when the list elements don't actually have
a common supertype.
It doesn't seem desirable to add more checking to select_common_type
itself, as that'd just slow down the mainstream use-cases. Instead,
write a separate function verify_common_type that performs the
missing checks, and add a call to that where necessary. Likewise add
verify_common_type_from_oids to go with select_common_type_from_oids.
Back-patch to v13 where the "anycompatible" types came in. (The
symptom complained of in bug #17387 doesn't appear till v14, but
that's just because we didn't get around to converting || to use
anycompatible till then.) In principle the "x IN (list)" fix could
go back all the way, but I'm not currently convinced that it makes
much difference in real-world cases, so I won't bother for now.
Discussion: https://postgr.es/m/17387-5dfe54b988444963@postgresql.org
M src/backend/parser/parse_coerce.c
M src/backend/parser/parse_expr.c
M src/include/parser/parse_coerce.h
M src/test/regress/expected/arrays.out
M src/test/regress/expected/expressions.out
M src/test/regress/sql/arrays.sql
M src/test/regress/sql/expressions.sql
Fix ordering of XIDs in ProcArrayApplyRecoveryInfo
commit : e90f258acaf2d78afc20842e7b63f0734c412bae
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 27 Jan 2022 17:53:53 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 27 Jan 2022 17:53:53 +0100
Commit 8431e296ea reworked ProcArrayApplyRecoveryInfo to sort XIDs
before adding them to KnownAssignedXids. But the XIDs are sorted using
xidComparator, which compares the XIDs simply as uint32 values, not
logically. KnownAssignedXidsAdd() however expects XIDs in logical order,
and calls TransactionIdFollowsOrEquals() to enforce that. If there are
XIDs for which the two orderings disagree, an error is raised and the
recovery fails/restarts.
Hitting this issue is fairly easy - you just need two transactions, one
started before the 4B limit (e.g. XID 4294967290), the other sometime
after it (e.g. XID 1000). Logically (4294967290 <= 1000) but when
compared using xidComparator we try to add them in the opposite order.
Which makes KnownAssignedXidsAdd() fail with an error like this:
ERROR: out-of-order XID insertion in KnownAssignedXids
This only happens during replica startup, while processing RUNNING_XACTS
records to build the snapshot. Once we reach STANDBY_SNAPSHOT_READY, we
skip these records. So this does not affect already running replicas,
but if you restart (or create) a replica while there are transactions
with XIDs for which the two orderings disagree, you may hit this.
Long-running transactions and frequent replica restarts increase the
likelihood of hitting this issue. Once the replica gets into this state,
it can't be started (even if the old transactions are terminated).
Fixed by sorting the XIDs logically - this is fine because we're dealing
with normal XIDs (because it's XIDs assigned to backends) and from the
same wraparound epoch (otherwise the backends could not be running at
the same time on the primary node). So there are no problems with the
triangle inequality, which is why xidComparator compares raw values.
Investigation and root cause analysis by Abhijit Menon-Sen. Patch by me.
This issue is present in all releases since 9.4, however releases up to
9.6 are EOL already so backpatch to 10 only.
Reviewed-by: Abhijit Menon-Sen
Reviewed-by: Alvaro Herrera
Backpatch-through: 10
Discussion: https://postgr.es/m/36b8a501-5d73-277c-4972-f58a4dce088a%40enterprisedb.com
M src/backend/storage/ipc/procarray.c
M src/backend/utils/adt/xid.c
M src/include/utils/builtins.h
On sparc64+ext4, suppress test failures from known WAL read failure.
commit : 785a28e422ea3fecbd38a3a49b488dc168ac3fb3
author : Noah Misch <noah@leadboat.com>
date : Wed, 26 Jan 2022 18:06:19 -0800
committer: Noah Misch <noah@leadboat.com>
date : Wed, 26 Jan 2022 18:06:19 -0800
Buildfarm members kittiwake, tadarida and snapper began to fail
frequently when commits 3cd9c3b921977272e6650a5efbeade4203c4bca2 and
f47ed79cc8a0cfa154dc7f01faaf59822552363f added tests of concurrency, but
the problem was reachable before those commits. Back-patch to v10 (all
supported versions).
Discussion: https://postgr.es/m/20220116210241.GC756210@rfd.leadboat.com
M contrib/amcheck/t/003_cic_2pc.pl
M src/test/perl/TestLib.pm
Fix pg_hba_file_rules for authentication method cert
commit : 81596645ca2ba382918fca9e82aa3089db737e14
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 26 Jan 2022 09:52:41 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 26 Jan 2022 09:52:41 +0100
For authentication method cert, clientcert=verify-full is implied. But
the pg_hba_file_rules entry would incorrectly show clientcert=verify-ca.
Per bug #17354
Reported-By: Feike Steenbergen
Reviewed-By: Jonathan Katz
Backpatch-through: 12
M src/backend/libpq/hba.c
Revert "graceful shutdown" changes for Windows, in back branches only.
commit : 213c5aa3bdba5783529d3c0f103dbfadf4f93f50
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Jan 2022 12:17:40 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Jan 2022 12:17:40 -0500
This reverts commits 6051857fc and ed52c3707, but only in the back
branches. Further testing has shown that while those changes do fix
some things, they also break others; in particular, it looks like
walreceivers fail to detect walsender-initiated connection close
reliably if the walsender shuts down this way. We'll keep trying to
improve matters in HEAD, but it now seems unwise to push these changes
into stable releases.
Discussion: https://postgr.es/m/CA+hUKG+OeoETZQ=Qw5Ub5h3tmwQhBmDA=nuNO3KG=zWfUypFAw@mail.gmail.com
M src/backend/libpq/pqcomm.c
Consider parallel awareness when removing single-child Appends
commit : f8807e7742e5ce058b6fe05d797852e082e6d2c8
author : David Rowley <drowley@postgresql.org>
date : Tue, 25 Jan 2022 21:15:00 +1300
committer: David Rowley <drowley@postgresql.org>
date : Tue, 25 Jan 2022 21:15:00 +1300
8edd0e794 added some code to remove Append and MergeAppend nodes when they
contained a single child node. As it turned out, this was unsafe to do
when the Append/MergeAppend was parallel_aware and the child node was not.
Removing the Append/MergeAppend, in this case, could lead to the child plan
being called multiple times by parallel workers when it was unsafe to do
so.
Here we fix this by just not removing the Append/MergeAppend when the
parallel_aware flag of the parent and child node don't match.
Reported-by: Yura Sokolov
Bug: #17335
Discussion: https://postgr.es/m/b59605fecb20ba9ea94e70ab60098c237c870628.camel%40postgrespro.ru
Backpatch-through: 12, where 8edd0e794 was first introduced
M src/backend/optimizer/plan/setrefs.c
doc: Fix some grammar
commit : 35893cc96856ae191fbe5c639a542117c0479880
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 25 Jan 2022 10:49:41 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 25 Jan 2022 10:49:41 +0900
This is an extraction of the user-visible changes done in 410aa24,
including all the relevant documentation parts.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20220124030001.GQ23027@telsasoft.com
Backpatch-through: 10
M doc/src/sgml/config.sgml
M doc/src/sgml/ddl.sgml
M doc/src/sgml/perform.sgml
M doc/src/sgml/protocol.sgml
M doc/src/sgml/ref/pg_receivewal.sgml
M doc/src/sgml/ref/select_into.sgml
Fix limitations on what SQL commands can be issued to a walsender.
commit : d67354d870bbddbde551e5b9804a42fb78af527e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 24 Jan 2022 15:33:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 24 Jan 2022 15:33:34 -0500
In logical replication mode, a WalSender is supposed to be able
to execute any regular SQL command, as well as the special
replication commands. Poor design of the replication-command
parser caused it to fail in various cases, notably:
* semicolons embedded in a command, or multiple SQL commands
sent in a single message;
* dollar-quoted literals containing odd numbers of single
or double quote marks;
* commands starting with a comment.
The basic problem here is that we're trying to run repl_scanner.l
across the entire input string even when it's not a replication
command. Since repl_scanner.l does not understand all of the
token types known to the core lexer, this is doomed to have
failure modes.
We certainly don't want to make repl_scanner.l as big as scan.l,
so instead rejigger stuff so that we only lex the first token of
a non-replication command. That will usually look like an IDENT
to repl_scanner.l, though a comment would end up getting reported
as a '-' or '/' single-character token. If the token is a replication
command keyword, we push it back and proceed normally with repl_gram.y
parsing. Otherwise, we can drop out of exec_replication_command()
without examining the rest of the string.
(It's still theoretically possible for repl_scanner.l to fail on
the first token; but that could only happen if it's an unterminated
single- or double-quoted string, in which case you'd have gotten
largely the same error from the core lexer too.)
In this way, repl_gram.y isn't involved at all in handling general
SQL commands, so we can get rid of the SQLCmd node type. (In
the back branches, we can't remove it because renumbering enum
NodeTag would be an ABI break; so just leave it sit there unused.)
I failed to resist the temptation to clean up some other sloppy
coding in repl_scanner.l while at it. The only externally-visible
behavior change from that is it now accepts \r and \f as whitespace,
same as the core lexer.
Per bug #17379 from Greg Rychlewski. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/17379-6a5c6cfb3f1f5e77@postgresql.org
M src/backend/replication/repl_gram.y
M src/backend/replication/repl_scanner.l
M src/backend/replication/walsender.c
M src/include/replication/walsender_private.h
Remember to reset yy_start state when firing up repl_scanner.l.
commit : c94c6612da573d2789855b77a47da45a4a19cfbd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 24 Jan 2022 12:09:46 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 24 Jan 2022 12:09:46 -0500
Without this, we get odd behavior when the previous cycle of
lexing exited in a non-default exclusive state. Every other
copy of this code is aware that it has to do BEGIN(INITIAL),
but repl_scanner.l did not get that memo.
The real-world impact of this is probably limited, since most
replication clients would abandon their connection after getting
a syntax error. Still, it's a bug.
This mistake is old, so back-patch to all supported branches.
Discussion: https://postgr.es/m/1874781.1643035952@sss.pgh.pa.us
M src/backend/replication/repl_scanner.l
Suppress variable-set-but-not-used warning from clang 13.
commit : 0cbc50737864177a29430be41e5b134a29e77554
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 23 Jan 2022 11:09:00 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 23 Jan 2022 11:09:00 -0500
In the normal configuration where GEQO_DEBUG isn't defined,
recent clang versions have started to complain that geqo_main.c
accumulates the edge_failures count but never does anything
with it. As a minimal back-patchable fix, insert a void cast
to silence this warning. (I'd speculated about ripping out the
GEQO_DEBUG logic altogether, but I don't think we'd wish to
back-patch that.)
Per recently-established project policy, this is a candidate
for back-patching into out-of-support branches: it suppresses
an annoying compiler warning but changes no behavior. Hence,
back-patch all the way to 9.2.
Discussion: https://postgr.es/m/CA+hUKGLTSZQwES8VNPmWO9AO0wSeLt36OCPDAZTccT1h7Q7kTQ@mail.gmail.com
M src/backend/optimizer/geqo/geqo_main.c
Correct type of front_pathkey to PathKey
commit : 4d8c4d2061f90db009ec834308e260fb5ca1e885
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 23 Jan 2022 03:36:55 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 23 Jan 2022 03:36:55 +0100
In sort_inner_and_outer we iterate a list of PathKey elements, but the
variable is declared as (List *). This mistake is benign, because we
only pass the pointer to lcons() and never dereference it.
This exists since ~2004, but it's confusing. So fix and backpatch to all
supported branches.
Backpatch-through: 10
Discussion: https://postgr.es/m/bf3a6ea1-a7d8-7211-0669-189d5c169374%40enterprisedb.com
M src/backend/optimizer/path/joinpath.c
Check syscache result in AlterStatistics
commit : 267ccc38ba6a95889d98959f183de64ceff23087
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 23 Jan 2022 02:49:41 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 23 Jan 2022 02:49:41 +0100
The syscache lookup may return NULL even for valid OID, for example due
to a concurrent DROP STATISTICS, so a HeapTupleIsValid is necessary.
Without it, it may fail with a segfault.
Reported by Alexander Lakhin, patch by me. Backpatch to 13, where ALTER
STATISTICS ... SET STATISTICS was introduced.
Backpatch-through: 13
Discussion: https://postgr.es/m/17372-bf3b6e947e35ae77%40postgresql.org
M src/backend/commands/statscmds.c
Flush table's relcache during ALTER TABLE ADD PRIMARY KEY USING INDEX.
commit : 31b7b4d26e10086d4a79d49a28fd161da52da49a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 22 Jan 2022 13:32:40 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 22 Jan 2022 13:32:40 -0500
Previously, unless we had to add a NOT NULL constraint to the column,
this command resulted in updating only the index's relcache entry.
That's problematic when replication behavior is being driven off the
existence of a primary key: other sessions (and ours too for that
matter) failed to recalculate their opinion of whether the table can
be replicated. Add a relcache invalidation to fix it.
This has been broken since pg_class.relhaspkey was removed in v11.
Before that, updating the table's relhaspkey value sufficed to cause
a cache flush. Hence, backpatch to v11.
Report and patch by Hou Zhijie
Discussion: https://postgr.es/m/OS0PR01MB5716EBE01F112C62F8F9B786947B9@OS0PR01MB5716.jpnprd01.prod.outlook.com
M src/backend/catalog/index.c
M src/test/regress/expected/publication.out
M src/test/regress/sql/publication.sql
Fix race condition in gettext() initialization in libpq and ecpglib.
commit : 64ebb43df068e3a9c01beeaacf7842080c43e712
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Jan 2022 15:36:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 21 Jan 2022 15:36:12 -0500
In libpq and ecpglib, multiple threads can concurrently enter the
initialization logic for message localization. Since we set the
its-done flag before actually doing the work, it'd be possible
for some threads to reach gettext() before anyone has called
bindtextdomain(). Barring bugs in libintl itself, this would not
result in anything worse than failure to localize some early
messages. Nonetheless, it's a bug, and an easy one to fix.
Noted while investigating bug #17299 from Clemens Zeidler
(much thanks to Liam Bowen for followup investigation on that).
It currently appears that that actually *is* a bug in libintl itself,
but that doesn't let us off the hook for this bit.
Back-patch to all supported versions.
Discussion: https://postgr.es/m/17299-7270741958c0b1ab@postgresql.org
Discussion: https://postgr.es/m/CAE7q7Eit4Eq2=bxce=Fm8HAStECjaXUE=WBQc-sDDcgJQ7s7eg@mail.gmail.com
M src/interfaces/ecpg/ecpglib/misc.c
M src/interfaces/libpq/fe-misc.c
fsync pg_logical/mappings in CheckPointLogicalRewriteHeap().
commit : fd48e5f5d3a14dda804e7b74e16dac6f5ab1b781
author : Andres Freund <andres@anarazel.de>
date : Fri, 21 Jan 2022 11:22:55 -0800
committer: Andres Freund <andres@anarazel.de>
date : Fri, 21 Jan 2022 11:22:55 -0800
While individual logical rewrite files were synced to disk, the directory was
not. On some filesystems that could lead to loosing directory entries after a
crash.
Reported-By: Tom Lane <tgl@sss.pgh.pa.us>
Author: Nathan Bossart <bossartn@amazon.com>
Discussion: https://postgr.es/m/867F2E29-2782-4869-970E-B984C6D35A8F@amazon.com
Backpatch: 10-
M src/backend/access/heap/rewriteheap.c
Fix one-off bug causing missing commit timestamps for subtransactions
commit : b5f634116e8f3e264cc06c053bd7b4e25a615665
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 21 Jan 2022 14:54:51 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 21 Jan 2022 14:54:51 +0900
The logic in charge of writing commit timestamps (enabled with
track_commit_timestamp) for subtransactions had a one-bug bug,
where it would be possible that commit timestamps go missing for the
last subtransaction committed.
While on it, simplify a bit the iteration logic in the loop writing the
commit timestamps, as per suggestions from Kyotaro Horiguchi and Tom
Lane, so as some variable initializations are not part of the loop
itself.
Issue introduced in 73c986a.
Analyzed-by: Alex Kingsborough
Author: Alex Kingsborough, Kyotaro Horiguchi
Discussion: https://postgr.es/m/73A66172-4050-4F2A-B7F1-13508EDA2144@amazon.com
Backpatch-through: 10
M src/backend/access/transam/commit_ts.c
Tighten TAP tests' tracking of postmaster state some more.
commit : 4828a80069abc3e4b5baffe3ebffb69e6dd5bc10
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 20 Jan 2022 17:28:07 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 20 Jan 2022 17:28:07 -0500
Commits 6c4a8903b et al. had a couple of deficiencies:
* The logic I added to Cluster::start to see if a PID file is present
could be fooled by a stale PID file left over from a previous
postmaster. To fix, if we're not sure whether we expect to find a
running postmaster or not, validate the PID using "kill 0".
* 017_shm.pl has a loop in which it just issues repeated Cluster::start
calls; this will fail if some invocation fails but leaves self->_pid
set. Per buildfarm results, the above fix is not enough to make this
safe: we might have "validated" a PID for a postmaster that exits
immediately after we look. Hence, match each failed start call with
a stop call that will get us back to the self->_pid == undef state.
Add a fail_ok option to Cluster::stop to make this work.
Discussion: https://postgr.es/m/CA+hUKGKV6fOHvfiPt8=dOKzvswjAyLoFoJF1iQXMNpi7+hD1JQ@mail.gmail.com
M src/test/perl/PostgresNode.pm
M src/test/recovery/t/017_shm.pl
Allow clean.bat to be run from anywhere
commit : 31680730ef7bac82ff09efa0824c2d8e5e8840f1
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 20 Jan 2022 10:13:18 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 20 Jan 2022 10:13:18 -0500
This was omitted from c3879a7b4c which modified the other msvc .bat
files.
Per request from Juan José Santamaría Flecha
Discussion: https://postgr.es/m/CAC+AXB0_fxYGbQoaYjCA8um7TTbOVP4L9aXnVmHwK8WzaT4gdA@mail.gmail.com
Backpatch to all live branches.
M src/tools/msvc/clean.bat
Try to stabilize reloptions test, again.
commit : 8e8e253a7b90d89dd9cb9d33848b55ac79958351
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 20 Jan 2022 22:11:48 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 20 Jan 2022 22:11:48 +1300
Since the test requires reproducible behavior from VACUUM, and since
DISABLE_PAGE_SKIPPING doesn't actually disable all forms of page
skipping, let's use a temporary table to avoid contention.
Back-patch to 12, like commit 3414099c.
Discussion: https://postgr.es/m/20220120052404.sonrhq3f3qgplpzj%40alap3.anarazel.de
M src/test/regress/expected/reloptions.out
M src/test/regress/sql/reloptions.sql
doc: Mention the level of locks taken on objects in COMMENT
commit : 3ca40a2b18a0638994e35160dfc8d392b1aef898
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 20 Jan 2022 16:54:58 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 20 Jan 2022 16:54:58 +0900
This information was nowhere to be found. This adds one note on the
page of COMMENT, and one note in the section dedicated to explicit
locking, both telling that a SHARE UPDATE EXCLUSIVE lock is taken on the
object commented.
Author: Nikolai Berkoff
Reviewed-by: Laurenz Albe
Discussion: https://postgr.es/m/_0HDHIGcCdCsUyXn22QwI2FEuNR6Fs71rtgGX6hfyBlUh5rrnE2qMmvIFu9EY4Pijr2gUmJEAXCjuNU2Oxku9TryLp9CdHllpsCfN3gD0-Y=@pm.me
Backpatch-through: 10
M doc/src/sgml/mvcc.sgml
M doc/src/sgml/ref/comment.sgml
TAP tests: check for postmaster.pid anyway when "pg_ctl start" fails.
commit : 6eec809fbcfbd8e0ab5e1c6485c7f53020f0d0b0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 19 Jan 2022 16:29:09 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 19 Jan 2022 16:29:09 -0500
"pg_ctl start" might start a new postmaster and then return failure
anyway, for example if PGCTLTIMEOUT is exceeded. If there is a
postmaster there, it's still incumbent on us to shut it down at
script end, so check for the PID file even though we are about
to fail.
This has been broken all along, so back-patch to all supported branches.
Discussion: https://postgr.es/m/647439.1642622744@sss.pgh.pa.us
M src/test/perl/PostgresNode.pm
doc: Fix description of pg_replication_origin_oid() in error case
commit : 3204b8a7affc7277ae4eebc3f53c566f859d1815
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 19 Jan 2022 10:37:53 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 19 Jan 2022 10:37:53 +0900
This function returns NULL if the replication origin given in input
argument does not exist, contrary to what the docs described
previously.
Author: Ian Barwick
Discussion: https://postgr.es/m/CAB8KJ=htJjBL=103URqjOxV2mqb4rjphDpMeKdyKq_QXt6h05w@mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/func.sgml
Try to stabilize the reloptions test.
commit : 639a9293d4cbf6bdfcc641f335e2c5a2359cce75
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 19 Jan 2022 07:03:01 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 19 Jan 2022 07:03:01 +1300
Where we test vacuum_truncate's effects, sometimes this is failing to
truncate as expected on the build farm. That could be explained by page
skipping, so disable it explicitly, with the theory that commit fe246d1c
didn't go far enough.
Back-patch to 12, where the vacuum_truncate tests were added.
Discussion: https://postgr.es/m/CA%2BhUKGLT2UL5_JhmBzUgkdyKfc%3D5J-gJSQJLysMs4rqLUKLAzw%40mail.gmail.com
M src/test/regress/expected/reloptions.out
M src/test/regress/sql/reloptions.sql
Fix psql \d's query for identifying parent triggers.
commit : 90e0f9fd8cae7cfb09c11534f690edde6d6ee06c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Jan 2022 21:18:49 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Jan 2022 21:18:49 -0500
The original coding (from c33869cc3) failed with "more than one row
returned by a subquery used as an expression" if there were unrelated
triggers of the same tgname on parent partitioned tables. (That's
possible because statement-level triggers don't get inherited.) Fix
by applying LIMIT 1 after sorting the candidates by inheritance level.
Also, wrap the subquery in a CASE so that we don't have to execute it at
all when the trigger is visibly non-inherited. Aside from saving some
cycles, this avoids the need for a confusing and undocumented NULLIF().
While here, tweak the format of the emitted query to look a bit
nicer for "psql -E", and add some explanation of this subquery,
because it badly needs it.
Report and patch by Justin Pryzby (with some editing by me).
Back-patch to v13 where the faulty code came in.
Discussion: https://postgr.es/m/20211217154356.GJ17618@telsasoft.com
M src/bin/psql/describe.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
Avoid calling gettext() in signal handlers.
commit : d18ec312f9f36c220aa1a1497d3173729c862d66
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Jan 2022 13:30:04 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Jan 2022 13:30:04 -0500
It seems highly unlikely that gettext() can be relied on to be
async-signal-safe. psql used to understand that, but someone got
it wrong long ago in the src/bin/scripts/ version of handle_sigint,
and then the bad idea was perpetuated when those two versions were
unified into src/fe_utils/cancel.c.
I'm unsure why there have not been field complaints about this
... maybe gettext() is signal-safe once it's translated at least
one message? But we have no business assuming any such thing.
In cancel.c (v13 and up), I preserved our ability to localize
"Cancel request sent" messages by invoking gettext() before
the signal handler is set up. In earlier branches I just made
src/bin/scripts/ not localize those messages, as psql did then.
(Just for extra unsafety, the src/bin/scripts/ version was
invoking fprintf() from a signal handler. Sigh.)
Noted while fixing signal-safety issues in PQcancel() itself.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/2937814.1641960929@sss.pgh.pa.us
M src/fe_utils/cancel.c
Avoid calling strerror[_r] in PQcancel().
commit : f27af7b880de97cccd24e37a62692f294bba5bba
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Jan 2022 12:52:44 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Jan 2022 12:52:44 -0500
PQcancel() is supposed to be safe to call from a signal handler,
and indeed psql uses it that way. All of the library functions
it uses are specified to be async-signal-safe by POSIX ...
except for strerror. Neither plain strerror nor strerror_r
are considered safe. When this code was written, back in the
dark ages, we probably figured "oh, strerror will just index
into a constant array of strings" ... but in any locale except C,
that's unlikely to be true. Probably the reason we've not heard
complaints is that (a) this error-handling code is unlikely to be
reached in normal use, and (b) in many scenarios, localized error
strings would already have been loaded, after which maybe it's
safe to call strerror here. Still, this is clearly unacceptable.
The best we can do without relying on strerror is to print the
decimal value of errno, so make it do that instead. (This is
probably not much loss of user-friendliness, given that it is
hard to get a failure here.)
Back-patch to all supported branches.
Discussion: https://postgr.es/m/2937814.1641960929@sss.pgh.pa.us
M src/interfaces/libpq/fe-connect.c
Fix psql's tab-completion of enum label values.
commit : 90a847e6dcc8fcf8d6f0eaf7b8022153d3b0f184
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Jan 2022 14:59:20 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Jan 2022 14:59:20 -0500
Since enum labels have to be single-quoted, this part of the
tab completion machinery got side-swiped by commit cd69ec66c.
A side-effect of that commit is that (at least with some versions
of Readline) the text string passed for completion will omit the
leading quote mark of the enum label literal. Libedit still acts
the same as before, though, so adapt COMPLETE_WITH_ENUM_VALUE so
that it can cope with either convention.
Also, when we fail to find any valid completion, set
rl_completion_suppress_quote = 1. Otherwise readline will
go ahead and append a closing quote, which is unwanted.
Per report from Peter Eisentraut. Back-patch to v13 where
cd69ec66c came in.
Discussion: https://postgr.es/m/8ca82d89-ec3d-8b28-8291-500efaf23b25@enterprisedb.com
M src/bin/psql/t/010_tab_completion.pl
M src/bin/psql/tab-complete.c
Build inherited extended stats on partitioned tables
commit : d6817032d26becd3c49f11d16efd6012e2139fc4
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sat, 15 Jan 2022 18:17:20 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sat, 15 Jan 2022 18:17:20 +0100
Commit 859b3003de disabled building of extended stats for inheritance
trees, to prevent updating the same catalog row twice. While that
resolved the issue, it also means there are no extended stats for
declaratively partitioned tables, because there are no data in the
non-leaf relations.
That also means declaratively partitioned tables were not affected by
the issue 859b3003de addressed, which means this is a regression
affecting queries that calculate estimates for the whole inheritance
tree as a whole (which includes e.g. GROUP BY queries).
But because partitioned tables are empty, we can invert the condition
and build statistics only for the case with inheritance, without losing
anything. And we can consider them when calculating estimates.
It may be necessary to run ANALYZE on partitioned tables, to collect
proper statistics. For declarative partitioning there should no prior
statistics, and it might take time before autoanalyze is triggered. For
tables partitioned by inheritance the statistics may include data from
child relations (if built 859b3003de), contradicting the current code.
Report and patch by Justin Pryzby, minor fixes and cleanup by me.
Backpatch all the way back to PostgreSQL 10, where extended statistics
were introduced (same as 859b3003de).
Author: Justin Pryzby
Reported-by: Justin Pryzby
Backpatch-through: 10
Discussion: https://postgr.es/m/20210923212624.GI831%40telsasoft.com
M src/backend/commands/analyze.c
M src/backend/statistics/dependencies.c
M src/backend/statistics/extended_stats.c
M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Ignore extended statistics for inheritance trees
commit : acfde7c5837dd3c2a40ff9cc639ba5d914e8e8ea
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sat, 15 Jan 2022 02:15:23 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sat, 15 Jan 2022 02:15:23 +0100
Since commit 859b3003de we only build extended statistics for individual
relations, ignoring the child relations. This resolved the issue with
updating catalog tuple twice, but we still tried to use the statistics
when calculating estimates for the whole inheritance tree. When the
relations contain very distinct data, it may produce bogus estimates.
This is roughly the same issue 427c6b5b9 addressed ~15 years ago, and we
fix it the same way - by ignoring extended statistics when calculating
estimates for the inheritance tree as a whole. We still consider
extended statistics when calculating estimates for individual child
relations, of course.
This may result in plan changes due to different estimates, but if the
old statistics were not describing the inheritance tree particularly
well it's quite likely the new plans is actually better.
Report and patch by Justin Pryzby, minor fixes and cleanup by me.
Backpatch all the way back to PostgreSQL 10, where extended statistics
were introduced (same as 859b3003de).
Author: Justin Pryzby
Reported-by: Justin Pryzby
Backpatch-through: 10
Discussion: https://postgr.es/m/20210923212624.GI831%40telsasoft.com
M src/backend/statistics/dependencies.c
M src/backend/statistics/extended_stats.c
M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Fix ruleutils.c's dumping of whole-row Vars in more contexts.
commit : ca14c4184b55cbe2fa79c87174b8064fc5f90874
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Jan 2022 17:49:26 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Jan 2022 17:49:26 -0500
Commit 7745bc352 intended to ensure that whole-row Vars would be
printed with "::type" decoration in all contexts where plain
"var.*" notation would result in star-expansion, notably in
ROW() and VALUES() constructs. However, it missed the case of
INSERT with a single-row VALUES, as reported by Timur Khanjanov.
Nosing around ruleutils.c, I found a second oversight: the
code for RowCompareExpr generates ROW() notation without benefit
of an actual RowExpr, and naturally it wasn't in sync :-(.
(The code for FieldStore also does this, but we don't expect that
to generate strictly parsable SQL anyway, so I left it alone.)
Back-patch to all supported branches.
Discussion: https://postgr.es/m/efaba6f9-4190-56be-8ff2-7a1674f9194f@intrans.baku.az
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
Doc: fix bogus example about ambiguous timestamps.
commit : 2180833ba90e9657a7e622b419194763890c8a6d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Jan 2022 11:46:16 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Jan 2022 11:46:16 -0500
I had a brain fade in commit d32899157, and used 2:30AM as the
example timestamp for both spring-forward and fall-back cases.
But it's not actually ambiguous at all in the fall-back case,
because that transition is from 2AM to 1AM under USA rules.
Fix the example to use 1:30AM, which *is* ambiguous.
Noted while answering a question from Aleksander Alekseev.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/2191355.1641828552@sss.pgh.pa.us
M doc/src/sgml/datetime.sgml
Avoid warning about uninitialized value in MSVC python3 tests
commit : 32cd4264ccfc00234c6500913800983ca1073729
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 10 Jan 2022 10:08:44 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 10 Jan 2022 10:08:44 -0500
Juan José Santamaría Flecha
Backpatch to all live branches
M src/tools/msvc/vcregress.pl
Fix results of index-only scans on btree_gist char(N) indexes.
commit : 823d4c7e25383cb4056c21615130b2abde17efba
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 8 Jan 2022 14:54:39 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 8 Jan 2022 14:54:39 -0500
If contrib/btree_gist is used to make a GIST index on a char(N)
(bpchar) column, and that column is retrieved via an index-only
scan, what came out had all trailing spaces removed. Since
that doesn't happen in any other kind of table scan, this is
clearly a bug. The cause is that gbt_bpchar_compress() strips
trailing spaces (using rtrim1) before a new index entry is made.
That was probably a good idea when this code was first written,
but since we invented index-only scans, it's not so good.
One answer could be to mark this opclass as incapable of index-only
scans. But to do so, we'd need an extension module version bump,
followed by manual action by DBAs to install the updated version
of btree_gist. And it's not really a desirable place to end up,
anyway.
Instead, let's fix the code by removing the unwanted space-stripping
action and adjusting the opclass's comparison logic to ignore
trailing spaces as bpchar normally does. This will not hinder
cases that work today, since index searches with this logic will
act the same whether trailing spaces are stored or not. It will
not by itself fix the problem of getting space-stripped results
from index-only scans, of course. Users who care about that can
REINDEX affected indexes after installing this update, to immediately
replace all improperly-truncated index entries. Otherwise, it can
be expected that the index's behavior will change incrementally as
old entries are replaced by new ones.
Per report from Alexander Lakhin. Back-patch to all supported branches.
Discussion: https://postgr.es/m/696c995b-b37f-5526-f45d-04abe713179f@gmail.com
M contrib/btree_gist/btree_text.c
M contrib/btree_gist/expected/char.out
M contrib/btree_gist/expected/char_1.out
Update copyright for 2022
commit : 410567177cd418569f1acac5e8073a1c407943ee
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 7 Jan 2022 19:04:56 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 7 Jan 2022 19:04:56 -0500
Backpatch-through: 10
M COPYRIGHT
M doc/src/sgml/legal.sgml
Allow MSVC .bat wrappers to be called from anywhere
commit : f3ded9c4600c000cdd7e0eb307bdfccd39a0e90e
author : Andrew Dunstan <andrew@dunslane.net>
date : Fri, 7 Jan 2022 16:07:45 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Fri, 7 Jan 2022 16:07:45 -0500
Instead of using a hardcoded or default path to the perl file the .bat
file is a wrapper for, we use a path that means the file is found in
the same directory as the .bat file.
Patch by Anton Voloshin, slightly tweaked by me.
Backpatch to all live branches
Discussion: https://postgr.es/m/2b7a674b-5fb0-d264-75ef-ecc7a31e54f8@postgrespro.ru
M src/tools/msvc/build.bat
M src/tools/msvc/install.bat
M src/tools/msvc/pgbison.bat
M src/tools/msvc/pgflex.bat
M src/tools/msvc/vcregress.bat
Prevent altering partitioned table's rowtype, if it's used elsewhere.
commit : 86d4bbb56a8aa94e8926067a5bf86a5a74b8c933
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Jan 2022 16:46:46 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Jan 2022 16:46:46 -0500
We disallow altering a column datatype within a regular table,
if the table's rowtype is used as a column type elsewhere,
because we lack code to go around and rewrite the other tables.
This restriction should apply to partitioned tables as well, but it
was not checked because ATRewriteTables and ATPrepAlterColumnType
were not on the same page about who should do it for which relkinds.
Per bug #17351 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/17351-6db1870f3f4f612a@postgresql.org
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
doc: Remove link to JSON support in the SQL specification
commit : 1105efdc1bba91a60551feae0342ba5973fa69ba
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 6 Jan 2022 11:41:44 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 6 Jan 2022 11:41:44 +0900
The link used in the documentation is dead, and the only options to have
an access to this part of the SQL specification are not free. Like any
other books referred, just remove the link to keep some neutrality but
keep its reference.
Reported-by: Erik Rijkers
Discussion: https://postgr.es/m/989abd7d-af30-ab52-1201-bf0b4f33b872@xs4all.nl
Backpatch-through: 12
M doc/src/sgml/biblio.sgml
Reduce relcache access in WAL sender streaming logical changes
commit : 3f8062bcf7f9fdc5b0f9dac41cbe62204969ebd1
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 5 Jan 2022 10:27:53 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 5 Jan 2022 10:27:53 +0900
get_rel_sync_entry(), which is called each time a change needs to be
logically replicated, is a rather hot code path in the WAL sender
sending logical changes. This code path was doing a relcache access on
relkind and relpartition for each logical change, but we only need to
know this information when building or re-building the cached
information for a relation.
Some measurements prove that this is noticeable in perf profiles,
particularly when attempting to replicate changes from relations that
are not published as these cause less overhead in the WAL sender,
delaying further the replication of changes for relations that are
published.
Issue introduced in 83fd453.
Author: Hou Zhijie
Reviewed-by: Kyotaro Horiguchi, Euler Taveira
Discussion: https://postgr.es/m/OS0PR01MB5716E863AA9E591C1F010F7A947D9@OS0PR01MB5716.jpnprd01.prod.outlook.com
Backpatch-through: 13
M src/backend/replication/pgoutput/pgoutput.c
Fix silly mistake in Assert
commit : 33fdd9f854f8db263d96e2916aa67325b8b26992
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 4 Jan 2022 13:21:23 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 4 Jan 2022 13:21:23 -0300
M src/backend/access/heap/heapam.c
Allow special SKIP LOCKED condition in Assert()
commit : 29f9fb8fe87005b2a75bd8ad2bc3d1f3ac0e9561
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 4 Jan 2022 13:01:05 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 4 Jan 2022 13:01:05 -0300
Under concurrency, it is possible for two sessions to be merrily locking
and releasing a tuple and marking it again as HEAP_XMAX_INVALID all the
while a third session attempts to lock it, miserably fails at it, and
then contemplates life, the universe and everything only to eventually
fail an assertion that said bit is not set. Before SKIP LOCKED that was
indeed a reasonable expectation, but alas! commit df630b0dd5ea falsified
it.
This bug is as old as time itself, and even older, if you think time
begins with the oldest supported branch. Therefore, backpatch to all
supported branches.
Author: Simon Riggs <simon.riggs@enterprisedb.com>
Discussion: https://postgr.es/m/CANbhV-FeEwMnN8yuMyss7if1ZKjOKfjcgqB26n8pqu1e=q0ebg@mail.gmail.com
M src/backend/access/heap/heapam.c
Fix index-only scan plans, take 2.
commit : 20d08b2c61cd7f224739a52fb069e93abe5d448d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Jan 2022 15:42:27 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Jan 2022 15:42:27 -0500
Commit 4ace45677 failed to fix the problem fully, because the
same issue of attempting to fetch a non-returnable index column
can occur when rechecking the indexqual after using a lossy index
operator. Moreover, it broke EXPLAIN for such indexquals (which
indicates a gap in our test cases :-().
Revert the code changes of 4ace45677 in favor of adding a new field
to struct IndexOnlyScan, containing a version of the indexqual that
can be executed against the index-returned tuple without using any
non-returnable columns. (The restrictions imposed by check_index_only
guarantee this is possible, although we may have to recompute indexed
expressions.) Support construction of that during setrefs.c
processing by marking IndexOnlyScan.indextlist entries as resjunk
if they can't be returned, rather than removing them entirely.
(We could alternatively require setrefs.c to look up the IndexOptInfo
again, but abusing resjunk this way seems like a reasonably safe way
to avoid needing to do that.)
This solution isn't great from an API-stability standpoint: if there
are any extensions out there that build IndexOnlyScan structs directly,
they'll be broken in the next minor releases. However, only a very
invasive extension would be likely to do such a thing. There's no
change in the Path representation, so typical planner extensions
shouldn't have a problem.
As before, back-patch to all supported branches.
Discussion: https://postgr.es/m/3179992.1641150853@sss.pgh.pa.us
Discussion: https://postgr.es/m/17350-b5bdcf476e5badbb@postgresql.org
M src/backend/commands/explain.c
M src/backend/executor/nodeIndexonlyscan.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/setrefs.c
M src/backend/optimizer/plan/subselect.c
M src/include/nodes/execnodes.h
M src/include/nodes/plannodes.h
M src/test/regress/expected/gist.out
M src/test/regress/sql/gist.sql
Fix typo
commit : 6c8110854168eb3799ccaaddb720678d0de6b0ee
author : Magnus Hagander <magnus@hagander.net>
date : Sun, 2 Jan 2022 17:03:32 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Sun, 2 Jan 2022 17:03:32 +0100
Reported-By: Eric Mutta
Backpatch-through: 10
Discussion: https://postgr.es/m/164052477973.21665.7888120874624887609@wrigleys.postgresql.org
M doc/src/sgml/high-availability.sgml
Fix index-only scan plans when not all index columns can be returned.
commit : 45ae4271410bfba0daba8e71eeb631c6f91088bb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 1 Jan 2022 16:12:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 1 Jan 2022 16:12:03 -0500
If an index has both returnable and non-returnable columns, and one of
the non-returnable columns is an expression using a Var that is in a
returnable column, then a query returning that expression could result
in an index-only scan plan that attempts to read the non-returnable
column, instead of recomputing the expression from the returnable
column as intended.
To fix, redefine the "indextlist" list of an IndexOnlyScan plan node
as containing null Consts in place of any non-returnable columns.
This solves the problem by preventing setrefs.c from falsely matching
to such entries. The executor is happy since it only cares about the
exposed types of the entries, and ruleutils.c doesn't care because a
correct plan won't reference those entries. I considered some other
ways to prevent setrefs.c from doing the wrong thing, but this way
seems good since (a) it allows a very localized fix, (b) it makes
the indextlist structure more compact in many cases, and (c) the
indextlist is now a more faithful representation of what the index AM
will actually produce, viz. nulls for any non-returnable columns.
This is easier to hit since we introduced included columns, but it's
possible to construct failing examples without that, as per the
added regression test. Hence, back-patch to all supported branches.
Per bug #17350 from Louis Jachiet.
Discussion: https://postgr.es/m/17350-b5bdcf476e5badbb@postgresql.org
M src/backend/optimizer/plan/createplan.c
M src/include/nodes/plannodes.h
M src/test/regress/expected/gist.out
M src/test/regress/sql/gist.sql
Fix overly generic name in with.sql test.
commit : cadd98cd3088b02581585cc5b1f11d38349a2128
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 30 Dec 2021 16:09:53 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 30 Dec 2021 16:09:53 +1300
Avoid the name "test". In the 10 branch, this could clash with
alter_table.sql, as seen in the build farm. That other instance was
already renamed in later branches by commit 2cf8c7aa, but it's good to
future-proof the name here too.
Back-patch to 10.
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CA%2BhUKGJf4RAXUyAYVUcQawcptX%3DnhEco3SYpuPK5cCbA-F1eLA%40mail.gmail.com
M src/test/regress/expected/with.out
M src/test/regress/sql/with.sql
doc: clarify when expression indexes evaluate their expressions
commit : e4f7c5144533c6ee9a84e1b1a30cedb20a3ebc75
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 22 Dec 2021 16:29:16 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 22 Dec 2021 16:29:16 -0500
Only non-HOT updates evaluate the index expression.
Reported-by: Chris Lowder
Discussion: https://postgr.es/m/163967385701.26064.15365003480975321072@wrigleys.postgresql.org
Backpatch-through: 10
M doc/src/sgml/indices.sgml
Correct comment and some documentation about REPLICA_IDENTITY_INDEX
commit : 28e1e5c2a91ccc2ad8f2749f36f0ac8eb3bca759
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 22 Dec 2021 16:38:42 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 22 Dec 2021 16:38:42 +0900
catalog/pg_class.h was stating that REPLICA_IDENTITY_INDEX with a
dropped index is equivalent to REPLICA_IDENTITY_DEFAULT. The code tells
a different story, as it is equivalent to REPLICA_IDENTITY_NOTHING.
The behavior exists since the introduction of replica identities, and
fe7fd4e even added tests for this case but I somewhat forgot to fix this
comment.
While on it, this commit reorganizes the documentation about replica
identities on the ALTER TABLE page, and a note is added about the case
of dropped indexes with REPLICA_IDENTITY_INDEX.
Author: Michael Paquier, Wei Wang
Reviewed-by: Euler Taveira
Discussion: https://postgr.es/m/OS3PR01MB6275464AD0A681A0793F56879E759@OS3PR01MB6275.jpnprd01.prod.outlook.com
Backpatch-through: 10
M doc/src/sgml/ref/alter_table.sgml
M src/include/catalog/pg_class.h
Ensure casting to typmod -1 generates a RelabelType.
commit : da0d8a4545e639ca9c22dc2a0a10dcddcdf58761
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 Dec 2021 15:36:02 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 Dec 2021 15:36:02 -0500
Fix the code changed by commit 5c056b0c2 so that we always generate
RelabelType, not something else, for a cast to unspecified typmod.
Otherwise planner optimizations might not happen.
It appears we missed this point because the previous experiments were
done on type numeric: the parser undesirably generates a call on the
numeric() length-coercion function, but then numeric_support()
optimizes that down to a RelabelType, so that everything seems fine.
It misbehaves for types that have a non-optimized length coercion
function, such as bpchar.
Per report from John Naylor. Back-patch to all supported branches,
as the previous patch eventually was. Unfortunately, that no longer
includes 9.6 ... we really shouldn't put this type of change into a
nearly-EOL branch.
Discussion: https://postgr.es/m/CAFBsxsEfbFHEkouc+FSj+3K1sHipLPbEC67L0SAe-9-da8QtYg@mail.gmail.com
M src/backend/parser/parse_coerce.c
M src/test/regress/expected/expressions.out
M src/test/regress/sql/expressions.sql
Adjust behavior of some env settings for the TAP tests of MSVC
commit : aadbf825b7c41e241d27dc4d8ed7d77fc4718634
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 15 Dec 2021 10:40:12 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 15 Dec 2021 10:40:12 +0900
edc2332 has introduced in vcregress.pl some control on the environment
variables LZ4, TAR and GZIP_PROGRAM to allow any TAP tests to be able
use those commands. This makes the settings more consistent with
src/Makefile.global.in, as the same default gets used for Make and MSVC
builds.
Each parameter can be changed in buildenv.pl, but as a default gets
assigned after loading buldenv.pl, it is not possible to unset any of
these, and using an empty value would not work with "||=" either. As
some environments may not have a compatible command in their PATH (tar
coming from MinGW is an issue, for one), this could break tests without
an exit path to bypass any failing test. This commit changes things so
as the default values for LZ4, TAR and GZIP_PROGRAM are assigned before
loading buildenv.pl, not after. This way, we keep the same amount of
compatibility as a GNU build with the same defaults, and it becomes
possible to unset any of those values.
While on it, this adds some documentation about those three variables in
the section dedicated to the TAP tests for MSVC.
Per discussion with Andrew Dunstan.
Discussion: https://postgr.es/m/YbGYe483803il3X7@paquier.xyz
Backpatch-through: 10
M doc/src/sgml/install-windows.sgml
M src/tools/msvc/vcregress.pl
Fix datatype confusion in logtape.c's right_offset().
commit : 0a5682041dbf991bd325a7d14daf39ecfc9bd624
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Dec 2021 11:46:36 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Dec 2021 11:46:36 -0500
This could only matter if (a) long is wider than int, and (b) the heap
of free blocks exceeds UINT_MAX entries, which seems pretty unlikely.
Still, it's a theoretical bug, so backpatch to v13 where the typo came
in (in commit c02fdc922).
In passing, also make swap_nodes() use consistent datatypes.
Ma Liangzhu
Discussion: https://postgr.es/m/17336-fc4e522d26a750fd@postgresql.org
M src/backend/utils/sort/logtape.c
Remove assertion for replication origins in PREPARE TRANSACTION
commit : 3f710fc2b48d6326958260f10bd139a1e87fcf53
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 14 Dec 2021 10:58:29 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 14 Dec 2021 10:58:29 +0900
When using replication origins, pg_replication_origin_xact_setup() is an
optional choice to be able to set a LSN and a timestamp to mark the
origin, which would be additionally added to WAL for transaction commits
or aborts (including 2PC transactions). An assertion in the code path
of PREPARE TRANSACTION assumed that this data should always be set, so
it would trigger when using replication origins without setting up an
origin LSN. Some tests are added to cover more this kind of scenario.
Oversight in commit 1eb6d65.
Per discussion with Amit Kapila and Masahiko Sawada.
Discussion: https://postgr.es/m/YbbBfNSvMm5nIINV@paquier.xyz
Backpatch-through: 11
M contrib/test_decoding/expected/replorigin.out
M contrib/test_decoding/sql/replorigin.sql
M src/backend/access/transam/twophase.c
Doc: de-document unimplemented geometric operators.
commit : e459dcfde80402ab55e2fe84c5be4483ce34fce1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Dec 2021 17:49:36 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Dec 2021 17:49:36 -0500
In commit 791090bd7, I made an effort to fill in documentation
for all geometric operators listed in pg_operator. However,
it now appears that at least some of the omissions may have been
intentional, because some of those operator entries point at
unimplemented stub functions. Remove those from the docs again.
(In HEAD, poly_distance stays, because c5c192d7b just added an
implementation for it.)
Per complaint from Anton Voloshin.
Discussion: https://postgr.es/m/3426566.1638832718@sss.pgh.pa.us
M doc/src/sgml/func.sgml
isolationtester: append session name to application_name.
commit : 65f860e78a04f4f035dcec04c5c796793113dfba
author : Andres Freund <andres@anarazel.de>
date : Mon, 13 Dec 2021 12:02:45 -0800
committer: Andres Freund <andres@anarazel.de>
date : Mon, 13 Dec 2021 12:02:45 -0800
When writing / debugging an isolation test it sometimes is useful to see which
session holds what lock etc. To make it easier, both as part of spec files and
interactively, append the session name to application_name. Since b1907d688
application_name already contains the test name, this appends the session's
name to that.
insert-conflict-specconflict did something like this manually, which can now
be removed.
As we have done lately with other test infrastructure improvements, backpatch
this change, to make it easier to backpatch tests.
Author: Andres Freund <andres@anarazel.de>
Reviewed-By: Michael Paquier <michael@paquier.xyz>
Reviewed-By: Andrew Dunstan <andrew@dunslane.net>
Discussion: https://postgr.es/m/20211211012052.2blmzcmxnxqawd2z@alap3.anarazel.de
Backpatch: 10-, to make backpatching of tests easier.
M src/test/isolation/expected/insert-conflict-specconflict.out
M src/test/isolation/isolationtester.c
M src/test/isolation/specs/insert-conflict-specconflict.spec
Fix double publish of child table's data.
commit : 3f06c00cf6dcd838b61c5d452d4908b5b6e17762
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 9 Dec 2021 09:00:35 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 9 Dec 2021 09:00:35 +0530
We publish the child table's data twice for a publication that has both
child and parent tables and is published with publish_via_partition_root
as true. This happens because subscribers will initiate synchronization
using both parent and child tables, since it gets both as separate tables
in the initial table list.
Ensure that pg_publication_tables returns only parent tables in such
cases.
Author: Hou Zhijie
Reviewed-by: Greg Nancarrow, Amit Langote, Vignesh C, Amit Kapila
Backpatch-through: 13
Discussion: https://postgr.es/m/OS0PR01MB57167F45D481F78CDC5986F794B99@OS0PR01MB5716.jpnprd01.prod.outlook.com
M src/backend/catalog/pg_publication.c
M src/test/regress/expected/publication.out
M src/test/regress/sql/publication.sql
M src/test/subscription/t/013_partition.pl
Doc: improve xfunc-c-type-table.
commit : a96a1d656274d3e1ca7cd4c34b7ba79a2754b71d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Dec 2021 16:54:31 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Dec 2021 16:54:31 -0500
List types numeric and timestamptz, which don't seem to have ever been
included here. Restore bigint, which was no-doubt-accidentally deleted
in v12. Fix some errors, or at least obsolete usages (nobody declares
float arguments as "float8*" anymore, even though they might be that
under the hood). Re-alphabetize. Remove the seeming claim that this
is a complete list of built-in types.
Per question from Oskar Stenberg.
Discussion: https://postgr.es/m/HE1PR03MB2971DE2527ECE1E99D6C19A8F96E9@HE1PR03MB2971.eurprd03.prod.outlook.com
M doc/src/sgml/xfunc.sgml
Fix corruption of toast indexes with REINDEX CONCURRENTLY
commit : 9acea52ea3d48627f12b9a2b4498197d3b05fe2e
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 8 Dec 2021 11:01:19 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 8 Dec 2021 11:01:19 +0900
REINDEX CONCURRENTLY run on a toast index or a toast relation could
corrupt the target indexes rebuilt, as a backend running in parallel
that manipulates toast values would directly release the lock on the
toast relation when its local operation is done, rather than releasing
the lock once the transaction that manipulated the toast values
committed.
The fix done here is simple: we now hold a ROW EXCLUSIVE lock on the
toast relation when saving or deleting a toast value until the
transaction working on them is committed, so as a concurrent reindex
happening in parallel would be able to wait for any activity and see any
new rows inserted (or deleted).
An isolation test is added to check after the case fixed here, which is
a bit fancy by design as it relies on allow_system_table_mods to rename
the toast table and its index to fixed names. This way, it is possible
to reindex them directly without any dependency on the OID of the
underlying relation. Note that this could not use a DO block either, as
REINDEX CONCURRENTLY cannot be run in a transaction block. The test is
backpatched down to 13, where it is possible, thanks to c4a7a39, to use
allow_system_table_mods in a test suite.
Reported-by: Alexey Ermakov
Analyzed-by: Andres Freund, Noah Misch
Author: Michael Paquier
Reviewed-by: Nathan Bossart
Discussion: https://postgr.es/m/17268-d2fb426e0895abd4@postgresql.org
Backpatch-through: 12
M src/backend/access/common/toast_internals.c
A src/test/isolation/expected/reindex-concurrently-toast.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/reindex-concurrently-toast.spec
Enable settings used in TAP tests for MSVC builds
commit : 14c54e40f59a741afafa84015681f13ba083eed6
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 7 Dec 2021 15:05:33 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 7 Dec 2021 15:05:33 -0500
Certain settings from configuration or the Makefile infrastructure are
used by the TAP tests, but were not being set up by vcregress.pl. This
remedies those omissions. This should increase test coverage, especially
on the buildfarm.
Reviewed by Noah Misch
Discussion: https://postgr.es/m/17093da5-e40d-8335-d53a-2bd803fc38b0@dunslane.net
Backpatch to all live branches.
M src/tools/msvc/vcregress.pl
On Windows, also call shutdown() while closing the client socket.
commit : a8a983e8299ae7e63b18b3965ca1f55e18f84a06
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Dec 2021 13:34:06 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Dec 2021 13:34:06 -0500
Further experimentation shows that commit 6051857fc is not sufficient
when using (some versions of?) OpenSSL. The reason is obscure, but
calling shutdown(socket, SD_SEND) improves matters.
Per testing by Andrew Dunstan and Alexander Lakhin.
Back-patch as before.
Discussion: https://postgr.es/m/af5e0bf3-6a61-bb97-6cba-061ddf22ff6b@dunslane.net
M src/backend/libpq/pqcomm.c
Doc: Fix misleading wording of CRL parameters
commit : e2ebc90eb8090def69b2d3aa86f6caf3a8026f6b
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Fri, 3 Dec 2021 14:15:50 +0100
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Fri, 3 Dec 2021 14:15:50 +0100
ssl_crl_file and ssl_crl_dir are both used to for client certificate
revocation, not server certificates. The description for the params
could be easily misread to mean the opposite however, as evidenced
by the bugreport leading to this fix. Similarly, expand sslcrl and
and sslcrldir to explicitly mention server certificates. While there
also mention sslcrldir where previously only sslcrl was discussed.
Backpatch down to v10, with the CRL dir fixes down to 14 where they
were introduced.
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Reviewed-by: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Discussion: https://postgr.es/m/20211202.135441.590555657708629486.horikyota.ntt@gmail.com
Discussion: https://postgr.es/m/CABWY_HCBUCjY1EJHrEGePGEaSZ5b29apgTohCyygtsqe_ySYng@mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/config.sgml
M doc/src/sgml/libpq.sgml
postgres_fdw: Fix unexpected reporting of empty message.
commit : f89015b63f532063560ef78bc1d0d8c166173c6d
author : Fujii Masao <fujii@postgresql.org>
date : Fri, 3 Dec 2021 17:35:29 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Fri, 3 Dec 2021 17:35:29 +0900
pgfdw_report_error() in postgres_fdw gets a message from PGresult or
PGconn to report an error received from a remote server. Previously
if it could get a message from neither of them, it reported empty
message unexpectedly. The cause of this issue was that pgfdw_report_error()
didn't handle properly the case where no message could be obtained
and its local variable message_primary was set to '\0'.
This commit improves pgfdw_report_error() so that it reports the message
"could not obtain ..." when it gets no message and message_primary
is set to '\0'. This is the same behavior as when message_primary is NULL.
dblink_res_error() in dblink has the same issue, so this commit also
improves it in the same way.
Back-patch to all supported branches.
Author: Fujii Masao
Reviewed-by: Bharath Rupireddy
Discussion: https://postgr.es/m/477c16c8-7ea4-20fc-38d5-ed3a77ed616c@oss.nttdata.com
M contrib/dblink/dblink.c
M contrib/postgres_fdw/connection.c
On Windows, close the client socket explicitly during backend shutdown.
commit : 6251f86241acd05facefc4b4caacc9430b059d58
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 Dec 2021 17:14:43 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 Dec 2021 17:14:43 -0500
It turns out that this is necessary to keep Winsock from dropping any
not-yet-sent data, such as an error message explaining the reason for
process termination. It's pretty weird that the implicit close done
by the kernel acts differently from an explicit close, but it's hard
to argue with experimental results.
Independently submitted by Alexander Lakhin and Lars Kanis (comments
by me, though). Back-patch to all supported branches.
Discussion: https://postgr.es/m/90b34057-4176-7bb0-0dbb-9822a5f6425b@greiz-reinsdorf.de
Discussion: https://postgr.es/m/16678-253e48d34dc0c376@postgresql.org
M src/backend/libpq/pqcomm.c
Move into separate file all the SQL queries used in pg_upgrade tests
commit : fae5f08e17193a8e0c8ca941e0bed4c4d105df14
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 2 Dec 2021 10:31:34 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 2 Dec 2021 10:31:34 +0900
The existing pg_upgrade/test.sh and the buildfarm code have been holding
the same set of SQL queries when doing cross-version upgrade tests to
adapt the objects created by the regression tests before the upgrade
(mostly, incompatible or non-existing objects need to be dropped from
the origin, perhaps re-created).
This moves all those SQL queries into a new, separate, file with a set
of \if clauses to handle the version checks depending on the old version
of the cluster to-be-upgraded.
The long-term plan is to make the buildfarm code re-use this new SQL
file, so as committers are able to fix any compatibility issues in the
tests of pg_upgrade with a refresh of the core code, without having to
poke at the buildfarm client. Note that this is only able to handle the
main regression test suite, and that nothing is done yet for contrib
modules yet (these have more issues like their database names).
A backpatch down to 10 is done, adapting the version checks as this
script needs to be only backward-compatible, so as it becomes possible
to clean up a maximum amount of code within the buildfarm client.
Author: Justin Pryzby, Michael Paquier
Discussion: https://postgr.es/m/20201206180248.GI24052@telsasoft.com
Backpatch-through: 10
M src/bin/pg_upgrade/test.sh
A src/bin/pg_upgrade/upgrade_adapt.sql
Avoid leaking memory during large-scale REASSIGN OWNED BY operations.
commit : 7413caabe66e02b8967825a2dc1041e9db246622
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Dec 2021 13:44:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Dec 2021 13:44:47 -0500
The various ALTER OWNER routines tend to leak memory in
CurrentMemoryContext. That's not a problem when they're only called
once per command; but in this usage where we might be touching many
objects, it can amount to a serious memory leak. Fix that by running
each call in a short-lived context.
(DROP OWNED BY likely has a similar issue, except that you'll probably
run out of lock table space before noticing. REASSIGN is worth fixing
since for most non-table object types, it won't take any lock.)
Back-patch to all supported branches. Unfortunately, in the back
branches this helps to only a limited extent, since the sinval message
queue bloats quite a lot in this usage before commit 3aafc030a,
consuming memory more or less comparable to what's actually leaked.
Still, it's clearly a leak with a simple fix, so we might as well fix it.
Justin Pryzby, per report from Guillaume Lelarge
Discussion: https://postgr.es/m/CAECtzeW2DAoioEGBRjR=CzHP6TdL=yosGku8qZxfX9hhtrBB0Q@mail.gmail.com
M src/backend/catalog/pg_shdepend.c
Doc: Add "Attach Partition" limitation during logical replication.
commit : 64e8456bbde159f29aaa528d311e41590a3dbec5
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 1 Dec 2021 10:26:59 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 1 Dec 2021 10:26:59 +0530
ATTACHing a table into a partition tree whose root is published using a
publication with publish_via_partition_root set to true does not result in
the table's existing contents being replicated. This happens because
subscriber doesn't consider replicating the newly attached partition as
the root table is already in a 'ready' state.
This behavior was introduced in PG13 (83fd4532a7) where we allowed to
publish partition changes via ancestors.
We can consider fixing this limitation in the future.
Author: Amit Langote
Reviewed-by: Hou Zhijie, Amit Kapila
Backpatch-through: 13
Discussion: https://postgr.es/m/OS0PR01MB5716E97F00732B52DC2BBC2594989@OS0PR01MB5716.jpnprd01.prod.outlook.com
M doc/src/sgml/ref/create_publication.sgml
Doc: improve documentation about ORDER BY in matviews.
commit : a7359913a1c22e8c04f37140b9d983919baf10b2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Nov 2021 12:13:13 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Nov 2021 12:13:13 -0500
Remove the confusing use of ORDER BY in an example materialized
view. It adds nothing to the example, but might encourage
people to follow bad practice. Clarify REFRESH MATERIALIZED
VIEW's note about whether view ordering is retained (it isn't).
Maciek Sakrejda
Discussion: https://postgr.es/m/CAOtHd0D-OvrUU0C=4hX28p4BaSE1XL78BAQ0VcDaLLt8tdUzsg@mail.gmail.com
M doc/src/sgml/ref/refresh_materialized_view.sgml
M doc/src/sgml/rules.sgml
Harden be-gssapi-common.h for headerscheck
commit : f76fd05bae047103cb36ef5fb82137c8995142c1
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 26 Nov 2021 17:00:29 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 26 Nov 2021 17:00:29 -0300
Surround the contents with a test that the feature is enabled by
configure, to silence header checking tools on systems without GSSAPI
installed.
Backpatch to 12, where the file appeared.
Discussion: https://postgr.es/m/202111161709.u3pbx5lxdimt@alvherre.pgsql
M src/include/libpq/be-gssapi-common.h
Document units for max_slot_wal_keep_size
commit : 899a4b25ad6b45c3f7fbdbc177211b7279dba56a
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 26 Nov 2021 14:31:57 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 26 Nov 2021 14:31:57 -0300
The doc blurb failed to mention units, as well as lacking the point
about changeability.
Backpatch to 13.
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Reported by: b1000101@pm.me
Discussion: https://postgr.es/m/163760291192.26193.10801700492025355788@wrigleys.postgresql.org
M doc/src/sgml/config.sgml
Fix determination of broken LSN in OVERWRITTEN_CONTRECORD
commit : ef41c3fd6c86d6fa504144996b339704347322c9
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 26 Nov 2021 11:14:27 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 26 Nov 2021 11:14:27 -0300
In commit ff9f111bce24 I mixed up inconsistent definitions of the LSN of
the first record in a page, when the previous record ends exactly at the
page boundary. The correct LSN is adjusted to skip the WAL page header;
I failed to use that when setting XLogReaderState->overwrittenRecPtr,
so at WAL replay time VerifyOverwriteContrecord would refuse to let
replay continue past that record.
Backpatch to 10. 9.6 also contains this bug, but it's no longer being
maintained.
Discussion: https://postgr.es/m/45597.1637694259@sss.pgh.pa.us
M src/backend/access/transam/xlogreader.c
Remove unneeded Python includes
commit : 04875ae92f14c0b23438e5316d92f82518bb068a
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 25 Nov 2021 14:19:22 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 25 Nov 2021 14:19:22 +0100
Inluding <compile.h> and <eval.h> has not been necessary since Python
2.4, since they are included via <Python.h>. Morever, <eval.h> is
being removed in Python 3.11. So remove these includes.
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/flat/84884.1637723223%40sss.pgh.pa.us
M src/pl/plpython/plpython.h
Block ALTER TABLE .. DROP NOT NULL on columns in replica identity index
commit : 37827de430deba44f373db1e4efae0c9e320ef2d
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 25 Nov 2021 15:05:28 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 25 Nov 2021 15:05:28 +0900
Replica identities that depend directly on an index rely on a set of
properties, one of them being that all the columns defined in this index
have to be marked as NOT NULL. There was a hole in the logic with ALTER
TABLE DROP NOT NULL, where it was possible to remove the NOT NULL
property of a column part of an index used as replica identity, so block
it to avoid problems with logical decoding down the road.
The same check was already done columns part of a primary key, so the
fix is straight-forward.
Author: Haiying Tang, Hou Zhijie
Reviewed-by: Dilip Kumar, Michael Paquier
Discussion: https://postgr.es/m/OS0PR01MB6113338C102BEE8B2FFC5BD9FB619@OS0PR01MB6113.jpnprd01.prod.outlook.com
Backpatch-through: 10
M src/backend/commands/tablecmds.c
M src/test/regress/expected/replica_identity.out
M src/test/regress/sql/replica_identity.sql
Doc: improve documentation about nextval()/setval().
commit : 499552273d47645c759d58c5916b3bc8ecc7f13d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Nov 2021 13:37:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Nov 2021 13:37:12 -0500
Clarify that the results of nextval and setval are not guaranteed
persistent until the calling transaction commits. Some people
seem to have drawn the opposite conclusion from the statement that
these functions are never rolled back, so re-word to avoid saying
it quite that way.
Discussion: https://postgr.es/m/CAKU4AWohO=NfM-4KiZWvdc+z3c1C9FrUBR6xnReFJ6sfy0i=Lw@mail.gmail.com
M doc/src/sgml/func.sgml
Fix missing space in docs.
commit : 892da5200aaf31f950021b4bf92916ad35113f2e
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 24 Nov 2021 18:32:56 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 24 Nov 2021 18:32:56 +0200
Author: Japin Li
Discussion: https://www.postgresql.org/message-id/MEYP282MB1669C36E5F733C2EFBDCB80BB6619@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
M doc/src/sgml/arch-dev.sgml
Add support for Visual Studio 2022 in build scripts
commit : baef657d3c846a43932e6c8c467afd69472f273e
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 24 Nov 2021 13:03:59 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 24 Nov 2021 13:03:59 +0900
Documentation and any code paths related to VS are updated to keep the
whole consistent. Similarly to 2017 and 2019, the version of VS and the
version of nmake that we use to determine which code paths to use for
the build are still inconsistent in their own way.
Backpatch down to 10, so as buildfarm members are able to use this new
version of Visual Studio on all the stable branches supported.
Author: Hans Buschmann
Discussion: https://postgr.es/m/1633101364685.39218@nidsa.net
Backpatch-through: 10
M doc/src/sgml/install-windows.sgml
M src/tools/msvc/MSBuildProject.pm
M src/tools/msvc/README
M src/tools/msvc/Solution.pm
M src/tools/msvc/VSObjectFactory.pm
Adjust pg_dump's priority ordering for casts.
commit : d4f6a36d8265b06d50ec3d55c928fb1d92cb0586
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Nov 2021 17:16:29 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Nov 2021 17:16:29 -0500
When a stored expression depends on a user-defined cast, the backend
records the dependency as being on the cast's implementation function
--- or indeed, if there's no cast function involved but just
RelabelType or CoerceViaIO, no dependency is recorded at all. This
is problematic for pg_dump, which is at risk of dumping things in the
wrong order leading to restore failures. Given the lack of previous
reports, the risk isn't that high, but it can be demonstrated if the
cast is used in some view whose rowtype is then used as an input or
result type for some other function. (That results in the view
getting hoisted into the functions portion of the dump, ahead of
the cast.)
A logically bulletproof fix for this would require including the
cast's OID in the parsed form of the expression, whence it could be
extracted by dependency.c, and then the stored dependency would force
pg_dump to do the right thing. Such a change would be fairly invasive,
and certainly not back-patchable. Moreover, since we'd prefer that
an expression using cast syntax be equal() to one doing the same
thing by explicit function call, the cast OID field would have to
have special ignored-by-comparisons semantics, making things messy.
So, let's instead fix this by a very simple hack in pg_dump: change
the object-type priority order so that casts are initially sorted
before functions, immediately after types. This fixes the problem
in a fairly direct way for casts that have no implementation function.
For those that do, the implementation function will be hoisted to just
before the cast by the dependency sorting step, so that we still have
a valid dump order. (I'm not sure that this provides a full guarantee
of no problems; but since it's been like this for many years without
any previous reports, this is probably enough to fix it in practice.)
Per report from Дмитрий Иванов.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAPL5KHoGa3uvyKp6z6m48LwCnTsK+LRQ_mcA4uKGfqAVSEjV_A@mail.gmail.com
M src/bin/pg_dump/pg_dump_sort.c
Pacify perlcritic.
commit : b542e4596e339b8a6ca94723f35ccc1667dbc306
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Nov 2021 15:57:31 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Nov 2021 15:57:31 -0500
Per buildfarm.
M config/check_modules.pl
Fix pg_dump --inserts mode for generated columns with dropped columns.
commit : 6fc8b145e74303bfba6bd21fd7c33d343ee37d44
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Nov 2021 15:25:48 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Nov 2021 15:25:48 -0500
If a table contains a generated column that's preceded by a dropped
column, dumpTableData_insert failed to account for the dropped
column, and would emit DEFAULT placeholder(s) in the wrong column(s).
This resulted in failures at restore time. The default COPY code path
did not have this bug, likely explaining why it wasn't noticed sooner.
While we're fixing this, we can be a little smarter about the
situation: (1) avoid unnecessarily fetching the values of generated
columns, (2) omit generated columns from the output, too, if we're
using --column-inserts. While these modes aren't expected to be
as high-performance as the COPY path, we might as well be as
efficient as we can; it doesn't add much complexity.
Per report from Дмитрий Иванов.
Back-patch to v12 where generated columns came in.
Discussion: https://postgr.es/m/CAPL5KHrkBniyQt5e1rafm5DdXvbgiiqfEQEJ9GjtVzN71Jj5pA@mail.gmail.com
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl
Probe $PROVE not $PERL while checking for modules needed by TAP tests.
commit : ec383ca2df0a6f77a9b49dcd8853e76e6b328d37
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Nov 2021 12:54:52 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Nov 2021 12:54:52 -0500
Normally "prove" and "perl" come from the same Perl installation,
but we support the case where they don't (mainly because the MSys
buildfarm animals need this). In that case, AX_PROG_PERL_MODULES
is completely the wrong thing to use, because it's checking what
"perl" has. Instead, make a little TAP test script including the
required modules, and run that under "prove".
We don't need ax_prog_perl_modules.m4 at all after this change,
so remove it.
Back-patch to all supported branches, for the buildfarm's benefit.
(In v10, this also back-patches the effects of commit 264eb03aa.)
Andrew Dunstan and Tom Lane, per an observation by Noah Misch
Discussion: https://postgr.es/m/E1moZHS-0002Cu-Ei@gemulon.postgresql.org
M aclocal.m4
D config/ax_prog_perl_modules.m4
A config/check_modules.pl
M configure
M configure.in
pg_receivewal, pg_recvlogical: allow canceling initial password prompt.
commit : 33edf4a3ca4c1fdb7665ea3a4d01bb5fc7477117
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 21 Nov 2021 14:13:35 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 21 Nov 2021 14:13:35 -0500
Previously it was impossible to terminate these programs via control-C
while they were prompting for a password. We can fix that trivially
for their initial password prompts, by moving setup of the SIGINT
handler from just before to just after their initial GetConnection()
calls.
This fix doesn't permit escaping out of later re-prompts, but those
should be exceedingly rare, since the user's password or the server's
authentication setup would have to have changed meanwhile. We
considered applying a fix similar to commit 46d665bc2, but that
seemed more complicated than it'd be worth. Moreover, this way is
back-patchable, which that wasn't.
The misbehavior exists in all supported versions, so back-patch to all.
Tom Lane and Nathan Bossart
Discussion: https://postgr.es/m/747443.1635536754@sss.pgh.pa.us
M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_basebackup/pg_recvlogical.c
Fix parallel operations that prevent oldest xmin from advancing.
commit : 33b6dd83e26f06c96e7d54af534a70476749cbab
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 19 Nov 2021 09:24:00 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 19 Nov 2021 09:24:00 +0530
While determining xid horizons, we skip over backends that are running
Vacuum. We also ignore Create Index Concurrently, or Reindex Concurrently
for the purposes of computing Xmin for Vacuum. But we were not setting the
flags corresponding to these operations when they are performed in
parallel which was preventing Xid horizon from advancing.
The optimization related to skipping Create Index Concurrently, or Reindex
Concurrently operations was implemented in PG-14 but the fix is the same
for the Parallel Vacuum as well so back-patched till PG-13.
Author: Masahiko Sawada
Reviewed-by: Amit Kapila
Backpatch-through: 13
Discussion: https://postgr.es/m/CAD21AoCLQqgM1sXh9BrDFq0uzd3RBFKi=Vfo6cjjKODm0Onr5w@mail.gmail.com
M src/backend/access/heap/vacuumlazy.c
M src/backend/storage/ipc/procarray.c
M src/include/storage/proc.h
Use appropriate -Wno-warning switches when compiling bitcode.
commit : 77c8892a1989d91d8f1c9eb988b3c27ddad0ea07
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 18 Nov 2021 14:50:13 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 18 Nov 2021 14:50:13 -0500
We use "clang" to compile bitcode files for LLVM inlining. That might
be different from the build's main C compiler, so it needs its own set
of compiler flags. To simplify configure, we don't bother adding any
-W switches to that flag set; there's little need since the main build
will show us any warnings. However, if we don't want to see unwanted
warnings, we still have to add any -Wno-warning switches we'd normally
use with clang.
This escaped notice before commit 9ff47ea41, which tried to add
-Wno-compound-token-split-by-macro; buildfarm animals using mismatched
CC and CLANG still showed those warnings. I'm not sure why we never
saw any effects from the lack of -Wno-unused-command-line-argument
(maybe that's only activated by -Wall?). clang does not currently
support -Wno-format-truncation or -Wno-stringop-truncation, although
in the interests of future-proofing and consistency I included tests
for those.
Back-patch to v11 where we started building bitcode files.
Discussion: https://postgr.es/m/2921539.1637254619@sss.pgh.pa.us
M configure
M configure.in
Fix quoting of ACL item in table for upgrade binary compatibility checks
commit : 49f2b1168a8f4ad29b6c1cf9e448ace5e3c8f901
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 18 Nov 2021 12:53:02 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 18 Nov 2021 12:53:02 +0900
Per buildfarm member prion, that runs the regression tests under a role
name that uses a hyphen. Issue introduced by 835bcba.
Discussion: https://postgr.es/m/YZW4MvzCZ+hQ34vw@paquier.xyz
Backpatch-through: 12
M src/test/regress/expected/type_sanity.out
M src/test/regress/sql/type_sanity.sql
Add table to regression tests for binary-compatibility checks in pg_upgrade
commit : 755f04c72ef1bac5e34ab698aaf9d3a303ac5197
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 18 Nov 2021 10:37:39 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 18 Nov 2021 10:37:39 +0900
This commit adds to the main regression test suite a table with all
the in-core data types (some exceptions apply). This table is not
dropped, so as pg_upgrade would be able to check the binary
compatibility of the types tracked in the table. If a new type is added
in core, this part of the tests would need a refresh but the tests are
designed to fail if that were to happen.
As this is useful for upgrades and that these rely on the objects
created in the regression test suite of the old version upgraded from,
a backpatch down to 12 is done, which is the last point where a binary
incompatible change has been done (7c15cef). This will hopefully be
enough to find out if something gets broken during the development of a
new version of Postgres, so as it is possible to take actions in
pg_upgrade itself in this case (like 0ccfc28 for sql_identifier).
An area that is not covered yet is related to external modules, which
may create their own types. The testing infrastructure of pg_upgrade is
not integrated yet with the external modules stored in core
(src/test/modules/ or contrib/, all use the same database name for their
tests so there would be an overlap). This could be improved in the
future.
Author: Justin Pryzby
Reviewed-by: Jacob Champion, Peter Eisentraut, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/20201206180248.GI24052@telsasoft.com
Backpatch-through: 12
M src/test/regress/expected/sanity_check.out
M src/test/regress/expected/type_sanity.out
M src/test/regress/sql/type_sanity.sql
Clean up error handling in pg_basebackup's walmethods.c.
commit : c8b5221b57677231511039e943150a74353ed44d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Nov 2021 14:16:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Nov 2021 14:16:34 -0500
The error handling here was a mess, as a result of a fundamentally
bad design (relying on errno to keep its value much longer than is
safe to assume) as well as a lot of just plain sloppiness, both as
to noticing errors at all and as to reporting the correct errno.
Moreover, the recent addition of LZ4 compression broke things
completely, because liblz4 doesn't use errno to report errors.
To improve matters, keep the error state in the DirectoryMethodData or
TarMethodData struct, and add a string field so we can handle cases
that don't set errno. (The tar methods already had a version of this,
but it can be done more efficiently since all these cases use a
constant error string.) Make the dir and tar methods handle errors
in basically identical ways, which they didn't before.
This requires copying errno into the state struct in a lot of places,
which is a bit tedious, but it has the virtue that we can get rid of
ad-hoc code to save and restore errno in a number of places ... not
to mention that it fixes other places that should've saved/restored
errno but neglected to.
In passing, fix some pointlessly static buffers to be ordinary
local variables.
There remains an issue about exactly how to handle errors from
fsync(), but that seems like material for its own patch.
While the LZ4 problems are new, all the rest of this is fixes for
old bugs, so backpatch to v10 where walmethods.c was introduced.
Patch by me; thanks to Michael Paquier for review.
Discussion: https://postgr.es/m/1343113.1636489231@sss.pgh.pa.us
M src/bin/pg_basebackup/walmethods.c
Handle close() failures more robustly in pg_dump and pg_basebackup.
commit : bbda88c3383dd8da07f36f06d34cb876bc4982e7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Nov 2021 13:08:25 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Nov 2021 13:08:25 -0500
Coverity complained that applying get_gz_error after a failed gzclose,
as we did in one place in pg_basebackup, is unsafe. I think it's
right: it's entirely likely that the call is touching freed memory.
Change that to inspect errno, as we do for other gzclose calls.
Also, be careful to initialize errno to zero immediately before any
gzclose() call where we care about the error status. (There are
some calls where we don't, because we already failed at some previous
step.) This ensures that we don't get a misleadingly irrelevant
error code if gzclose() fails in a way that doesn't set errno.
We could work harder at that, but it looks to me like all such cases
are basically can't-happen if we're not misusing zlib, so it's
not worth the extra notational cruft that would be required.
Also, fix several places that simply failed to check for close-time
errors at all, mostly at some remove from the close or gzclose itself;
and one place that did check but didn't bother to report the errno.
Back-patch to v12. These mistakes are older than that, but between
the frontend logging API changes that happened in v12 and the fact
that frontend code can't rely on %m before that, the patch would need
substantial revision to work in older branches. It doesn't quite
seem worth the trouble given the lack of related field complaints.
Patch by me; thanks to Michael Paquier for review.
Discussion: https://postgr.es/m/1343113.1636489231@sss.pgh.pa.us
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_basebackup/receivelog.c
M src/bin/pg_basebackup/walmethods.c
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_directory.c
M src/bin/pg_dump/pg_backup_tar.c
Doc: add see-also references to CREATE PUBLICATION.
commit : df9e65b854647aa12607baa6ed8071b02f481a8c
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Wed, 17 Nov 2021 13:34:41 +0100
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Wed, 17 Nov 2021 13:34:41 +0100
The "See also" section on the reference page for CREATE PUBLICATION
didn't match the cross references on CREATE SUBSCRIPTION and their
ALTER counterparts. Fixed by adding an xref to the CREATE and ALTER
SUBSCRIPTION pages. Backpatch down to v10 where CREATE PUBLICATION
was introduced.
Author: Peter Smith <smithpb2250@gmail.com>
Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com>
Discussion: https://postgr.es/m/CAHut+PvGWd3-Ktn96c-z6uq-8TGVVP=TPOkEovkEfntoo2mRhw@mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/ref/create_publication.sgml
Invalidate relcache when changing REPLICA IDENTITY index.
commit : 63c3eeddc2db1b939e7f4fa8ad8ad0f3757232b1
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 16 Nov 2021 08:46:12 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 16 Nov 2021 08:46:12 +0530
When changing REPLICA IDENTITY INDEX to another one, the target table's
relcache was not being invalidated. This leads to skipping update/delete
operations during apply on the subscriber side as the columns required to
search corresponding rows won't get logged.
Author: Tang Haiying, Hou Zhijie
Reviewed-by: Euler Taveira, Amit Kapila
Backpatch-through: 10
Discussion: https://postgr.es/m/OS0PR01MB61133CA11630DAE45BC6AD95FB939@OS0PR01MB6113.jpnprd01.prod.outlook.com
M src/backend/commands/tablecmds.c
M src/test/subscription/t/100_bugs.pl
Make psql's \password default to CURRENT_USER, not PQuser(conn).
commit : 843925fadbd8d450d00229647b1d6933a4aae5e8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 Nov 2021 14:55:32 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 Nov 2021 14:55:32 -0500
The documentation says plainly that \password acts on "the current user"
by default. What it actually acted on, or tried to, was the username
used to log into the current session. This is not the same thing if
one has since done SET ROLE or SET SESSION AUTHENTICATION. Aside from
the possible surprise factor, it's quite likely that the current role
doesn't have permissions to set the password of the original role.
To fix, use "SELECT CURRENT_USER" to get the role name to act on.
(This syntax works with servers at least back to 7.0.) Also, in
hopes of reducing confusion, include the role name that will be
acted on in the password prompt.
The discrepancy from the documentation makes this a bug, so
back-patch to all supported branches.
Patch by me; thanks to Nathan Bossart for review.
Discussion: https://postgr.es/m/747443.1635536754@sss.pgh.pa.us
M src/bin/psql/command.c
Fix memory overrun when querying pg_stat_slru
commit : a691a229831ad3b72d933b1858c76be44b508400
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 12 Nov 2021 21:50:08 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 12 Nov 2021 21:50:08 +0900
pg_stat_get_slru() in pgstatfuncs.c would point to one element after the
end of the array PgStat_SLRUStats when finishing to scan its entries.
This had no direct consequences as no data from the extra memory area
was read, but static analyzers would rightfully complain here. So let's
be clean.
While on it, this adds one regression test in the area reserved for
system views.
Reported-by: Alexander Kozhemyakin, via AddressSanitizer
Author: Kyotaro Horiguchi
Discussion: https://postgr.es/m/17280-37da556e86032070@postgresql.org
Backpatch-through: 13
M src/backend/utils/adt/pgstatfuncs.c
M src/test/regress/expected/sysviews.out
M src/test/regress/sql/sysviews.sql
Report any XLogReadRecord() error in XlogReadTwoPhaseData().
commit : d4e9d6946995cceaed97ee4570c4c867b3ea2104
author : Noah Misch <noah@leadboat.com>
date : Thu, 11 Nov 2021 17:10:18 -0800
committer: Noah Misch <noah@leadboat.com>
date : Thu, 11 Nov 2021 17:10:18 -0800
Buildfarm members kittiwake and tadarida have witnessed errors at this
site. The site discarded key facts. Back-patch to v10 (all supported
versions).
Reviewed by Michael Paquier and Tom Lane.
Discussion: https://postgr.es/m/20211107013157.GB790288@rfd.leadboat.com
M src/backend/access/transam/twophase.c
Fix buffer overrun in unicode string normalization with empty input
commit : 13c8adf90e9d9bc58209ab820775949336d901f7
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 11 Nov 2021 15:01:54 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 11 Nov 2021 15:01:54 +0900
PostgreSQL 13 and newer versions are directly impacted by that through
the SQL function normalize(), which would cause a call of this function
to write one byte past its allocation if using in input an empty
string after recomposing the string with NFC and NFKC. Older versions
(v10~v12) are not directly affected by this problem as the only code
path using normalization is SASLprep in SCRAM authentication that
forbids the case of an empty string, but let's make the code more robust
anyway there so as any out-of-core callers of this function are covered.
The solution chosen to fix this issue is simple, with the addition of a
fast-exit path if the decomposed string is found as empty. This would
only happen for an empty string as at its lowest level a codepoint would
be decomposed as itself if it has no entry in the decomposition table or
if it has a decomposition size of 0.
Some tests are added to cover this issue in v13~. Note that an empty
string has always been considered as normalized (grammar "IS NF[K]{C,D}
NORMALIZED", through the SQL function is_normalized()) for all the
operations allowed (NFC, NFD, NFKC and NFKD) since this feature has been
introduced as of 2991ac5. This behavior is unchanged but some tests are
added in v13~ to check after that.
I have also checked "make normalization-check" in src/common/unicode/,
while on it (works in 13~, and breaks in older stable branches
independently of this commit).
The release notes should just mention this commit for v13~.
Reported-by: Matthijs van der Vleuten
Discussion: https://postgr.es/m/17277-0c527a373794e802@postgresql.org
Backpatch-through: 10
M src/common/unicode_norm.c
M src/test/regress/expected/unicode.out
M src/test/regress/sql/unicode.sql
Clean up compilation warnings coming from PL/Perl with clang-12~
commit : aa449e5caed8b3745ec86d358bbfdaaacf8dbfbe
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 11 Nov 2021 10:51:12 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 11 Nov 2021 10:51:12 +0900
clang-12 has introduced -Wcompound-token-split-by-macro, that is causing
a large amount of warnings when building PL/Perl because of its
interactions with upstream Perl. This commit adds one -Wno to CFLAGS at
./configure time if the flag is supported by the compiler to silence all
those warnings.
Upstream perl has fixed this issue, but it is going to take some time
before this is spread across the buildfarm, and we have noticed that
some animals would be useful with an extra -Werror to help with the
detection of incorrect placeholders (see b0cf544), dangomushi being
one.
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/YYr3qYa/R3Gw+Sbg@paquier.xyz
Backpatch-through: 10
M configure
M configure.in
Doc: improve protocol spec for logical replication Type messages.
commit : 78f058411b02a54e4fde43744e35089d0ab57683
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 10 Nov 2021 13:12:58 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 10 Nov 2021 13:12:58 -0500
protocol.sgml documented the layout for Type messages, but completely
dropped the ball otherwise, failing to explain what they are, when
they are sent, or what they're good for. While at it, do a little
copy-editing on the description of Relation messages.
In passing, adjust the comment for apply_handle_type() to make it
clearer that we choose not to do anything when receiving a Type
message, not that we think it has no use whatsoever.
Per question from Stefen Hillman.
Discussion: https://postgr.es/m/CAPgW8pMknK5pup6=T4a_UG=Cz80Rgp=KONqJmTdHfaZb0RvnFg@mail.gmail.com
M doc/src/sgml/protocol.sgml
M src/backend/replication/logical/worker.c
Fix instability in 026_overwrite_contrecord.pl test.
commit : 5a3240cf6b2e9f5fb6befe7e1ac4c0c0464ce3d2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 9 Nov 2021 18:40:19 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 9 Nov 2021 18:40:19 -0500
We've seen intermittent failures in this test on slower buildfarm
machines, which I think can be explained by assuming that autovacuum
emitted some additional WAL. Disable autovacuum to stabilize it.
In passing, use stringwise not numeric comparison to compare
WAL file names. Doesn't matter at present, but they are
hex strings not decimal ...
Discussion: https://postgr.es/m/1372189.1636499287@sss.pgh.pa.us
M src/test/recovery/t/026_overwrite_contrecord.pl
Stamp 13.5.
commit : 084346ccee8ead6b387a90cdf6a29036ae9ec77e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Nov 2021 17:00:24 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Nov 2021 17:00:24 -0500
M configure
M configure.in
Last-minute updates for release notes.
commit : 402c3ba3954d81531b6c9ff9b5d554552a85c6a7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Nov 2021 14:02:16 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Nov 2021 14:02:16 -0500
Security: CVE-2021-23214, CVE-2021-23222
M doc/src/sgml/release-13.sgml
libpq: reject extraneous data after SSL or GSS encryption handshake.
commit : 844b3169204c28cd086c1b4fae4a2cbdd0540640
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Nov 2021 11:14:56 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
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 : e92ed93e8eb76ee0701b42d4f0ce94e6af3fc741
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Nov 2021 11:01:43 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
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 : 7c0a78f089980cec45927aa3160add1781aed402
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 8 Nov 2021 09:17:24 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 8 Nov 2021 09:17:24 -0300
Introduced in 1d97d3d0867f.
Co-authored-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/83641f59-d566-b33e-ef21-a272a98675aa@gmail.com
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 : 98da5cd0d1b1c47a19f8453413c0fd01c07b3830
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 8 Nov 2021 10:08:56 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 8 Nov 2021 10:08:56 +0100
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 027ff7dad8afb1a907cb4c59da4e13c3ace8d376
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/pg_archivecleanup/po/fr.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_checksums/po/fr.po
M src/bin/pg_checksums/po/ru.po
M src/bin/pg_checksums/po/sv.po
M src/bin/pg_config/po/fr.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_controldata/po/fr.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/fr.po
M src/bin/pg_ctl/po/ru.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_timing/po/ru.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_verifybackup/po/fr.po
M src/bin/pg_verifybackup/po/ru.po
M src/bin/pg_waldump/po/fr.po
M src/bin/pg_waldump/po/ru.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/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/plpgsql/src/po/fr.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/fr.po
M src/pl/tcl/po/fr.po
Release notes for 14.1, 13.5, 12.9, 11.14, 10.19, 9.6.24.
commit : 5d73415d20086406f083eb0929626036e10797a1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 Nov 2021 14:21:50 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 Nov 2021 14:21:50 -0500
M doc/src/sgml/release-13.sgml
Reset lastOverflowedXid on standby when needed
commit : e1fee28a0441652f021045646808a772314798f9
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sat, 6 Nov 2021 18:31:21 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
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 : bf5cdcfd5e444756378e60307a89b8cad16f65c0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 5 Nov 2021 12:29:34 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
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 <exclusion@gmail.com>
Discussion: https://postgr.es/m/17126-21887f04508cb5c8@postgresql.org
M src/backend/catalog/dependency.c
M src/backend/catalog/pg_shdepend.c
Update alternative expected output file.
commit : b7299b66469fe90c5cbb19c1d02d8e91fc95e4f2
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 3 Nov 2021 19:38:17 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
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/DBA08346-9962-4706-92D1-230EE5201C10@yesql.se
M src/test/regress/output/largeobject_1.source
Fix snapshot reference leak if lo_export fails.
commit : 07070c0082aacc9e9bf09d1d08bc3a60c999332e
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 3 Nov 2021 10:28:52 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
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/32bf767a-2d65-71c4-f170-122f416bab7e@iki.fi
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
Fix variable lifespan in ExecInitCoerceToDomain().
commit : ada667b45496998674818e135e9cd6580f1bc019
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Nov 2021 13:36:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Nov 2021 13:36:47 -0400
This undoes a mistake in 1ec7679f1: domainval and domainnull were
meant to live across loop iterations, but they were incorrectly
moved inside the loop. The effect was only to emit useless extra
EEOP_MAKE_READONLY steps, so it's not a big deal; nonetheless,
back-patch to v13 where the mistake was introduced.
Ranier Vilela
Discussion: https://postgr.es/m/CAEudQAqXuhbkaAp-sGH6dR6Nsq7v28_0TPexHOm6FiDYqwQD-w@mail.gmail.com
M src/backend/executor/execExpr.c
Avoid O(N^2) behavior in SyncPostCheckpoint().
commit : 0151af40cd4e0321bc549cea9f0c631bce0303c5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Nov 2021 11:31:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Nov 2021 11:31:54 -0400
As in commits 6301c3ada and e9d9ba2a4, avoid doing repetitive
list_delete_first() operations, since that would be expensive when
there are many files waiting to be unlinked. This is a slightly
larger change than in those cases. We have to keep the list state
valid for calls to AbsorbSyncRequests(), so it's necessary to invent a
"canceled" field instead of immediately deleting PendingUnlinkEntry
entries. Also, because we might not be able to process all the
entries, we need a new list primitive list_delete_first_n().
list_delete_first_n() is almost list_copy_tail(), but it modifies the
input List instead of making a new copy. I found a couple of existing
uses of the latter that could profitably use the new function. (There
might be more, but the other callers look like they probably shouldn't
overwrite the input List.)
As before, back-patch to v13.
Discussion: https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com
M src/backend/nodes/list.c
M src/backend/optimizer/util/clauses.c
M src/backend/parser/parse_func.c
M src/backend/storage/sync/sync.c
M src/include/nodes/pg_list.h
Avoid some other O(N^2) hazards in list manipulation.
commit : e477642a1ba8041c94cae2f8bbdb689f05cb0260
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Nov 2021 16:24:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Nov 2021 16:24:40 -0400
In the same spirit as 6301c3ada, fix some more places where we were
using list_delete_first() in a loop and thereby risking O(N^2)
behavior. It's not clear that the lists manipulated in these spots
can get long enough to be really problematic ... but it's not clear
that they can't, either, and the fixes are simple enough.
As before, back-patch to v13.
Discussion: https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com
M contrib/pg_trgm/trgm_regexp.c
M src/backend/executor/nodeAgg.c
M src/backend/jit/llvm/llvmjit.c
Handle XLOG_OVERWRITE_CONTRECORD in DecodeXLogOp
commit : 17227825ca4288c70af45038ac6af26be7fde570
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 1 Nov 2021 13:07:23 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
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 <petr.jelinek@enterprisedb.com>
M src/backend/replication/logical/decode.c
Preserve opclass parameters across REINDEX CONCURRENTLY
commit : 77f7909a409eac9ee9a5728a4f80741925580fb6
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 1 Nov 2021 11:40:29 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 1 Nov 2021 11:40:29 +0900
The opclass parameter Datums from the old index are fetched in the same
way as for predicates and expressions, by grabbing them directly from
the system catalogs. They are then copied into the new IndexInfo that
will be used for the creation of the new copy.
This caused the new index to be rebuilt with default parameters rather
than the ones pre-defined by a user. The only way to get back a new
index with correct opclass parameters would be to recreate a new index
from scratch.
The issue has been introduced by 911e702.
Author: Michael Paquier
Reviewed-by: Zhihong Yu
Discussion: https://postgr.es/m/YX0CG/QpLXcPr8HJ@paquier.xyz
Backpatch-through: 13
M src/backend/catalog/index.c
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Don't try to read a multi-GB pg_stat_statements file in one call.
commit : 3a5b313ce74864303a8a5d6556b49d642c422922
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 31 Oct 2021 19:13:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/17254-a926c89dc03375c2@postgresql.org
M contrib/pg_stat_statements/pg_stat_statements.c
Avoid O(N^2) behavior when the standby process releases many locks.
commit : df238aed1090249a2bcd21e1688a398c6f513dfd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 31 Oct 2021 15:31:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 31 Oct 2021 15:31:29 -0400
When replaying a transaction that held many exclusive locks on the
primary, a standby server's startup process would expend O(N^2)
effort on manipulating the list of locks. This code was fine when
written, but commit 1cff1b95a made repetitive list_delete_first()
calls inefficient, as explained in its commit message. Fix by just
iterating the list normally, and releasing storage only when done.
(This'd be inadequate if we needed to recover from an error occurring
partway through; but we don't.)
Back-patch to v13 where 1cff1b95a came in.
Nathan Bossart
Discussion: https://postgr.es/m/CD2F0E7F-9822-45EC-A411-AE56F14DEA9F@amazon.com
M src/backend/storage/ipc/standby.c
Update time zone data files to tzdata release 2021e.
commit : 4cd72add0579d33e741cb1a2effe6ee727a994dd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 29 Oct 2021 11:38:18 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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
Improve contrib/amcheck's tests for CREATE INDEX CONCURRENTLY.
commit : 5a4b8a8a720ca699c5cbcfc04069dfe089f218c8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 28 Oct 2021 11:45:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 28 Oct 2021 11:45:14 -0400
Commits fdd965d07 and 3cd9c3b92 tested CREATE INDEX CONCURRENTLY by
launching two separate pgbench runs concurrently. This was needed so
that only a single client thread would run CREATE INDEX CONCURRENTLY,
avoiding deadlock between two CICs. However, there's a better way,
which is to use an advisory lock to prevent concurrent CICs. That's
better in part because the test code is shorter and more readable, but
mostly because it automatically scales things to launch an appropriate
number of CICs relative to the number of INSERT transactions.
As committed, typically half to three-quarters of the CIC transactions
were pointless because the INSERT transactions had already stopped.
In passing, remove background_pgbench, which was added to support
these tests and isn't needed anymore. We can always put it back
if we find a use for it later.
Back-patch to v12; older pgbench versions lack the
conditional-execution features needed for this method.
Tom Lane and Andrey Borodin
Discussion: https://postgr.es/m/139687.1635277318@sss.pgh.pa.us
M contrib/amcheck/t/002_cic.pl
M contrib/amcheck/t/003_cic_2pc.pl
M src/test/perl/PostgresNode.pm
doc: Fix link to SELinux user guide in sepgsql page
commit : 0a75e1186afe58e140cc5eb0f6f0c13f5b7d8c3b
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 28 Oct 2021 09:26:18 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 28 Oct 2021 09:26:18 +0900
Reported-by: Anton Voloshin
Discussion: https://postgr.es/m/15a86d4e-a237-1acd-18a2-fd69730f1ab9@postgrespro.ru
Backpatch-through: 10
M doc/src/sgml/sepgsql.sgml
Fix ordering of items in nbtree error message.
commit : d5a2ffbce534e4fe9d207da14c9b7cf7a00a7953
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 27 Oct 2021 13:09:00 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 27 Oct 2021 13:09:00 -0700
Oversight in commit a5213adf.
Backpatch: 13-, just like commit a5213adf.
M src/backend/access/nbtree/nbtinsert.c
Further harden nbtree posting split code.
commit : f8cce4a3d88ccce830086bc80b563bd152f4955f
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 27 Oct 2021 12:10:43 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 27 Oct 2021 12:10:43 -0700
Add more defensive checks around posting list split code. These should
detect corruption involving duplicate table TIDs earlier and more
reliably than any existing check.
Follow up to commit 8f72bbac.
Discussion: https://postgr.es/m/CAH2-WzkrSY_kjyd1_M5xJK1uM0govJXMxPn8JUSvwcUOiHuWVw@mail.gmail.com
Backpatch: 13-, where nbtree deduplication was introduced.
M src/backend/access/nbtree/nbtinsert.c
M src/backend/access/nbtree/nbtsearch.c
Clarify that --system reindexes system catalogs *only*
commit : dd111887fbaead778d1077dfbc92b520a5188b51
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 27 Oct 2021 16:20:02 +0200
committer: Magnus Hagander <magnus@hagander.net>
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
Reject huge_pages=on if shared_memory_type=sysv.
commit : 24b7cf8a5cff0b0e2dba12a3a1f5c7638ace9986
author : Thomas Munro <tmunro@postgresql.org>
date : Tue, 26 Oct 2021 12:54:55 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Tue, 26 Oct 2021 12:54:55 +1300
It doesn't work (it could, but hasn't been implemented).
Back-patch to 12, where shared_memory_type arrived.
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Reviewed-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/163271880203.22789.1125998876173795966@wrigleys.postgresql.org
M doc/src/sgml/config.sgml
M src/backend/port/sysv_shmem.c
Fix CREATE INDEX CONCURRENTLY for the newest prepared transactions.
commit : a9d0a54094153d8714a66444e89e565bb3eb21e4
author : Noah Misch <noah@leadboat.com>
date : Sat, 23 Oct 2021 18:36:38 -0700
committer: Noah Misch <noah@leadboat.com>
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/01824242-AA92-4FE9-9BA7-AEBAFFEA3D0C@yandex-team.ru
A contrib/amcheck/t/003_cic_2pc.pl
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
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 : 2e33b43599ad3868ee180f149050444bf0a7ca15
author : Noah Misch <noah@leadboat.com>
date : Sat, 23 Oct 2021 18:36:38 -0700
committer: Noah Misch <noah@leadboat.com>
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/20210730022548.GA1940096@gust.leadboat.com
M contrib/amcheck/Makefile
A contrib/amcheck/t/002_cic.pl
M src/backend/utils/cache/inval.c
M src/backend/utils/cache/relcache.c
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 : 7c949f1b3aab8f0cf02afa42c44a9dfc66188c70
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 23 Oct 2021 14:43:45 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 23 Oct 2021 14:43:45 +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
Fix frontend version of sh_error() in simplehash.h.
commit : 2e01d050d989d67f491349018a09574427d1d0ba
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Oct 2021 16:43:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Oct 2021 16:43:38 -0400
The code does not expect sh_error() to return, but the patch
that made this header usable in frontend didn't get that memo.
While here, plaster unlikely() on the tests that decide whether
to invoke sh_error(), and add our standard copyright notice.
Noted by Andres Freund. Back-patch to v13 where this frontend
support came in.
Discussion: https://postgr.es/m/0D54435C-1199-4361-9D74-2FBDCF8EA164@anarazel.de
M src/include/lib/simplehash.h
pg_dump: fix mis-dumping of non-global default privileges.
commit : 476006023538730d2291125b883bfe07d03f3dfa
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Oct 2021 15:22:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/111621616618184@mail.yandex.ru
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 : 23469b867ac000b8ed36fdeaab5c40ba9be23772
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 21 Oct 2021 09:36:27 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 21 Oct 2021 09:36:27 +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/808ed65b-994c-915a-361c-577f088b837f@amazon.com
M src/backend/replication/logical/reorderbuffer.c
Protect against collation variations in test
commit : a73a3671daea34f244e1c51321d714be3200f2d9
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 20 Oct 2021 13:05:42 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 20 Oct 2021 13:05:42 -0300
Discussion: https://postgr.es/m/YW/MYdSRQZtPFBWR@paquier.xyz
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Fix build of MSVC with OpenSSL 3.0.0
commit : abb9ee92c5070d2b742aea9175c6a59ee403049f
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 20 Oct 2021 16:49:00 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 20 Oct 2021 16:49:00 +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/YW5XKYkq6k7OtrFq@paquier.xyz
Backpatch-through: 9.6
M src/tools/msvc/Solution.pm
Ensure correct lock level is used in ALTER ... RENAME
commit : 842fe6123c8acd09fac904ffb89bee883b36ac12
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 19 Oct 2021 19:08:45 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 19 Oct 2021 19:08:45 -0300
Commit 1b5d797cd4f7 intended to relax the lock level used to rename
indexes, but inadvertently allowed *any* relation to be renamed with a
lowered lock level, as long as the command is spelled ALTER INDEX.
That's undesirable for other relation types, so retry the operation with
the higher lock if the relation turns out not to be an index.
After this fix, ALTER INDEX <sometable> RENAME will require access
exclusive lock, which it didn't before.
Author: Nathan Bossart <bossartn@amazon.com>
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reported-by: Onder Kalaci <onderk@microsoft.com>
Discussion: https://postgr.es/m/PH0PR21MB1328189E2821CDEC646F8178D8AE9@PH0PR21MB1328.namprd21.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
Adapt src/test/ldap/t/001_auth.pl to work with openldap 2.5.
commit : 246a035f05c6accca34113de8e78f7afad90b329
author : Andres Freund <andres@anarazel.de>
date : Tue, 19 Oct 2021 10:14:49 -0700
committer: Andres Freund <andres@anarazel.de>
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/20211009233850.wvr6apcrw2ai6cnj@alap3.anarazel.de
Backpatch: 11-, where the tests were added.
M src/test/ldap/t/001_auth.pl
Fix assignment to array of domain over composite.
commit : 30e61a8cdc8624102ebdb1abbbb1e45457877c5c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Oct 2021 13:54:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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 : cf33fb7f4a199213a0a83209b81caa728f5c7750
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Oct 2021 11:35:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/17236-3210de9bcba1d7ca@postgresql.org
M src/backend/parser/parse_target.c
Fix bug in TOC file error message printing
commit : 687fe8a9d7a636d0792da39eb4dc1630741c7937
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Tue, 19 Oct 2021 12:59:54 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
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/A2B151F5-B32B-4F2C-BA4A-6870856D9BDE@yesql.se
Backpatch-through: 9.6
M src/bin/pg_dump/pg_backup_directory.c
Fix sscanf limits in pg_basebackup and pg_dump
commit : d3a4c1eb3d2188e8df58b4f2837cd17acc8629e1
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Tue, 19 Oct 2021 12:59:50 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
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/B14D3D7B-F98C-4E20-9459-C122C67647FB@yesql.se
Backpatch-through: 11 and 9.6
M src/bin/pg_basebackup/streamutil.c
M src/bin/pg_dump/pg_backup_directory.c
Block ALTER INDEX/TABLE index_name ALTER COLUMN colname SET (options)
commit : 85dc4292a7a1c0b9943cd285cbb3a90a5e368b3f
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 19 Oct 2021 11:04:04 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 19 Oct 2021 11:04:04 +0900
The grammar of this command run on indexes with column names has always
been authorized by the parser, and it has never been documented.
Since 911e702, it is possible to define opclass parameters as of CREATE
INDEX, which actually broke the old case of ALTER INDEX/TABLE where
relation-level parameters n_distinct and n_distinct_inherited could be
defined for an index (see 76a47c0 and its thread where this point has
been touched, still remained unused). Attempting to do that in v13~
would cause the index to become unusable, as there is a new dedicated
code path to load opclass parameters instead of the relation-level ones
previously available. Note that it is possible to fix things with a
manual catalog update to bring the relation back online.
This commit disables this command for now as the use of column names for
indexes does not make sense anyway, particularly when it comes to index
expressions where names are automatically computed. One way to properly
support this case properly in the future would be to use column numbers
when it comes to indexes, in the same way as ALTER INDEX .. ALTER COLUMN
.. SET STATISTICS.
Partitioned indexes were already blocked, but not indexes. Some tests
are added for both cases.
There was some code in ANALYZE to enforce n_distinct to be used for an
index expression if the parameter was defined, but just remove it for
now until/if there is support for this (note that index-level parameters
never had support in pg_dump either, previously), so this was just dead
code.
Reported-by: Matthijs van der Vleuten
Author: Nathan Bossart, Michael Paquier
Reviewed-by: Vik Fearing, Dilip Kumar
Discussion: https://postgr.es/m/17220-15d684c6c2171a83@postgresql.org
Backpatch-through: 13
M src/backend/commands/analyze.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/btree_index.out
M src/test/regress/sql/btree_index.sql
Invalidate partitions of table being attached/detached
commit : fe35528a5ed6934e0d60c19a02798236160d93f1
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 18 Oct 2021 19:08:25 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
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 <houzj.fnst@fujitsu.com>
Author: Amit Langote <amitlangote09@gmail.com>
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Nitin Jadhav <nitinjadhavpostgres@gmail.com>
Reviewed-by: Pavel Borisov <pashkin.elfe@gmail.com>
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 : 8f4fe8d7f8dc790545c84be4ed7af5d5d47d5ea7
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 18 Oct 2021 11:56:52 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 18 Oct 2021 11:56:52 +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 : 0b5f557b7e87527c0f14230326b7e279c9fd26c1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 16 Oct 2021 15:02:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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 : 6a262ba8c8648d7f2bfb419313d2d5d6daefeeb7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 16 Oct 2021 12:23:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/1018205.1634346327@sss.pgh.pa.us
M src/bin/pg_dump/pg_dump.c
Check criticalSharedRelcachesBuilt in GetSharedSecurityLabel().
commit : 20f785732fdd8872d9942761e2fbc1677adec9b7
author : Jeff Davis <jdavis@postgresql.org>
date : Thu, 14 Oct 2021 12:24:47 -0700
committer: Jeff Davis <jdavis@postgresql.org>
date : Thu, 14 Oct 2021 12:24:47 -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/ecb7af0b26e3be1d96d291c8453a86f1f82d9061.camel@j-davis.com
Backpatch-through: 9.6
M src/backend/commands/seclabel.c
Fix planner error with pulling up subquery expressions into function RTEs.
commit : fdd6a4d8d90aee36d2d81f0ab29399021228183a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Oct 2021 12:43:43 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Oct 2021 12:43:43 -0400
If a function-in-FROM laterally references the output of some sub-SELECT
earlier in the FROM clause, and we are able to flatten that sub-SELECT
into the outer query, the expression(s) copied into the function RTE
missed being processed by eval_const_expressions. This'd lead to trouble
and probable crashes at execution if such expressions contained
named-argument function call syntax or functions with defaulted arguments.
The bug is masked if the query contains any explicit JOIN syntax, which
may help explain why we'd not noticed.
Per bug #17227 from Bernd Dorn. This is an oversight in commit 7266d0997,
so back-patch to v13 where that came in.
Discussion: https://postgr.es/m/17227-5a28ed1512189fa4@postgresql.org
M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/rangefuncs.out
M src/test/regress/sql/rangefuncs.sql
Change recently added test code for stability
commit : 2cdf97fd1ec86301c70ccffb2414a6047c9f8dd1
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 13 Oct 2021 18:49:27 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
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/20211013180338.5guyqzpkcisqugrl@alap3.anarazel.de
M src/test/recovery/t/026_overwrite_contrecord.pl
postgres_fdw: Move comments about elog level in (sub)abort cleanup.
commit : cdab0a80d28501692584e798abbbfcfe9b5a6b48
author : Etsuro Fujita <efujita@postgresql.org>
date : Wed, 13 Oct 2021 19:00:03 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Wed, 13 Oct 2021 19:00:03 +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 tests of pg_upgrade across different major versions
commit : 2a8dee6a67ccde6074f463786d9152dbb87c7eb9
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 13 Oct 2021 09:22:00 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 13 Oct 2021 09:22:00 +0900
This fixes a set of issues that cause different breakages or annoyances
when using pg_upgrade's test.sh to do upgrades across different major
versions:
- test.sh is completely broken when using v14 as new version because of
the removal of testtablespace/ as Makefile rule. Older versions of
pg_regress don't support --make-tablespacedir, blocking the creation of
the tablespace. In order to fix that, it is simple enough to create
those directories in the script itself, but only do that when an old
version is involved. This fix is needed on HEAD and REL_14_STABLE.
- The script would fail when using PG <= v11 as old version because of
WITH OIDS relations not supported in v12. In order to fix this, this
steals a method from the buildfarm that uses a DO block to change all
the relations marked as WITH OIDS, allowing pg_upgrade to pass. This is
more portable than using ALTER TABLE queries on the relations causing
issues. This is fixed down to v12, and authored originally by Andrew
Dunstan.
- Not using --extra-float-digits=0 with v11 as old version causes
a lot of diffs in the dumps, making the whole unreadable. This gets
only done when using v11 as old version. This is fixed down to v12.
The buildfarm code uses that already.
Note that the addition of --wal-segsize and --allow-group-access breaks
the script when using v10 or older at initdb time as these got added in
11. 10 would be EOL'd next year and nobody has complained about those
problems yet, so nothing is done about that. This means that this
commit fixes upgrade tests using test.sh with v11 as minimum older
version, up to HEAD, and that it is enough to apply this change down to
12. The old and new dumps still generate diffs, still require manual
checks, and more could be done to reduce the noise, but this allows the
tests to run with a rather minimal amount of them.
I have tested this commit and test.sh with v11 as minimum across all the
branches where this is applied. Note that this commit has no impact on
the normal pg_upgrade test run with a simple "make check".
Author: Justin Pryzby, Andrew Dunstan, Michael Paquier
Discussion: https://postgr.es/m/20201206180248.GI24052@telsasoft.com
Backpatch-through: 12
M src/bin/pg_upgrade/test.sh
Add more $Test::Builder::Level in the TAP tests
commit : bab0ff2e44b781ec1b1180c5e96bdb95c385c80b
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 12 Oct 2021 11:16:25 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 12 Oct 2021 11:16:25 +0900
Incrementing the level of the call stack reported is useful for
debugging purposes as it allows to control which part of the test is
exactly failing, especially if a test is structured with subroutines
that call routines from Test::More.
This adds more incrementations of $Test::Builder::Level where debugging
gets improved (for example it does not make sense for some paths like
pg_rewind where long subroutines are used).
A note is added to src/test/perl/README about that, based on a
suggestion from Andrew Dunstan and a wording coming from both of us.
Usage of Test::Builder::Level has spread in 12, so a backpatch down to
this version is done.
Reviewed-by: Andrew Dunstan, Peter Eisentraut, Daniel Gustafsson
Discussion: https://postgr.es/m/YV1CCFwgM1RV1LeS@paquier.xyz
Backpatch-through: 12
M src/bin/pg_archivecleanup/t/010_pg_archivecleanup.pl
M src/bin/pg_verifybackup/t/005_bad_manifest.pl
M src/bin/psql/t/010_tab_completion.pl
M src/test/kerberos/t/001_auth.pl
M src/test/perl/README
M src/test/recovery/t/001_stream_rep.pl
M src/test/recovery/t/003_recovery_targets.pl
M src/test/recovery/t/007_sync_rep.pl
M src/test/recovery/t/009_twophase.pl
M src/test/recovery/t/018_wal_optimize.pl
Add missing word to comment in joinrels.c.
commit : 08f37e2592920a6df9584821614aa8deb93ed39f
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 7 Oct 2021 17:45:03 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 7 Oct 2021 17:45:03 +0900
Author: Amit Langote
Backpatch-through: 13
Discussion: https://postgr.es/m/CA%2BHiwqGQNbtamQ_9DU3osR1XiWR4wxWFZurPmN6zgbdSZDeWmw%40mail.gmail.com
M src/backend/optimizer/path/joinrels.c
Fix null-pointer crash in postgres_fdw's conversion_error_callback.
commit : aee83f39a86bb66baa66d65e87ca8415ac26800b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 6 Oct 2021 15:50:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/08916396-55E4-4D68-AB3A-BD6066F9E5C0@yandex-team.ru
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 : 9ab94ccb15af288f9ff295b4f04b28d86115b803
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 6 Oct 2021 13:20:23 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 6 Oct 2021 13:20:23 +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
Fix warning in TAP test of pg_verifybackup
commit : d6d68e223379985661df45c728c32c3b6d462629
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 6 Oct 2021 13:28:35 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 6 Oct 2021 13:28:35 +0900
Oversight in a3fcbcd.
Reported-by: Thomas Munro
Discussion: https://postgr.es/m/CA+hUKGKnajZEwe91OTjro9kQLCMGGFHh2vvFn8tgHgbyn4bF9w@mail.gmail.com
Backpatch-through: 13
M src/bin/pg_verifybackup/t/007_wal.pl
Doc: improve description of UNION/INTERSECT/EXCEPT syntax.
commit : 9024a35c11d7e8c42c2489ae2f912e4d0572f1df
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 Oct 2021 10:24:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 5 Oct 2021 10:24:14 -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/163338891727.12510.3939775743980651160@wrigleys.postgresql.org
M doc/src/sgml/queries.sgml
doc: remove URL for ICU explorer/locexp
commit : 0a6549316ee852ebea843671b755dc6d54b0e85b
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 4 Oct 2021 17:10:59 -0400
committer: Bruce Momjian <bruce@momjian.us>
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 : 5ba397f7404e911c7822e85441d42673080c5b98
author : Andres Freund <andres@anarazel.de>
date : Mon, 4 Oct 2021 13:28:06 -0700
committer: Andres Freund <andres@anarazel.de>
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 <andrew@dunslane.net>
Author: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/20211003173038.64mmhgxctfqn7wl6@alap3.anarazel.de
Backpatch: 9.6-, like 3c5b0685b921
M src/test/perl/TestLib.pm
Update our mapping of Windows time zone names some more.
commit : c53ff69e1fd24ae4905fe50ce8d3ca3a08d6a3c2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Oct 2021 14:52:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/3266414.1633045628@sss.pgh.pa.us
M src/bin/initdb/findtimezone.c
Fix snapshot builds during promotion of hot standby node with 2PC
commit : 194e535a07b3c36738b67f59aaa1291276929e9b
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 4 Oct 2021 14:05:52 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 4 Oct 2021 14:05:52 +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/20210422203603.fdnh3fu2mmfp2iov@alap3.anarazel.de
Backpatch-through: 9.6
M src/backend/access/transam/xlog.c
Update our mapping of Windows time zone names using CLDR info.
commit : 9c76689de442fc5849e383cc370d0769f8196bf6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 2 Oct 2021 16:05:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/3266414.1633045628@sss.pgh.pa.us
M src/bin/initdb/findtimezone.c
Re-alphabetize the win32_tzmap[] array.
commit : 7ba8eb81f6b79e7c1aaa3001137f38a61de80aba
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 2 Oct 2021 16:05:10 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/3266414.1633045628@sss.pgh.pa.us
M src/bin/initdb/findtimezone.c
Error out if SKIP LOCKED and WITH TIES are both specified
commit : 170206e458bce1d4be34bb805f884b2735430519
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 1 Oct 2021 18:29:18 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 1 Oct 2021 18:29:18 -0300
Both bugs #16676[1] and #17141[2] illustrate that the combination of
SKIP LOCKED and FETCH FIRST WITH TIES break expectations when it comes
to rows returned to other sessions accessing the same row. Since this
situation is detectable from the syntax and hard to fix otherwise,
forbid for now, with the potential to fix in the future.
[1] https://postgr.es/m/16676-fd62c3c835880da6@postgresql.org
[2] https://postgr.es/m/17141-913d78b9675aac8e@postgresql.org
Backpatch-through: 13, where WITH TIES was introduced
Author: David Christensen <david.christensen@crunchydata.com>
Discussion: https://postgr.es/m/CAOxo6XLPccCKru3xPMaYDpa+AXyPeWFs+SskrrL+HKwDjJnLhg@mail.gmail.com
M doc/src/sgml/ref/select.sgml
M src/backend/commands/matview.c
M src/backend/parser/gram.y
M src/test/regress/expected/limit.out
M src/test/regress/sql/limit.sql
Avoid believing incomplete MCV-only stats in get_variable_range().
commit : 7adbe186f7fd7e036d2cab7d8ed8ee99354ec219
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 1 Oct 2021 14:59:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/17207-5265aefa79e333b4@postgresql.org
M src/backend/utils/adt/selfuncs.c
Fix Portal snapshot tracking to handle subtransactions properly.
commit : 04ef2021e3ca7207b87ffce437b0b4db73a7f6b2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 1 Oct 2021 11:10:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/ff82b8c5-77f4-3fe7-6028-fcf3303e82dd@amazon.com
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 : 649e561f65c579630e5c31ee65308eefdd21ec93
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 30 Sep 2021 16:23:10 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/20210930183641.7lh4jhvpipvromca@alap3.anarazel.de
M src/test/subscription/t/002_types.pl
Fix WAL replay in presence of an incomplete record
commit : 1d97d3d0867faf967a3ab977b6a0b675b6a451da
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 29 Sep 2021 11:21:51 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
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 <alvherre@alvh.no-ip.org>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Reviewed-by: Nathan Bossart <bossartn@amazon.com>
Discussion: https://postgr.es/m/202108232252.dh7uxf6oxwcy@alvherre.pgsql
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
pgbench: Fix handling of socket errors during benchmark.
commit : 8cf4f7118596a2a3f5b51c04f73f1a06b4e363da
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 29 Sep 2021 21:01:10 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 29 Sep 2021 21:01:10 +0900
Previously socket errors such as invalid socket or socket wait method failures
during benchmark caused pgbench to exit with status 0. Instead, errors during
the run should result in exit status 2.
Back-patch to v12 where pgbench started reporting exit status.
Original complaint and patch by Hayato Kuroda.
Author: Yugo Nagata, Fabien COELHO
Reviewed-by: Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/TYCPR01MB5870057375ACA8A73099C649F5349@TYCPR01MB5870.jpnprd01.prod.outlook.com
M src/bin/pgbench/pgbench.c
pgbench: Correct log level of message output when socket wait method fails.
commit : 3cc85d7d5353945bf5bdb26bb7771f40aeacaf0b
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 29 Sep 2021 20:35:00 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 29 Sep 2021 20:35:00 +0900
The failure of socket wait method like "select()" doesn't terminate pgbench.
So the log level of error message when that failure happens should be ERROR.
But previously FATAL was used in that case.
Back-patch to v13 where pgbench started using common logging API.
Author: Yugo Nagata, Fabien COELHO
Reviewed-by: Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/20210617005934.8bd37bf72efd5f1b38e6f482@sraoss.co.jp
M src/bin/pgbench/pgbench.c
Fix instability in contrib/bloom TAP tests.
commit : cf26a8d8a75ff4ae78bf0818ebb2bf6cf90db69c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 28 Sep 2021 17:34:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 28 Sep 2021 17:34:31 -0400
It turns out that the instability complained of in commit d3c09b9b1
has an embarrassingly simple explanation. The test script waits for
the standby to flush incoming WAL to disk, but it should wait for
the WAL to be replayed, since we are testing for the effects of that
to be visible.
While at it, use wait_for_catchup instead of reinventing that logic,
and adjust $Test::Builder::Level to improve future error reports.
Back-patch to v12 where the necessary infrastructure came in
(cf. aforesaid commit). Also back-patch 7d1aa6bf1 so that the
test will actually get run.
Discussion: https://postgr.es/m/2854602.1632852664@sss.pgh.pa.us
M contrib/bloom/Makefile
M contrib/bloom/t/001_wal.pl
Fix typos in docs
commit : 78515b89f2985ef78136732cd239609c569797b3
author : Michael Paquier <michael@paquier.xyz>
date : Sun, 26 Sep 2021 19:18:27 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sun, 26 Sep 2021 19:18:27 +0900
Author: Justin Pryzby
Discussion: https://postgr.es/m/20210924215827.GS831@telsasoft.com
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 : 739b872f6c98459a460b522e726f369b6fc67ca3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Sep 2021 10:53:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/2438715.1632510693@sss.pgh.pa.us
M doc/src/sgml/postgres-fdw.sgml
Add alternative output for OpenSSL 3 without legacy loaded
commit : 8e7199453bf9fe142f3f4a5e17010320c24867e7
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Sat, 25 Sep 2021 11:27:28 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
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/FEF81714-D479-4512-839B-C769D2605F8A@yesql.se
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_1.out
A contrib/pgcrypto/expected/pgp-pubkey-decrypt_1.out
M doc/src/sgml/pgcrypto.sgml
Disable OpenSSL EVP digest padding in pgcrypto
commit : 135d8687adf12a0d4cd7c94d1095ed5a7a08f7ed
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Sat, 25 Sep 2021 11:27:20 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
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/FEF81714-D479-4512-839B-C769D2605F8A@yesql.se
Backpatch-through: 9.6
M contrib/pgcrypto/openssl.c
pgcrypto: Check for error return of px_cipher_decrypt()
commit : a69e1506f618d4577bf7fdbfea51924a44c6e7de
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Sat, 25 Sep 2021 11:25:48 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
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 <peter@eisentraut.org>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://www.postgresql.org/message-id/9e9c431c-0adc-7a6d-9b1a-915de1ba3fe7@enterprisedb.com
Backpatch-through: 9.6
M contrib/pgcrypto/px.c
doc: Improve description of index vacuuming with GUCs
commit : 52f8575a9e75e67ed7a7ae1585be28a85e85ae0e
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 25 Sep 2021 15:12:00 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 25 Sep 2021 15:12:00 +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/161545365522.10134.12195402324485546870@wrigleys.postgresql.org
Backpatch-through: 9.6
M doc/src/sgml/monitoring.sgml
doc: Add missing markup in CREATE EVENT TRIGGER page
commit : ca925fe3c4d3727679f00deedde83765b89c32bb
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 25 Sep 2021 14:48:13 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 25 Sep 2021 14:48:13 +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
Split macros from visibilitymap.h into a separate header
commit : fd22aec631af9f2b967af20e23206840c6594c72
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Thu, 23 Sep 2021 19:59:03 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Thu, 23 Sep 2021 19:59:03 +0300
That allows to include just visibilitymapdefs.h from file.c, and in turn,
remove include of postgres.h from relcache.h.
Reported-by: Andres Freund
Discussion: https://postgr.es/m/20210913232614.czafiubr435l6egi%40alap3.anarazel.de
Author: Alexander Korotkov
Reviewed-by: Andres Freund, Tom Lane, Alvaro Herrera
Backpatch-through: 13
M src/bin/pg_upgrade/file.c
M src/include/access/visibilitymap.h
A src/include/access/visibilitymapdefs.h
M src/include/utils/relcache.h
Release memory allocated by dependency_degree
commit : c0386f403a832f50d61fc7bb9bb265f7700273f3
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Tue, 21 Sep 2021 01:13:11 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
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 : b564eb0181e678ee58c1be2e9f3c53eeb68f8c4b
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Tue, 21 Sep 2021 01:14:11 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
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
Invalidate all partitions for a partitioned table in publication.
commit : f09a81f1c08fa5c2fed12bed88d53a11a72ff993
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 22 Sep 2021 08:24:20 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 22 Sep 2021 08:24:20 +0530
Updates/Deletes on a partition were allowed even without replica identity
after the parent table was added to a publication. This would later lead
to an error on subscribers. The reason was that we were not invalidating
the partition's relcache and the publication information for partitions
was not getting rebuilt. Similarly, we were not invalidating the
partitions' relcache after dropping a partitioned table from a publication
which will prohibit Updates/Deletes on its partition without replica
identity even without any publication.
Reported-by: Haiying Tang
Author: Hou Zhijie and Vignesh C
Reviewed-by: Vignesh C and Amit Kapila
Backpatch-through: 13
Discussion: https://postgr.es/m/OS0PR01MB6113D77F583C922F1CEAA1C3FBD29@OS0PR01MB6113.jpnprd01.prod.outlook.com
M src/backend/catalog/pg_publication.c
M src/backend/commands/publicationcmds.c
M src/include/catalog/pg_publication.h
M src/include/commands/publicationcmds.h
M src/test/regress/expected/publication.out
M src/test/regress/sql/publication.sql
Fix places in TestLib.pm in need of adaptation to the output of Msys perl
commit : 583e15af9976f8905e2b27f985d619e758270e16
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 22 Sep 2021 08:43:10 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 22 Sep 2021 08:43:10 +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/1252480.1631829409@sss.pgh.pa.us
Backpatch-through: 9.6
M src/test/perl/TestLib.pm
Fix misevaluation of STABLE parameters in CALL within plpgsql.
commit : 5f0a073cbbf8bdc276e570ffa006e762fc815e44
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 Sep 2021 19:06:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/17199-1ab2561f0d94af92@postgresql.org
M src/backend/commands/functioncmds.c
M src/pl/plpgsql/src/expected/plpgsql_transaction.out
M src/pl/plpgsql/src/sql/plpgsql_transaction.sql
Remove overzealous index deletion assertion.
commit : a1708ab652eaef3e9405d5119721a9a4ecb6fcbd
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 20 Sep 2021 14:26:22 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 20 Sep 2021 14:26:22 -0700
A broken HOT chain is not an unexpected condition, even when the offset
number points past the end of the page's line pointer array.
heap_prune_chain() does not (and never has) treated this condition as
unexpected, so derivative code in heap_index_delete_tuples() shouldn't
do so either.
Oversight in commit 4228817449.
The assertion can probably only fail on Postgres 14 and master. Earlier
releases don't have commit 3c3b8a4b, which taught VACUUM to truncate the
line pointer array of heap pages. Backpatch all the same, just to be
consistent.
Author: Peter Geoghegan <pg@bowt.ie>
Reported-By: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/17197-9438f31f46705182@postgresql.org
Backpatch: 12-, just like commit 4228817449.
M src/backend/access/heap/heapam.c
Don't elide casting to typmod -1.
commit : dede1439978120d2196e0d3963bb809a8b262e5b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 Sep 2021 11:48:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/1488389.1631984807@sss.pgh.pa.us
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 : 89b5676b65b5f27fcab4f972390197983d7a9bfe
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 Sep 2021 11:36:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 Sep 2021 11:36:53 -0400
"PGcon" should be "PGconn". Noted by D. Frey.
Discussion: https://postgr.es/m/163191739352.4680.16994248583642672629@wrigleys.postgresql.org
M doc/src/sgml/lobj.sgml
Fix pull_varnos to cope with translated PlaceHolderVars.
commit : e0b0d1eab48c85f961a39c263d2074ad11931920
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Sep 2021 15:41:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Sep 2021 15:41:16 -0400
Commit 55dc86eca changed pull_varnos to use (if possible) the associated
ph_eval_at for a PlaceHolderVar. I missed a fine point though: we might
be looking at a PHV in the quals or tlist of a child appendrel, in which
case we need to compute a ph_eval_at value that's been translated in the
same way that the PHV itself has been (cf. adjust_appendrel_attrs).
Fortunately, enough info is available in the PlaceHolderInfo to make
such translation possible without additional outside data, so we don't
need another round of uglification of planner APIs. This is a little
bit complicated, but since it's a hard-to-hit corner case, I'm not much
worried about adding cycles here.
Per report from Jaime Casanova. Back-patch to v12, like the previous
commit.
Discussion: https://postgr.es/m/20210915230959.GB17635@ahch-to
M src/backend/optimizer/util/var.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix variable shadowing in procarray.c.
commit : 8767a86fa2b1d24537cca318a26fc68d7e457911
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 16 Sep 2021 13:07:29 +0900
committer: Fujii Masao <fujii@postgresql.org>
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
Disallow LISTEN in background workers.
commit : e06cc024bd3372cb4280246e114d7508e3e2c20a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 15 Sep 2021 12:31:56 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 15 Sep 2021 12:31:56 -0400
It's possible to execute user-defined SQL in some background processes;
for example, logical replication workers can fire triggers. This opens
the possibility that someone would try to execute LISTEN in such a
context. But since only regular backends ever call
ProcessNotifyInterrupt, no messages would actually be received, and
thus the registered listener would simply prevent the message queue
from being cleaned. Eventually NOTIFY would stop working, which is bad.
Perhaps someday somebody will invent infrastructure to make listening
in a background worker actually useful. In the meantime, forbid it.
Back-patch to v13, which is where we introduced the MyBackendType
variable. It'd be a lot harder to implement the check without that,
and it doesn't seem worth the trouble.
Discussion: https://postgr.es/m/153243441449.1404.2274116228506175596@wrigleys.postgresql.org
M src/backend/tcop/utility.c
Send NOTIFY signals during CommitTransaction.
commit : 63f28776cb9fbefd99c5e2134f02c80057b8b717
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Sep 2021 17:18:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Sep 2021 17:18:25 -0400
Formerly, we sent signals for outgoing NOTIFY messages within
ProcessCompletedNotifies, which was also responsible for sending
relevant ones of those messages to our connected client. It therefore
had to run during the main-loop processing that occurs just before
going idle. This arrangement had two big disadvantages:
* Now that procedures allow intra-command COMMITs, it would be
useful to send NOTIFYs to other sessions immediately at COMMIT
(though, for reasons of wire-protocol stability, we still shouldn't
forward them to our client until end of command).
* Background processes such as replication workers would not send
NOTIFYs at all, since they never execute the client communication
loop. We've had requests to allow triggers running in replication
workers to send NOTIFYs, so that's a problem.
To fix these things, move transmission of outgoing NOTIFY signals
into AtCommit_Notify, where it will happen during CommitTransaction.
Also move the possible call of asyncQueueAdvanceTail there, to
ensure we don't bloat the async SLRU if a background worker sends
many NOTIFYs with no one listening.
We can also drop the call of asyncQueueReadAllNotifications,
allowing ProcessCompletedNotifies to go away entirely. That's
because commit 790026972 added a call of ProcessNotifyInterrupt
adjacent to PostgresMain's call of ProcessCompletedNotifies,
and that does its own call of asyncQueueReadAllNotifications,
meaning that we were uselessly doing two such calls (inside two
separate transactions) whenever inbound notify signals coincided
with an outbound notify. We need only set notifyInterruptPending
to ensure that ProcessNotifyInterrupt runs, and we're done.
The existing documentation suggests that custom background workers
should call ProcessCompletedNotifies if they want to send NOTIFY
messages. To avoid an ABI break in the back branches, reduce it
to an empty routine rather than removing it entirely. Removal
will occur in v15.
Although the problems mentioned above have existed for awhile,
I don't feel comfortable back-patching this any further than v13.
There was quite a bit of churn in adjacent code between 12 and 13.
At minimum we'd have to also backpatch 51004c717, and a good deal
of other adjustment would also be needed, so the benefit-to-risk
ratio doesn't look attractive.
Per bug #15293 from Michael Powers (and similar gripes from others).
Artur Zakirov and Tom Lane
Discussion: https://postgr.es/m/153243441449.1404.2274116228506175596@wrigleys.postgresql.org
M doc/src/sgml/bgworker.sgml
M src/backend/access/transam/xact.c
M src/backend/commands/async.c
M src/backend/tcop/postgres.c
M src/include/commands/async.h
jit: Do not try to shut down LLVM state in case of LLVM triggered errors.
commit : c49e6f9d974966c7b0fc3eac43a6be922cf6eaee
author : Andres Freund <andres@anarazel.de>
date : Mon, 13 Sep 2021 18:07:19 -0700
committer: Andres Freund <andres@anarazel.de>
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 <Jelte.Fennema@microsoft.com>
Author: Andres Freund <andres@anarazel.de>
Author: Justin Pryzby <pryzby@telsasoft.com>
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 : 745abdd951ab31f3276adbbbf67bbc3b7dac0923
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Sep 2021 12:42:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/868ae948-e3ca-c7ec-95a6-83cfc08ef750@gmail.com
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
Doc: Remove type information for import_generated in postgres-fdw.sgml.
commit : b7b8e2c4a5cb9d520c907f12fe9ebd3837dffc49
author : Etsuro Fujita <efujita@postgresql.org>
date : Mon, 13 Sep 2021 17:30:02 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Mon, 13 Sep 2021 17:30:02 +0900
The type information for FDW options is only added to HEAD; remove this
from back branches. Oversight in commit aa769f80e.
Apply the patch to v12, v13, and v14.
Discussion: https://postgr.es/m/CAPmGK14z92twaKwRoccHbbh5Va5vbRDZcTYYTx50+0JTQ8xx_g@mail.gmail.com
M doc/src/sgml/postgres-fdw.sgml
Fix reorder buffer memory accounting for toast changes.
commit : 58cf794ca68d90ea11888f200e0b74d01d0c7093
author : Amit Kapila <akapila@postgresql.org>
date : Mon, 13 Sep 2021 10:46:58 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Mon, 13 Sep 2021 10:46:58 +0530
While processing toast changes in logical decoding, we rejigger the
tuple change to point to in-memory toast tuples instead to on-disk toast
tuples. And, to make sure the memory accounting is correct, we were
subtracting the old change size and then after re-computing the new tuple,
re-adding its size at the end. Now, if there is any error before we add
the new size, we will release the changes and that will update the
accounting info (subtracting the size from the counters). And we were
underflowing there which leads to an assertion failure in assert enabled
builds and wrong memory accounting in reorder buffer otherwise.
Author: Bertrand Drouvot
Reviewed-by: Amit Kapila
Backpatch-through: 13, where memory accounting was introduced
Discussion: https://postgr.es/m/92b0ee65-b8bd-e42d-c082-4f3f4bf12d34@amazon.com
M src/backend/replication/logical/reorderbuffer.c
Fix error handling with threads on OOM in ECPG connection logic
commit : b589d212fdd7e449ec0d5da8e46c0d86eee943d6
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 13 Sep 2021 13:24:20 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 13 Sep 2021 13:24:20 +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/17186-b4cfd8f0eb4d1dee@postgresql.org
Backpatch-through: 9.6
M src/interfaces/ecpg/ecpglib/connect.c
Make pg_regexec() robust against out-of-range search_start.
commit : 7e420072ea4a9f873d3378c8b35f2d939d925022
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 11 Sep 2021 15:19:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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 : fa5d0415f10fac3c2aa4c301840fde1780b91b79
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Sep 2021 13:18:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/3712911.1631207435@sss.pgh.pa.us
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 : d8d93bc8baa934fb23c90271d200e061386b546d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 Sep 2021 13:36:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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 : 04118de78fe9a8a7160775b47e89bf21a5efb620
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 Sep 2021 11:45:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/YTn1iTkUYBZfcODk@msg.credativ.de
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/smgr/md.c
Fix issue with WAL archiving in standby.
commit : dd9b3fced83edb51a3e2f44d3d4476a45d0f5a24
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 9 Sep 2021 23:58:05 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 9 Sep 2021 23:58:05 +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/20200630.165503.1465894182551545886.horikyota.ntt@gmail.com
M src/backend/replication/walreceiver.c
Avoid useless malloc/free traffic around getFormattedTypeName().
commit : da7d81dd0579a2579741bcfc816cf614c58d0aab
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Sep 2021 15:09:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Sep 2021 15:09:42 -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 : cbba6ba3a0628fdc47185f71d5f06ed7af95c147
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Sep 2021 12:05:43 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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 : ddfc7299d0a3a41f0c178a8157bd751430428e8a
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 8 Sep 2021 10:20:02 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 8 Sep 2021 10:20:02 +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
AIX: Fix missing libpq symbols by respecting SHLIB_EXPORTS.
commit : aae398a87cfafcb1d62fd1e464b2c4d2525a039a
author : Noah Misch <noah@leadboat.com>
date : Mon, 6 Sep 2021 11:27:59 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 6 Sep 2021 11:27:59 -0700
We make each AIX shared library export all globals found in .o files
that originate in the library. That doesn't include symbols acquired by
-lpgcommon_shlib. That is good on average, but it became a problem for
libpq when commit e6afa8918c461c1dd80c5063a950518fa4e950cd moved five
official libpq API symbols into src/common. Fix this by implementing
the SHLIB_EXPORTS mechanism for AIX, so affected libraries export the
same symbols that they export on Linux. This reintroduces symbols
pg_encoding_to_char, pg_utf_mblen, pg_char_to_encoding,
pg_valid_server_encoding, and pg_valid_server_encoding_id. Back-patch
to v13, where the aforementioned commit first appeared. While a minor
release is usually the wrong time to add or remove symbol exports in
libpq or libecpg, we should expect users to want each documented symbol.
Tony Reix
Discussion: https://postgr.es/m/PR3PR02MB6396742E2FC3E77D37A920BC86C79@PR3PR02MB6396.eurprd02.prod.outlook.com
M src/Makefile.shlib
M src/port/README
Fix bogus timetz_zone() results for DYNTZ abbreviations.
commit : d8a266c5e1bd50785d4619ecb3e686f86771685f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Sep 2021 11:29:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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
Fix pkg-config files for static linking
commit : 9f9ae019d194d012c74084cec3722ba2d67af8eb
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 6 Sep 2021 09:41:03 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 6 Sep 2021 09:41:03 +0200
Since ea53100d5 (PostgreSQL 12), the shipped pkg-config files have
been broken for statically linking libpq because libpgcommon and
libpgport are missing. This patch adds those two missing private
dependencies (in a non-hardcoded way).
Reported-by: Filip Gospodinov <f@gospodinov.ch>
Discussion: https://www.postgresql.org/message-id/flat/c7108bde-e051-11d5-a234-99beec01ce2a@gospodinov.ch
M src/Makefile.shlib
Further portability tweaks for float4/float8 hash functions.
commit : 2c0dd669c3c909484c24b40a797bd99b352c6f0b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 4 Sep 2021 16:29:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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 : 518621c40b23b4188478578d21de62d25582d9e3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sat, 4 Sep 2021 12:14:30 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
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/20210831042949.52eqp5xwbxgrfank@alap3.anarazel.de
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 : 742b30caee65a8d54388c1a249e93f27c65315f5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Sep 2021 21:04:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/567e199c6b97ee19deee600311515b86@krylov.eu
M src/bin/pg_ctl/pg_ctl.c
Disallow creating an ICU collation if the DB encoding won't support it.
commit : 132be60006b334df00093973465215cd8b892f37
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Sep 2021 16:38:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/17170-95845cf3f0a9c36d@postgresql.org
M src/backend/commands/collationcmds.c
Fix portability issue in tests from commit ce773f230.
commit : 9089f1543ef50414e1cecf89bc34eeb3ab1cb968
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 Sep 2021 10:01:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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 : be2beadaff1ad87792efa58273698898d84afd4e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 Sep 2021 17:24:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/17172-7505bea9e04e230f@postgresql.org
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 : e976cc4a79af63b3f1453a8e2d9eb9bcdeb91616
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 2 Sep 2021 11:36:01 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 2 Sep 2021 11:36:01 +0900
This makes the documentation more accurate grammatically.
Author: Elena Indrupskaya
Discussion: https://postgr.es/m/1c994b3d-951e-59bb-1ac2-7b9221c0e4cf@postgrespro.ru
Backpatch-through: 9.6
M doc/src/sgml/parallel.sgml
Fix the random test failure in 001_rep_changes.
commit : b51985d8a0e1a7487d17559cbeefc87892c4d916
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 1 Sep 2021 09:16:35 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 1 Sep 2021 09:16:35 +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/YRnhFxa9bo73wfpV@paquier.xyz
M src/test/subscription/t/001_rep_changes.pl
In pg_dump, avoid doing per-table queries for RLS policies.
commit : db11b4a3db5f6613c844c1b3a6c203bbceb05532
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 Aug 2021 15:04:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/20210826084430.GA26282@depesz.com
M src/bin/pg_dump/pg_dump.c
Cache the results of format_type() queries in pg_dump.
commit : 904ce45bfa8862d4ae04065c8033182ad812b009
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 Aug 2021 13:53:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/20210826084430.GA26282@depesz.com
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 : c8213aa949626deb19f098332eded3586624ff59
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Tue, 31 Aug 2021 19:21:29 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
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 : 1fe1a04af81de4c659ab2a85e578a6bbd4903035
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Tue, 31 Aug 2021 18:03:05 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
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 : 6197d7b5383e69383801a4e1c6eed7b7dbc086a3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 30 Aug 2021 16:29:12 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
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/202108191637.oqyzrdtnheir@alvherre.pgsql
M src/backend/access/heap/heapam_handler.c
Fix incorrect error code in StartupReplicationOrigin().
commit : 8ba3bad4c362ef71bf6a13ecf4ae5e26066a4876
author : Amit Kapila <akapila@postgresql.org>
date : Mon, 30 Aug 2021 09:26:49 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Mon, 30 Aug 2021 09:26:49 +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
psql \dP: reference regclass with "pg_catalog." prefix
commit : 9a33ed8fa10354bdb3f12d87ccd9f387bec338d1
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sat, 28 Aug 2021 11:45:47 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sat, 28 Aug 2021 11:45:47 -0400
Strictly speaking this isn't a bug, but since all references to catalog
objects are schema-qualified, we might as well be consistent. The
omission first appeared in commit 1c5d9270e339, so backpatch to 12.
Author: Justin Pryzby <pryzbyj@telsasoft.com>
Discussion: https://postgr.es/m/20210827193151.GN26465@telsasoft.com
M src/bin/psql/describe.c
Fix data loss in wal_level=minimal crash recovery of CREATE TABLESPACE.
commit : b18669f5e652f1d0c1dbf332fd7cd24a38c7ed31
author : Noah Misch <noah@leadboat.com>
date : Fri, 27 Aug 2021 23:33:23 -0700
committer: Noah Misch <noah@leadboat.com>
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
M src/test/recovery/t/018_wal_optimize.pl
Count SP-GiST index scans in pg_stat statistics.
commit : dbb239d518eef791ec6e8f2180e71078e7f89e38
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 27 Aug 2021 19:42:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/17163-b8c5cc88322a5e92@postgresql.org
M src/backend/access/spgist/spgscan.c
docs: clarify bgw_restart_time documentation
commit : 53597fd6c3cc2042cad9909b962459fa26c26e20
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Fri, 27 Aug 2021 22:50:19 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Fri, 27 Aug 2021 22:50:19 +0200
Author: Dave Cramer <davecramer@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CADK3HHLZmqAQZ2ByPDQQ9yhGqax36kksq6sDkV0yYzsxw6ipvQ@mail.gmail.com
M doc/src/sgml/bgworker.sgml
Fix broken snapshot handling in parallel workers.
commit : bc062cb938234d8e815d14fecd8d3b2abff3fe88
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 25 Aug 2021 08:32:04 -0400
committer: Robert Haas <rhaas@postgresql.org>
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/002f01d748ac$eaa781a0$bff684e0$@tju.edu.cn
M src/backend/access/transam/parallel.c
Fix toast rewrites in logical decoding.
commit : 794025eff0db181e463cb92d4b1aedd0879c88a6
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 25 Aug 2021 09:23:27 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 25 Aug 2021 09:23:27 +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/b5146fb1-ad9e-7d6e-f980-98ed68744a7c@amazon.com
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 : 7d9026cbfd340a4de6c96ff7c728e53c3791e1cc
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 25 Aug 2021 11:46:25 +0900
committer: Fujii Masao <fujii@postgresql.org>
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/20210819.170315.1413060634876301811.horikyota.ntt@gmail.com
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 : 81fa1bce2770ee9c9ffe92baa7c5abae70939c59
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 25 Aug 2021 11:43:56 +0900
committer: Fujii Masao <fujii@postgresql.org>
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/20210819.170315.1413060634876301811.horikyota.ntt@gmail.com
M src/backend/utils/adt/tsquery.c
Fix regexp misbehavior with capturing parens inside "{0}".
commit : 071146184a59de4ac20f5508903fdbc21f963b6c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 24 Aug 2021 16:37:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/A099E4A8-4377-4C64-A98C-3DEDDC075502@enterprisedb.com
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 : 9a327179c824712b35eda01a1edef33ad674b188
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 Aug 2021 17:41:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/151435.1629733387@sss.pgh.pa.us
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 : ad1231171f5d4319024a2f48c52d267bbee43503
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 23 Aug 2021 15:50:35 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
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 <bossartn@amazon.com>
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Reviewed-by: Ryo Matsumura <matsumura.ryo@fujitsu.com>
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
Discussion: https://postgr.es/m/CBDDFA01-6E40-46BB-9F98-9340F4379505@amazon.com
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 backup manifests to generate correct WAL-Ranges across timelines
commit : 29f94232517bb5c5f22d1deebecfe2160711150f
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 23 Aug 2021 11:09:57 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 23 Aug 2021 11:09:57 +0900
In a backup manifest, WAL-Ranges stores the range of WAL that is
required for the backup to be valid. pg_verifybackup would then
internally use pg_waldump for the checks based on this data.
When the timeline where the backup started was more than 1 with a
history file looked at for the manifest data generation, the calculation
of the WAL range for the first timeline to check was incorrect. The
previous logic used as start LSN the start position of the first
timeline, but it needs to use the start LSN of the backup. This would
cause failures with pg_verifybackup, or any tools making use of the
backup manifests.
This commit adds a test based on a logic using a self-promoted node,
making it rather cheap.
Author: Kyotaro Horiguchi
Discussion: https://postgr.es/m/20210818.143031.1867083699202617521.horikyota.ntt@gmail.com
Backpatch-through: 13
M src/backend/replication/backup_manifest.c
M src/bin/pg_verifybackup/t/007_wal.pl
Fix performance bug in regexp's citerdissect/creviterdissect.
commit : b30f7f399ea87f0621dfe900547cda401f8da762
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Aug 2021 14:19:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/1808998.1629412269@sss.pgh.pa.us
M src/backend/regex/regexec.c
Avoid trying to lock OLD/NEW in a rule with FOR UPDATE.
commit : 7fa367d96bb1ae25f422d6c2a78424f0f9227b5a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Aug 2021 12:12:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/17151-c03a3e6e4ec9aadb@postgresql.org
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 : ecd4dd9f1df00ef9e872a4d13bbbe3f3d8d3f966
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 18 Aug 2021 18:12:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/17152-c7f906cc1a88e61b@postgresql.org
M src/backend/parser/parse_agg.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql
Prevent ALTER TYPE/DOMAIN/OPERATOR from changing extension membership.
commit : 7b01246e1de94a436c64f1d396674b2dc44dab70
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Aug 2021 14:29:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Aug 2021 14:29:22 -0400
If recordDependencyOnCurrentExtension is invoked on a pre-existing,
free-standing object during an extension update script, that object
will become owned by the extension. In our current code this is
possible in three cases:
* Replacing a "shell" type or operator.
* CREATE OR REPLACE overwriting an existing object.
* ALTER TYPE SET, ALTER DOMAIN SET, and ALTER OPERATOR SET.
The first of these cases is intentional behavior, as noted by the
existing comments for GenerateTypeDependencies. It seems like
appropriate behavior for CREATE OR REPLACE too; at least, the obvious
alternatives are not better. However, the fact that it happens during
ALTER is an artifact of trying to share code (GenerateTypeDependencies
and makeOperatorDependencies) between the CREATE and ALTER cases.
Since an extension script would be unlikely to ALTER an object that
didn't already belong to the extension, this behavior is not very
troubling for the direct target object ... but ALTER TYPE SET will
recurse to dependent domains, and it is very uncool for those to
become owned by the extension if they were not already.
Let's fix this by redefining the ALTER cases to never change extension
membership, full stop. We could minimize the behavioral change by
only changing the behavior when ALTER TYPE SET is recursing to a
domain, but that would complicate the code and it does not seem like
a better definition.
Per bug #17144 from Alex Kozhemyakin. Back-patch to v13 where ALTER
TYPE SET was added. (The other cases are older, but since they only
affect the directly-named object, there's not enough of a problem to
justify changing the behavior further back.)
Discussion: https://postgr.es/m/17144-e67d7a8f049de9af@postgresql.org
M src/backend/catalog/pg_depend.c
M src/backend/catalog/pg_operator.c
M src/backend/catalog/pg_type.c
M src/backend/commands/operatorcmds.c
M src/backend/commands/typecmds.c
M src/include/catalog/pg_operator.h
M src/include/catalog/pg_type.h
Set type identifier on BIO
commit : e15f32f0edf6e22669e309bd58fbd72b8aa43fd3
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Tue, 17 Aug 2021 14:27:37 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
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 : c9e75c21d8c96c9385fdb3693d35628a2a625630
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 17 Aug 2021 10:00:06 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
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 : 7f0873f328efe057090071805be3f1ade48ecc8a
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 16 Aug 2021 12:11:53 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 16 Aug 2021 12:11:53 +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 : 48695decc27159275a10cf9e1f31bae51f311305
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 13 Aug 2021 13:58:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/dea97b6d-f55f-1f6d-9109-504aa7dfa421@gentoo.org
M src/include/storage/s_lock.h
Fix incorrect hash table resizing code in simplehash.h
commit : 4873da79da4bbd54f580ca6e5b2f5c46ae6e4bc6
author : David Rowley <drowley@postgresql.org>
date : Fri, 13 Aug 2021 16:42:35 +1200
committer: David Rowley <drowley@postgresql.org>
date : Fri, 13 Aug 2021 16:42:35 +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/b1f7f32737c3438136f64b26f4852b96@postgrespro.ru
Backpatch-through: 10, where simplehash.h was added
M src/include/lib/simplehash.h
Make EXEC_BACKEND more convenient on macOS.
commit : 2c6275423535f86d0d4bc2a4651852d05b3d60c1
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 13 Aug 2021 10:38:22 +1200
committer: Thomas Munro <tmunro@postgresql.org>
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 <tgl@sss.pgh.pa.us>
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 : 7ba487cf90071717c9c352dc074a9140860eba55
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 Aug 2021 18:10:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
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/20210810001649.htnltbh7c63re42p@jasonk.me
M contrib/btree_gin/btree_gin.c
M contrib/btree_gin/expected/char.out
Stamp 13.4.
commit : e849f3f1f884ad140b60a24354c6371cbd2efbb6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Aug 2021 16:49:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Aug 2021 16:49:05 -0400
M configure
M configure.in
Last-minute updates for release notes.
commit : 0145ec9be92b2146e7b94f286cb3dab9eb77ef70
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Aug 2021 14:41:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Aug 2021 14:41:00 -0400
Security: CVE-2021-3677
M doc/src/sgml/release-13.sgml
Translation updates
commit : dc10035ecc8256d4489eb33ba3026efe9bfba082
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 9 Aug 2021 11:56:40 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 9 Aug 2021 11:56:40 +0200
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 9bb123c161ac8f773572e112ced524b99e81c1d9
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/bin/pg_checksums/po/es.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_resetwal/po/de.po
M src/bin/pg_rewind/po/es.po
M src/bin/pg_upgrade/po/de.po
M src/bin/pg_upgrade/po/es.po
M src/bin/pg_verifybackup/po/es.po
M src/bin/psql/po/de.po
M src/bin/psql/po/es.po
M src/bin/psql/po/fr.po
M src/bin/scripts/po/de.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/fr.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/libpq/po/es.po
Doc: Fix misleading statement about VACUUM memory limits
commit : bb08e78972b1d0ec9f11f3d0b18903ec7a216855
author : David Rowley <drowley@postgresql.org>
date : Mon, 9 Aug 2021 16:47:25 +1200
committer: David Rowley <drowley@postgresql.org>
date : Mon, 9 Aug 2021 16:47:25 +1200
In ec34040af I added a mention that there was no point in setting
maintenance_work_limit to anything higher than 1GB for vacuum, but that
was incorrect as ginInsertCleanup() also looks at what
maintenance_work_mem is set to during VACUUM and that's not limited to
1GB.
Here I attempt to make it more clear that the limitation is only around
the number of dead tuple identifiers that we can collect during VACUUM.
I've also added a note to autovacuum_work_mem to mention this limitation.
I didn't do that in ec34040af as I'd had some wrong-headed ideas about
just limiting the maximum value for that GUC to 1GB.
Author: David Rowley
Discussion: https://postgr.es/m/CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@mail.gmail.com
Backpatch-through: 9.6, same as ec34040af
M doc/src/sgml/config.sgml
doc: mention pg_upgrade extension script
commit : ff18b8d1b169b2bf47daab7d92c5376bc19c0748
author : Bruce Momjian <bruce@momjian.us>
date : Sun, 8 Aug 2021 21:05:46 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sun, 8 Aug 2021 21:05:46 -0400
Since commit e462856a7a, pg_upgrade automatically creates a script to
update extensions, so mention that instead of ALTER EXTENSION.
Backpatch-through: 9.6
M doc/src/sgml/ref/pgupgrade.sgml
Doc: remove bogus <indexterm> items.
commit : 410c5a08df4381917cd6da7d94609644e10ca322
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Aug 2021 15:35:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Aug 2021 15:35:30 -0400
Copy-and-pasteo in 665c5855e, evidently. The 9.6 docs toolchain
whined about duplicate index entries, though our modern toolchain
doesn't. In any case, these GUCs surely are not about the
default settings of these values.
M doc/src/sgml/config.sgml
Release notes for 13.4, 12.8, 11.13, 10.18, 9.6.23.
commit : 6432cf92658307688be4e241eb16fc9c41a8c0cf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Aug 2021 14:35:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Aug 2021 14:35:19 -0400
M doc/src/sgml/release-13.sgml
Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.
commit : ba9f665a4413f855bbf4b544481db326f7b9bd73
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Aug 2021 13:29:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Aug 2021 13:29:32 -0400
Rather than trying to pick table aliases that won't conflict with
any possible user-defined matview column name, adjust the queries'
syntax so that the aliases are only used in places where they can't be
mistaken for column names. Mostly this consists of writing "alias.*"
not just "alias", which adds clarity for humans as well as machines.
We do have the issue that "SELECT alias.*" acts differently from
"SELECT alias", but we can use the same hack ruleutils.c uses for
whole-row variables in SELECT lists: write "alias.*::compositetype".
We might as well revert to the original aliases after doing this;
they're a bit easier to read.
Like 75d66d10e, back-patch to all supported branches.
Discussion: https://postgr.es/m/2488325.1628261320@sss.pgh.pa.us
M src/backend/commands/matview.c
M src/test/regress/expected/matview.out
M src/test/regress/sql/matview.sql
Adjust the integer overflow tests in the numeric code.
commit : da188b993450c824b03e7dca18c27e9f4c04754f
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Fri, 6 Aug 2021 21:31:20 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Fri, 6 Aug 2021 21:31:20 +0100
Formerly, the numeric code tested whether an integer value of a larger
type would fit in a smaller type by casting it to the smaller type and
then testing if the reverse conversion produced the original value.
That's perfectly fine, except that it caused a test failure on
buildfarm animal castoroides, most likely due to a compiler bug.
Instead, do these tests by comparing against PG_INT16/32_MIN/MAX. That
matches existing code in other places, such as int84(), which is more
widely tested, and so is less likely to go wrong.
While at it, add regression tests covering the numeric-to-int8/4/2
conversions, and adjust the recently added tests to the style of
434ddfb79a (on the v11 branch) to make failures easier to diagnose.
Per buildfarm via Tom Lane, reviewed by Tom Lane.
Discussion: https://postgr.es/m/2394813.1628179479%40sss.pgh.pa.us
M src/backend/utils/adt/numeric.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
Fix wording
commit : d3ad6566a130988af7693267bc8605b86772618c
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 6 Aug 2021 20:55:59 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 6 Aug 2021 20:55:59 +0200
M doc/src/sgml/rules.sgml
M src/backend/utils/adt/rangetypes_selfuncs.c
M src/backend/utils/adt/rangetypes_spgist.c
M src/bin/pg_resetwal/pg_resetwal.c
First-draft release notes for 13.4.
commit : 2f38ec6a157b60291ece1deb072bfff84f317334
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 Aug 2021 14:54:59 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 Aug 2021 14:54:59 -0400
As usual, the release notes for older branches will be made by cutting
these down, but put them up for community review first.
M doc/src/sgml/release-13.sgml
postgres_fdw: Fix issues with generated columns in foreign tables.
commit : 388a81bf4df4fc86a947368d94094e5276c2f255
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 5 Aug 2021 20:00:02 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 5 Aug 2021 20:00:02 +0900
postgres_fdw imported generated columns from the remote tables as plain
columns, and caused failures like "ERROR: cannot insert a non-DEFAULT
value into column "foo"" when inserting into the foreign tables, as it
tried to insert values into the generated columns. To fix, we do the
following under the assumption that generated columns in a postgres_fdw
foreign table are defined so that they represent generated columns in
the underlying remote table:
* Send DEFAULT for the generated columns to the foreign server on insert
or update, not generated column values computed on the local server.
* Add to postgresImportForeignSchema() an option "import_generated" to
include column generated expressions in the definitions of foreign
tables imported from a foreign server. The option is true by default.
The assumption seems reasonable, because that would make a query of the
postgres_fdw foreign table return values for the generated columns that
are consistent with the generated expression.
While here, fix another issue in postgresImportForeignSchema(): it tried
to include column generated expressions as column default expressions in
the foreign table definitions when the import_default option was enabled.
Per bug #16631 from Daniel Cherniy. Back-patch to v12 where generated
columns were added.
Discussion: https://postgr.es/m/16631-e929fe9db0ffc7cf%40postgresql.org
M contrib/postgres_fdw/deparse.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql
M doc/src/sgml/postgres-fdw.sgml
Fix division-by-zero error in to_char() with 'EEEE' format.
commit : a72ad63154256bd3adf1c885f8c3371e9e8ce67a
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 5 Aug 2021 09:29:13 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 5 Aug 2021 09:29:13 +0100
This fixes a long-standing bug when using to_char() to format a
numeric value in scientific notation -- if the value's exponent is
less than -NUMERIC_MAX_DISPLAY_SCALE-1 (-1001), it produced a
division-by-zero error.
The reason for this error was that get_str_from_var_sci() divides its
input by 10^exp, which it produced using power_var_int(). However, the
underflow test in power_var_int() causes it to return zero if the
result scale is too small. That's not a problem for power_var_int()'s
only other caller, power_var(), since that limits the rscale to 1000,
but in get_str_from_var_sci() the exponent can be much smaller,
requiring a much larger rscale. Fix by introducing a new function to
compute 10^exp directly, with no rscale limit. This also allows 10^exp
to be computed more efficiently, without any numeric multiplication,
division or rounding.
Discussion: https://postgr.es/m/CAEZATCWhojfH4whaqgUKBe8D5jNHB8ytzemL-PnRx+KCTyMXmg@mail.gmail.com
M src/backend/utils/adt/numeric.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
C comment: correct heading of extension query
commit : 47a573d9113e18864dcb637b72ee3ac1a9ec6b5e
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 12:26:08 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 12:26:08 -0400
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20210803161345.GZ12533@telsasoft.com
Backpatch-through: 9.6
M src/bin/pg_upgrade/version.c
doc: interval spill method for units greater than months
commit : 1dd84002060cc2cdc20b6cebd0f6bb2b56c7b35b
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 12:17:58 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 12:17:58 -0400
Units are _truncated_ to months, but only in back branches since the
recent commit.
Reported-by: Bryn Llewellyn
Discussion: https://postgr.es/m/BDAE4B56-3337-45A2-AC8A-30593849D6C0@yugabyte.com
Backpatch-through: 9.6 to 14
M doc/src/sgml/datatype.sgml
pg_upgrade: warn about extensions that need updating
commit : a81c71e3a830aecdfea7a53ae75781e50ba66018
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 11:58:15 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 11:58:15 -0400
Also create a script that can be run to update them.
Reported-by: Dave Cramer
Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com
Backpatch-through: 9.6
M src/bin/pg_upgrade/check.c
M src/bin/pg_upgrade/pg_upgrade.h
M src/bin/pg_upgrade/version.c
pg_upgrade: improve docs about extension upgrades
commit : 0e6cf3c6f43453f848b41a4f87434d2d9c627a34
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 11:27:33 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 11:27:33 -0400
The previous wording was unclear about the steps needed to upgrade
extensions, and how to update them after pg_upgrade.
Reported-by: Dave Cramer
Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com
Backpatch-through: 9.6
M doc/src/sgml/ref/pgupgrade.sgml
doc: mention inheritance's tableoid can be used in partitioning
commit : 7134b8cacca445115df7115615c063f5cc119b06
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 11:11:51 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 11:11:51 -0400
Previously tableoid was not mentioned in the partition doc section. We
only had a link to the "all the normal rules" of inheritance section.
Reported-by: michal.palenik@freemap.sk
Discussion: https://postgr.es/m/162627031219.693.11508199541771263335@wrigleys.postgresql.org
Backpatch-through: 10
M doc/src/sgml/ddl.sgml
doc: add example of using pg_dump with GNU split and gzip
commit : 073069075f227f27342e4d935d937141a2ba3910
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 10:57:32 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Aug 2021 10:57:32 -0400
This is only possible with GNU split, not other versions like BSD split.
Reported-by: jim@jdoherty.net
Discussion: https://postgr.es/m/162653459215.701.6323855956817776386@wrigleys.postgresql.org
Backpatch-through: 9.6
M doc/src/sgml/backup.sgml
Use elog, not Assert, to report failure to provide an outer snapshot.
commit : 93f99693f9c2a8e0662d847c4ba2abed1628c1d8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 31 Jul 2021 11:50:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 31 Jul 2021 11:50:14 -0400
As of commit 84f5c2908, executing SQL commands (via SPI or otherwise)
requires having either an active Portal, or a caller-established
active snapshot. We were simply Assert'ing that that's the case.
But we've now had a couple different reports of people testing
extensions that didn't meet this requirement, and were confused by
the resulting crash. Let's convert the Assert to a test-and-elog,
in hopes of making the issue clearer for extension authors.
Per gripes from Liu Huailing and RekGRpth. Back-patch to v11,
like the prior commit.
Discussion: https://postgr.es/m/OSZPR01MB6215671E3C5956A034A080DFBEEC9@OSZPR01MB6215.jpnprd01.prod.outlook.com
Discussion: https://postgr.es/m/17035-14607d308ac8643c@postgresql.org
M src/backend/tcop/pquery.c
Fix corner-case errors and loss of precision in numeric_power().
commit : 053ec4e0c4e8027bc084d25a846e35ba84ae966c
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 31 Jul 2021 11:25:39 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 31 Jul 2021 11:25:39 +0100
This fixes a couple of related problems that arise when raising
numbers to very large powers.
Firstly, when raising a negative number to a very large integer power,
the result should be well-defined, but the previous code would only
cope if the exponent was small enough to go through power_var_int().
Otherwise it would throw an internal error, attempting to take the
logarithm of a negative number. Fix this by adding suitable handling
to the general case in power_var() to cope with negative bases,
checking for integer powers there.
Next, when raising a (positive or negative) number whose absolute
value is slightly less than 1 to a very large power, the result should
approach zero as the power is increased. However, in some cases, for
sufficiently large powers, this would lose all precision and return 1
instead of 0. This was due to the way that the local_rscale was being
calculated for the final full-precision calculation:
local_rscale = rscale + (int) val - ln_dweight + 8
The first two terms on the right hand side are meant to give the
number of significant digits required in the result ("val" being the
estimated result weight). However, this failed to account for the fact
that rscale is clipped to a maximum of NUMERIC_MAX_DISPLAY_SCALE
(1000), and the result weight might be less then -1000, causing their
sum to be negative, leading to a loss of precision. Fix this by
forcing the number of significant digits calculated to be nonnegative.
It's OK for it to be zero (when the result weight is less than -1000),
since the local_rscale value then includes a few extra digits to
ensure an accurate result.
Finally, add additional underflow checks to exp_var() and power_var(),
so that they consistently return zero for cases like this where the
result is indistinguishable from zero. Some paths through this code
already returned zero in such cases, but others were throwing overflow
errors.
Dean Rasheed, reviewed by Yugo Nagata.
Discussion: http://postgr.es/m/CAEZATCW6Dvq7+3wN3tt5jLj-FyOcUgT5xNoOqce5=6Su0bCR0w@mail.gmail.com
M src/backend/utils/adt/numeric.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
Fix range check in ECPG numeric to int conversion
commit : 171bf1cea579ce11bc7f0b2986f052022f2b6be1
author : John Naylor <john.naylor@postgresql.org>
date : Fri, 30 Jul 2021 13:50:23 -0400
committer: John Naylor <john.naylor@postgresql.org>
date : Fri, 30 Jul 2021 13:50:23 -0400
The previous coding guarded against -INT_MAX instead of INT_MIN,
leading to -2147483648 being rejected as out of range.
Per bug #17128 from Kevin Sweet
Discussion: https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.org
Reviewed-by: Tom Lane
Backpatch to all supported branches
M doc/src/sgml/ecpg.sgml
M src/interfaces/ecpg/pgtypeslib/numeric.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test.stderr
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test.stdout
M src/interfaces/ecpg/test/pgtypeslib/num_test.pgc
Close yet another race condition in replication slot test code
commit : 41d27ee7b870c1a1213704d3c020a01eb55799b0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 29 Jul 2021 17:26:25 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 29 Jul 2021 17:26:25 -0400
Buildfarm shows that this test has a further failure mode when a
checkpoint starts earlier than expected, so we detect a "checkpoint
completed" line that's not the one we want. Change the config to try
and prevent this.
Per buildfarm
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://postgr.es/m/20210729.162038.534808353849568395.horikyota.ntt@gmail.com
M src/test/recovery/t/019_replslot_limit.pl
Add missing exit() in pg_verifybackup when failing to find pg_waldump
commit : efe169c90090684d2a4ffb0810a0cf2c9b72e19d
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 29 Jul 2021 11:00:00 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 29 Jul 2021 11:00:00 +0900
pg_verifybackup needs by default pg_waldump to check after a range of
WAL segments required for a backup, except if --no-parse-wal is
specified. The code checked for the presence of the binary pg_waldump
in an installation and reported an error, but it forgot to properly
exit(). This could lead to confusing errors reported.
Reviewed-by: Robert Haas, Fabien Coelho
Discussion: https://postgr.es/m/YQDMdB+B68yePFeT@paquier.xyz
Backpatch-through: 13
M src/bin/pg_verifybackup/pg_verifybackup.c
Update minimum recovery point on truncation during WAL replay of abort record.
commit : a66b05b422d74111f2a6407108f4ba7bdddbb6a0
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 29 Jul 2021 01:34:13 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 29 Jul 2021 01:34:13 +0900
If a file is truncated, we must update minRecoveryPoint. Once a file is
truncated, there's no going back; it would not be safe to stop recovery
at a point earlier than that anymore.
Commit 7bffc9b7bf changed xact_redo_commit() so that it updates
minRecoveryPoint on truncation, but forgot to change xact_redo_abort().
Back-patch to all supported versions.
Reported-by: mengjuan.cmj@alibaba-inc.com
Author: Fujii Masao
Reviewed-by: Heikki Linnakangas
Discussion: https://postgr.es/m/b029fce3-4fac-4265-968e-16f36ff4d075.mengjuan.cmj@alibaba-inc.com
M src/backend/access/transam/xact.c
Doc: Clarify lock levels taken during ATTACH PARTITION
commit : aa1e9211ecf7ef410b4313f0e061de087aed0aa2
author : David Rowley <drowley@postgresql.org>
date : Wed, 28 Jul 2021 15:01:40 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 28 Jul 2021 15:01:40 +1200
It wasn't all that clear which lock levels, if any, would be held on the
DEFAULT partition during an ATTACH PARTITION operation.
Also, clarify which locks will be taken if the DEFAULT partition or the
table being attached are themselves partitioned tables.
Here I'm only backpatching to v12 as before then we obtained an ACCESS
EXCLUSIVE lock on the partitioned table. It seems much less relevant to
mention which locks are taken on other tables when the partitioned table
itself is locked with an ACCESS EXCLUSIVE lock.
Author: Matthias van de Meent, David Rowley
Discussion: https://postgr.es/m/CAEze2WiTB6iwrV8W_J=fnrnZ7fowW3qu-8iQ8zCHP3FiQ6+o-A@mail.gmail.com
Backpatch-through: 12
M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/alter_table.sgml
Set pg_setting.pending_restart when pertinent config lines are removed
commit : b8f91d7f926368115c27b978c939174c96df1a5f
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Jul 2021 15:44:12 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 27 Jul 2021 15:44:12 -0400
This changes the behavior of examining the pg_file_settings view after
changing a config option that requires restart. The user needs to know
that any change of such options does not take effect until a restart,
and this worked correctly if the line is edited without removing it.
However, for the case where the line is removed altogether, the flag
doesn't get set, because a flag was only set in set_config_option, but
that's not called for lines removed. Repair.
(Ref.: commits 62d16c7fc561 and a486e35706ea)
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/202107262302.xsfdfc5sb7sh@alvherre.pgsql
M src/backend/utils/misc/guc-file.l
Avoid using ambiguous word "non-negative" in error messages.
commit : 92913fc290f3adb3fe937485474a11ac6708e4b0
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 28 Jul 2021 01:21:52 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 28 Jul 2021 01:21:52 +0900
The error messages using the word "non-negative" are confusing
because it's ambiguous about whether it accepts zero or not.
This commit improves those error messages by replacing it with
less ambiguous word like "greater than zero" or
"greater than or equal to zero".
Also this commit added the note about the word "non-negative" to
the error message style guide, to help writing the new error messages.
When postgres_fdw option fetch_size was set to zero, previously
the error message "fetch_size requires a non-negative integer value"
was reported. This error message was outright buggy. Therefore
back-patch to all supported versions where such buggy error message
could be thrown.
Reported-by: Hou Zhijie
Author: Bharath Rupireddy
Reviewed-by: Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/OS0PR01MB5716415335A06B489F1B3A8194569@OS0PR01MB5716.jpnprd01.prod.outlook.com
M contrib/postgres_fdw/option.c
M doc/src/sgml/sources.sgml
M src/backend/partitioning/partbounds.c
M src/backend/utils/adt/tsquery_op.c
M src/test/modules/test_shm_mq/test.c
M src/test/regress/expected/hash_part.out
doc: for various substring funcs, document if only first match
commit : d629fcf4b36ca8c1e4e9677745ff7d725433ee19
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 26 Jul 2021 22:54:35 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 26 Jul 2021 22:54:35 -0400
Reported-by: troy@frericks.us
Discussion: https://postgr.es/m/162614304115.701.2392941350859387646@wrigleys.postgresql.org
Backpatch-through: 13
M doc/src/sgml/func.sgml
pg_resetxlog: add option to set oldest xid & use by pg_upgrade
commit : 0a5e708e2bd87adb0779d7c8758e5743cc1c0adf
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 26 Jul 2021 22:38:14 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 26 Jul 2021 22:38:14 -0400
Add pg_resetxlog -u option to set the oldest xid in pg_control.
Previously -x set this value be -2 billion less than the -x value.
However, this causes the server to immediately scan all relation's
relfrozenxid so it can advance pg_control's oldest xid to be inside the
autovacuum_freeze_max_age range, which is inefficient and might disrupt
diagnostic recovery. pg_upgrade will use this option to better create
the new cluster to match the old cluster.
Reported-by: Jason Harvey, Floris Van Nee
Discussion: https://postgr.es/m/20190615183759.GB239428@rfd.leadboat.com, 87da83168c644fd9aae38f546cc70295@opammb0562.comp.optiver.com
Author: Bertrand Drouvot
Backpatch-through: 9.6
M doc/src/sgml/ref/pg_resetwal.sgml
M src/bin/pg_resetwal/pg_resetwal.c
M src/bin/pg_upgrade/controldata.c
M src/bin/pg_upgrade/pg_upgrade.c
M src/bin/pg_upgrade/pg_upgrade.h
Harden pg_stat_statements tests against CLOBBER_CACHE_ALWAYS.
commit : 882d15144bbb21856676ff046faee1e9a580e3e4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Jul 2021 23:25:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Jul 2021 23:25:15 -0400
Turns out the buildfarm hasn't been testing this, which will soon change.
Julien Rouhaud, per report from me
Discussion: https://postgr.es/m/42557.1627229005@sss.pgh.pa.us
M contrib/pg_stat_statements/expected/pg_stat_statements.out
M contrib/pg_stat_statements/sql/pg_stat_statements.sql
Fix a couple of memory leaks in src/bin/pg_basebackup/
commit : 2c7395aad7e849235faac4ead5f69700cfd3c21b
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 26 Jul 2021 11:14:11 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 26 Jul 2021 11:14:11 +0900
These have been introduced by 7fbe0c8, and could happen for
pg_basebackup and pg_receivewal.
Per report from Coverity for the ones in walmethods.c, I have spotted
the ones in receivelog.c after more review.
Backpatch-through: 10
M src/bin/pg_basebackup/receivelog.c
M src/bin/pg_basebackup/walmethods.c
M src/bin/pg_basebackup/walmethods.h
Get rid of artificial restriction on hash table sizes on Windows.
commit : 2b8f3f5a7c0ede24903782fcffe2553fec01bfbe
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Jul 2021 14:02:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Jul 2021 14:02:27 -0400
The point of introducing the hash_mem_multiplier GUC was to let users
reproduce the old behavior of hash aggregation, i.e. that it could use
more than work_mem at need. However, the implementation failed to get
the job done on Win64, where work_mem is clamped to 2GB to protect
various places that calculate memory sizes using "long int". As
written, the same clamp was applied to hash_mem. This resulted in
severe performance regressions for queries requiring a bit more than
2GB for hash aggregation, as they now spill to disk and there's no
way to stop that.
Getting rid of the work_mem restriction seems like a good idea, but
it's a big job and could not conceivably be back-patched. However,
there's only a fairly small number of places that are concerned with
the hash_mem value, and it turns out to be possible to remove the
restriction there without too much code churn or any ABI breaks.
So, let's do that for now to fix the regression, and leave the
larger task for another day.
This patch does introduce a bit more infrastructure that should help
with the larger task, namely pg_bitutils.h support for working with
size_t values.
Per gripe from Laurent Hasson. Back-patch to v13 where the
behavior change came in.
Discussion: https://postgr.es/m/997817.1627074924@sss.pgh.pa.us
Discussion: https://postgr.es/m/MN2PR15MB25601E80A9B6D1BA6F592B1985E39@MN2PR15MB2560.namprd15.prod.outlook.com
M src/backend/executor/execGrouping.c
M src/backend/executor/nodeAgg.c
M src/backend/executor/nodeHash.c
M src/backend/optimizer/path/costsize.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/plan/subselect.c
M src/backend/optimizer/prep/prepunion.c
M src/backend/optimizer/util/pathnode.c
M src/include/miscadmin.h
M src/include/port/pg_bitutils.h
Make the standby server promptly handle interrupt signals.
commit : 8d091922ffcc27323ffe2127e228e302b9f153f4
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 16 Nov 2020 18:27:51 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 16 Nov 2020 18:27:51 +0900
This commit changes the startup process in the standby server so that
it handles the interrupt signals after waiting for wal_retrieve_retry_interval
on the latch and resetting it, before entering another wait on the latch.
This change causes the standby server to promptly handle interrupt signals.
Otherwise, previously, there was the case where the standby needs to
wait extra five seconds to shutdown when the shutdown request arrived
while the startup process was waiting for wal_retrieve_retry_interval
on the latch.
Author: Fujii Masao, but implementation idea is from Soumyadeep Chakraborty
Reviewed-by: Soumyadeep Chakraborty
Discussion: https://postgr.es/m/9d7e6ab0-8a53-ddb9-63cd-289bcb25fe0e@oss.nttdata.com
Per discussion of BUG #17073, back-patch to all supported versions.
Discussion: https://postgr.es/m/17073-1a5fdaed0fa5d4d0@postgresql.org
M src/backend/access/transam/xlog.c
Fix check for conflicting session- vs transaction-level locks.
commit : f47408cdc19c2bbe357703afd81037b6d12ed3ba
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jul 2021 18:35:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jul 2021 18:35:52 -0400
We have an implementation restriction that PREPARE TRANSACTION can't
handle cases where both session-lifespan and transaction-lifespan locks
are held on the same lockable object. (That's because we'd otherwise
need to acquire a new PROCLOCK entry during post-prepare cleanup, which
is an operation that might fail. The situation can only arise with odd
usages of advisory locks, so removing the restriction is probably not
worth the amount of effort it would take.) AtPrepare_Locks attempted
to enforce this, but its logic was many bricks shy of a load, because
it only detected cases where the session and transaction locks had the
same lockmode. Locks of different modes on the same object would lead
to the rather unhelpful message "PANIC: we seem to have dropped a bit
somewhere".
To fix, build a transient hashtable with one entry per locktag,
not one per locktag + mode, and use that to detect conflicts.
Per bug #17122 from Alexander Pyhalov. This bug is ancient,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/17122-04f3c32098a62233@postgresql.org
M src/backend/storage/lmgr/lock.c
M src/test/regress/expected/prepared_xacts.out
M src/test/regress/expected/prepared_xacts_1.out
M src/test/regress/sql/prepared_xacts.sql
Make printf("%s", NULL) print "(null)" instead of crashing.
commit : c0a6f83deba9c55459e52ad4475207f62354a1f1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jul 2021 13:41:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jul 2021 13:41:17 -0400
We previously took a hard-line attitude that callers should never print
a null string pointer, and doing so is worthy of an assertion failure
or crash. However, we've long since flushed out any easy-to-find bugs
of that nature. What remains is a lot of code that perhaps could fail
that way in hard-to-reach corner cases. For example, in something as
simple as
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("constraint \"%s\" for table \"%s\" does not exist",
conname, get_rel_name(relid))));
one must wonder whether it's completely guaranteed that get_rel_name
cannot return NULL in this context. If such a situation did occur,
the existing policy converts what might be a pretty minor bug into
a server crash condition. This is not good for robustness.
Hence, let's follow the lead of glibc and print "(null)" instead
of failing. We should, of course, still consider it a bug if that
behavior is reachable in ordinary use; but crashing seems less
desirable than not crashing.
This fix works across-the-board in v12 and up, where we always use
src/port/snprintf.c. Before that, on most platforms we're at the mercy
of the local libc, but it appears that Solaris 10 is the only supported
platform where we'd still get a crash. Most other platforms such as
*BSD, macOS, and Solaris 11 have adopted glibc's behavior at some
point. (AIX and HPUX just print "" not "(null)", but that's close
enough.) I've not checked what Windows' native printf would do, but
it doesn't matter because we've long used snprintf.c on that platform.
In v12 and up, also const-ify related code so that we're not casting
away const on the constant string. This is just neatnik-ism, since
next to no compilers will warn about that.
Discussion: https://postgr.es/m/17098-b960f3616c861f83@postgresql.org
M src/port/snprintf.c
jit: Don't inline functions that access thread-locals.
commit : 1cfc9f2ef61df81fa54a697081e372672c23e980
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 22 Jul 2021 14:11:17 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 22 Jul 2021 14:11:17 +1200
Code inlined by LLVM can crash or fail with "Relocation type not
implemented yet!" if it tries to access thread local variables. Don't
inline such code.
Back-patch to 11, where LLVM arrived. Bug #16696.
Author: Dmitry Marakasov <amdmi3@amdmi3.ru>
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/16696-29d944a33801fbfe@postgresql.org
M src/backend/jit/llvm/llvmjit_inline.cpp
Doc: improve documentation about exponentiation operator.
commit : 8344979d5bbc63aa8fb8c804bd933c887a2abb58
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Jul 2021 18:03:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Jul 2021 18:03:33 -0400
Now that we're not having to wedge this into the straitjacket of
the old operator table format, we can add another example to
clarify the point about left-to-right associativity.
Per suggestion from mdione at grulic.org.ar.
https://postgr.es/m/162661954599.693.13700316547731859171@wrigleys.postgresql.org
M doc/src/sgml/func.sgml
Document "B" and "us" as accepted units in postgres.conf.sample
commit : 0b5dc1f171c4c7433cff2949d7bf64aa912765b3
author : John Naylor <john.naylor@postgresql.org>
date : Wed, 21 Jul 2021 10:17:07 -0400
committer: John Naylor <john.naylor@postgresql.org>
date : Wed, 21 Jul 2021 10:17:07 -0400
In postgresql.conf, memory and file size GUCs can be specified with "B"
(bytes) as of b06d8e58b. Likewise, time GUCs can be specified with "us"
(microsecond