Stamp 12.20.
commit : 76265a851b13bbb001a218481c0cb6315c0fdfe6
author : Tom Lane <[email protected]>
date : Mon, 5 Aug 2024 16:11:34 -0400
committer: Tom Lane <[email protected]>
date : Mon, 5 Aug 2024 16:11:34 -0400
M configure
M configure.in
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
Last-minute updates for release notes.
commit : 1b85e65846aa16ede7aeddd67a9bd16ec73a18ae
author : Tom Lane <[email protected]>
date : Mon, 5 Aug 2024 14:03:20 -0400
committer: Tom Lane <[email protected]>
date : Mon, 5 Aug 2024 14:03:20 -0400
Security: CVE-2024-7348
M doc/src/sgml/release-12.sgml
Restrict accesses to non-system views and foreign tables during pg_dump.
commit : 79c7a7e29695a32fef2e65682be224b8d61ec972
author : Masahiko Sawada <[email protected]>
date : Mon, 5 Aug 2024 06:05:17 -0700
committer: Masahiko Sawada <[email protected]>
date : Mon, 5 Aug 2024 06:05:17 -0700
When pg_dump retrieves the list of database objects and performs the
data dump, there was possibility that objects are replaced with others
of the same name, such as views, and access them. This vulnerability
could result in code execution with superuser privileges during the
pg_dump process.
This issue can arise when dumping data of sequences, foreign
tables (only 13 or later), or tables registered with a WHERE clause in
the extension configuration table.
To address this, pg_dump now utilizes the newly introduced
restrict_nonsystem_relation_kind GUC parameter to restrict the
accesses to non-system views and foreign tables during the dump
process. This new GUC parameter is added to back branches too, but
these changes do not require cluster recreation.
Back-patch to all supported branches.
Reviewed-by: Noah Misch
Security: CVE-2024-7348
Backpatch-through: 12
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M doc/src/sgml/config.sgml
M src/backend/foreign/foreign.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/util/plancat.c
M src/backend/rewrite/rewriteHandler.c
M src/backend/tcop/postgres.c
M src/backend/utils/misc/guc.c
M src/bin/pg_dump/pg_dump.c
M src/include/tcop/tcopprot.h
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
Translation updates
commit : c2916c0933d190da323a01658b3ac4c332767adf
author : Peter Eisentraut <[email protected]>
date : Mon, 5 Aug 2024 12:25:03 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 5 Aug 2024 12:25:03 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 03e32419667b55fd8088a8238177d5b4c20f2b56
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/ru.po
M src/backend/po/sv.po
M src/bin/initdb/po/es.po
M src/bin/pg_archivecleanup/po/es.po
M src/bin/pg_basebackup/po/es.po
M src/bin/pg_checksums/po/es.po
M src/bin/pg_config/po/es.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetwal/po/es.po
M src/bin/pg_rewind/po/es.po
M src/bin/pg_test_fsync/po/es.po
M src/bin/pg_test_timing/po/es.po
M src/bin/pg_upgrade/po/de.po
M src/bin/pg_upgrade/po/es.po
M src/bin/pg_upgrade/po/fr.po
M src/bin/pg_upgrade/po/ja.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_waldump/po/es.po
M src/bin/psql/po/es.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/sv.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/es.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/po/de.po
M src/pl/tcl/po/es.po
M src/pl/tcl/po/fr.po
M src/pl/tcl/po/ja.po
M src/pl/tcl/po/ru.po
M src/pl/tcl/po/sv.po
Release notes for 16.4, 15.8, 14.13, 13.16, 12.20.
commit : 29337a5ff7bd3b2dbff24b3b9f68f87c91bebbe8
author : Tom Lane <[email protected]>
date : Sun, 4 Aug 2024 13:38:59 -0400
committer: Tom Lane <[email protected]>
date : Sun, 4 Aug 2024 13:38:59 -0400
M doc/src/sgml/release-12.sgml
Update comment in portal.h.
commit : fba830573335bf767fb1d92a9a9ef86c6f791044
author : Etsuro Fujita <[email protected]>
date : Thu, 1 Aug 2024 17:45:09 +0900
committer: Etsuro Fujita <[email protected]>
date : Thu, 1 Aug 2024 17:45:09 +0900
We store tuples into the portal's tuple store for a PORTAL_ONE_MOD_WITH
query as well.
Back-patch to all supported branches.
Reviewed by Andy Fan.
Discussion: https://postgr.es/m/CAPmGK14HVYBZYZtHabjeCd-e31VT%3Dwx6rQNq8QfehywLcpZ2Hw%40mail.gmail.com
M src/include/utils/portal.h
Revert "Allow parallel workers to cope with a newly-created session user ID."
commit : 41fb45a482a4643e5ed44aa66f52f1512cb57ce3
author : Tom Lane <[email protected]>
date : Wed, 31 Jul 2024 20:56:30 -0400
committer: Tom Lane <[email protected]>
date : Wed, 31 Jul 2024 20:56:30 -0400
This reverts commit 68855c03878c0c90227e24533ca40127da3578cd.
Some buildfarm animals are failing with "cannot change
"client_encoding" during a parallel operation". It looks like
assign_client_encoding is unhappy at being asked to roll back a
client_encoding setting after a parallel worker encounters a
failure. There must be more to it though: why didn't I see this
during local testing? In any case, it's clear that moving the
RestoreGUCState() call is not as side-effect-free as I thought.
Given that the bug f5f30c22e intended to fix has gone unreported
for years, it's not something that's urgent to fix; I'm not
willing to risk messing with it further with only days to our
next release wrap.
M src/backend/access/transam/parallel.c
M src/backend/commands/variable.c
M src/test/regress/expected/select_parallel.out
M src/test/regress/sql/select_parallel.sql
Allow parallel workers to cope with a newly-created session user ID.
commit : 68855c03878c0c90227e24533ca40127da3578cd
author : Tom Lane <[email protected]>
date : Wed, 31 Jul 2024 18:54:10 -0400
committer: Tom Lane <[email protected]>
date : Wed, 31 Jul 2024 18:54:10 -0400
Parallel workers failed after a sequence like
BEGIN;
CREATE USER foo;
SET SESSION AUTHORIZATION foo;
because check_session_authorization could not see the uncommitted
pg_authid row for "foo". This is because we ran RestoreGUCState()
in a separate transaction using an ordinary just-created snapshot.
The same disease afflicts any other GUC that requires catalog lookups
and isn't forgiving about the lookups failing.
To fix, postpone RestoreGUCState() into the worker's main transaction
after we've set up a snapshot duplicating the leader's. This affects
check_transaction_isolation and check_transaction_deferrable, which
think they should only run during transaction start. Make them
act like check_transaction_read_only, which already knows it should
silently accept the value when InitializingParallelWorker.
Per bug #18545 from Andrey Rachitskiy. Back-patch to all
supported branches, because this has been wrong for awhile.
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/transam/parallel.c
M src/backend/commands/variable.c
M src/test/regress/expected/select_parallel.out
M src/test/regress/sql/select_parallel.sql
Doc: mention executor memory usage for enable_partitionwise* GUCs
commit : 447e25c049150a0954b0532393de24916a1b7479
author : David Rowley <[email protected]>
date : Thu, 1 Aug 2024 01:28:48 +1200
committer: David Rowley <[email protected]>
date : Thu, 1 Aug 2024 01:28:48 +1200
Prior to this commit, the docs for enable_partitionwise_aggregate and
enable_partitionwise_join mentioned the additional overheads enabling
these causes for the query planner, but they mentioned nothing about the
possible surge in work_mem-consuming executor nodes that could end up in
the final plan. Dimitrios reported the OOM killer intervened on his
query as a result of using enable_partitionwise_aggregate=on.
Here we adjust the docs to mention the possible increase in the number of
work_mem-consuming executor nodes that can appear in the final plan as a
result of enabling these GUCs.
Reported-by: Dimitrios Apostolou
Reviewed-by: Ashutosh Bapat
Discussion: https://postgr.es/m/3603c380-d094-136e-e333-610914fb3e80%40gmx.net
Discussion: https://postgr.es/m/CAApHDvoZ0_yqwPFEpb6h261L76BUpmh5GxBQq0LeRzQ5Jh3zzg@mail.gmail.com
Backpatch-through: 12, oldest supported version
M doc/src/sgml/config.sgml
libpq: Use strerror_r instead of strerror
commit : 4070489999fdc230e7cc390e2fb63cd2a87c7d97
author : Peter Eisentraut <[email protected]>
date : Sun, 28 Jul 2024 09:12:00 +0200
committer: Peter Eisentraut <[email protected]>
date : Sun, 28 Jul 2024 09:12:00 +0200
Commit 453c4687377 introduced a use of strerror() into libpq, but that
is not thread-safe. Fix by using strerror_r() instead.
In passing, update some of the code comments added by 453c4687377, as
we have learned more about the reason for the change in OpenSSL that
started this.
Reviewed-by: Daniel Gustafsson <[email protected]>
Discussion: Discussion: https://postgr.es/m/[email protected]
M src/backend/libpq/be-secure-openssl.c
M src/interfaces/libpq/fe-secure-openssl.c
Fix building with MSVC for TLS session disabling
commit : e6dd0b8637b3577ab710738164139cf711164527
author : Daniel Gustafsson <[email protected]>
date : Fri, 26 Jul 2024 19:10:37 +0200
committer: Daniel Gustafsson <[email protected]>
date : Fri, 26 Jul 2024 19:10:37 +0200
Commit 274bbced85 omitted the required changes for the MSVC build
system in v16 through v12. Per buildfarm animal hamerkop.
Discussion: https://postgr.es/m/[email protected]
M src/include/pg_config.h.win32
M src/tools/msvc/Solution.pm
Fix macro placement in pg_config.h.in
commit : ac77add23b8141ed5f45d68bba129710e86c0a08
author : Daniel Gustafsson <[email protected]>
date : Fri, 26 Jul 2024 14:16:40 +0200
committer: Daniel Gustafsson <[email protected]>
date : Fri, 26 Jul 2024 14:16:40 +0200
Commit 274bbced85383e831dde accidentally placed the pg_config.h.in
for SSL_CTX_set_num_tickets on the wrong line wrt where autoheader
places it. Fix by re-arranging and backpatch to the same level as
the original commit.
Reported-by: Marina Polyakova <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: v12
M src/include/pg_config.h.in
Disable all TLS session tickets
commit : 32121c077d69e22ed4686d7ae3a9c637f3a64d85
author : Daniel Gustafsson <[email protected]>
date : Fri, 26 Jul 2024 11:09:45 +0200
committer: Daniel Gustafsson <[email protected]>
date : Fri, 26 Jul 2024 11:09:45 +0200
OpenSSL supports two types of session tickets for TLSv1.3, stateless
and stateful. The option we've used only turns off stateless tickets
leaving stateful tickets active. Use the new API introduced in 1.1.1
to disable all types of tickets.
Backpatch to all supported versions.
Reviewed-by: Heikki Linnakangas <[email protected]>
Reported-by: Andres Freund <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: v12
M configure
M configure.in
M src/backend/libpq/be-secure-openssl.c
M src/include/pg_config.h.in
Doc: fix misleading syntax synopses for targetlists.
commit : 551ea63aaa2d6f63f167f273926ca6d2f8c6f9ac
author : Tom Lane <[email protected]>
date : Thu, 25 Jul 2024 19:52:08 -0400
committer: Tom Lane <[email protected]>
date : Thu, 25 Jul 2024 19:52:08 -0400
In the syntax synopses for SELECT, INSERT, UPDATE, etc,
SELECT ... and RETURNING ... targetlists were missing { ... }
braces around an OR (|) operator. That allows misinterpretation
which could lead to confusion.
David G. Johnston, per gripe from [email protected].
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/delete.sgml
M doc/src/sgml/ref/insert.sgml
M doc/src/sgml/ref/select.sgml
M doc/src/sgml/ref/select_into.sgml
M doc/src/sgml/ref/update.sgml
Fix a missing article in the documentation
commit : e29203a60b1c7e0d667e3a912d04c4a715bda6e9
author : Alvaro Herrera <[email protected]>
date : Wed, 24 Jul 2024 14:13:55 +0200
committer: Alvaro Herrera <[email protected]>
date : Wed, 24 Jul 2024 14:13:55 +0200
Per complaint from Grant Gryczan.
It's a very old typo; backpatch all the way back.
Author: Laurenz Albe <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/parallel.sgml
Reset relhassubclass upon attaching table as a partition
commit : 08b6a9ecf922dc7e4a39bcb88ca568f515a7e93b
author : Alvaro Herrera <[email protected]>
date : Wed, 24 Jul 2024 12:38:18 +0200
committer: Alvaro Herrera <[email protected]>
date : Wed, 24 Jul 2024 12:38:18 +0200
We don't allow inheritance parents as partitions, and have checks to
prevent this; but if a table _was_ in the past an inheritance parents
and all their children are removed, the pg_class.relhassubclass flag
may remain set, which confuses the partition pruning code (most
obviously, it results in an assertion failure; in production builds it
may be worse.)
Fix by resetting relhassubclass on attach.
Backpatch to all supported versions.
Reported-by: Alexander Lakhin <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/catalog/heap.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Detect integer overflow in array_set_slice().
commit : 878e8c6be7ab2523b3dcbe238578e95162f521e9
author : Nathan Bossart <[email protected]>
date : Tue, 23 Jul 2024 21:59:02 -0500
committer: Nathan Bossart <[email protected]>
date : Tue, 23 Jul 2024 21:59:02 -0500
When provided an empty initial array, array_set_slice() fails to
check for overflow when computing the new array's dimensions.
While such overflows are ordinarily caught by ArrayGetNItems(),
commands with the following form are accepted:
INSERT INTO t (i[-2147483648:2147483647]) VALUES ('{}');
To fix, perform the hazardous computations using overflow-detecting
arithmetic routines. As with commit 18b585155a, the added test
cases generate errors that include a platform-dependent value, so
we again use psql's VERBOSITY parameter to suppress printing the
message text.
Reported-by: Alexander Lakhin
Author: Joseph Koshakow
Reviewed-by: Jian He
Discussion: https://postgr.es/m/31ad2cd1-db94-bdb3-f91a-65ffdb4bef95%40gmail.com
Backpatch-through: 12
M src/backend/utils/adt/arrayfuncs.c
M src/test/regress/expected/arrays.out
M src/test/regress/sql/arrays.sql
Doc: improve description of plpgsql's FETCH and MOVE commands.
commit : 77b116724c7545fb610e0f7287d3fbff35ffea22
author : Tom Lane <[email protected]>
date : Mon, 22 Jul 2024 19:43:12 -0400
committer: Tom Lane <[email protected]>
date : Mon, 22 Jul 2024 19:43:12 -0400
We were not being clear about which variants of the "direction"
clause are permitted in MOVE. Also, the text seemed to be
written with only the FETCH/MOVE NEXT case in mind, so it
didn't apply very well to other variants.
Also, document that "MOVE count IN cursor" only works if count
is a constant. This is not the whole truth, because some other
cases such as a parenthesized expression will also work, but
we want to push people to use "MOVE FORWARD count" instead.
The constant case is enough to cover what we allow in plain SQL,
and that seems sufficient to claim support for.
Update a comment in pl_gram.y claiming that we don't document
that point.
Per gripe from Philipp Salvisberg.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/plpgsql.sgml
M src/pl/plpgsql/src/pl_gram.y
Correctly check updatability of columns targeted by INSERT...DEFAULT.
commit : feca6c688cd99c68ce10caf21f8566b2483ca3f2
author : Tom Lane <[email protected]>
date : Sat, 20 Jul 2024 13:40:15 -0400
committer: Tom Lane <[email protected]>
date : Sat, 20 Jul 2024 13:40:15 -0400
If a view has some updatable and some non-updatable columns, we failed
to verify updatability of any columns for which an INSERT or UPDATE
on the view explicitly specifies a DEFAULT item (unless the view has
a declared default for that column, which is rare anyway, and one
would almost certainly not write one for a non-updatable column).
This would lead to an unexpected "attribute number N not found in
view targetlist" error rather than the intended error.
Per bug #18546 from Alexander Lakhin. This bug is old, so back-patch
to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql
Add overflow checks to money type.
commit : 4f962815871f6ac4eb3b516832b5c95a2f628f1b
author : Nathan Bossart <[email protected]>
date : Fri, 19 Jul 2024 11:52:32 -0500
committer: Nathan Bossart <[email protected]>
date : Fri, 19 Jul 2024 11:52:32 -0500
None of the arithmetic functions for the the money type handle
overflow. This commit introduces several helper functions with
overflow checking and makes use of them in the money type's
arithmetic functions.
Fixes bug #18240.
Reported-by: Alexander Lakhin
Author: Joseph Koshakow
Discussion: https://postgr.es/m/18240-c5da758d7dc1ecf0%40postgresql.org
Discussion: https://postgr.es/m/CAAvxfHdBPOyEGS7s%2Bxf4iaW0-cgiq25jpYdWBqQqvLtLe_t6tw%40mail.gmail.com
Backpatch-through: 12
M src/backend/utils/adt/cash.c
M src/test/regress/expected/money.out
M src/test/regress/sql/money.sql
Avoid error in recovery test if history file is not yet present
commit : b06fe880da1423063104ac42214b04245c3277a4
author : Andrew Dunstan <[email protected]>
date : Wed, 17 Jul 2024 10:35:50 -0400
committer: Andrew Dunstan <[email protected]>
date : Wed, 17 Jul 2024 10:35:50 -0400
Error was detected when testing use of libpq sessions instead of psql
for polling queries.
Discussion: https://postgr.es/m/[email protected]
Backpatch to all live branches
M src/test/recovery/t/002_archiving.pl
Fix bad indentation introduced in 43cd30bcd1c
commit : 69bdee12e4437d3681de584de8ecced1fda4bcb5
author : Andres Freund <[email protected]>
date : Mon, 15 Jul 2024 15:17:18 -0700
committer: Andres Freund <[email protected]>
date : Mon, 15 Jul 2024 15:17:18 -0700
Oops.
Reported-by: Nathan Bossart <[email protected]>
Discussion: https://postgr.es/m/ZpVZB9rH5tHllO75@nathan
Backpatch: 12-, like 43cd30bcd1c
M src/backend/utils/misc/guc.c
Fix type confusion in guc_var_compare()
commit : 92f02c39c0facc817450a77bdff042dabe4aa6a3
author : Andres Freund <[email protected]>
date : Mon, 15 Jul 2024 09:26:03 -0700
committer: Andres Freund <[email protected]>
date : Mon, 15 Jul 2024 09:26:03 -0700
Before this change guc_var_compare() cast the input arguments to
const struct config_generic *. That's not quite right however, as the input
on one side is often just a char * on one side.
Instead just use char *, the first field in config_generic.
This fixes a -Warray-bounds warning with some versions of gcc. While the
warning is only known to be triggered for <= 15, the issue the warning points
out seems real, so apply the fix everywhere.
Author: Nazir Bilal Yavuz <[email protected]>
Reported-by: Erik Rijkers <[email protected]>
Suggested-by: Andres Freund <[email protected]>
Discussion: https://postgr.es/m/a74a1a0d-0fd2-3649-5224-4f754e8f91aa%40xs4all.nl
M src/backend/utils/misc/guc.c
Avoid unhelpful internal error for incorrect recursive-WITH queries.
commit : 236b225ed452ae54bf3bb778b926495c4f1aa388
author : Tom Lane <[email protected]>
date : Sun, 14 Jul 2024 13:49:46 -0400
committer: Tom Lane <[email protected]>
date : Sun, 14 Jul 2024 13:49:46 -0400
checkWellFormedRecursion would issue "missing recursive reference"
if a WITH RECURSIVE query contained a single self-reference but
that self-reference was inside a top-level WITH, ORDER BY, LIMIT,
etc, rather than inside the second arm of the UNION as expected.
We already intended to throw more-on-point errors for such cases,
but those error checks must be done before examining the UNION arm
in order to have the desired results. So this patch need only
move some code (and improve the comments).
Per bug #18536 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/parser/parse_cte.c
M src/test/regress/expected/with.out
M src/test/regress/sql/with.sql
Make sure to run pg_isready on correct port
commit : 53a14ec29024e8060755e462c384bc6c323dee14
author : Andrew Dunstan <[email protected]>
date : Fri, 12 Jul 2024 18:29:15 -0400
committer: Andrew Dunstan <[email protected]>
date : Fri, 12 Jul 2024 18:29:15 -0400
The current code can have pg_isready unexpectedly succeed if there is a
server running on the default port. To avoid this we delay running the
test until after a node has been created but before it starts, and then
use that node's port, so we are fairly sure there is nothing running on
the port.
Backpatch to all live branches.
M src/bin/scripts/t/080_pg_isready.pl
Fix lost Windows socket EOF events.
commit : ba9fcac7209d884a63cc3e434914132f1ee0dfd2
author : Thomas Munro <[email protected]>
date : Sat, 13 Jul 2024 14:59:46 +1200
committer: Thomas Munro <[email protected]>
date : Sat, 13 Jul 2024 14:59:46 +1200
Winsock only signals an FD_CLOSE event once if the other end of the
socket shuts down gracefully. Because each WaitLatchOrSocket() call
constructs and destroys a new event handle every time, with unlucky
timing we can lose it and hang. We get away with this only if the other
end disconnects non-gracefully, because FD_CLOSE is repeatedly signaled
in that case.
To fix this design flaw in our Windows socket support fundamentally,
we'd probably need to rearchitect it so that a single event handle
exists for the lifetime of a socket, or switch to completely different
multiplexing or async I/O APIs. That's going to be a bigger job
and probably wouldn't be back-patchable.
This brute force kludge closes the race by explicitly polling with
MSG_PEEK before sleeping.
Back-patch to all supported releases. This should hopefully clear up
some random build farm and CI hang failures reported over the years. It
might also allow us to try using graceful shutdown in more places again
(reverted in commit 29992a6) to fix instability in the transmission of
FATAL error messages, but that isn't done by this commit.
Reported-by: Tom Lane <[email protected]>
Tested-by: Alexander Lakhin <[email protected]>
Discussion: https://postgr.es/m/176008.1715492071%40sss.pgh.pa.us
M src/backend/storage/ipc/latch.c
Add ORDER BY to new test query
commit : 067cb6c5da6cfe60618c2951b061137233680c20
author : Alvaro Herrera <[email protected]>
date : Fri, 12 Jul 2024 13:44:19 +0200
committer: Alvaro Herrera <[email protected]>
date : Fri, 12 Jul 2024 13:44:19 +0200
Per buildfarm.
M src/test/regress/input/constraints.source
M src/test/regress/output/constraints.source
Fix ALTER TABLE DETACH for inconsistent indexes
commit : d0054432d480e958e4650c4b56de4a4a6e05da78
author : Alvaro Herrera <[email protected]>
date : Fri, 12 Jul 2024 12:54:01 +0200
committer: Alvaro Herrera <[email protected]>
date : Fri, 12 Jul 2024 12:54:01 +0200
When a partitioned table has an index that doesn't support a constraint,
but a partition has an equivalent index that does, then a DETACH
operation would misbehave: a crash in assertion-enabled systems (because
we fail to find the constraint in the parent that we expect to), or a
broken coninhcount value (-1) in production systems (because we blindly
believe that we've successfully detached the parent).
While we should reject an ATTACH of a partition with such an index, we
have failed to do so in existing releases, so adding an error in stable
releases might break the (unlikely) existing applications that rely on
this behavior. At this point I don't even want to reject them in
master, because it'd break pg_upgrade if such databases exist, and there
would be no easy way to fix existing databases without expensive index
rebuilds.
(Later on we could add ALTER TABLE ... ADD CONSTRAINT USING INDEX to
partitioned tables, which would allow the user to fix such patterns. At
that point we could add more restrictions to prevent the problem from
its root.)
Also, add a test case that leaves one table in this condition, so that
we can verify that pg_upgrade continues to work if we later decide to
change the policy on the master branch.
Backpatch to all supported branches.
Co-authored-by: Tender Wang <[email protected]>
Reported-by: Alexander Lakhin <[email protected]>
Reviewed-by: Tender Wang <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
M src/test/regress/expected/sanity_check.out
M src/test/regress/input/constraints.source
M src/test/regress/output/constraints.source
Fix possibility of logical decoding partial transaction changes.
commit : 1b370758770c3259f2ec09eefe47274be995792e
author : Masahiko Sawada <[email protected]>
date : Thu, 11 Jul 2024 22:48:08 +0900
committer: Masahiko Sawada <[email protected]>
date : Thu, 11 Jul 2024 22:48:08 +0900
When creating and initializing a logical slot, the restart_lsn is set
to the latest WAL insertion point (or the latest replay point on
standbys). Subsequently, WAL records are decoded from that point to
find the start point for extracting changes in the
DecodingContextFindStartpoint() function. Since the initial
restart_lsn could be in the middle of a transaction, the start point
must be a consistent point where we won't see the data for partial
transactions.
Previously, when not building a full snapshot, serialized snapshots
were restored, and the SnapBuild jumps to the consistent state even
while finding the start point. Consequently, the slot's restart_lsn
and confirmed_flush could be set to the middle of a transaction. This
could lead to various unexpected consequences. Specifically, there
were reports of logical decoding decoding partial transactions, and
assertion failures occurred because only subtransactions were decoded
without decoding their top-level transaction until decoding the commit
record.
To resolve this issue, the changes prevent restoring the serialized
snapshot and jumping to the consistent state while finding the start
point.
On v17 and HEAD, a flag indicating whether snapshot restores should be
skipped has been added to the SnapBuild struct, and SNAPBUILD_VERSION
has been bumpded.
On backbranches, the flag is stored in the LogicalDecodingContext
instead, preserving on-disk compatibility.
Backpatch to all supported versions.
Reported-by: Drew Callahan
Reviewed-by: Amit Kapila, Hayato Kuroda
Discussion: https://postgr.es/m/2444AA15-D21B-4CCE-8052-52C7C2DAFE5C%40amazon.com
Backpatch-through: 12
M contrib/test_decoding/Makefile
A contrib/test_decoding/expected/skip_snapshot_restore.out
A contrib/test_decoding/specs/skip_snapshot_restore.spec
M src/backend/replication/logical/logical.c
M src/backend/replication/logical/snapbuild.c
M src/include/replication/logical.h
Make our back branches compatible with libxml2 2.13.x.
commit : a134baea7ab0cc907b9d9d3d16f9ac97ec8200be
author : Tom Lane <[email protected]>
date : Wed, 10 Jul 2024 20:15:52 -0400
committer: Tom Lane <[email protected]>
date : Wed, 10 Jul 2024 20:15:52 -0400
This back-patches HEAD commits 066e8ac6e, 6082b3d5d, e7192486d,
and 896cd266f into supported branches. Changes:
* Use xmlAddChildList not xmlAddChild in XMLSERIALIZE
(affects v16 and up only). This was a flat-out coding mistake
that we got away with due to lax checking in previous versions
of xmlAddChild.
* Use xmlParseInNodeContext not xmlParseBalancedChunkMemory.
This is to dodge a bug in xmlParseBalancedChunkMemory in libxm2
releases 2.13.0-2.13.2. While that bug is now fixed upstream and
will probably never be seen in any production-oriented distro, it is
currently a problem on some more-bleeding-edge-friendly platforms.
* Suppress "chunk is not well balanced" errors from libxml2,
unless it is the only error. This eliminates an error-reporting
discrepancy between 2.13 and older releases. This error is
almost always redundant with previous errors, if not flat-out
inappropriate, which is why 2.13 changed the behavior and why
nobody's likely to miss it.
Erik Wienhold and Tom Lane, per report from Frank Streitzig.
Discussion: https://postgr.es/m/trinity-b0161630-d230-4598-9ebc-7a23acdb37cb-1720186432160@3c-app-gmx-bap25
Discussion: https://postgr.es/m/trinity-361ba18b-541a-4fe7-bc63-655ae3a7d599-1720259822452@3c-app-gmx-bs01
M src/backend/utils/adt/xml.c
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_2.out
Unrevert "Force nodes for SSL tests to start in TCP mode"
commit : d1c30fd884b60c6f342e728df046cf2f701e79d7
author : Andrew Dunstan <[email protected]>
date : Tue, 9 Jul 2024 09:40:30 -0400
committer: Andrew Dunstan <[email protected]>
date : Tue, 9 Jul 2024 09:40:30 -0400
This reverts commit 8b03d743a85fed4930645382a219cc75bdf7ab73.
Release 12 required a little extra sauce to make it work, but this has
been tested now.
M src/test/ssl/t/SSLServer.pm
Revert "Force nodes for SSL tests to start in TCP mode"
commit : 8b03d743a85fed4930645382a219cc75bdf7ab73
author : Andrew Dunstan <[email protected]>
date : Mon, 8 Jul 2024 17:15:10 -0400
committer: Andrew Dunstan <[email protected]>
date : Mon, 8 Jul 2024 17:15:10 -0400
This reverts commit 198088dc63de4f89835419969c7b5d1640be3441.
This is causing errors on Release 12, so revert for now to keep the
buildfarm green.
M src/test/ssl/t/SSLServer.pm
Choose ports for test servers less likely to result in conflicts
commit : 8398485957b630a6686cb83b67a17c75dc6ec54b
author : Andrew Dunstan <[email protected]>
date : Mon, 8 Jul 2024 11:18:06 -0400
committer: Andrew Dunstan <[email protected]>
date : Mon, 8 Jul 2024 11:18:06 -0400
If we choose ports in the range typically used for ephemeral ports there
is a danger of encountering a port conflict due to a race condition
between the time we choose the port in a range below that typically used
to allocate ephemeral ports, but higher than the range typically used by
well known services.
Author: Jelte Fenema-Nio, with some editing by me.
Discussion: https://postgr.es/m/[email protected]
Backpatch to all live branches (12 and up)
M src/test/perl/PostgresNode.pm
Force nodes for SSL tests to start in TCP mode
commit : 198088dc63de4f89835419969c7b5d1640be3441
author : Andrew Dunstan <[email protected]>
date : Mon, 8 Jul 2024 05:51:26 -0400
committer: Andrew Dunstan <[email protected]>
date : Mon, 8 Jul 2024 05:51:26 -0400
Currently they are started in unix socket mode in ost cases, and then
converted to run in TCP mode. This can result in port collisions, and
there is no virtue in startng in unix socket mode, so start as we will
be going on.
Discussion: https://postgr.es/m/[email protected]
Backpatch to all live branches (12 and up).
M src/test/ssl/t/SSLServer.pm
Fix scale clamping in numeric round() and trunc().
commit : 8badee7875c0eac9e2c4fd61f23eceaa64276b3f
author : Dean Rasheed <[email protected]>
date : Mon, 8 Jul 2024 17:58:42 +0100
committer: Dean Rasheed <[email protected]>
date : Mon, 8 Jul 2024 17:58:42 +0100
The numeric round() and trunc() functions clamp the scale argument to
the range between +/- NUMERIC_MAX_RESULT_SCALE (2000), which is much
smaller than the actual allowed range of type numeric. As a result,
they return incorrect results when asked to round/truncate more than
2000 digits before or after the decimal point.
Fix by using the correct upper and lower scale limits based on the
actual allowed (and documented) range of type numeric.
While at it, use the new NUMERIC_WEIGHT_MAX constant instead of
SHRT_MAX in all other overflow checks, and fix a comment thinko in
power_var() introduced by e54a758d24 -- the minimum value of
ln_dweight is -NUMERIC_DSCALE_MAX (-16383), not -SHRT_MAX, though this
doesn't affect the point being made in the comment, that the resulting
local_rscale value may exceed NUMERIC_MAX_DISPLAY_SCALE (1000).
Back-patch to all supported branches.
Dean Rasheed, reviewed by Joel Jacobson.
Discussion: https://postgr.es/m/CAEZATCXB%2BrDTuMjhK5ZxcouufigSc-X4tGJCBTMpZ3n%3DxxQuhg%40mail.gmail.com
M src/backend/utils/adt/numeric.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
Cope with <regex.h> name clashes.
commit : 274a8195d479894339facb940568d2cb19d9b486
author : Thomas Munro <[email protected]>
date : Sat, 6 Jul 2024 10:24:49 +1200
committer: Thomas Munro <[email protected]>
date : Sat, 6 Jul 2024 10:24:49 +1200
macOS 15's SDK pulls in headers related to <regex.h> when we include
<xlocale.h>. This causes our own regex_t implementation to clash with
the OS's regex_t implementation. Luckily our function names already had
pg_ prefixes, but the macros and typenames did not.
Include <regex.h> explicitly on all POSIX systems, and fix everything
that breaks. Then we can prove that we are capable of fully hiding and
replacing the system regex API with our own.
1. Deal with standard-clobbering macros by undefining them all first.
POSIX says they are "symbolic constants". If they are macros, this
allows us to redefine them. If they are enums or variables, our macros
will hide them.
2. Deal with standard-clobbering types by giving our types pg_
prefixes, and then using macros to redirect xxx_t -> pg_xxx_t.
After including our "regex/regex.h", the system <regex.h> is hidden,
because we've replaced all the standard names. The PostgreSQL source
tree and extensions can continue to use standard prefix-less type and
macro names, but reach our implementation, if they included our
"regex/regex.h" header.
Back-patch to all supported branches, so that macOS 15's tool chain can
build them.
Reported-by: Stan Hu <[email protected]>
Suggested-by: Tom Lane <[email protected]>
Tested-by: Aleksander Alekseev <[email protected]>
Discussion: https://postgr.es/m/CAMBWrQnEwEJtgOv7EUNsXmFw2Ub4p5P%2B5QTBEgYwiyjy7rAsEQ%40mail.gmail.com
M src/include/regex/regex.h
M src/tools/pgindent/typedefs.list
Doc: small improvements in discussion of geometric data types.
commit : ac2ec6c57b38ea5baec08ef01d9cbabf1565017e
author : Tom Lane <[email protected]>
date : Thu, 4 Jul 2024 13:23:32 -0400
committer: Tom Lane <[email protected]>
date : Thu, 4 Jul 2024 13:23:32 -0400
State explicitly that the coordinates in our geometric data types are
float8. Also explain that polygons store their bounding box.
While here, fix the table of geometric data types to show type
"line"'s size correctly: it's 24 bytes not 32. This has somehow
escaped notice since that table was made in 1998.
Per suggestion from Sebastian Skałacki. The size error seems
important enough to justify back-patching.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/datatype.sgml
doc: Specify when ssl_prefer_server_ciphers was added
commit : 65b51c75415dde0a1782870d4746208438e7b3b4
author : Daniel Gustafsson <[email protected]>
date : Thu, 4 Jul 2024 11:38:37 +0200
committer: Daniel Gustafsson <[email protected]>
date : Thu, 4 Jul 2024 11:38:37 +0200
The ssl_prefer_server_ciphers setting is quite important from a
security point of view, so simply stating that older versions
doesn't have it isn't very helpful. This adds the version when
the GUC was added to help readers.
Backpatch to all supported versions since this setting has been
around since 9.4.
Reviewed-by: Peter Eisentraut <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: v12
M doc/src/sgml/config.sgml
Fix missing installation/uninstallation rules for BackgroundPsql.pm
commit : 241ef53b6a95be0c7c175cbad48e5492dc3ae29c
author : Heikki Linnakangas <[email protected]>
date : Mon, 1 Jul 2024 19:22:36 +0300
committer: Heikki Linnakangas <[email protected]>
date : Mon, 1 Jul 2024 19:22:36 +0300
Commit d5fd7865 backported BackgroundPsql perl module module with
helper functions for tests running interactive or background psql
tasks to PG 12 to 15, but did not add installation/uninstallation
rules of the build system, causing problems running TAP tests for the
extensions.
Author: Pavan Deolasee <[email protected]>
Discussion: https://www.postgresql.org/message-id/CABOikdPmRuZrcf_gtgXmQzZ5Tbg9yUJmqXDCAZ2aW%3DWi-PbDyQ%40mail.gmail.com
M src/test/perl/Makefile
Preserve CurrentMemoryContext across notify and sinval interrupts.
commit : 8565fb6fbb6908b6af0ad2035820cb7578f9bcb8
author : Tom Lane <[email protected]>
date : Mon, 1 Jul 2024 12:21:07 -0400
committer: Tom Lane <[email protected]>
date : Mon, 1 Jul 2024 12:21:07 -0400
ProcessIncomingNotify is called from the main processing loop that
normally runs in MessageContext. That outer-loop code assumes that
whatever it allocates will be cleaned up when we're done processing
the current client message --- but if we service a notify interrupt,
then whatever gets allocated before the next switch into
MessageContext will be permanently leaked in TopMemoryContext,
because CommitTransactionCommand sets CurrentMemoryContext to
TopMemoryContext. There are observable leaks associated with
(at least) encoding conversion of incoming queries and parameters
attached to Bind messages.
sinval catchup interrupts have a similar problem. There might be
others, but I've not identified any other clear cases.
To fix, take care to save and restore CurrentMemoryContext across
the Start/CommitTransactionCommand calls in these functions.
Per bug #18512 from wizardbrony. Commit to back branches only;
in HEAD, this was dealt with by the riskier but more thoroughgoing
approach in commit 1afe31f03.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/async.c
M src/backend/storage/ipc/sinval.c
Remove configuration-dependent output from new inplace-inval test.
commit : 79567599cd2166867fd0057363800d0604f4fc64
author : Noah Misch <[email protected]>
date : Fri, 28 Jun 2024 09:33:40 -0700
committer: Noah Misch <[email protected]>
date : Fri, 28 Jun 2024 09:33:40 -0700
Per buildfarm members prion and trilobite. Back-patch to v12 (all
supported versions), like commit
0844b3968985447ed0a6937cfc8639e379da2fe6.
Strategy reviewed by Tom Lane.
Discussion: https://postgr.es/m/[email protected]
M src/test/isolation/expected/inplace-inval.out
M src/test/isolation/specs/inplace-inval.spec
Remove comment about xl_heap_inplace "AT END OF STRUCT".
commit : 77d0bc8001e64bc901b952ed86d016259c713bab
author : Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:06 -0700
committer: Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:06 -0700
Commit 2c03216d831160bedd72d45f712601b6f7d03f1c moved the tuple data
from there to the buffer-0 data. Back-patch to v12 (all supported
versions), the plan for the next change to this struct.
Discussion: https://postgr.es/m/[email protected]
M src/include/access/heapam_xlog.h
Cope with inplace update making catcache stale during TOAST fetch.
commit : 11f3815d6af840dc9d557cc680ec477931a6825b
author : Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:06 -0700
committer: Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:06 -0700
This extends ad98fb14226ae6456fbaed7990ee7591cbe5efd2 to invals of
inplace updates. Trouble requires an inplace update of a catalog having
a TOAST table, so only pg_database was at risk. (The other catalog on
which core code performs inplace updates, pg_class, has no TOAST table.)
Trouble would require something like the inplace-inval.spec test.
Consider GRANT ... ON DATABASE fetching a stale row from cache and
discarding a datfrozenxid update that vac_truncate_clog() has already
relied upon. Back-patch to v12 (all supported versions).
Reviewed (in an earlier version) by Robert Haas.
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]
M src/backend/catalog/catalog.c
M src/backend/utils/cache/catcache.c
M src/include/catalog/catalog.h
AccessExclusiveLock new relations just after assigning the OID.
commit : 7af775bbae5724272f3b72766df977f07fa5455a
author : Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:05 -0700
committer: Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:05 -0700
This has no user-visible, important consequences, since other sessions'
catalog scans can't find the relation until we commit. However, this
unblocks introducing a rule about locks required to heap_update() a
pg_class row. CREATE TABLE has been acquiring this lock eventually, but
it can heap_update() pg_class.relchecks earlier. create_toast_table()
has been acquiring only ShareLock. Back-patch to v12 (all supported
versions), the plan for the commit relying on the new rule.
Reviewed (in an earlier version) by Robert Haas.
Discussion: https://postgr.es/m/[email protected]
M src/backend/catalog/heap.c
Lock before setting relhassubclass on RELKIND_PARTITIONED_INDEX.
commit : e2eefb97e31a64b48bb22fe53d0101586891d01f
author : Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:05 -0700
committer: Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:05 -0700
Commit 5b562644fec696977df4a82790064e8287927891 added a comment that
SetRelationHasSubclass() callers must hold this lock. When commit
17f206fbc824d2b4b14480199ca9ff7dea417eda extended use of this column to
partitioned indexes, it didn't take the lock. As the latter commit
message mentioned, we currently never reset a partitioned index to
relhassubclass=f. That largely avoids harm from the lock omission. The
cause for fixing this now is to unblock introducing a rule about locks
required to heap_update() a pg_class row. This might cause more
deadlocks. It gives minor user-visible benefits:
- If an ALTER INDEX SET TABLESPACE runs concurrently with ALTER TABLE
ATTACH PARTITION or CREATE PARTITION OF, one transaction blocks
instead of failing with "tuple concurrently updated". (Many cases of
DDL concurrency still fail that way.)
- Match ALTER INDEX ATTACH PARTITION in choosing to lock the index.
While not user-visible today, we'll need this if we ever make something
set the flag to false for a partitioned index, like ANALYZE does today
for tables. Back-patch to v12 (all supported versions), the plan for
the commit relying on the new rule. In back branches, add
LockOrStrongerHeldByMe() instead of adding a LockHeldByMe() parameter.
Reviewed (in an earlier version) by Robert Haas.
Discussion: https://postgr.es/m/[email protected]
M src/backend/catalog/index.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/storage/lmgr/lmgr.c
M src/backend/storage/lmgr/lock.c
M src/include/storage/lmgr.h
M src/include/storage/lock.h
Expand comments and add an assertion in nodeModifyTable.c.
commit : fea47de3016ac8bc29bce10382220a457d2ef57f
author : Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:05 -0700
committer: Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:05 -0700
Most comments concern RELKIND_VIEW. One addresses the ExecUpdate()
"tupleid" parameter. A later commit will rely on these facts, but they
hold already. Back-patch to v12 (all supported versions), the plan for
that commit.
Reviewed (in an earlier version) by Robert Haas.
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/nodeModifyTable.c
Improve test coverage for changes to inplace-updated catalogs.
commit : 796d191028bb642bb04d9b3fd18d6f0aab7b1f1f
author : Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:05 -0700
committer: Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:05 -0700
This covers both regular and inplace changes, since bugs arise at their
intersection. Where marked, these witness extant bugs. Back-patch to
v12 (all supported versions).
Reviewed (in an earlier version) by Robert Haas.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pgbench/t/001_pgbench_with_server.pl
M src/test/isolation/expected/eval-plan-qual.out
A src/test/isolation/expected/inplace-inval.out
A src/test/isolation/expected/intra-grant-inplace-db.out
A src/test/isolation/expected/intra-grant-inplace.out
M src/test/isolation/isolation_schedule
M src/test/isolation/specs/eval-plan-qual.spec
A src/test/isolation/specs/inplace-inval.spec
A src/test/isolation/specs/intra-grant-inplace-db.spec
A src/test/isolation/specs/intra-grant-inplace.spec
A src/test/regress/expected/database.out
M src/test/regress/parallel_schedule
A src/test/regress/sql/database.sql
Avoid crashing when a JIT-inlined backend function throws an error.
commit : dccda847b709e38ce6f09ac5c47f2bdf30e93a2c
author : Tom Lane <[email protected]>
date : Thu, 27 Jun 2024 14:43:59 -0400
committer: Tom Lane <[email protected]>
date : Thu, 27 Jun 2024 14:43:59 -0400
errfinish() assumes that the __FUNC__ and __FILE__ arguments it's
passed are compile-time constant strings that can just be pointed
to rather than physically copied. However, it's possible for LLVM
to generate code in which those pointers point into a dynamically
loaded code segment. If that segment gets unloaded before we're
done with the ErrorData struct, we have dangling pointers that
will lead to SIGSEGV. In simple cases that won't happen, because we
won't unload LLVM code before end of transaction. But it's possible
to happen if the error is thrown within end-of-transaction code run by
_SPI_commit or _SPI_rollback, because since commit 2e517818f those
functions clean up by ending the transaction and starting a new one.
Rather than fixing this by adding pstrdup() overhead to every
elog/ereport sequence, let's fix it by copying the risky pointers
in CopyErrorData(). That solves it for _SPI_commit/_SPI_rollback
because they use that function to preserve the error data across
the transaction end/restart sequence; and it seems likely that
any other code doing something similar would need to do that too.
I'm suspicious that this behavior amounts to an LLVM bug (or a
bug in our use of it?), because it implies that string constant
references that should be pointer-equal according to a naive
understanding of C semantics will sometimes not be equal.
However, even if it is a bug and someday gets fixed, we'll have
to cope with the current behavior for a long time to come.
Report and patch by me. Back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/error/elog.c
Fix MVCC bug with prepared xact with subxacts on standby
commit : 5dea6628b32d8092e789d9e31509ed74840a271e
author : Heikki Linnakangas <[email protected]>
date : Thu, 27 Jun 2024 21:06:32 +0300
committer: Heikki Linnakangas <[email protected]>
date : Thu, 27 Jun 2024 21:06:32 +0300
We did not recover the subtransaction IDs of prepared transactions
when starting a hot standby from a shutdown checkpoint. As a result,
such subtransactions were considered as aborted, rather than
in-progress. That would lead to hint bits being set incorrectly, and
the subtransactions suddenly becoming visible to old snapshots when
the prepared transaction was committed.
To fix, update pg_subtrans with prepared transactions's subxids when
starting hot standby from a shutdown checkpoint. The snapshots taken
from that state need to be marked as "suboverflowed", so that we also
check the pg_subtrans.
Backport to all supported versions.
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xlog.c
M src/backend/storage/ipc/procarray.c
M src/backend/storage/ipc/standby.c
M src/include/storage/standby.h
M src/test/recovery/t/009_twophase.pl
M src/tools/pgindent/typedefs.list
tests: Trim newline from result returned by BackgroundPsql->query
commit : 266454f192e8f67e8e5e8e9f7667d7c8c77de232
author : Heikki Linnakangas <[email protected]>
date : Thu, 27 Jun 2024 21:06:27 +0300
committer: Heikki Linnakangas <[email protected]>
date : Thu, 27 Jun 2024 21:06:27 +0300
This went unnoticed, because only a few existing callers of
BackgroundPsql->query used the result, and the ones that did were not
bothered by an extra newline. I noticed because I was about to add a
new test that checks the result.
Backport to all supported versions, since I just backported the
BackgroundPsql facility to all supported versions too.
M src/test/perl/PostgreSQL/Test/BackgroundPsql.pm
Backport BackgroundPsql perl test module
commit : 4b467a6581af0ff029133558ce1f1e55597b8be1
author : Heikki Linnakangas <[email protected]>
date : Thu, 27 Jun 2024 19:00:59 +0300
committer: Heikki Linnakangas <[email protected]>
date : Thu, 27 Jun 2024 19:00:59 +0300
Backport the new BackgroundPsql modules and the constructor functions,
background_psql() and interactive_psql, to all supported
branches. That makes it easier to backpatch tests that use it.
BackgroundPsql was introduced in version 16. On version 16, this
commit backports just the new timeout argument from master (commit
334f512f45). On older branches, the whole facility. This includes the
change to `use warnings FATAL => 'all'`, which we haven't otherwise
backported, but it seems good to keep the file identical across
branches.
Discussion: https://www.postgresql.org/message-id/[email protected]
M contrib/amcheck/t/003_cic_2pc.pl
A src/test/perl/PostgreSQL/Test/BackgroundPsql.pm
M src/test/perl/PostgresNode.pm
M src/test/recovery/t/010_logical_decoding_timelines.pl
M src/test/recovery/t/031_recovery_conflict.pl
M src/test/recovery/t/037_invalid_database.pl
Remove redundant perl version checks
commit : ab46e132fa82cfcdd33accaa6eb18c887f3cd2a3
author : Andrew Dunstan <[email protected]>
date : Wed, 26 Jun 2024 07:01:47 -0400
committer: Andrew Dunstan <[email protected]>
date : Wed, 26 Jun 2024 07:01:47 -0400
Commit 4c1532763a removed some redundant uses of 'use 5.008001;' in perl
scripts, including in plperl's plc_perlboot.pl. Because it made other
changes it wasn't backpatched. However, now this is causing a failure on
back branches when built with bleeding edge perl. Therefore, backpatch
just that part of it which removed those uses, from 15 all the way down
to 9.2, which is the earliest version currently built in the buildfarm.
per report from Alexander Lakhin
Discussion: https://postgr.es/m/[email protected]
M src/pl/plperl/plc_perlboot.pl
M src/tools/pgindent/pgindent
Doc: Generated columns are skipped for logical replication.
commit : b0121801d3870a3663c8cef9224e8ada53a7008c
author : Amit Kapila <[email protected]>
date : Fri, 21 Jun 2024 09:16:06 +0530
committer: Amit Kapila <[email protected]>
date : Fri, 21 Jun 2024 09:16:06 +0530
Add a note in docs that generated columns are skipped for logical
replication.
Author: Peter Smith
Reviewed-by: Peter Eisentraut
Backpatch-through: 12
Discussion: https://postgr.es/m/CAHut+PuXb1GLQztQkoWzYjSwkAZZ0dgCJaAHyJtZF3kmtcL=kA@mail.gmail.com
M doc/src/sgml/ddl.sgml
Don't throw an error if a queued AFTER trigger no longer exists.
commit : b0037bbefda3339c821ff4b5d04d672274bf7238
author : Tom Lane <[email protected]>
date : Thu, 20 Jun 2024 14:21:36 -0400
committer: Tom Lane <[email protected]>
date : Thu, 20 Jun 2024 14:21:36 -0400
afterTriggerInvokeEvents and AfterTriggerExecute have always
treated it as an error if the trigger OID mentioned in a queued
after-trigger event can't be found. However, that fails to
account for the edge case where the trigger's been dropped in
the current transaction since queueing the event. There seems
no very good reason to disallow that case, so instead silently
do nothing if the trigger OID can't be found.
This does give up a little bit of bug-detection ability, but I don't
recall that these error messages have ever actually revealed a bug,
so it seems mostly theoretical. Alternatives such as marking
pending events DONE at the time of dropping a trigger would be
complicated and perhaps introduce bugs of their own.
Per bug #18517 from Alexander Lakhin. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRENTLY.
commit : 3e3e2ebea79c6327f1dbf279d1ee894153508558
author : Tom Lane <[email protected]>
date : Mon, 17 Jun 2024 14:30:59 -0400
committer: Tom Lane <[email protected]>
date : Mon, 17 Jun 2024 14:30:59 -0400
Reconstruction of an SP-GiST index by REINDEX CONCURRENTLY may
insert some REDIRECT tuples. This will typically happen in
a transaction that lacks an XID, which leads either to assertion
failure in spgFormDeadTuple or to insertion of a REDIRECT tuple
with zero xid. The latter's not good either, since eventually
VACUUM will apply GlobalVisTestIsRemovableXid() to the zero xid,
resulting in either an assertion failure or a garbage answer.
In practice, since REINDEX CONCURRENTLY locks out index scans
till it's done, it doesn't matter whether it inserts REDIRECTs
or PLACEHOLDERs; and likewise it doesn't matter how soon VACUUM
reduces such a REDIRECT to a PLACEHOLDER. So in non-assert builds
there's no observable problem here, other than perhaps a little
index bloat. But it's not behaving as intended.
To fix, remove the failing Assert in spgFormDeadTuple, acknowledging
that we might sometimes insert a zero XID; and guard VACUUM's
GlobalVisTestIsRemovableXid() call with a test for valid XID,
ensuring that we'll reduce such a REDIRECT the first time VACUUM
sees it. (Versions before v14 use TransactionIdPrecedes here,
which won't fail on zero xid, so they really have no bug at all
in non-assert builds.)
Another solution could be to not create REDIRECTs at all during
REINDEX CONCURRENTLY, making the relevant code paths treat that
case like index build (which likewise knows that no concurrent
index scans can be happening). That would allow restoring the
Assert in spgFormDeadTuple, but we'd still need the VACUUM change
because redirection tuples with zero xid may be out there already.
But there doesn't seem to be a nice way for spginsert() to tell that
it's being called in REINDEX CONCURRENTLY without some API changes,
so we'll leave that as a possible future improvement.
In HEAD, also rename the SpGistState.myXid field to redirectXid,
which seems less misleading (since it might not in fact be our
transaction's XID) and is certainly less uninformatively generic.
Per bug #18499 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/spgist/spgutils.c
M src/backend/access/spgist/spgvacuum.c
M src/include/access/spgist_private.h
Clean out column-level pg_init_privs entries when dropping tables.
commit : 0a39343ae7d7430f4a993c404d95162f60daf937
author : Tom Lane <[email protected]>
date : Fri, 14 Jun 2024 16:20:35 -0400
committer: Tom Lane <[email protected]>
date : Fri, 14 Jun 2024 16:20:35 -0400
DeleteInitPrivs did not get the memo about how, when dropping a
whole object (with subid == 0), you should drop entries relating
to its sub-objects too. This is visible in the test_pg_dump test
case if one drops the extension at the end: the entry for
GRANT SELECT(col1) ON regress_pg_dump_table TO public;
was still present in pg_init_privs afterwards, although it was
pointing to a dangling table OID.
Noted while fooling with a fix for REASSIGN OWNED for pg_init_privs
entries. This bug is aboriginal in the pg_init_privs feature
though, and there seems no reason not to back-patch the fix.
M src/backend/catalog/dependency.c
M src/test/modules/test_pg_dump/expected/test_pg_dump.out
M src/test/modules/test_pg_dump/sql/test_pg_dump.sql
Fix parsing of ignored operators in websearch_to_tsquery().
commit : 5e63a6f434152b34795e02f534615af2174707f7
author : Tom Lane <[email protected]>
date : Thu, 13 Jun 2024 20:34:43 -0400
committer: Tom Lane <[email protected]>
date : Thu, 13 Jun 2024 20:34:43 -0400
The manual says clearly that punctuation in the input of
websearch_to_tsquery() is ignored, except for the special cases
of dashes and quotes. However, this failed for cases like
"(foo bar) or something", or in general an ISOPERATOR character
in front of the "or". We'd switch back to WAITOPERAND state,
then ignore the operator character while remaining in that state,
and then reach the "or" in WAITOPERAND state which (intentionally)
makes us treat it as data.
The fix is simple enough: if we see an ISOPERATOR character while in
WAITOPERATOR state, we have to skip it while staying in that state.
(We don't need to worry about other punctuation characters: those will
be consumed as though they were words, but then rejected by lexizing.)
In v14 and up (since commit eb086056f) we can simplify the code a bit
more too, because there is no longer a reason for the WAITOPERAND
state to distinguish between quoted and unquoted operands.
Per bug #18479 from Manos Emmanouilidis. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/tsquery.c
M src/test/regress/expected/tsearch.out
M src/test/regress/sql/tsearch.sql
When replanning a plpgsql "simple expression", check it's still simple.
commit : ec210914c751e715913405e25d734f859f79a47a
author : Tom Lane <[email protected]>
date : Thu, 13 Jun 2024 13:37:46 -0400
committer: Tom Lane <[email protected]>
date : Thu, 13 Jun 2024 13:37:46 -0400
The previous coding here assumed that we didn't need to recheck any
of the querytree tests made in exec_simple_check_plan(). I think
we supposed that those properties were fully determined by the
syntax of the source text and hence couldn't change. That is true
for most of them, but at least hasTargetSRFs and hasAggs can change
by dint of forcibly dropping an originally-referenced function and
recreating it with new properties. That leads to "unexpected plan
node type" or similar failures.
These tests are pretty cheap compared to the cost of replanning, so
rather than sweat over exactly which properties need to be rechecked,
let's just recheck them all. Hence, factor out those tests into a new
function exec_is_simple_query(), and rearrange callers as needed.
A second problem in the same area was that if we failed during
replanning or during exec_save_simple_expr(), we'd potentially
leave behind now-dangling pointers to the old simple expression,
potentially resulting in crashes later. To fix, clear those pointers
before replanning.
The v12 code looks quite different in this area but still has the
bug about needing to recheck query simplicity. I chose to back-patch
all of the plpgsql_simple.sql test script, which formerly didn't exist
in this branch.
Per bug #18497 from Nikita Kalinin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/pl/plpgsql/src/Makefile
A src/pl/plpgsql/src/expected/plpgsql_simple.out
M src/pl/plpgsql/src/pl_exec.c
A src/pl/plpgsql/src/sql/plpgsql_simple.sql
Clamp result of MultiXactMemberFreezeThreshold
commit : a5662ba345e732c1f714409b38b75be98105aab6
author : Heikki Linnakangas <[email protected]>
date : Thu, 13 Jun 2024 19:01:30 +0300
committer: Heikki Linnakangas <[email protected]>
date : Thu, 13 Jun 2024 19:01:30 +0300
The purpose of the function is to reduce the effective
autovacuum_multixact_freeze_max_age if the multixact members SLRU is
approaching wraparound, to make multixid freezing more aggressive.
The returned value should therefore never be greater than plain
autovacuum_multixact_freeze_max_age.
Reviewed-by: Robert Haas
Discussion: https://www.postgresql.org/message-id/[email protected]
Backpatch-through: 12, all supported versions
M src/backend/access/transam/multixact.c
Skip some permissions checks on Cygwin
commit : ca947649208ce7343c54c8f92e67ea9274be812c
author : Andrew Dunstan <[email protected]>
date : Thu, 13 Jun 2024 07:38:48 -0400
committer: Andrew Dunstan <[email protected]>
date : Thu, 13 Jun 2024 07:38:48 -0400
These are checks that are already skipped on other Windows systems.
Backpatch to all live branches, as appropriate.
M src/bin/initdb/t/001_initdb.pl
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/bin/pg_ctl/t/001_start_stop.pl
M src/bin/pg_rewind/t/002_databases.pl
Fix infer_arbiter_indexes() to not assume resultRelation is 1.
commit : 9256bf6eb35a06d5d78db1c3cae7e23225038172
author : Tom Lane <[email protected]>
date : Tue, 11 Jun 2024 17:57:46 -0400
committer: Tom Lane <[email protected]>
date : Tue, 11 Jun 2024 17:57:46 -0400
infer_arbiter_indexes failed to renumber varnos in index expressions
or predicates that it got from the catalogs. This escaped detection
up to now because the stored varnos in such trees will be 1, and an
INSERT's result relation is usually the first rangetable entry,
so that that was fine. However, in cases such as inserting through
an updatable view, it's not fine, leading to failure to match the
expressions to the query with ensuing "there is no unique or exclusion
constraint matching the ON CONFLICT specification" errors.
Fix by copy-and-paste from get_relation_info().
Per bug #18502 from Michael Wang. Back-patch to all supported
versions.
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/util/plancat.c
M src/test/regress/expected/insert_conflict.out
M src/test/regress/sql/insert_conflict.sql
Tighten test_predtest's input checks, and improve error messages.
commit : f4b44f2786950782526b407ead5daa849df3cb1b
author : Tom Lane <[email protected]>
date : Fri, 7 Jun 2024 16:45:56 -0400
committer: Tom Lane <[email protected]>
date : Fri, 7 Jun 2024 16:45:56 -0400
test_predtest() neglected to consider the possibility that
SPI_plan_get_cached_plan would return NULL. This led to a core
dump if the input (incorrectly) contains more than one SQL
command.
While here, let's expend more than zero effort on the error
message for this case and nearby ones.
Per (half of) bug #18483 from Alexander Kozhemyakin.
Back-patch to all supported branches, not because this is
very significant (it's merely test scaffolding) but to make
our world a bit safer for fuzz testing.
Discussion: https://postgr.es/m/[email protected]
M src/test/modules/test_predtest/test_predtest.c
Reject modifying a temp table of another session with ALTER TABLE.
commit : b8efd756dfc7be368d9dc679e367c66cf815e4d8
author : Tom Lane <[email protected]>
date : Fri, 7 Jun 2024 14:50:09 -0400
committer: Tom Lane <[email protected]>
date : Fri, 7 Jun 2024 14:50:09 -0400
Normally this case isn't even reachable by non-superusers, since
permissions checks prevent naming such a table. However, it is
possible to make it happen by altering a parent table whose child
is another session's temp table.
We definitely can't support any such ALTER that requires modifying
the contents of such a table, since we lack access to the other
session's temporary-buffer pool. But there seems no good reason
to allow it even if it'd only require changing catalog contents.
One reason not to allow it is that we'd rather not expose the
implementation-dependent behavior of whether a specific ALTER
requires touching the table contents. Another is that there may
be (in future, even if not today) optimizations that assume that
a session's own temp tables won't be modified by other sessions.
Hence, add a RELATION_IS_OTHER_TEMP() check to all the places
where ALTER TABLE currently does CheckTableNotInUse(). (I looked
through all other callers of CheckTableNotInUse(), and they seem
OK already.)
Per bug #18492 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
Fix behavior of stable functions called from a CALL's argument list.
commit : 0be81dd71c854eaea506100765a0a52b9e54b461
author : Tom Lane <[email protected]>
date : Fri, 7 Jun 2024 13:27:26 -0400
committer: Tom Lane <[email protected]>
date : Fri, 7 Jun 2024 13:27:26 -0400
If the CALL is within an atomic context (e.g. there's an outer
transaction block), _SPI_execute_plan should acquire a fresh snapshot
to execute any such functions with. We failed to do that and instead
passed them the Portal snapshot, which had been acquired at the start
of the current SQL command. This'd lead to seeing stale values of
rows modified since the start of the command.
This is arguably a bug in 84f5c2908: I failed to see that "are we in
non-atomic mode" needs to be defined the same way as it is further
down in _SPI_execute_plan, i.e. check !_SPI_current->atomic not just
options->allow_nonatomic. Alternatively the blame could be laid on
plpgsql, which is unconditionally passing allow_nonatomic = true
for CALL/DO even when it knows it's in an atomic context. However,
fixing it in spi.c seems like a better idea since that will also fix
the problem for any extensions that may have copied plpgsql's coding
pattern.
While here, update an obsolete comment about _SPI_execute_plan's
snapshot management.
Per report from Victor Yegorov. Back-patch to all supported versions.
Discussion: https://postgr.es/m/CAGnEboiRe+fG2QxuBO2390F7P8e2MQ6UyBjZSL_w1Cej+E4=Vw@mail.gmail.com
M src/backend/executor/spi.c
M src/pl/plpgsql/src/expected/plpgsql_call.out
M src/pl/plpgsql/src/sql/plpgsql_call.sql
doc: Fix copy-and-paste mistake
commit : 9c4ce2da10551ae9fd695bb62494294b4ee07f95
author : Peter Eisentraut <[email protected]>
date : Fri, 7 Jun 2024 08:02:15 +0200
committer: Peter Eisentraut <[email protected]>
date : Fri, 7 Jun 2024 08:02:15 +0200
The wording from the "columns" view was copied to the "attributes"
view without the required adjustments.
M doc/src/sgml/information_schema.sgml
Fix failure with SQL-procedure polymorphic output arguments in v12.
commit : 4208f44c9469fa6b105bbb1d1f7ee18b37472860
author : Tom Lane <[email protected]>
date : Thu, 6 Jun 2024 15:16:56 -0400
committer: Tom Lane <[email protected]>
date : Thu, 6 Jun 2024 15:16:56 -0400
Before the v13-era commit 913bbd88d, check_sql_fn_retval fails to
resolve polymorphic output types and then just throws up its hands and
assumes the check will be made at runtime. I think that's true for
ordinary functions returning RECORD, but it doesn't happen in CALL,
potentially resulting in crashes if the actual output of the SQL
procedure's SELECT doesn't match the type inferred from polymorphism.
With a little bit of rearrangement, we can use get_call_result_type
instead of get_func_result_type and thereby infer the correct types.
I'm still unwilling to back-patch all of 913bbd88d, so if the types
don't match you'll get an error rather than perhaps silently inserting
a cast as v13 and later can. That's consistent with prior behavior
though, so it seems fine.
Prior to 70ffb27b2, you'd typically get other errors due to other
shortcomings of CALL's management of polymorphism. Nonetheless,
this is an independent bug.
Although there is no bug in v13 and up, it seems prudent to add
the test case for this to the newer branches too. It's clearly
an under-tested area.
Per report from Andrew Bille.
Discussion: https://postgr.es/m/CAJnzarw9EeWHAQRm76dXd=7j+rgw6ERqC=nCay8jeFqTwKwhqQ@mail.gmail.com
M src/backend/executor/functions.c
M src/test/regress/expected/create_procedure.out
M src/test/regress/sql/create_procedure.sql
Fix documentation for POSIX semaphores.
commit : 78fe33742dccc23d4b8a4a1cc7a311e7be0403d1
author : Nathan Bossart <[email protected]>
date : Wed, 5 Jun 2024 15:32:47 -0500
committer: Nathan Bossart <[email protected]>
date : Wed, 5 Jun 2024 15:32:47 -0500
The documentation for POSIX semaphores is missing a reference to
max_wal_senders. This commit fixes that in the same way that
commit 4ebe51a5fb fixed the same issue in the documentation for
System V semaphores.
Discussion: https://postgr.es/m/20240517164452.GA1914161%40nathanxps13
Backpatch-through: 12
M doc/src/sgml/runtime.sgml
Fix pl/tcl's handling of errors from Tcl_ListObjGetElements().
commit : 30487423c8296ea448f4deb56f5caec46111b763
author : Tom Lane <[email protected]>
date : Tue, 4 Jun 2024 18:02:13 -0400
committer: Tom Lane <[email protected]>
date : Tue, 4 Jun 2024 18:02:13 -0400
In a procedure or function returning tuple, we use that function to
parse the Tcl script's result, which is supposed to be a Tcl list.
If it isn't, you get an error. Commit 26abb50c4 incautiously
supposed that we could use throw_tcl_error() to report such an error.
That doesn't actually work, because low-level functions like
Tcl_ListObjGetElements() don't fill Tcl's errorInfo variable.
The result is either a null-pointer-dereference crash or emission
of misleading context information describing the previous Tcl error.
Back off to just reporting the interpreter's result string, and
improve throw_tcl_error()'s comment to explain when to use it.
Also, although the similar code in pltcl_trigger_handler() avoided
this mistake, it was using a fairly confusing wording of the
error message. Improve that while we're here.
Per report from A. Kozhemyakin. Back-patch to all supported
branches.
Erik Wienhold and Tom Lane
Discussion: https://postgr.es/m/[email protected]
M src/pl/tcl/expected/pltcl_call.out
M src/pl/tcl/pltcl.c
M src/pl/tcl/sql/pltcl_call.sql
Fix documentation for System V semaphores.
commit : 09d7caad32d8d6987964a85ff71d12f18f63f43f
author : Nathan Bossart <[email protected]>
date : Mon, 3 Jun 2024 12:10:43 -0500
committer: Nathan Bossart <[email protected]>
date : Mon, 3 Jun 2024 12:10:43 -0500
The formulas for SEMMNI and SEMMNS do not include the archiver
process, which was converted to an auxiliary process in v14, and
the WAL summarizer process, which was introduced in v17. This
commit corrects these formulas and adds a missing reference to
max_wal_senders nearby. Since this section of the documentation
tends to be incorrect quite often, we should likely give up on
documenting the exact formulas in favor of something less fragile,
but that is left as a future exercise.
Reported-by: Sami Imseih
Reviewed-by: Sami Imseih
Discussion: https://postgr.es/m/20240517164452.GA1914161%40nathanxps13
Backpatch-through: 12
M doc/src/sgml/runtime.sgml
Remove race conditions between ECPGdebug() and ecpg_log().
commit : cd8f1c1207994c8b3d41c48a02fa40547ee48bea
author : Tom Lane <[email protected]>
date : Thu, 23 May 2024 15:52:06 -0400
committer: Tom Lane <[email protected]>
date : Thu, 23 May 2024 15:52:06 -0400
Coverity complains that ECPGdebug is accessing debugstream without
holding debug_mutex, which is a fair complaint: we should take
debug_mutex while changing the settings ecpg_log looks at.
In some branches it also complains about unlocked use of simple_debug.
I think it's intentional and safe to have a quick unlocked check of
simple_debug at the start of ecpg_log, since that early exit will
always be taken in non-debug cases. But we should recheck
simple_debug after acquiring the mutex. In the worst case, calling
ECPGdebug concurrently with ecpg_log in another thread could result
in a null-pointer dereference due to debugstream transiently being
NULL while simple_debug isn't 0.
This is largely hypothetical, since it's unlikely anybody uses
ECPGdebug() at all in the field, and our own regression tests
don't seem to be hitting the theoretical race conditions either.
Still, if we're going to the trouble of having mutexes here, we ought
to be using them in a way that's actually safe not just almost safe.
Hence, back-patch to all supported branches.
M src/interfaces/ecpg/ecpglib/misc.c
doc: Fix column_name parameter in ALTER MATERIALIZED VIEW
commit : c0acf25a5cf2d62b60d82e5bb0c553ce9c05a51d
author : Michael Paquier <[email protected]>
date : Thu, 23 May 2024 13:03:22 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 23 May 2024 13:03:22 +0900
Parameter column_name must be an existing column because ALTER
MATERIALIZED VIEW cannot add new columns. The old description was
likely copied from ALTER TABLE.
Author: Erik Wienhold
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M doc/src/sgml/ref/alter_materialized_view.sgml
Account for optimized MinMax aggregates during SS_finalize_plan.
commit : 686c995fc2223426706ee3f2472e220e7aac4041
author : Tom Lane <[email protected]>
date : Sat, 18 May 2024 14:31:35 -0400
committer: Tom Lane <[email protected]>
date : Sat, 18 May 2024 14:31:35 -0400
We are capable of optimizing MIN() and MAX() aggregates on indexed
columns into subqueries that exploit the index, rather than the normal
thing of scanning the whole table. When we do this, we replace the
Aggref node(s) with Params referencing subquery outputs. Such Params
really ought to be included in the per-plan-node extParam/allParam
sets computed by SS_finalize_plan. However, we've never done so
up to now because of an ancient implementation choice to perform
that substitution during set_plan_references, which runs after
SS_finalize_plan, so that SS_finalize_plan never sees these Params.
The cleanest fix would be to perform a separate tree walk to do
these substitutions before SS_finalize_plan runs. That seems
unattractive, first because a whole-tree mutation pass is expensive,
and second because we lack infrastructure for visiting expression
subtrees in a Plan tree, so that we'd need a new function knowing
as much as SS_finalize_plan knows about that. I also considered
swapping the order of SS_finalize_plan and set_plan_references,
but that fell foul of various assumptions that seem tricky to fix.
So the approach adopted here is to teach SS_finalize_plan itself
to check for such Aggrefs. I refactored things a bit in setrefs.c
to avoid having three copies of the code that does that.
Back-patch of v17 commits d0d44049d and 779ac2c74. When d0d44049d
went in, there was no evidence that it was fixing a reachable bug,
so I refrained from back-patching. Now we have such evidence.
Per bug #18465 from Hal Takahara. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/plan/setrefs.c
M src/backend/optimizer/plan/subselect.c
M src/include/optimizer/planmain.h
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql
Refuse upgrades from pre-9.0 clusters
commit : bcd2be0c2f7e494597ad02a69127c82478369b07
author : Daniel Gustafsson <[email protected]>
date : Fri, 17 May 2024 14:24:27 +0200
committer: Daniel Gustafsson <[email protected]>
date : Fri, 17 May 2024 14:24:27 +0200
Commit 695b4a113ab added a dependency on retrieving oldestxid from
pg_control, which only exists in 9.0 and onwards, but the check for
8.4 as the oldest version was retained. Since there has been few if
any complaints of 8.4 upgrades not working, fix by setting 9.0 as
the oldest version supported rather than resurrecting 8.4 support.
Backpatch to all supported versions.
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: v12
M doc/src/sgml/ref/pgupgrade.sgml
M src/bin/pg_upgrade/check.c
doc: Remove claims that initdb and pg_ctl use libpq environment variables
commit : 3566fc0150acd569079a90a65c4d2a2b501e067f
author : Peter Eisentraut <[email protected]>
date : Wed, 15 May 2024 13:05:30 +0200
committer: Peter Eisentraut <[email protected]>
date : Wed, 15 May 2024 13:05:30 +0200
Erroneously introduced by 571df93cff8.
Reviewed-by: Daniel Gustafsson <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/8458c9c5-18f1-46d7-94c4-1c30e4f44908%40eisentraut.org
M doc/src/sgml/ref/initdb.sgml
M doc/src/sgml/ref/pg_ctl-ref.sgml
Fix handling of polymorphic output arguments for procedures.
commit : 70ffb27b2349441b6a62b41338ac19aadb619151
author : Tom Lane <[email protected]>
date : Tue, 14 May 2024 20:19:20 -0400
committer: Tom Lane <[email protected]>
date : Tue, 14 May 2024 20:19:20 -0400
Most of the infrastructure for procedure arguments was already
okay with polymorphic output arguments, but it turns out that
CallStmtResultDesc() was a few bricks shy of a load here. It thought
all it needed to do was call build_function_result_tupdesc_t, but
that function specifically disclaims responsibility for resolving
polymorphic arguments. Failing to handle that doesn't seem to be
a problem for CALL in plpgsql, but CALL from plain SQL would get
errors like "cannot display a value of type anyelement", or even
crash outright.
In v14 and later we can simply examine the exposed types of the
CallStmt.outargs nodes to get the right type OIDs. But it's a lot
more complicated to fix in v12/v13, because those versions don't
have CallStmt.outargs, nor do they do expand_function_arguments
until ExecuteCallStmt runs. We have to duplicatively run
expand_function_arguments, and then re-determine which elements
of the args list are output arguments.
Per bug #18463 from Drew Kimball. Back-patch to all supported
versions, since it's busted in all of them.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/functioncmds.c
M src/pl/plpgsql/src/expected/plpgsql_call.out
M src/pl/plpgsql/src/sql/plpgsql_call.sql
M src/test/regress/expected/create_procedure.out
M src/test/regress/sql/create_procedure.sql
Fix pg_sequence_last_value() for unlogged sequences on standbys.
commit : 2812059d3eeaa05ef98dc2e2cc71a716967aeeb8
author : Nathan Bossart <[email protected]>
date : Mon, 13 May 2024 15:53:50 -0500
committer: Nathan Bossart <[email protected]>
date : Mon, 13 May 2024 15:53:50 -0500
Presently, when this function is called for an unlogged sequence on
a standby server, it will error out with a message like
ERROR: could not open file "base/5/16388": No such file or directory
Since the pg_sequences system view uses pg_sequence_last_value(),
it can error similarly. To fix, modify the function to return NULL
for unlogged sequences on standby servers. Since this bug is
present on all versions since v15, this approach is preferable to
making the ERROR nicer because we need to repair the pg_sequences
view without modifying its definition on released versions. For
consistency, this commit also modifies the function to return NULL
for other sessions' temporary sequences. The pg_sequences view
already appropriately filters out such sequences, so there's no bug
there, but we might as well offer some defense in case someone
invokes this function directly.
Unlogged sequences were first introduced in v15, but temporary
sequences are much older, so while the fix for unlogged sequences
is only back-patched to v15, the temporary sequence portion is
back-patched to all supported versions.
We could also remove the privilege check in the pg_sequences view
definition in v18 if we modify this function to return NULL for
sequences for which the current user lacks privileges, but that is
left as a future exercise for when v18 development begins.
Reviewed-by: Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/20240501005730.GA594666%40nathanxps13
Backpatch-through: 12
M src/backend/commands/sequence.c
Fix recursive RECORD-returning plpython functions.
commit : 157b1e6b41b4a1f4bdb3166c791bb3a103abd8c4
author : Tom Lane <[email protected]>
date : Thu, 9 May 2024 13:16:21 -0400
committer: Tom Lane <[email protected]>
date : Thu, 9 May 2024 13:16:21 -0400
If we recursed to a new call of the same function, with a different
coldeflist (AS clause), it would fail because the inner call would
overwrite the outer call's idea of what to return. This is vaguely
like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions:
it's just that we computed the actual output rowtype at the start of
the call, and saved it in the per-procedure data structure. We can
fix it at basically zero cost by doing the computation at the end
of each call instead of the start.
It's not clear that there's any real-world use-case for such a
function, but given that it doesn't cost anything to fix,
it'd be silly not to.
Per report from Andreas Karlsson. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/pl/plpython/expected/plpython_composite.out
M src/pl/plpython/plpy_exec.c
M src/pl/plpython/sql/plpython_composite.sql
Ensure that "pg_restore -l" reports dependent TOC entries correctly.
commit : a3c00ab1545029ee5d8c87d55da976ae1ccf2ba8
author : Tom Lane <[email protected]>
date : Tue, 7 May 2024 18:22:52 -0400
committer: Tom Lane <[email protected]>
date : Tue, 7 May 2024 18:22:52 -0400
If -l was specified together with selective-restore options such as -n
or -N, dependent TOC entries such as comments would be omitted from
the listing, even when an actual restore would have selected them.
This happened because PrintTOCSummary neglected to update the te->reqs
marking of the entry they depended on.
Per report from Justin Pryzby. This has been wrong since 0d4e6ed30
taught _tocEntryRequired to sometimes look at the "reqs" marking of
other TOC entries, so back-patch to all supported branches.
Discussion: https://postgr.es/m/ZjoeirG7yxODdC4P@pryzbyj2023
M src/bin/pg_dump/pg_backup_archiver.c
Don't corrupt plpython's "TD" dictionary in a recursive trigger call.
commit : 4488142a463c623d3567b1452deb6d768cd0ee9b
author : Tom Lane <[email protected]>
date : Tue, 7 May 2024 18:15:00 -0400
committer: Tom Lane <[email protected]>
date : Tue, 7 May 2024 18:15:00 -0400
If a plpython-language trigger caused another one to be invoked,
the "TD" dictionary created for the inner one would overwrite the
outer one's "TD" dictionary. This is more or less the same problem
that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it
the same way, by saving and restoring "TD" during a recursive
invocation.
This fix makes an ABI-incompatible change in struct PLySavedArgs.
I'm not too worried about that because it seems highly unlikely that
any extension is messing with those structs. We could imagine doing
something weird to preserve nominal ABI compatibility in the back
branches, like keeping the saved TD object in an extra element of
namedargs[]. However, that would only be very nominal compatibility:
if anything *is* touching PLySavedArgs, it would likely do the wrong
thing due to not knowing about the additional value. So I judge it
not worth the ugliness to do something different there.
(I also changed struct PLyProcedure, but its added field fits
into formerly-padding space, so that should be safe.)
Per bug #18456 from Jacques Combrink. This bug is very ancient,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/pl/plpython/expected/plpython_trigger.out
M src/pl/plpython/plpy_exec.c
M src/pl/plpython/plpy_procedure.c
M src/pl/plpython/plpy_procedure.h
M src/pl/plpython/sql/plpython_trigger.sql