Stamp 15.4.
commit : 83ed1f71c88ae948a5b6ec6d2a4802cc54470102
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Aug 2023 16:08:18 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Aug 2023 16:08:18 -0400
M configure
M configure.ac
Last-minute updates for release notes.
commit : 948757fe493c1031d43bb082b6466db9a08f34a3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Aug 2023 12:50:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Aug 2023 12:50:15 -0400
Security: CVE-2023-39417, CVE-2023-39418
M doc/src/sgml/release-15.sgml
Reject substituting extension schemas or owners matching ["$'\].
commit : de494ec14f6bd7f2676623a5934723a6c8ba51c2
author : Noah Misch <noah@leadboat.com>
date : Mon, 7 Aug 2023 06:05:56 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 7 Aug 2023 06:05:56 -0700
Substituting such values in extension scripts facilitated SQL injection
when @extowner@, @extschema@, or @extschema:...@ appeared inside a
quoting construct (dollar quoting, '', or ""). No bundled extension was
vulnerable. Vulnerable uses do appear in a documentation example and in
non-bundled extensions. Hence, the attack prerequisite was an
administrator having installed files of a vulnerable, trusted,
non-bundled extension. Subject to that prerequisite, this enabled an
attacker having database-level CREATE privilege to execute arbitrary
code as the bootstrap superuser. By blocking this attack in the core
server, there's no need to modify individual extensions. Back-patch to
v11 (all supported versions).
Reported by Micah Gate, Valerie Woolard, Tim Carey-Smith, and Christoph
Berg.
Security: CVE-2023-39417
M src/backend/commands/extension.c
M src/test/modules/test_extensions/Makefile
M src/test/modules/test_extensions/expected/test_extensions.out
M src/test/modules/test_extensions/sql/test_extensions.sql
A src/test/modules/test_extensions/test_ext_extschema–1.0.sql
A src/test/modules/test_extensions/test_ext_extschema.control
Translation updates
commit : 0fee069960a65a22e92923d5406fcb9dae5d794c
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 7 Aug 2023 12:10:58 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 7 Aug 2023 12:10:58 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 1168da8e78b0511c8bfa99ceb08e848fbaa7e8f2
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/ja.po
M src/backend/po/zh_CN.po
M src/bin/initdb/po/es.po
M src/bin/psql/po/es.po
M src/pl/plpython/po/es.po
Don't Memoize lateral joins with volatile join conditions
commit : 71662373b38b838d2e62b353319e93de64ad2036
author : David Rowley <drowley@postgresql.org>
date : Mon, 7 Aug 2023 22:15:23 +1200
committer: David Rowley <drowley@postgresql.org>
date : Mon, 7 Aug 2023 22:15:23 +1200
The use of Memoize was already disabled in normal joins when the join
conditions had volatile functions per the code in
match_opclause_to_indexcol(). Ordinarily, the parameterization for the
inner side of a nested loop will be an Index Scan or at least eventually
lead to an index scan (perhaps nested several joins deep). However, for
lateral joins, that's not the case and seq scans can be parameterized
too, so we can't rely on match_opclause_to_indexcol().
Here we explicitly check the parameterization for volatile functions and
don't consider the generation of a Memoize path when such functions
are present.
Author: Richard Guo
Discussion: https://postgr.es/m/CAMbWs49nHFnHbpepLsv_yF3qkpCS4BdB-v8HoJVv8_=Oat0u_w@mail.gmail.com
Backpatch-through: 14, where Memoize was introduced
M src/backend/optimizer/path/joinpath.c
Fix RLS policy usage in MERGE.
commit : cb2ae5741f2458a474ed3c31458d242e678ff229
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 7 Aug 2023 09:24:27 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 7 Aug 2023 09:24:27 +0100
If MERGE executes an UPDATE action on a table with row-level security,
the code incorrectly applied the WITH CHECK clauses from the target
table's INSERT policies to new rows, instead of the clauses from the
table's UPDATE policies. In addition, it failed to check new rows
against the target table's SELECT policies, if SELECT permissions were
required (likely to always be the case).
In addition, if MERGE executes a DO NOTHING action for matched rows,
the code incorrectly applied the USING clauses from the target table's
DELETE policies to existing target tuples. These policies were applied
as checks that would throw an error, if they did not pass.
Fix this, so that a MERGE UPDATE action applies the same RLS policies
as a plain UPDATE query with a WHERE clause, and a DO NOTHING action
does not apply any RLS checks (other than adding clauses from SELECT
policies to the join).
Back-patch to v15, where MERGE was introduced.
Dean Rasheed, reviewed by Stephen Frost.
Security: CVE-2023-39418
M src/backend/executor/nodeModifyTable.c
M src/backend/rewrite/rowsecurity.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Release notes for 15.4, 14.9, 13.12, 12.16, 11.21.
commit : accf4f84887eb8b53978a0dbf9cb5656e1779fcb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Aug 2023 16:47:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Aug 2023 16:47:04 -0400
M doc/src/sgml/release-15.sgml
Doc: update documentation for creating custom scan paths.
commit : dea12a1fd4fdce69c596b2b31782868d76b7abc2
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 3 Aug 2023 17:45:02 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 3 Aug 2023 17:45:02 +0900
Commit f49842d1e added a new callback for custom scan paths, but missed
updating the documentation.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAPmGK15ODkN%2B%3DhkBCufj1HBW0x5OTb65Xuy7ryXchMdiCMpx_g%40mail.gmail.com
M doc/src/sgml/custom-scan.sgml
Update comments on CustomPath struct.
commit : 9f495270cca7c75a50783be0a94edd28c1338ea9
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 3 Aug 2023 17:15:02 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 3 Aug 2023 17:15:02 +0900
Commit e7cb7ee14 allowed custom scan providers to create CustomPath
paths for join relations as well, but missed updating the comments.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAPmGK15ODkN%2B%3DhkBCufj1HBW0x5OTb65Xuy7ryXchMdiCMpx_g%40mail.gmail.com
M src/include/nodes/pathnodes.h
First-draft release notes for 15.4.
commit : c6344d7686f3e3c8243c2c6771996cfc63e71eae
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Aug 2023 17:44:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Aug 2023 17:44:34 -0400
As usual, the release notes for other branches will be made by cutting
these down, but put them up for community review first.
M doc/src/sgml/release-15.sgml
Fix ReorderBufferCheckMemoryLimit() comment.
commit : 01357f1da94b9926336448d88ac519f20ab27cd7
author : Masahiko Sawada <msawada@postgresql.org>
date : Wed, 2 Aug 2023 15:01:08 +0900
committer: Masahiko Sawada <msawada@postgresql.org>
date : Wed, 2 Aug 2023 15:01:08 +0900
Commit 7259736a6 updated the comment but it was not correct since
ReorderBufferLargestStreamableTopTXN() returns only top-level
transactions.
Reviewed-by: Amit Kapila
Discussion: https://postgr.es/m/CAD21AoA9XB7OR86BqvrCe2dMYX%2BZv3-BvVmjF%3DGY2z6jN-kqjg%40mail.gmail.com
Backpatch-through: 14
M src/backend/replication/logical/reorderbuffer.c
Fix overly strict Assert in jsonpath code
commit : 67f3a697ba83489fc69fefd82bc6dbc19f87ac56
author : David Rowley <drowley@postgresql.org>
date : Wed, 2 Aug 2023 01:40:56 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 2 Aug 2023 01:40:56 +1200
This was failing for queries which try to get the .type() of a
jpiLikeRegex. For example:
select jsonb_path_query('["string", "string"]',
'($[0] like_regex ".{7}").type()');
Reported-by: Alexander Kozhemyakin
Bug: #18035
Discussion: https://postgr.es/m/18035-64af5cdcb5adf2a9@postgresql.org
Backpatch-through: 12, where SQL/JSON path was added.
M src/backend/utils/adt/jsonpath.c
Disallow replacing joins with scans in problematic cases.
commit : d1ef5631e620f9a5b6480a32bb70124c857af4f1
author : Etsuro Fujita <efujita@postgresql.org>
date : Fri, 28 Jul 2023 15:45:02 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Fri, 28 Jul 2023 15:45:02 +0900
Commit e7cb7ee14, which introduced the infrastructure for FDWs and
custom scan providers to replace joins with scans, failed to add support
handling of pseudoconstant quals assigned to replaced joins in
createplan.c, leading to an incorrect plan without a gating Result node
when postgres_fdw replaced a join with such a qual.
To fix, we could add the support by 1) modifying the ForeignPath and
CustomPath structs to store the list of RestrictInfo nodes to apply to
the join, as in JoinPaths, if they represent foreign and custom scans
replacing a join with a scan, and by 2) modifying create_scan_plan() in
createplan.c to use that list in that case, instead of the
baserestrictinfo list, to get pseudoconstant quals assigned to the join;
but #1 would cause an ABI break. So fix by modifying the infrastructure
to just disallow replacing joins with such quals.
Back-patch to all supported branches.
Reported by Nishant Sharma. Patch by me, reviewed by Nishant Sharma and
Richard Guo.
Discussion: https://postgr.es/m/CADrsxdbcN1vejBaf8a%2BQhrZY5PXL-04mCd4GDu6qm6FigDZd6Q%40mail.gmail.com
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/optimizer/path/joinpath.c
M src/backend/optimizer/util/restrictinfo.c
M src/include/optimizer/restrictinfo.h
Raise fixed token-length limit in hba.c.
commit : 313ceda2fe2ee8dd903ad4773f54de14807807c6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Jul 2023 12:07:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Jul 2023 12:07:48 -0400
Historically, hba.c limited tokens in the authentication configuration
files (pg_hba.conf and pg_ident.conf) to less than 256 bytes. We have
seen a few reports of this limit causing problems; notably, for
moderately-complex LDAP configurations. Increase the limit to 10240
bytes as a low-risk stop-gap solution.
In v13 and earlier, this also requires raising MAX_LINE, the limit
on overall line length. I'm hesitant to make this code consume
too much stack space, so I only raised that to 20480 bytes.
Discussion: https://postgr.es/m/1588937.1690221208@sss.pgh.pa.us
M src/backend/libpq/hba.c
Fix the display of UNKNOWN message type in apply worker.
commit : 2864eb977a6e49d4355b679d7e1e54f01a231b80
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 25 Jul 2023 08:50:37 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 25 Jul 2023 08:50:37 +0530
We include the message type while displaying an error context in the
apply worker. Now, while retrieving the message type string if the
message type is unknown we throw an error that will hide the original
error. So, instead, we need to simply return the string indicating an
unknown message type.
Reported-by: Ashutosh Bapat
Author: Euler Taveira, Amit Kapila
Reviewed-by: Ashutosh Bapat
Backpatch-through: 15
Discussion: https://postgr.es/m/CAExHW5suAEDW-mBZt_qu4RVxWZ1vL54-L+ci2zreYWebpzxYsA@mail.gmail.com
M src/backend/replication/logical/proto.c
M src/backend/replication/logical/worker.c
M src/include/replication/logicalproto.h
Make test_decoding ddl.out shorter
commit : 3bb8b9342f8abe81af47ff7e5217865107cc15b3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 24 Jul 2023 17:48:06 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 24 Jul 2023 17:48:06 +0200
Some of the test_decoding test output was extremely wide, because it
deals with massive toasted values, and the aligned mode causes psql to
produce 200kB of whitespace and dashes. Change to unaligned mode
temporarily to avoid that behavior.
Backpatch to 14, where it applies cleanly.
Discussion: https://postgr.es/m/20230405103953.sxleixp3uz5lazst@alvherre.pgsql
M contrib/test_decoding/expected/ddl.out
M contrib/test_decoding/sql/ddl.sql
Guard against null plan pointer in CachedPlanIsSimplyValid().
commit : fbaf65cd65f4f0810dab9f2b3e840e68d8b959eb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 20 Jul 2023 14:23:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 20 Jul 2023 14:23:46 -0400
If both the passed-in plan pointer and plansource->gplan are
NULL, CachedPlanIsSimplyValid would think that the plan pointer
is possibly-valid and try to dereference it. For the one extant
call site in plpgsql, this situation doesn't normally happen
which is why we've not noticed. However, it appears to be possible
if the previous use of the cached plan failed, as per report from
Justin Pryzby. Add an extra check to prevent crashing.
Back-patch to v13 where this code was added.
Discussion: https://postgr.es/m/ZLlV+STFz1l/WhAQ@telsasoft.com
M src/backend/utils/cache/plancache.c
Doc: improve description of IN and row-constructor comparisons.
commit : bc9993a5497748ca333beac34a8446114bfacce7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 19 Jul 2023 11:00:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 19 Jul 2023 11:00:34 -0400
IN and NOT IN work fine on records and arrays, so just say that
they accept "expressions" not "scalar expressions". I think that
that phrasing was meant to say that they don't work on set-returning
expressions, but that's not the common meaning of "scalar".
Revise the description of row-constructor comparisons to make it
perhaps a bit less confusing. (This partially reverts some
dubious wording changes made by commit f56651519.)
Per gripe from Ilya Nenashev. Back-patch to supported branches.
In HEAD and v16, also drop a NOTE about pre-8.2 behavior, which
is hopefully no longer of interest to anybody.
Discussion: https://postgr.es/m/168968062460.632.14303906825812821399@wrigleys.postgresql.org
M doc/src/sgml/func.sgml
Doc: fix out-of-date example of SPI usage.
commit : f9278cb0ae947bd6b3ba88145ead6a991c5ddb5c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Jul 2023 11:59:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Jul 2023 11:59:39 -0400
The "count" argument of SPI_exec() only limits execution when
the query is actually returning rows. This was not the case
before PG 9.0, so this example was correct when written; but
we missed updating it in commit 2ddc600f8. Extend the example
to show the behavior both with and without RETURNING.
While here, improve the commentary and markup for the rest
of the example.
David G. Johnston and Tom Lane, per report from Curt Kolovson.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/CANhYJV6HWtgz_qjx_APfK0PAgLUzY-2vjLuj7i_o=TZF1LAQew@mail.gmail.com
M doc/src/sgml/spi.sgml
Fix indentation in twophase.c
commit : f6ecd2622c0a40e5992b2db44c5b052761e53aa6
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 18 Jul 2023 14:04:48 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 18 Jul 2023 14:04:48 +0900
This has been missed in cb0cca1, noticed before buildfarm member koel
has been able to complain while poking at a different patch. Like the
other commit, backpatch all the way down to limit the odds of merge
conflicts.
Backpatch-through: 11
M src/backend/access/transam/twophase.c
Fix recovery of 2PC transaction during crash recovery
commit : a878eff6b4b9600763db95ba9dd5725497847fa3
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 18 Jul 2023 13:44:29 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 18 Jul 2023 13:44:29 +0900
A crash in the middle of a checkpoint with some two-phase state data
already flushed to disk by this checkpoint could cause a follow-up crash
recovery to recover twice the same transaction, once from what has been
found in pg_twophase/ at the beginning of recovery and a second time
when replaying its corresponding record.
This would lead to FATAL failures in the startup process during
recovery, where the same transaction would have a state recovered twice
instead of once:
LOG: recovering prepared transaction 731 from shared memory
LOG: recovering prepared transaction 731 from shared memory
FATAL: lock ExclusiveLock on object 731/0/0 is already held
This issue is fixed by skipping the addition of any 2PC state coming
from a record whose equivalent 2PC state file has already been loaded in
TwoPhaseState at the beginning of recovery by restoreTwoPhaseData(),
which is OK as long as the system has not reached a consistent state.
The timing to get a messed up recovery processing is very racy, and
would very unlikely happen. The thread that has reported the issue has
demonstrated the bug using injection points to force a PANIC in the
middle of a checkpoint.
Issue introduced in 728bd99, so backpatch all the way down.
Reported-by: "suyu.cmj" <mengjuan.cmj@alibaba-inc.com>
Author: "suyu.cmj" <mengjuan.cmj@alibaba-inc.com>
Author: Michael Paquier
Discussion: https://postgr.es/m/109e6994-b971-48cb-84f6-829646f18b4c.mengjuan.cmj@alibaba-inc.com
Backpatch-through: 11
M src/backend/access/transam/twophase.c
Add indisreplident to fields refreshed by RelationReloadIndexInfo()
commit : eb3abec4b67d2b51406c23030dd87643fa2024c2
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 14 Jul 2023 11:16:06 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 14 Jul 2023 11:16:06 +0900
RelationReloadIndexInfo() is a fast-path used for index reloads in the
relation cache, and it has always forgotten about updating
indisreplident, which is something that would happen after an index is
selected for a replica identity. This can lead to incorrect cache
information provided when executing a command in a transaction context
that updates indisreplident.
None of the code paths currently on HEAD that need to check upon
pg_index.indisreplident fetch its value from the relation cache, always
relying on a fresh copy on the syscache. Unfortunately, this may not be
the case of out-of-core code, that could see out-of-date value.
Author: Shruthi Gowda
Reviewed-by: Robert Haas, Dilip Kumar, Michael Paquier
Discussion: https://postgr.es/m/CAASxf_PBcxax0wW-3gErUyftZ0XrCs3Lrpuhq4-Z3Fak1DoW7Q@mail.gmail.com
Backpatch-through: 11
M src/backend/utils/cache/relcache.c
Fix updates of indisvalid for partitioned indexes
commit : c0dc97c7bfd14b460536c40d14787f82ab61d0d9
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 14 Jul 2023 10:13:15 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 14 Jul 2023 10:13:15 +0900
indisvalid is switched to true for partitioned indexes when all its
partitions have valid indexes when attaching a new partition, up to the
top-most parent if all its leaves are themselves valid when dealing with
multiple layers of partitions.
The copy of the tuple from pg_index used to switch indisvalid to true
came from the relation cache, which is incorrect. Particularly, in the
case reported by Shruthi Gowda, executing a series of commands in a
single transaction would cause the validation of partitioned indexes to
use an incorrect version of a pg_index tuple, as indexes are reloaded
after an invalidation request with RelationReloadIndexInfo(), a much
faster version than a full index cache rebuild. In this case, the
limited information updated in the cache leads to an incorrect version
of the tuple used. One of the symptoms reported was the following
error, with a replica identity update, for instance:
"ERROR: attempted to update invisible tuple"
This is incorrect since 8b08f7d, so backpatch all the way down.
Reported-by: Shruthi Gowda
Author: Michael Paquier
Reviewed-by: Shruthi Gowda, Dilip Kumar
Discussion: https://postgr.es/m/CAASxf_PBcxax0wW-3gErUyftZ0XrCs3Lrpuhq4-Z3Fak1DoW7Q@mail.gmail.com
Backpatch-through: 11
M src/backend/commands/tablecmds.c
M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql
Handle DROP DATABASE getting interrupted
commit : f66403749df744be60f45d20cace48cbc030b804
author : Andres Freund <andres@anarazel.de>
date : Thu, 13 Jul 2023 13:03:31 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 13 Jul 2023 13:03:31 -0700
Until now, when DROP DATABASE got interrupted in the wrong moment, the removal
of the pg_database row would also roll back, even though some irreversible
steps have already been taken. E.g. DropDatabaseBuffers() might have thrown
out dirty buffers, or files could have been unlinked. But we continued to
allow connections to such a corrupted database.
To fix this, mark databases invalid with an in-place update, just before
starting to perform irreversible steps. As we can't add a new column in the
back branches, we use pg_database.datconnlimit = -2 for this purpose.
An invalid database cannot be connected to anymore, but can still be
dropped.
Unfortunately we can't easily add output to psql's \l to indicate that some
database is invalid, it doesn't fit in any of the existing columns.
Add tests verifying that a interrupted DROP DATABASE is handled correctly in
the backend and in various tools.
Reported-by: Evgeny Morozov <postgresql3@realityexists.net>
Author: Andres Freund <andres@anarazel.de>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/20230509004637.cgvmfwrbht7xm7p6@awork3.anarazel.de
Discussion: https://postgr.es/m/20230314174521.74jl6ffqsee5mtug@awork3.anarazel.de
Backpatch: 11-, bug present in all supported versions
M doc/src/sgml/catalogs.sgml
M src/backend/commands/dbcommands.c
M src/backend/commands/vacuum.c
M src/backend/postmaster/autovacuum.c
M src/backend/utils/init/postinit.c
M src/bin/pg_amcheck/pg_amcheck.c
M src/bin/pg_amcheck/t/002_nonesuch.pl
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_dump/t/002_pg_dump.pl
M src/bin/pg_upgrade/t/002_pg_upgrade.pl
M src/bin/scripts/clusterdb.c
M src/bin/scripts/reindexdb.c
M src/bin/scripts/t/011_clusterdb_all.pl
M src/bin/scripts/t/050_dropdb.pl
M src/bin/scripts/t/091_reindexdb_all.pl
M src/bin/scripts/t/101_vacuumdb_all.pl
M src/bin/scripts/vacuumdb.c
M src/include/catalog/pg_database.h
A src/test/recovery/t/037_invalid_database.pl
Release lock after encountering bogs row in vac_truncate_clog()
commit : 82e97b864004810db2d335cf26117f7f1c2ff435
author : Andres Freund <andres@anarazel.de>
date : Thu, 13 Jul 2023 13:03:31 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 13 Jul 2023 13:03:31 -0700
When vac_truncate_clog() encounters bogus datfrozenxid / datminmxid values, it
returns early. Unfortunately, until now, it did not release
WrapLimitsVacuumLock. If the backend later tries to acquire
WrapLimitsVacuumLock, the session / autovacuum worker hangs in an
uncancellable way. Similarly, other sessions will hang waiting for the
lock. However, if the backend holding the lock exited or errored out for some
reason, the lock was released.
The bug was introduced as a side effect of 566372b3d643.
It is interesting that there are no production reports of this problem. That
is likely due to a mix of bugs leading to bogus values having gotten less
common, process exit releasing locks and instances of hangs being hard to
debug for "normal" users.
Discussion: https://postgr.es/m/20230621221208.vhsqgduwfpzwxnpg@awork3.anarazel.de
M src/backend/commands/vacuum.c
Remove unnecessary pfree() in g_intbig_compress().
commit : 5cb4619896d87b4fa8d625268ab9f391ce4ea9c3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Jul 2023 13:07:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Jul 2023 13:07:51 -0400
GiST compress functions (like all GiST opclass functions) are
supposed to be called in short-lived memory contexts, so that
minor memory leaks in them are not of concern, and indeed
explicit pfree's are likely slightly counterproductive.
But this one in g_intbig_compress() is more than
slightly counterproductive, because it's guarded by
"if (in != DatumGetArrayTypeP(entry->key))" which means
that if this test succeeds, we've detoasted the datum twice.
(And to add insult to injury, the extra detoast result is
leaked.) Let's just drop the whole stanza, relying on the
GiST temporary context mechanism to clean up in good time.
The analogous bit in g_int_compress() is
if (r != (ArrayType *) DatumGetPointer(entry->key))
pfree(r);
which doesn't have the gratuitous-detoast problem so
I left it alone. Perhaps there is a case for removing
unnecessary pfree's more widely, but I'm not sure if it's
worth the code churn.
The potential extra decompress seems expensive enough to
justify calling this a (minor) performance bug and
back-patching.
Konstantin Knizhnik, Matthias van de Meent, Tom Lane
Discussion: https://postgr.es/m/CAEze2Wi86=DxErfvf+SCB2UKmU2amKOF60BKuJOX=w-RojRn0A@mail.gmail.com
M contrib/intarray/_intbig_gist.c
Be more rigorous about local variables in PostgresMain().
commit : 22447db17cc009efe2c8b23d6625c5c9abe499c8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Jul 2023 12:14:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 10 Jul 2023 12:14:34 -0400
Since PostgresMain calls sigsetjmp, any local variables that are not
marked "volatile" have a risk of unspecified behavior. In practice
this means that when control returns via longjmp, such variables might
get reset to their values as of the time of sigsetjmp, depending on
whether the compiler chose to put them in registers or on the stack.
We were careful about this for "send_ready_for_query", but not the
other local variables.
In the case of the timeout_enabled flags, resetting them to
their initial "false" states is actually good, since we do
"disable_all_timeouts()" in the longjmp cleanup code path. If that
does not happen, we risk uselessly calling "disable_timeout()" later,
which is harmless but a little bit expensive. Let's explicitly reset
these flags so that the behavior is correct and platform-independent.
(This change means that we really don't need the new "volatile"
markings after all, but let's install them anyway since any change
in this logic could re-introduce a problem.)
There is no issue for "firstchar" and "input_message" because those
are explicitly reinitialized each time through the query processing
loop. To make that clearer, move them to be declared inside the loop.
That leaves us with all the function-lifespan locals except the
sigjmp_buf itself marked as volatile, which seems like a good policy
to have going forward.
Because of the possibility of extra disable_timeout() calls, this
seems worth back-patching.
Sergey Shinderuk and Tom Lane
Discussion: https://postgr.es/m/2eda015b-7dff-47fd-d5e2-f1a9899b90a6@postgrespro.ru
M src/backend/tcop/postgres.c
Fix ALTER EXTENSION SET SCHEMA with objects outside an extension's schema
commit : d1e0f408cbe25e534c760998c109a56e7502ba05
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 10 Jul 2023 09:40:14 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 10 Jul 2023 09:40:14 +0900
As coded, the code would use as a base comparison the namespace OID from
the first object scanned in pg_depend when switching its namespace
dependency entry to the new one, and use it as a base of comparison for
any follow-up checks. It would also be used as the old namespace OID to
switch *from* for the extension's pg_depend entry. Hence, if the first
object scanned has a namespace different than the one stored in the
extension, we would finish by:
- Not checking that the extension objects map with the extension's
schema.
- Not switching the extension -> namespace dependency entry to the new
namespace provided by the user, making ALTER EXTENSION ineffective.
This issue exists since this command has been introduced in d9572c4 for
relocatable extension, so backpatch all the way down to 11. The test
case has been provided by Heikki, that I have tweaked a bit to show the
effects on pg_depend for the extension.
Reported-by: Heikki Linnakangas
Author: Michael Paquier, Heikki Linnakangas
Discussion: https://postgr.es/m/20eea594-a05b-4c31-491b-007b6fceef28@iki.fi
Backpatch-through: 11
M src/backend/commands/extension.c
Doc: update old reference to "result cache"
commit : 3883ef3236e583cd21cea1fdb469f4c13a11a82d
author : David Rowley <drowley@postgresql.org>
date : Sun, 9 Jul 2023 16:15:25 +1200
committer: David Rowley <drowley@postgresql.org>
date : Sun, 9 Jul 2023 16:15:25 +1200
During the PostgreSQL 14 cycle, the Memoize executor node was briefly
called "Result Cache" until it was renamed in 83f4fcc65. That commit
missed one reference.
Reported-by: Paul A Jungwirth
Packpatch-through: 14, where Memoize was added
Discussion: https://postgr.es/m/CA+renyX=40YXhsfPTzn13oNOPO3TJ12CK9GX-2P2pvnQiScefA@mail.gmail.com
M doc/src/sgml/config.sgml
Fix tmpdir issues with commit e213de8e78
commit : 432fbeaa522ebad417ec0104aee9bd9bd3bfc3ff
author : Andrew Dunstan <andrew@dunslane.net>
date : Sat, 8 Jul 2023 12:34:25 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sat, 8 Jul 2023 12:34:25 -0400
Commit e213de8e78 fixed a problem with path lengths to a tempdir on
Windows, but caused problems on at least some Unix systems where the
system tempdir is on a different file system. To work around this, only
used the system temdir for the destination of pg_replslot on Windows,
and otherwise restore the old behaviour.
Backpatch to relase 14 like the previous patch.
Problem exposed by a myriad of buildfarm animals.
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
Use shorter location for pg_replslot in pg_basebackup test
commit : 3e859b3d7af1b249e89d5e8e25a6f4b678624238
author : Andrew Dunstan <andrew@dunslane.net>
date : Sat, 8 Jul 2023 11:21:58 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sat, 8 Jul 2023 11:21:58 -0400
The symlink to a longer location tripped up some Windows limit on
buildfarm animal fairywren when running with meson, which uses slightly
longer paths.
Backpatch to release 14 to keep the script in sync. Before that the
script skipped all symlink related tests on Windows.
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
Fix type of iterator variable in SH_START_ITERATE
commit : d12d1a9278dfd40694ef98fe8bc9e2d07fd1000e
author : Andres Freund <andres@anarazel.de>
date : Thu, 6 Jul 2023 08:34:17 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 6 Jul 2023 08:34:17 -0700
Also add comment to make the reasoning behind the Assert() more explicit (per
Tom).
Reported-by: Ranier Vilela
Discussion: https://postgr.es/m/CAEudQAocXNJ6s1VLz+hMamLAQAiewRoW17OJ6-+9GACKfj6iPQ@mail.gmail.com
Backpatch: 11-
M src/include/lib/simplehash.h
Skip pg_baseback long filename test if path too long on Windows
commit : c0cb12f9e7b33bbcd64cc93d0811bc10e17e5452
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 6 Jul 2023 12:27:40 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 6 Jul 2023 12:27:40 -0400
On Windows, it's sometimes difficult to create a file with a path longer
than 255 chars, and if it can be created it might not be seen by the
archiver. This can be triggered by the test for tar backups with
filenames greater than 100 bytes. So we skip that test if the path would
exceed 255.
Backpatch to all live branches.
Reviewed by Daniel Gustafsson
Discussion: https://postgr.es/m/666ac55b-3400-fb2c-2cea-0281bf36a53c@dunslane.net
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
WAL-log the creation of the init fork of unlogged indexes.
commit : 25624c5d3f2907e3ffd5dee05240e3d33785915a
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 6 Jul 2023 17:25:29 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 6 Jul 2023 17:25:29 +0300
We create a file, so we better WAL-log it. In practice, all the
built-in index AMs and all extensions that I'm aware of write a
metapage to the init fork, which is WAL-logged, and replay of the
metapage implicitly creates the fork too. But if ambuildempty() didn't
write any page, we would miss it.
This can be seen with dummy_index_am. Set up replication, create a
'dummy_index_am' index on an unlogged table, and look at the files
created in the replica: the init fork is not created on the
replica. Dummy_index_am doesn't do anything with the relation files,
however, so it doesn't lead to any user-visible errors.
Backpatch to all supported versions.
Reviewed-by: Robert Haas
Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9%40iki.fi
M src/backend/catalog/index.c
Fix MarkGUCPrefixReserved() to check all options.
commit : a5f312c58d67bcad622a1582776c20643c7dd43b
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 6 Jul 2023 13:05:25 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 6 Jul 2023 13:05:25 +0300
This bug was only present on v15. MarkGUCPrefixReserved() is new in
v15, and in v16, it was rewritten to use a hash table and the new
implementation did not have this bug.
Author: Karina Litskevich, Ekaterina Sokolova
Discussion: https://www.postgresql.org/message-id/CACiT8ibqyC=_g1n6FXyFJvFW0BEjAH3_5aGqUSFeEp8GpnVrhw@mail.gmail.com
M src/backend/utils/misc/guc.c
Revert the commits related to allowing page lock to conflict among parallel group members.
commit : 907d3dd53159fb50402ec292ad60b2452c281310
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 6 Jul 2023 08:28:27 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 6 Jul 2023 08:28:27 +0530
This commit reverts the work done by commits 3ba59ccc89 and 72e78d831a.
Those commits were incorrect in asserting that we never acquire any other
heavy-weight lock after acquring page lock other than relation extension
lock. We can acquire a lock on catalogs while doing catalog look up after
acquring page lock.
This won't impact any existing feature but we need to think some other way
to achieve this before parallelizing other write operations or even
improving the parallelism in vacuum (like allowing multiple workers
for an index).
Reported-by: Jaime Casanova
Author: Amit Kapila
Backpatch-through: 13
Discussion: https://postgr.es/m/CAJKUy5jffnRKNvRHKQ0LynRb0RJC-o4P8Ku3x9vGAVLwDBWumQ@mail.gmail.com
M src/backend/optimizer/plan/planner.c
M src/backend/storage/lmgr/README
M src/backend/storage/lmgr/deadlock.c
M src/backend/storage/lmgr/lock.c
M src/backend/storage/lmgr/proc.c
Fix leak of LLVM "fatal-on-oom" section counter.
commit : fa96a74a0f76c49ac5a43a16fca8bf705fa98d99
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 5 Jul 2023 13:13:13 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 5 Jul 2023 13:13:13 +0300
llvm_release_context() called llvm_enter_fatal_on_oom(), but was missing
the corresponding llvm_leave_fatal_on_oom() call. As a result, if JIT was
used at all, we were almost always in the "fatal-on-oom" state.
It only makes a difference if you use an extension written in C++, and
run out of memory in a C++ 'new' call. In that case, you would get a
PostgreSQL FATAL error, instead of the default behavior of throwing a
C++ exception.
Back-patch to all supported versions.
Reviewed-by: Daniel Gustafsson
Discussion: https://www.postgresql.org/message-id/54b78cca-bc84-dad8-4a7e-5b56f764fab5@iki.fi
M src/backend/jit/llvm/llvmjit.c
pgstat: fix subscription stats entry leak.
commit : 66f8a139731957a7d516ade70cd3aa43d12d3c4f
author : Masahiko Sawada <msawada@postgresql.org>
date : Wed, 5 Jul 2023 14:49:53 +0900
committer: Masahiko Sawada <msawada@postgresql.org>
date : Wed, 5 Jul 2023 14:49:53 +0900
Commit 7b64e4b3 taught DropSubscription() to drop stats entry of
subscription that is not associated with a replication slot for apply
worker at DROP SUBSCRIPTION but missed covering the case where the
subscription is not associated with replication slots for both apply
worker and tablesync worker.
Also add a test to verify that the stats for slot-less subscription is
removed at DROP SUBSCRIPTION time.
Backpatch down to 15.
Author: Masahiko Sawada
Reviewed-by: Nathan Bossart, Hayato Kuroda, Melih Mutlu, Amit Kapila
Discussion: https://postgr.es/m/CAD21AoB71zkP7uPT7JDPsZcvp0749ExEQnOJxeNKPDFisHar+w@mail.gmail.com
Backpatch-through: 15
M src/backend/commands/subscriptioncmds.c
M src/test/subscription/t/026_stats.pl
Ensure that creation of an empty relfile is fsync'd at checkpoint.
commit : e24c02e4d258f8cc0305f5ec6708bceb57403276
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 4 Jul 2023 17:57:03 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 4 Jul 2023 17:57:03 +0300
If you create a table and don't insert any data into it, the relation file
is never fsync'd. You don't lose data, because an empty table doesn't have
any data to begin with, but if you crash and lose the file, subsequent
operations on the table will fail with "could not open file" error.
To fix, register an fsync request in mdcreate(), like we do for mdwrite().
Per discussion, we probably should also fsync the containing directory
after creating a new file. But that's a separate and much wider issue.
Backpatch to all supported versions.
Reviewed-by: Andres Freund, Thomas Munro
Discussion: https://www.postgresql.org/message-id/d47d8122-415e-425c-d0a2-e0160829702d%40iki.fi
M src/backend/storage/smgr/md.c
Re-bin segment when memory pages are freed.
commit : 9ffb10f183f1b7bcfbede2035fcfeeef3dee5014
author : Thomas Munro <tmunro@postgresql.org>
date : Tue, 4 Jul 2023 15:16:34 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Tue, 4 Jul 2023 15:16:34 +1200
It's OK to be lazy about re-binning memory segments when allocating,
because that can only leave segments in a bin that's too high. We'll
search higher bins if necessary while allocating next time, and
also eventually re-bin, so no memory can become unreachable that way.
However, when freeing memory, the largest contiguous range of free pages
might go up, so we should re-bin eagerly to make sure we don't leave the
segment in a bin that is too low for get_best_segment() to find.
The re-binning code is moved into a function of its own, so it can be
called whenever free pages are returned to the segment's free page map.
Back-patch to all supported releases.
Author: Dongming Liu <ldming101@gmail.com>
Reviewed-by: Robert Haas <robertmhaas@gmail.com> (earlier version)
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/CAL1p7e8LzB2LSeAXo2pXCW4%2BRya9s0sJ3G_ReKOU%3DAjSUWjHWQ%40mail.gmail.com
M src/backend/utils/mmgr/dsa.c
Fix race in SSI interaction with gin fast path.
commit : d34aa0a2f4f36e25d49d43cd1836e20f9c96899e
author : Thomas Munro <tmunro@postgresql.org>
date : Mon, 3 Jul 2023 16:20:01 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Mon, 3 Jul 2023 16:20:01 +1200
The ginfast.c code previously checked for conflicts in before locking
the relevant buffer, leaving a window where a RW conflict could be
missed. Re-order.
There was also a place where buffer ID and block number were confused
while trying to predicate-lock a page, noted by visual inspection.
Back-patch to all supported releases. Fixes one more problem discovered
with the reproducer from bug #17949, in this case when Dmitry tried
other index types.
Reported-by: Artem Anisimov <artem.anisimov.255@gmail.com>
Reported-by: Dmitry Dolgov <9erthalion6@gmail.com>
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>
Discussion: https://postgr.es/m/17949-a0f17035294a55e2%40postgresql.org
M src/backend/access/gin/ginfast.c
M src/backend/access/gin/ginget.c
Fix race in SSI interaction with bitmap heap scan.
commit : ab265e98500bfbc70b39c18a13b8ae43b34d5721
author : Thomas Munro <tmunro@postgresql.org>
date : Mon, 3 Jul 2023 16:18:20 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Mon, 3 Jul 2023 16:18:20 +1200
When performing a bitmap heap scan, we don't want to miss concurrent
writes that occurred after we observed the heap's rs_nblocks, but before
we took predicate locks on index pages. Therefore, we can't skip
fetching any heap tuples that are referenced by the index, because we
need to test them all with CheckForSerializableConflictOut(). The
old optimization that would ignore any references to blocks >=
rs_nblocks gets in the way of that requirement, because it means that
concurrent writes in that window are ignored.
Removing that optimization shouldn't affect correctness at any isolation
level, because any new tuples shouldn't be visible to an MVCC snapshot.
There also shouldn't be any error-causing references to heap blocks past
the end, because we should have held at least an AccessShareLock on the
table before the index scan. It can't get smaller while our transaction
is running. For now, though, we'll keep the optimization at lower
levels to avoid making unnecessary changes in a bug fix.
Back-patch to all supported releases. In release 11, the code is in a
different place but not fundamentally different. Fixes one aspect of
bug #17949.
Reported-by: Artem Anisimov <artem.anisimov.255@gmail.com>
Reviewed-by: Dmitry Dolgov <9erthalion6@gmail.com>
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>
Discussion: https://postgr.es/m/17949-a0f17035294a55e2%40postgresql.org
M src/backend/access/heap/heapam_handler.c
Fix race in SSI interaction with empty btrees.
commit : 0f275b0ee8e440046e7403b35d055f3cd0326c87
author : Thomas Munro <tmunro@postgresql.org>
date : Mon, 3 Jul 2023 16:16:27 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Mon, 3 Jul 2023 16:16:27 +1200
When predicate-locking btrees, we have a special case for completely
empty btrees, since there is no page to lock. This was racy, because,
without buffer lock held, a matching key could be inserted between the
_bt_search() and the PredicateLockRelation() calls.
Fix, by rechecking _bt_search() after taking the relation-level SIREAD
lock, if using SERIALIZABLE isolation and an empty btree is discovered.
Back-patch to all supported releases. Fixes one aspect of bug #17949.
Reported-by: Artem Anisimov <artem.anisimov.255@gmail.com>
Reviewed-by: Dmitry Dolgov <9erthalion6@gmail.com>
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>
Discussion: https://postgr.es/m/17949-a0f17035294a55e2%40postgresql.org
M src/backend/access/nbtree/nbtsearch.c
Remove expensive test of postgres_fdw batch inserts
commit : 23ce74811a1d10c873cdafe5b264d630e5ab74d4
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Mon, 3 Jul 2023 18:16:58 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Mon, 3 Jul 2023 18:16:58 +0200
The test inserted 70k rows into a foreign table, in order to verify
correct behavior with more than 65535 parameters, and was added in
response to a bug report.
However, this is rather expensive, especially when running the tests
under valgrind, CLOBBER_CACHE_ALWAYS etc. It doesn't seem worth it to
keep running the test, so remove it from all branches (14+).
Backpatch-through: 14
Discussion: https://postgr.es/m/2131017.1623451468@sss.pgh.pa.us
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
Improve pg_basebackup long file name test Windows robustness
commit : 86f23d90e560878b5b261c27263aba7d396b22ad
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 3 Jul 2023 10:06:26 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 3 Jul 2023 10:06:26 -0400
Creation of a file with a very long name can create problems on Windows
due to its file path limits. Work around that by creating the file via a
symlink with a shorter name.
Error displayed by buildfarm animal fairywren.o
Backpatch to all live branches
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
Make PG_TEST_NOCLEAN work for temporary directories in TAP tests
commit : 4b15868b698a78b97a270b654903204ad0ac0f42
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 3 Jul 2023 10:06:14 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 3 Jul 2023 10:06:14 +0900
When set, this environment variable was only effective for data
directories but not for all the other temporary files created by
PostgreSQL::Test::Utils. Keeping the temporary files after a successful
run can be useful for debugging purposes.
The documentation is updated to reflect the new behavior, with contents
available in doc/ since v16 and in src/test/perl/README since v15.
Author: Jacob Champion
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/CAAWbhmgHtDH1SGZ+Fw05CsXtE0mzTmjbuUxLB9mY9iPKgM6cUw@mail.gmail.com
Discussion: https://postgr.es/m/YyPd9unV14SX2bLF@paquier.xyz
Backpatch-through: 11
M src/test/perl/PostgreSQL/Test/Utils.pm
M src/test/perl/README
Silence "missing contrecord" error.
commit : f50200c0163c1dbb5aa015828e8bf32b50a2cd29
author : Thomas Munro <tmunro@postgresql.org>
date : Mon, 3 Jul 2023 10:53:44 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Mon, 3 Jul 2023 10:53:44 +1200
Commit dd38ff28ad added a new error message "missing contrecord" when
we fail to reassemble a record. Unfortunately that caused noisy
messages to be logged by pg_waldump at end of segment, and by walsender
when asked to shut down on a segment boundary.
Remove the new error message, so that this condition signals end-of-
WAL without a message. It's arguably a reportable condition that should
not be silenced while performing crash recovery, but fixing that without
introducing noise in the other cases will require more research.
Back-patch to 15.
Reported-by: Tomas Vondra <tomas.vondra@enterprisedb.com>
Discussion: https://postgr.es/m/6a1df56e-4656-b3ce-4b7a-a9cb41df8189%40enterprisedb.com
M src/backend/access/transam/xlogreader.c
Fix oversight in handling of modifiedCols since f24523672d
commit : 7ae4e786892f45af4ded23c94a26537a4b11a4c7
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 2 Jul 2023 20:29:01 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 2 Jul 2023 20:29:01 +0200
Commit f24523672d fixed a memory leak by moving the modifiedCols bitmap
into the per-row memory context. In the case of AFTER UPDATE triggers,
the bitmap is however referenced from an event kept until the end of the
query, resulting in a use-after-free bug.
Fixed by copying the bitmap into the AfterTriggerEvents memory context,
which is the one where we keep the trigger events. There's only one
place that needs to do the copy, but the memory context may not exist
yet. Doing that in a separate function seems more readable.
Report by Alexander Pyhalov, fix by me. Backpatch to 13, where the
bitmap was added to the event by commit 71d60e2aa0.
Reported-by: Alexander Pyhalov
Backpatch-through: 13
Discussion: https://postgr.es/m/acddb17c89b0d6cb940eaeda18c08bbe@postgrespro.ru
M src/backend/commands/trigger.c
Fix memory leak in Incremental Sort rescans
commit : 0c5fe4ff6b2b3daf08676d7939f1d7f3a6235212
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 2 Jul 2023 18:54:09 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 2 Jul 2023 18:54:09 +0200
The Incremental Sort had a couple issues, resulting in leaking memory
during rescans, possibly triggering OOM. The code had a couple of
related flaws:
1. During rescans, the sort states were reset but then also set to NULL
(despite the comment saying otherwise). ExecIncrementalSort then
sees NULL and initializes a new sort state, leaking the memory used
by the old one.
2. Initializing the sort state also automatically rebuilt the info about
presorted keys, leaking the already initialized info. presorted_keys
was also unnecessarily reset to NULL.
Patch by James Coleman, based on patches by Laurenz Albe and Tom Lane.
Backpatch to 13, where Incremental Sort was introduced.
Author: James Coleman, Laurenz Albe, Tom Lane
Reported-by: Laurenz Albe, Zu-Ming Jiang
Backpatch-through: 13
Discussion: https://postgr.es/m/b2bd02dff61af15e3526293e2771f874cf2a3be7.camel%40cybertec.at
Discussion: https://postgr.es/m/db03c582-086d-e7cd-d4a1-3bc722f81765%40inf.ethz.ch
M src/backend/executor/nodeIncrementalSort.c
Fix marking of indisvalid for partitioned indexes at creation
commit : cb4ac3e5685f823e79aaa8508edef86d48718bea
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 30 Jun 2023 13:54:55 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 30 Jun 2023 13:54:55 +0900
The logic that introduced partitioned indexes missed a few things when
invalidating a partitioned index when these are created, still the code
is written to handle recursions:
1) If created from scratch because a mapping index could not be found,
the new index created could be itself invalid, if for example it was a
partitioned index with one of its leaves invalid.
2) A CCI was missing when indisvalid is set for a parent index, leading
to inconsistent trees when recursing across more than one level for a
partitioned index creation if an invalidation of the parent was
required.
This could lead to the creation of a partition index tree where some of
the partitioned indexes are marked as invalid, but some of the parents
are marked valid, which is not something that should happen (as
validatePartitionedIndex() defines, indisvalid is switched to true for a
partitioned index iff all its partitions are themselves valid).
This patch makes sure that indisvalid is set to false on a partitioned
index if at least one of its partition is invalid. The flag is set to
true if *all* its partitions are valid.
The regression test added in this commit abuses of a failed concurrent
index creation, marked as invalid, that maps with an index created on
its partitioned table afterwards.
Reported-by: Alexander Lakhin
Reviewed-by: Alexander Lakhin
Discussion: https://postgr.es/m/14987634-43c0-0cb3-e075-94d423607e08@gmail.com
Backpatch-through: 11
M src/backend/commands/indexcmds.c
M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql
Fix pg_depend entry to AMs after ALTER TABLE .. SET ACCESS METHOD
commit : 93401ec02f40dd85dd98147b883b158ebf5648c9
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 30 Jun 2023 07:49:07 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 30 Jun 2023 07:49:07 +0900
ALTER TABLE .. SET ACCESS METHOD was not registering a dependency to the
new access method with the relation altered in its rewrite phase, making
possible the drop of an access method even if there are relations that
depend on it. During the rewrite, a temporary relation is created to
build the new relation files before swapping the new and old files, and,
while the temporary relation was registering a correct dependency to the
new AM, the old relation did not do that. A dependency on the access
method is added when the relation files are swapped, which is the point
where pg_class is updated.
Materialized views and tables use the same code path, hence both were
impacted.
Backpatch down to 15, where this command has been introduced.
Reported-by: Alexander Lakhin
Reviewed-by: Nathan Bossart, Andres Freund
Discussion: https://postgr.es/m/18000-9145c25b1af475ca@postgresql.org
Backpatch-through: 15
M src/backend/commands/cluster.c
M src/test/regress/expected/create_am.out
M src/test/regress/sql/create_am.sql
Fix order of operations in ExecEvalFieldStoreDeForm().
commit : cc8cca3c2d6061295c72f19f81fdaa774a208bca
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 29 Jun 2023 10:19:10 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 29 Jun 2023 10:19:10 -0400
If the given composite datum is toasted out-of-line,
DatumGetHeapTupleHeader will perform database accesses to detoast it.
That can invalidate the result of get_cached_rowtype, as documented
(perhaps not plainly enough) in that function's API spec; which leads
to strange errors or crashes when we try to use the TupleDesc to read
the tuple. In short then, trying to update a field of a composite
column could fail intermittently if the overall column value is wide
enough to require toasting.
We can fix the bug at no cost by just changing the order of
operations, since we don't need the TupleDesc until after detoasting.
(Other callers of get_cached_rowtype appear to get this right already,
so there's only one bug.)
Note that the added regression test case reveals this bug reliably
only with debug_discard_caches/CLOBBER_CACHE_ALWAYS.
Per bug #17994 from Alexander Lakhin. Sadly, this patch does not fix
the missing-values issue revealed in the bug discussion; we'll need
some more work to cover that.
Discussion: https://postgr.es/m/17994-5c7100b51b4790e9@postgresql.org
M src/backend/executor/execExprInterp.c
M src/test/regress/expected/rowtypes.out
M src/test/regress/sql/rowtypes.sql
Remove inappropriate raw_expression_tree_walker() code
commit : df5dcf41cf01af158d2b833a0ae752e52f5d38e8
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 29 Jun 2023 10:30:55 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 29 Jun 2023 10:30:55 +0200
It was walking into the ColumnDef->compression field, which is not a
node but a string. This code is currently not reachable (because the
compression field is only set in situations that don't go through
raw_expression_tree_walker()), but if it had been, this could have
behaved erratically.
M src/backend/nodes/nodeFuncs.c
pg_stat_statements: Fix second comment related to entry resets
commit : e886124647ce88681ee09dda9a94dd03140c664b
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 29 Jun 2023 09:17:30 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 29 Jun 2023 09:17:30 +0900
This should have been part of dc73db6, but it got lost in the mix.
Oversight in 6b4d23f.
Author: Japin Li
Discussion: https://postgr.es/m/MEYP282MB1669FC91C764E277821936D3B624A@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
Backpatch-through: 14
M contrib/pg_stat_statements/pg_stat_statements.c
pg_stat_statements: Fix incorrect comment with entry resets
commit : a757e16b7e7c20a89f9fc6269b63ddbc06f7a785
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 29 Jun 2023 08:05:06 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 29 Jun 2023 08:05:06 +0900
Oversight in 6b4d23f.
Author: Japin Li, Richard Guo
Discussion: https://postgr.es/m/MEYP282MB1669FC91C764E277821936D3B624A@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
Backpatch-through: 14
M contrib/pg_stat_statements/pg_stat_statements.c
Ignore invalid indexes when enforcing index rules in ALTER TABLE ATTACH PARTITION
commit : 7aa17b498b6349954e9386dbbe06db9959bf9d26
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 28 Jun 2023 15:57:43 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 28 Jun 2023 15:57:43 +0900
A portion of ALTER TABLE .. ATTACH PARTITION is to ensure that the
partition being attached to the partitioned table has a correct set of
indexes, so as there is a consistent index mapping between the
partitioned table and its new-to-be partition. However, as introduced
in 8b08f7d, the current logic could choose an invalid index as a match,
which is something that can exist when dealing with more than two levels
of partitioning, like attaching a partitioned table (that has
partitions, with an index created by CREATE INDEX ON ONLY) to another
partitioned table.
A partitioned index with indisvalid set to false is equivalent to an
incomplete partition tree, meaning that an invalid partitioned index
does not have indexes defined in all its partitions. Hence, choosing an
invalid partitioned index can create inconsistent partition index trees,
where the parent attaching to is valid, but its partition may be
invalid.
In the report from Alexander Lakhin, this showed up as an assertion
failure when validating an index. Without assertions enabled, the
partition index tree would be actually broken, as indisvalid should
be switched to true for a partitioned index once all its partitions are
themselves valid. With two levels of partitioning, the top partitioned
table used a valid index and was able to link to an invalid index stored
on its partition, itself a partitioned table.
I have studied a few options here (like the possibility to switch
indisvalid to false for the parent), but came down to the conclusion
that we'd better rely on a simple rule: invalid indexes had better never
be chosen, so as the partition attached uses and creates indexes that
the parent expects. Some regression tests are added to provide some
coverage. Note that the existing coverage is not impacted.
This is a problem since partitioned indexes exist, so backpatch all the
way down to v11.
Reported-by: Alexander Lakhin
Discussion: https://postgr.es/14987634-43c0-0cb3-e075-94d423607e08@gmail.com
Backpatch-through: 11
M src/backend/commands/tablecmds.c
M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql
Fix comment on clearing padding.
commit : 596177a9222f5a093679fe6ac05876444057fe6f
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 27 Jun 2023 10:11:31 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 27 Jun 2023 10:11:31 +0300
Author: Japin Li
Discussion: https://www.postgresql.org/message-id/MEYP282MB16696317B5DA7D0D92306149B627A@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
M contrib/pg_stat_statements/pg_stat_statements.c
Check for interrupts and stack overflow in TParserGet().
commit : a77d901714416f6bd4343c367585b060f385bbbc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jun 2023 17:18:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 24 Jun 2023 17:18:08 -0400
TParserGet() recurses for some token types, meaning it's possible
to drive it to stack overflow. Since this is a minority behavior,
I chose to add the check_stack_depth() call to the two places that
recurse rather than doing it during every single call.
While at it, add CHECK_FOR_INTERRUPTS(), because this can run
unpleasantly long for long inputs.
Per bug #17995 from Zuming Jiang. This is old, so back-patch
to all supported branches.
Discussion: https://postgr.es/m/17995-9f20ff3e6389db4c@postgresql.org
M src/backend/tsearch/wparser_def.c
doc: rename "decades" to be more generic
commit : f08faee4b94504e30b21ce85bda459f6e5281145
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 23 Jun 2023 22:50:55 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 23 Jun 2023 22:50:55 -0400
Reported-by: Michael Paquier
Discussion: https://postgr.es/m/ZJTzwD2rTbHWWQ9g@paquier.xyz
Backpatch-through: 11
M doc/src/sgml/history.sgml
Fix incorrect error message in libpq_pipeline
commit : 4fd633df5080ef45b1a1665e6599463aad42305a
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Jun 2023 17:50:23 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Jun 2023 17:50:23 +0900
One of the tests for the pipeline mode with portal description expects a
non-NULL PQgetResult, but used an incorrect error message on failure,
telling that PQgetResult being NULL was the expected result.
Author: Jelte Fennema
Discussion: https://postgr.es/m/CAGECzQTkShHecFF+EZrm94Lbsu2ej569T=bz+PjMbw9Aiioxuw@mail.gmail.com
Backpatch-through: 14
M src/test/modules/libpq_pipeline/libpq_pipeline.c
Doc: Clarify the behavior of triggers/rules in a logical subscriber.
commit : 8aac6140c8ac44fe34ad8242e37d8f94e0156c49
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 22 Jun 2023 12:35:10 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 22 Jun 2023 12:35:10 +0530
By default, triggers and rules do not fire on a logical replication
subscriber based on the "session_replication_role" GUC being set to
"replica". However, the docs in the logical replication section assumed
that the reader understood how this GUC worked. This modifies the docs to
be more explicit and links back to the GUC itself.
Author: Jonathan Katz, Peter Smith
Reviewed-by: Vignesh C, Euler Taveira
Backpatch-through: 11
Discussion: https://postgr.es/m/5bb2c9a2-499f-e1a2-6e33-5ce96b35cc4a@postgresql.org
M doc/src/sgml/logical-replication.sgml
Doc: mention that extended stats aren't used for joins
commit : 4e17cb00dc2b57f0ac1bbe3c1fd587e982b33307
author : David Rowley <drowley@postgresql.org>
date : Thu, 22 Jun 2023 12:47:15 +1200
committer: David Rowley <drowley@postgresql.org>
date : Thu, 22 Jun 2023 12:47:15 +1200
Statistics defined by the CREATE STATISTICS command are only used to
assist with the selectivity estimations of base relations, never for
joins. Here we mention this fact in the notes section of the CREATE
STATISTICS command.
Discussion: https://postgr.es/m/CAApHDvrMuVgDOrmg_EtFDZ=AOovq6EsJNnHH1ddyZ8EqL4yzMw@mail.gmail.com
Backpatch-through: 11
M doc/src/sgml/ref/create_statistics.sgml
nbtree VACUUM: cope with topparent inconsistencies.
commit : 642bec1f8dd2e05b769a4ed3b42ef0fe57804647
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 21 Jun 2023 17:41:56 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 21 Jun 2023 17:41:56 -0700
Avoid "right sibling %u of block %u is not next child" errors when
vacuuming a corrupt nbtree index. Just LOG the issue and press on.
That way VACUUM will have a decent chance of finishing off all required
processing for the index (and for the table as a whole).
This is similar to recent work from commit 5abff197, as well as work
from commit 5b861baa (later backpatched as commit 43e409ce), which
taught nbtree VACUUM to keep going when its "re-find" check fails. The
hardening added by this commit takes place directly after the "re-find"
check, right before the critical section for the first stage of page
deletion.
Author: Peter Geoghegan <pg@bowt.ie>
Discussion: https://postgr.es/m/CAH2-Wz=dayg0vjs4+er84TS9ami=csdzjpuiCGbEw=idhwqhzQ@mail.gmail.com
Backpatch: 11- (all supported versions).
M src/backend/access/nbtree/nbtpage.c
doc: update PG history as over "three decades"
commit : 10fa5c425b5854bdde5a00e606e870af5c71ab8f
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 21 Jun 2023 19:20:07 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 21 Jun 2023 19:20:07 -0400
Reported-by: Pierre <pbaumard@gmail.com>
Discussion: https://postgr.es/m/168724660637.399156.7642965215720120947@wrigleys.postgresql.org
Backpatch-through: 11
M doc/src/sgml/history.sgml
Avoid Assert failure when processing empty statement in aborted xact.
commit : cb74f7bec64f3333efa4227f804f72a3c353cd08
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Jun 2023 11:07:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Jun 2023 11:07:11 -0400
exec_parse_message() wants to create a cached plan in all cases,
including for empty input. The empty-input path does not have
a test for being in an aborted transaction, making it possible
that plancache.c will fail due to trying to do database lookups
even though there's no real work to do.
One solution would be to throw an aborted-transaction error in
this path too, but it's not entirely clear whether the lack of
such an error was intentional or whether some clients might be
relying on non-error behavior. Instead, let's hack plancache.c
so that it treats empty statements with the same logic it
already had for transaction control commands, ensuring that it
can soldier through even in an already-aborted transaction.
Per bug #17983 from Alexander Lakhin. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/17983-da4569fcb878672e@postgresql.org
M src/backend/utils/cache/plancache.c
M src/test/regress/expected/psql.out
M src/test/regress/sql/psql.sql
Disable use of archiving in 009_twophase.pl
commit : bd78702ea17e2ff630d718071e26070eff13d750
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 21 Jun 2023 16:16:20 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 21 Jun 2023 16:16:20 +0900
This partially reverts 68cb5af, as using archiving to enforce the
rename of the last partial segment of the old timeline at promotion to
use .partial as suffix is impacting the tests when it does switchovers.
As showed by the logs gathered by the CI in the tests that failed, a new
standby may fail to find the WAL segment it needs to follow a promoted
instance with its timeline jump, as it got renamed to .partial.
This problem would manifest as a run timeout with 009_twophase.pl, as
the new standby repeatedly requests a segment from the promoted primary
that it would not find.
Reported-by: Nathan Bossart
Discussion: https://postgr.es/m/20230621043345.GA787473@nathanxps13
Backpatch-through: 13
M src/test/recovery/t/009_twophase.pl
Fix the errhint message and docs for drop subscription failure.
commit : fd079193d24ce81fdc31fbba687cadc70609c44d
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 21 Jun 2023 10:24:41 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 21 Jun 2023 10:24:41 +0530
The existing errhint message and docs were missing the fact that we can't
disassociate from the slot unless the subscription is disabled.
Author: Robert Sjöblom, Peter Smith
Reviewed-by: Peter Eisentraut, Amit Kapila
Backpatch-through: 11
Discussion: https://postgr.es/m/807bdf85-61ea-88e2-5712-6d9fcd4eabff@fortnox.se
M doc/src/sgml/ref/drop_subscription.sgml
M src/backend/commands/subscriptioncmds.c
Fix hash join when inner hashkey expressions contain Params.
commit : c2f974fffbecbbc10d302f69c9f4af80f0c9cd7b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 20 Jun 2023 17:47:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 20 Jun 2023 17:47:36 -0400
If the inner-side expressions contain PARAM_EXEC Params, we must
re-hash whenever the values of those Params change. The executor
mechanism for that exists already, but we failed to invoke it because
finalize_plan() neglected to search the Hash.hashkeys field for
Params. This allowed a previous scan's hash table to be re-used
when it should not be, leading to rows missing from the join's output.
(I believe incorrectly-included join rows are impossible however,
since checking the real hashclauses would reject false matches.)
This bug is very ancient, dating probably to d24d75ff1 of 7.4.
Sadly, this simple fix depends on the plan representational changes
made by 2abd7ae9b, so it will only work back to v12. I thought
about trying to make some kind of hack for v11, but I'm leery
of putting code significantly different from what is used in the
newer branches into a nearly-EOL branch. Seeing that the bug
escaped detection for a full twenty years, problematic cases
must be rare; so I don't feel too awful about leaving v11 as-is.
Per bug #17985 from Zuming Jiang. Back-patch to v12.
Discussion: https://postgr.es/m/17985-748b66607acd432e@postgresql.org
M src/backend/optimizer/plan/subselect.c
M src/test/regress/expected/join_hash.out
M src/test/regress/sql/join_hash.sql
docs: adjust tag indenting and add MERGE mention
commit : 39abe1401e3180a336424c30ece949607322f4a6
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 20 Jun 2023 16:25:59 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 20 Jun 2023 16:25:59 -0400
Discussion: https://postgr.es/m/CAMpnoC4_WsY3gsY+ud-Z0GDbafR=K7t7cXn2gatEqFnsRNY3yQ@mail.gmail.com
Author: Will Mortensen
Backpatch-through: 15
M doc/src/sgml/mvcc.sgml
Enable archiving in recovery TAP test 009_twophase.pl
commit : a10be37254fe06ca0d16f34d2fd5933d3adfa66e
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 20 Jun 2023 10:25:41 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 20 Jun 2023 10:25:41 +0900
This is a follow-up of f663b00, that has been committed to v13 and v14,
tweaking the TAP test for two-phase transactions so as it provides
coverage for the bug that has been fixed. This change is done in its
own commit for clarity, as v15 and HEAD did not show the problematic
behavior, still missed coverage for it.
While on it, this adds a comment about the dependency of the last
partial segment rename and RecoverPreparedTransactions() at the end of
recovery, as that can be easy to miss.
Author: Michael Paquier
Reviewed-by: Kyotaro Horiguchi
Discussion: https://postgr.es/m/743b9b45a2d4013bd90b6a5cba8d6faeb717ee34.camel@cybertec.at
Backpatch-through: 13
M src/backend/access/transam/xlog.c
M src/test/recovery/t/009_twophase.pl
Don't use partial unique indexes for unique proofs in the planner
commit : 8f2ec8cc7e3de918988a49302dddc64deca16c02
author : David Rowley <drowley@postgresql.org>
date : Mon, 19 Jun 2023 13:01:29 +1200
committer: David Rowley <drowley@postgresql.org>
date : Mon, 19 Jun 2023 13:01:29 +1200
Here we adjust relation_has_unique_index_for() so that it no longer makes
use of partial unique indexes as uniqueness proofs. It is incorrect to
use these as the predicates used by check_index_predicates() to set
predOK makes use of not only baserestrictinfo quals as proofs, but also
qual from join conditions. For relation_has_unique_index_for()'s case, we
need to know the relation is unique for a given set of columns before any
joins are evaluated, so if predOK was only set to true due to some join
qual, then it's unsafe to use such indexes in
relation_has_unique_index_for(). The final plan may not even make use
of that index, which could result in reading tuples that are not as
unique as the planner previously expected them to be.
Bug: #17975
Reported-by: Tor Erik Linnerud
Backpatch-through: 11, all supported versions
Discussion: https://postgr.es/m/17975-98a90c156f25c952%40postgresql.org
M src/backend/optimizer/path/indxpath.c
M src/backend/optimizer/plan/analyzejoins.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix typo in comment.
commit : 35470357ee4c6f05b78926d3e07a45d8712f3130
author : Amit Langote <amitlan@postgresql.org>
date : Fri, 16 Jun 2023 10:04:22 +0900
committer: Amit Langote <amitlan@postgresql.org>
date : Fri, 16 Jun 2023 10:04:22 +0900
Back-patch down to 11.
Author: Sho Kato (<kato-sho@fujitsu.com>)
Discussion: https://postgr.es/m/TYCPR01MB68499042A33BC32241193AAF9F5BA%40TYCPR01MB6849.jpnprd01.prod.outlook.com
M src/backend/rewrite/rewriteHandler.c
intarray: Prevent out-of-bound memory reads with gist__int_ops
commit : 4be308edee4495fe72075397efa0f6e0e0f9693b
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 15 Jun 2023 13:45:38 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 15 Jun 2023 13:45:38 +0900
As gist__int_ops stands in intarray, it is possible to store GiST
entries for leaf pages that can cause corruptions when decompressed.
Leaf nodes are stored as decompressed all the time by the compression
method, and the decompression method should map with that, retrieving
the contents of the page without doing any decompression. However, the
code authorized the insertion of leaf page data with a higher number of
array items than what can be supported, generating a NOTICE message to
inform about this matter (199 for a 8k page, for reference). When
calling the decompression method, a decompression would be attempted on
this leaf node item but the contents should be retrieved as they are.
The NOTICE message generated when dealing with the compression of a leaf
page and too many elements in the input array for gist__int_ops has been
introduced by 08ee64e, removing the marker stored in the array to track
if this is actually a leaf node. However, it also missed the fact that
the decompression path should do nothing for a leaf page. Hence, as the
code stand, a too-large array would be stored as uncompressed but the
decompression path would attempt a decompression rather that retrieving
the contents as they are.
This leads to various problems. First, even if 08ee64e tried to address
that, it is possible to do out-of-bound chunk writes with a large input
array, with the backend informing about that with WARNINGs. On
decompression, retrieving the stored leaf data would lead to incorrect
memory reads, leading to crashes or even worse.
Perhaps somebody would be interested in expanding the number of array
items that can be handled in a leaf page for this operator in the
future, which would require revisiting the choice done in 08ee64e, but
based on the lack of reports about this problem since 2005 it does not
look so. For now, this commit prevents the insertion of data for leaf
pages when using more array items that the code can handle on
decompression, switching the NOTICE message to an ERROR. If one wishes
to use more array items, gist__intbig_ops is an optional choice.
While on it, use ERRCODE_PROGRAM_LIMIT_EXCEEDED as error code when a
limit is reached, because that's what the module is facing in such
cases.
Author: Ankit Kumar Pandey, Alexander Lakhin
Reviewed-by: Richard Guo, Michael Paquier
Discussion: https://postgr.es/m/796b65c3-57b7-bddf-b0d5-a8afafb8b627@gmail.com
Discussion: https://postgr.es/m/17888-f72930e6b5ce8c14@postgresql.org
Backpatch-through: 11
M contrib/intarray/_int_gist.c
M contrib/intarray/expected/_int.out
M contrib/intarray/sql/_int.sql
Fix make_etags breakage on certain platforms.
commit : af26f28b9fdd610a7b6dfc5f2d3a2f7b324faa77
author : Tatsuo Ishii <ishii@postgresql.org>
date : Wed, 14 Jun 2023 11:11:18 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Wed, 14 Jun 2023 11:11:18 +0900
make_etags produced wrong format TAGS files on platforms such as Mac,
which uses non-Exuberant ctags.
Author: Masahiko Sawada
Reviewed-by: Tatsuo Ishii
Backpatch-through: 15
Discussion: https://postgr.es/m/CAD21AoDmCqpS%2BU6b9Bc-b4OFx3tz%3DNv6O2KVkoVg7sHk60spjA%40mail.gmail.com
M src/tools/make_ctags
Correctly update hasSubLinks while mutating a rule action.
commit : cc6974df16e0dfb106c4caefd9d42d332a04247d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Jun 2023 15:58:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Jun 2023 15:58:37 -0400
rewriteRuleAction neglected to check for SubLink nodes in the
securityQuals of range table entries. This could lead to failing
to convert such a SubLink to a SubPlan, resulting in assertion
crashes or weird errors later in planning.
In passing, fix some poor coding in rewriteTargetView:
we should not pass the source parsetree's hasSubLinks
field to ReplaceVarsFromTargetList's outer_hasSubLinks.
ReplaceVarsFromTargetList knows enough to ignore that
when a Query node is passed, but it's still confusing
and bad precedent: if we did try to update that flag
we'd be updating a stale copy of the parsetree.
Per bug #17972 from Alexander Lakhin. This has been broken since
we added RangeTblEntry.securityQuals (although the presented test
case only fails back to 215b43cdc), so back-patch all the way.
Discussion: https://postgr.es/m/17972-f422c094237847d0@postgresql.org
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql
Accept fractional seconds in jsonpath's datetime() method.
commit : bd590d1fea1ba9245c791d589eea94d2dbad5a2b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Jun 2023 10:54:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Jun 2023 10:54:28 -0400
Commit 927d9abb6 purported to make datetime() accept any string
that could be output for a datetime value by to_jsonb(). But it
overlooked the possibility of fractional seconds being present,
so that cases as simple as to_jsonb(now()) would defeat it.
Fix by adding formats that include ".US" to the list in
executeDateTimeMethod(). (Note that while this is nominally
microseconds, it'll do the right thing for fractions with
fewer than six digits.)
In passing, re-order the list to restore the datatype ordering
specified in its comment. The violation accidentally did not
break anything; but the next edit might be less lucky, so add
more comments.
Per report from Tim Field. Back-patch to v13 where datetime()
was added, like the previous patch.
Discussion: https://postgr.es/m/014A028B-5CE6-4FDF-AC24-426CA6FC9CEE@mohiohio.com
M src/backend/utils/adt/jsonpath_exec.c
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/sql/jsonb_jsonpath.sql
hstore: Tighten key/value parsing check for whitespaces
commit : 3a5222a432beeb980208a2d9abeb517412f4d469
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 12 Jun 2023 09:14:13 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 12 Jun 2023 09:14:13 +0900
isspace() can be locale-sensitive depending on the platform, causing
hstore to consider as whitespaces characters it should not see as such.
For example, U+0105, being decoded as 0xC4 0x85 in UTF-8, would be
discarded from the input given.
This problem is similar to 9ae2661, though it was missed that hstore
can also manipulate non-ASCII inputs, so replace the existing isspace()
calls with scanner_isspace().
This problem exists for a long time, so backpatch all the way down.
Author: Evan Jones
Discussion: https://postgr.es/m/CA+HWA9awUW0+RV_gO9r1ABZwGoZxPztcJxPy8vMFSTbTfi4jig@mail.gmail.com
Backpatch-through: 11
M contrib/hstore/Makefile
A contrib/hstore/expected/hstore_utf8.out
A contrib/hstore/expected/hstore_utf8_1.out
M contrib/hstore/hstore_io.c
A contrib/hstore/sql/hstore_utf8.sql
Refactor routine to find single log content pattern in TAP tests
commit : e25e5f7fc6b74c9d4ce82627e9145ef5537412e2
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 9 Jun 2023 11:56:33 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 9 Jun 2023 11:56:33 +0900
The same routine to check if a specific pattern can be found in the
server logs was copied over four different test scripts. This refactors
the whole to use a single routine located in PostgreSQL::Test::Cluster,
named log_contains, to grab the contents of the server logs and check
for a specific pattern.
On HEAD, the code previously used assumed that slurp_file() could not
handle an undefined offset, setting it to zero, but slurp_file() does
do an extra fseek() before retrieving the log contents only if an offset
is defined. In two places, the test was retrieving the full log
contents with slurp_file() after calling substr() to apply an offset,
ignoring that slurp_file() would be able to handle that.
Backpatch all the way down to ease the introduction of new tests that
could rely on the new routine.
Author: Vignesh C
Reviewed-by: Andrew Dunstan, Dagfinn Ilmari Mannsåker, Michael Paquier
Discussion: https://postgr.es/m/CALDaNm0YSiLpjCmajwLfidQrFOrLNKPQir7s__PeVvh9U3uoTQ@mail.gmail.com
Backpatch-through: 11
M src/test/perl/PostgreSQL/Test/Cluster.pm
M src/test/recovery/t/019_replslot_limit.pl
M src/test/recovery/t/033_replay_tsp_drops.pl
Refactor log check logic for connect_ok/fails in PostgreSQL::Test::Cluster
commit : 7fa7911c7675a4a9d5b36c50cb486b0fd6ca3bfb
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 9 Jun 2023 09:37:26 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 9 Jun 2023 09:37:26 +0900
This commit refactors a bit the code in charge of checking for log
patterns when connections fail or succeed, by moving the log pattern
checks into their own routine, for clarity. This has come up as
something to improve while discussing the refactoring of find_in_log().
Backpatch down to 14 where these routines are used, to ease the
introduction of new tests that could rely on them.
Author: Vignesh C, Michael Paquier
Discussion: https://postgr.es/m/CALDaNm0YSiLpjCmajwLfidQrFOrLNKPQir7s__PeVvh9U3uoTQ@mail.gmail.com
Backpatch-through: 14
M src/test/perl/PostgreSQL/Test/Cluster.pm
doc: Fix example command for ALTER FOREIGN TABLE ... OPTIONS.
commit : 0d3093f475605b4dd788a6016be5f96daca6b3f5
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 8 Jun 2023 20:11:52 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 8 Jun 2023 20:11:52 +0900
In the documentation, previously the example command for
ALTER FOREIGN TABLE ... OPTIONS incorrectly included both
the option name and value with the DROP operation.
The correct syntax for the DROP operation requires only
the name of the option to be specified. This commit fixes
the example by removing the option value from the DROP operation.
Back-patch to all supported versions.
Author: Mehmet Emin KARAKAS <emin100@gmail.com>
Reviewed-by: Fujii Masao
Discussion: https://postgr.es/m/CANQrdXAHzbcEYhjGoe5A42OmfvdQhHFJzyKj9gJvHuDKyOF5Ng@mail.gmail.com
M doc/src/sgml/ref/alter_foreign_table.sgml
Use per-tuple context in ExecGetAllUpdatedCols
commit : ee87f8b63aee39673d014e4ee9a1293b0b45d113
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 7 Jun 2023 16:48:50 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 7 Jun 2023 16:48:50 +0200
Commit fc22b6623b (generated columns) replaced ExecGetUpdatedCols() with
ExecGetAllUpdatedCols() in a couple places handling UPDATE (triggers and
lock mode). However, ExecGetUpdatedCols() did exec_rt_fetch() while
ExecGetAllUpdatedCols() also allocates memory through bms_union()
without paying attention to the memory context and happened to use the
long-lived ExecutorState, leaking the memory until the end of the query.
The amount of leaked memory is proportional to the number of (updated)
attributes, types of UPDATE triggers, and the number of processed rows
(which for UPDATE ... FROM ... may be much higher than updated rows).
Fixed by switching to the per-tuple context in GetAllUpdatedColumns().
This is fine for all in-core callers, but external callers may need to
copy the result. But we're not aware of any such callers.
Note the issue was introduced by fc22b6623b, but the macros were later
renamed by f50e888990.
Backpatch to 12, where the issue was introduced.
Reported-by: Tomas Vondra
Reviewed-by: Andres Freund, Tom Lane, Jakub Wartak
Backpatch-through: 12
Discussion: https://postgr.es/m/222a3442-7f7d-246c-ed9b-a76209d19239@enterprisedb.com
M src/backend/executor/execUtils.c
Initialize 'recordXtime' to silence compiler warning.
commit : 2a7fb520755f9132e0e9db7b4868887ac1af55bd
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 6 Jun 2023 20:30:53 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 6 Jun 2023 20:30:53 +0300
In reality, recordXtime will always be set by the getRecordTimestamp
call, but the compiler doesn't necessarily see that.
Back-patch to all supported versions.
Author: Tristan Partin
Discussion: https://www.postgresql.org/message-id/CT5MN8E11U0M.1NYNCHXYUHY41@gonk
M src/backend/access/transam/xlogrecovery.c
Doc: explain about dependency tracking for new-style SQL functions.
commit : 0aa5e4af1bda2d55f31c2f70fa09a188985d8d4a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Jun 2023 13:27:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Jun 2023 13:27:34 -0400
5.14 Dependency Tracking was not updated when we added new-style
SQL functions. Improve that.
Noted by Sami Imseih. Back-patch to v14 where
new-style SQL functions came in.
Discussion: https://postgr.es/m/2C1933AB-C2F8-499B-9D18-4AC1882256A0@amazon.com
M doc/src/sgml/ddl.sgml
Fix pg_dump's failure to honor dependencies of SQL functions.
commit : ca9e79274938d8ede07d9990c2f6f5107553b524
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Jun 2023 13:05:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Jun 2023 13:05:54 -0400
A new-style SQL function can contain a parse-time dependency
on a unique index, much as views and matviews can (such cases
arise from GROUP BY and ON CONFLICT clauses, for example).
To dump and restore such a function successfully, pg_dump must
postpone the function until after the unique index is created,
which will happen in the post-data part of the dump. Therefore
we have to remove the normal constraint that functions are
dumped in pre-data. Add code similar to the existing logic
that handles this for matviews. I added test cases for both
as well, since code coverage tests showed that we weren't
testing the matview logic.
Per report from Sami Imseih. Back-patch to v14 where
new-style SQL functions came in.
Discussion: https://postgr.es/m/2C1933AB-C2F8-499B-9D18-4AC1882256A0@amazon.com
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/bin/pg_dump/pg_dump_sort.c
M src/bin/pg_dump/t/002_pg_dump.pl
Fix misuse of pg_log_info() for details/hints.
commit : 751ba1a7c168b28a3cc43032e9a1cc996e004054
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Jun 2023 11:22:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Jun 2023 11:22:05 -0400
Two places in pg_dump_sort.c were using pg_log_info() to add
more details to a message printed with pg_log_warning().
This is bad, because at default verbosity level we would
print the warning line but not the details. One should use
pg_log_warning_detail() or pg_log_warning_hint() instead.
Commit 9a374b77f got rid of most such abuses, but unaccountably
missed these.
Noted while studying a bug report from Sami Imseih.
Back-patch to v15 where 9a374b77f came in. (Prior versions
don't have the missing-details misbehavior, for reasons
I didn't bother to track down.)
Discussion: https://postgr.es/m/2C1933AB-C2F8-499B-9D18-4AC1882256A0@amazon.com
M src/bin/pg_dump/pg_dump_sort.c
doc: add missing "the" in LATERAL sentence.
commit : 0d6fffb4f0b55357e68e8908acd9cf8dc4e178f2
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 1 Jun 2023 10:22:16 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 1 Jun 2023 10:22:16 -0400
Backpatch-through: 11
M doc/src/sgml/queries.sgml
nbtree VACUUM: cope with right sibling link corruption.
commit : 6983a511288cca3ed0c40f7e5f71c4c94010293a
author : Peter Geoghegan <pg@bowt.ie>
date : Thu, 25 May 2023 15:32:57 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Thu, 25 May 2023 15:32:57 -0700
Avoid "right sibling's left-link doesn't match" errors when vacuuming a
corrupt nbtree index. Just LOG the issue and press on. That way VACUUM
will have a decent chance of finishing off all required processing for
the index (and for the table as a whole).
This error was seen in the field from time to time (it's more than a
theoretical risk), so giving VACUUM the ability to press on like this
has real value. Nothing short of a REINDEX is expected to fix the
underlying index corruption, so giving up (by throwing an error) risks
making a bad situation far worse. Anything that blocks forward progress
by VACUUM like this might go unnoticed for a long time. This could
eventually lead to a wraparound/xidStopLimit outage.
Note that _bt_unlink_halfdead_page() has always been able to bail on
page deletion when the target page's left sibling page was in an
inconsistent state. It now does the same thing (returns false to back
out of the second phase of deletion) when it notices sibling link
corruption in the target page's right sibling page.
This is similar to the work from commit 5b861baa (later backpatched as
commit 43e409ce), which taught nbtree to press on with vacuuming an
index when page deletion fails to "re-find" a downlink in the target
page's parent page. The "re-find" check seems to make VACUUM bail on
page deletion more often in practice, but there is no reason to take any
chances here.
Author: Peter Geoghegan <pg@bowt.ie>
Reviewed-By: Heikki Linnakangas <hlinnaka@iki.fi>
Discussion: https://postgr.es/m/CAH2-Wzko2q2kP1+UvgJyP9g0mF4hopK0NtQZcxwvMv9_ytGhkQ@mail.gmail.com
Backpatch: 11- (all supported versions).
M src/backend/access/nbtree/nbtpage.c
M src/backend/access/nbtree/nbtree.c
doc: Fix example query for pg_walinspect
commit : 803a504342d7e41cd5a2ffea7fbcc20900fd1d0d
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Thu, 25 May 2023 12:43:16 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Thu, 25 May 2023 12:43:16 +0200
The LIMIT clause had ended up in the wrong place in the query.
Backpatch to v15 where pg_walinspect was introduced.
Reported-by: Jian He <jian.universality@gmail.com>
Discussion: https://postgr.es/m/CACJufxHqXDr4NnmwmR6pEiVPAg54J0dgwMuYQzrH5BX6+NtF1g@mail.gmail.com
Backpatch-through: 15
M doc/src/sgml/pgwalinspect.sgml
Fix pgbench in prepared mode with an empty pipeline
commit : 34f51196573ca19d83707d30b218c65b46f42d77
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 25 May 2023 12:36:18 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 25 May 2023 12:36:18 +0200
It crashes because it references memory that's not allocated in that
particular case. Fix by allocating it.
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/bcf802a6-afc1-95b9-7bf4-c5dd868ec144@gmail.com
M src/bin/pgbench/pgbench.c
M src/bin/pgbench/t/001_pgbench_with_server.pl
Fix misbehavior of EvalPlanQual checks with multiple result relations.
commit : 4729d1e8aab90bc5861a4ff01fc306ebf1bec433
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 19 May 2023 14:26:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 19 May 2023 14:26:34 -0400
The idea of EvalPlanQual is that we replace the query's scan of the
result relation with a single injected tuple, and see if we get a
tuple out, thereby implying that the injected tuple still passes the
query quals. (In join cases, other relations in the query are still
scanned normally.) This logic was not updated when commit 86dc90056
made it possible for a single DML query plan to have multiple result
relations, when the query target relation has inheritance or partition
children. We replaced the output for the current result relation
successfully, but other result relations were still scanned normally;
thus, if any other result relation contained a tuple satisfying the
quals, we'd think the EPQ check passed, even if it did not pass for
the injected tuple itself. This would lead to update or delete
actions getting performed when they should have been skipped due to
a conflicting concurrent update in READ COMMITTED isolation mode.
Fix by blocking all sibling result relations from emitting tuples
during an EvalPlanQual recheck. In the back branches, the fix is
complicated a bit by the need to not change the size of struct
EPQState (else we'd have ABI-breaking changes in offsets in
struct ModifyTableState). Like the back-patches of 3f7836ff6
and 4b3e37993, add a separately palloc'd struct to avoid that.
The logic is the same as in HEAD otherwise.
This is only a live bug back to v14 where 86dc90056 came in.
However, I chose to back-patch the test cases further, on the
grounds that this whole area is none too well tested. I skipped
doing so in v11 though because none of the test applied cleanly,
and it didn't quite seem worth extra work for a branch with only
six months to live.
Per report from Ante Krešić (via Aleksander Alekseev)
Discussion: https://postgr.es/m/CAJ7c6TMBTN3rcz4=AjYhLPD_w3FFT0Wq_C15jxCDn8U4tZnH1g@mail.gmail.com
M src/backend/executor/execMain.c
M src/backend/executor/execScan.c
M src/backend/executor/nodeModifyTable.c
M src/include/executor/executor.h
M src/include/nodes/execnodes.h
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec
Avoid naming conflict between transactions.sql and namespace.sql.
commit : 89f5eb26f6b9b2739aacf53676bfa0eee7be421a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 19 May 2023 10:57:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 19 May 2023 10:57:46 -0400
Commits 681d9e462 et al added a test case in namespace.sql that
implicitly relied on there not being a table "public.abc".
However, the concurrently-run transactions.sql test creates precisely
such a table, so with the right timing you'd get a failure.
Creating a table named as generically as "abc" in a common schema
seems like bad practice, so fix this by changing the name of
transactions.sql's table. (Compare 2cf8c7aa4.)
Marina Polyakova
Discussion: https://postgr.es/m/80d0201636665d82185942e7112257b4@postgrespro.ru
M src/test/regress/expected/transactions.out
M src/test/regress/sql/transactions.sql
pageinspect: Fix gist_page_items() with included columns
commit : 2dd77822178807f3da988e1d873777685d9f7504
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 19 May 2023 12:38:15 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 19 May 2023 12:38:15 +0900
Non-leaf pages of GiST indexes contain key attributes, leaf pages
contain both key and non-key attributes, and gist_page_items() ignored
the handling of non-key attributes. This caused a few problems when
using gist_page_items() on a GiST index with INCLUDE:
- On a non-leaf page, the function would crash.
- On a leaf page, the function would work, but miss to display all the
values for included attributes.
This commit fixes gist_page_items() to handle such cases in a more
appropriate way, and now displays the values of key and non-key
attributes for each item separately in a style consistent with what
ruleutils.c would generate for the attribute list, depending on the page
type dealt with. In a way similar to how a record is displayed, values
would be double-quoted for key or non-key attributes if required.
ruleutils.c did not provide a routine able to control if non-key
attributes should be displayed, so an extended() routine for index
definitions is added to work around the leaf and non-leaf page
differences.
While on it, this commit fixes a third problem related to the amount of
data reported for key attributes. The code originally relied on
BuildIndexValueDescription() (used for error reports on constraints)
that would not print all the data stored in the index but the index
opclass's input type, so this limited the amount of information
available. This switch makes gist_page_items() much cheaper as there is
no need to run ACL checks for each item printed, which is not an issue
anyway as superuser rights are required to execute the functions of
pageinspect. Opclasses whose data cannot be displayed can rely on
gist_page_items_bytea().
The documentation of this function was slightly incorrect for the
output results generated on HEAD and v15, so adjust it on these
branches.
Author: Alexander Lakhin, Michael Paquier
Discussion: https://postgr.es/m/17884-cb8c326522977acb@postgresql.org
Backpatch-through: 14
M contrib/pageinspect/expected/gist.out
M contrib/pageinspect/gistfuncs.c
M contrib/pageinspect/sql/gist.sql
M doc/src/sgml/pageinspect.sgml
M src/backend/utils/adt/ruleutils.c
M src/include/utils/ruleutils.h
Fix handling of empty ranges and NULLs in BRIN
commit : e187693239ad99fcfa368811f51fcf8af7428082
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Fri, 19 May 2023 00:00:22 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Fri, 19 May 2023 00:00:22 +0200
BRIN indexes did not properly distinguish between summaries for empty
(no rows) and all-NULL ranges, treating them as essentially the same
thing. Summaries were initialized with allnulls=true, and opclasses
simply reset allnulls to false when processing the first non-NULL value.
This however produces incorrect results if the range starts with a NULL
value (or a sequence of NULL values), in which case we forget the range
contains NULL values when adding the first non-NULL value.
This happens because the allnulls flag is used for two separate
purposes - to mark empty ranges (not representing any rows yet) and
ranges containing only NULL values.
Opclasses don't know which of these cases it is, and so don't know
whether to set hasnulls=true. Setting the flag in both cases would make
it correct, but it would also make BRIN indexes useless for queries with
IS NULL clauses. All ranges start empty (and thus allnulls=true), so all
ranges would end up with either allnulls=true or hasnulls=true.
The severity of the issue is somewhat reduced by the fact that it only
happens when adding values to an existing summary with allnulls=true.
This can happen e.g. for small tables (because a summary for the first
range exists for all BRIN indexes), or for tables with large fraction of
NULL values in the indexed columns.
Bulk summarization (e.g. during CREATE INDEX or automatic summarization)
that processes all values at once is not affected by this issue. In this
case the flags were updated in a slightly different way, not forgetting
the NULL values.
To identify empty ranges we use a new flag, stored in an unused bit in
the BRIN tuple header so the on-disk format remains the same. A matching
flag is added to BrinMemTuple, into a 3B gap after bt_placeholder.
That means there's no risk of ABI breakage, although we don't actually
pass the BrinMemTuple to any public API.
We could also skip storing index tuples for empty summaries, but then
we'd have to always process such ranges - even if there are no rows in
large parts of the table (e.g. after a bulk DELETE), it would still
require reading the pages etc. So we store them, but ignore them when
building the bitmap.
Backpatch to 11. The issue exists since BRIN indexes were introduced in
9.5, but older releases are already EOL.
Backpatch-through: 11
Reviewed-by: Justin Pryzby, Matthias van de Meent, Alvaro Herrera
Discussion: https://postgr.es/m/402430e4-7d9d-6cf1-09ef-464d80afff3b@enterprisedb.com
M src/backend/access/brin/brin.c
M src/backend/access/brin/brin_tuple.c
M src/include/access/brin_tuple.h
M src/test/modules/brin/expected/summarization-and-inprogress-insertion.out
M src/test/modules/brin/specs/summarization-and-inprogress-insertion.spec
Fix handling of NULLs when merging BRIN summaries
commit : 80f64b90088a8aeae6aeace2d344c8116ec28061
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 18 May 2023 13:00:31 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 18 May 2023 13:00:31 +0200
When merging BRIN summaries, union_tuples() did not correctly update the
target hasnulls/allnulls flags. When merging all-NULL summary into a
summary without any NULL values, the result had both flags set to false
(instead of having hasnulls=true).
This happened because the code only considered the hasnulls flags,
ignoring the possibility the source summary has allnulls=true.
Discovered while investigating issues with handling empty BRIN ranges
and handling of NULL values, but it's a separate problem (has nothing to
do with empty ranges).
Fixed by considering both flags on the source summary, and updating the
hasnulls flag on the target summary.
Backpatch to 11. The bug exists since 9.5 (where BRIN indexes were
introduced), but those releases are EOL already.
Discussion: https://postgr.es/m/9d993d0d-e431-2196-9ccc-0554d0e60154%40enterprisedb.com
M src/backend/access/brin/brin.c
Ensure Soundex difference() function handles empty input sanely.
commit : eaf99e4c4ae4084b8261e5e1f9c2c93004a98638
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 May 2023 10:53:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 May 2023 10:53:42 -0400
fuzzystrmatch's difference() function assumes that _soundex()
always initializes its output buffer fully. This was not so for
the case of a string containing no alphabetic characters, resulting
in unstable output and Valgrind complaints.
Fix by using memset() to fill the whole buffer in the early-exit
case. Also make some cosmetic improvements (I didn't care for the
random switches between "instr[0]" and "*instr" notation).
Report and diagnosis by Alexander Lakhin (bug #17935).
Back-patch to all supported branches.
Discussion: https://postgr.es/m/17935-b99316aa79c18513@postgresql.org
M contrib/fuzzystrmatch/expected/fuzzystrmatch.out
M contrib/fuzzystrmatch/fuzzystrmatch.c
M contrib/fuzzystrmatch/sql/fuzzystrmatch.sql
Mark internal messages as no longer translatable
commit : f06156da18f67bc2c904c0a76b70dafcb14ca7c2
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 16 May 2023 11:47:25 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 16 May 2023 11:47:25 +0200
The problem that these messages protect against can only occur because
a corrupted hash spill file was written, i.e., a Postgres bug. There's
no reason to have them as translatable.
Backpatch to 15, where these messages were changed by commit c4649cce39a4.
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/20230510175407.dwa5v477pw62ikyx@alvherre.pgsql
M src/backend/executor/nodeAgg.c
Tighten usage of PSQL_WATCH_PAGER.
commit : bc478a0a85bc8660bfa251866f85c673e4be84ac
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 May 2023 16:11:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 May 2023 16:11:14 -0400
Don't use PSQL_WATCH_PAGER when stdin/stdout are not a terminal.
This corresponds to the restrictions on when other commands will
use [PSQL_]PAGER. There isn't a lot of sense in trying to use a
pager in non-interactive cases, and doing so allows an environment
setting to break our tests.
Also, ignore PSQL_WATCH_PAGER if it is set but empty or all-blank,
for the same reasons we ignore such settings of [PSQL_]PAGER (see
commit 18f8f784c).
No documentation change is really needed, since there is nothing
suggesting that these constraints on [PSQL_]PAGER didn't already
apply to PSQL_WATCH_PAGER too. But I rearranged the text
a little to make it read more naturally (IMHO anyway).
Per report from Pavel Stehule. Back-patch to v15 where
PSQL_WATCH_PAGER was introduced.
Discussion: https://postgr.es/m/CAFj8pRDTwFzmEWdA-gdAcUh0ZnxUioSfTMre71WyB_wNJy-8gw@mail.gmail.com
M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/command.c
Doc: Fix link to fillfactor reloption.
commit : 95f2827c80acc06fecf4b47e46d95a038e0c8664
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 10 May 2023 10:49:48 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 10 May 2023 10:49:48 -0700
Fix a link from the "Heap-Only Tuples" documentation section.
Previously, its "fillfactor" link pointed to the "CREATE TABLE"
command's documentation. Now the link directly points to the fillfactor
storage parameter documentation (which is about half way into the
"CREATE TABLE" sect1).
Oversight in commit 115464bb.
Backpatch: 12-, the first version with a usable reloption link.
M doc/src/sgml/storage.sgml
Fix publication syntax error message
commit : 8e1d68c8f8eae96334db2f6633d2a61bcfb22f9a
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 10 May 2023 18:26:10 +0200
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 10 May 2023 18:26:10 +0200
There was some odd wording in corner-case gram.y error messages "some
error ... at or near", which appears to have been modeled after "syntax
error" messages. However, they don't work that way, and they're just
wrong. They're also uncovered by tests. Remove the trailing words,
and also add tests.
They were introduced with 5a2832465fd8; backpatch to 15.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
M src/backend/parser/gram.y
M src/test/regress/expected/publication.out
M src/test/regress/sql/publication.sql
Fix assertion failure when updating stats_fetch_consistency in a transaction
commit : ccd21e1cfa11fa4f39d01d95cf119beae9cf4d20
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 10 May 2023 11:24:40 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 10 May 2023 11:24:40 +0900
An update of the GUC stats_fetch_consistency in a transaction would be
able to trigger an assertion when doing cache->snapshot. In this case,
when retrieving a pgstat entry after the switch, a new snapshot would be
rebuilt, confusing pgstat_build_snapshot() because a snapshot is already
cached with an unexpected mode ("cache").
In order to fix this problem, this commit adds a flag to force a
snapshot clear each time this GUC is changed. Some tests are added to
check, while on it.
Some optimizations in avoiding the snapshot clear should be possible
depending on what is cached and the current GUC value, I guess, but this
solution is simple, and ensures that the state of the cache is updated
each time a new pgstat entry is fetched, hence being consistent with the
level wanted by the client that has set the GUC.
Note that cache->none and snapshot->none would not cause issues, as
fetching a pgstat entry would be retrieved from shared memory on the
second attempt, however a snapshot would still be cached. Similarly,
none->snapshot and none->cache would build a new snapshot on the second
fetch attempt. Finally, snapshot->cache would cache a new snapshot on
the second attempt.
Reported-by: Alexander Lakhin
Author: Kyotaro Horiguchi
Discussion: https://postgr.es/m/17804-2a118cd046f2d0e5@postgresql.org
backpatch-through: 15
M doc/src/sgml/config.sgml
M src/backend/utils/activity/pgstat.c
M src/backend/utils/misc/guc.c
M src/include/pgstat.h
M src/test/regress/expected/stats.out
M src/test/regress/sql/stats.sql