Stamp 17.0.
commit : d7ec59a63d745ba74fba0e280bbf85dc6d1caa3e
author : Tom Lane <[email protected]>
date : Mon, 23 Sep 2024 16:02:53 -0400
committer: Tom Lane <[email protected]>
date : Mon, 23 Sep 2024 16:02:53 -0400
M configure
M configure.ac
M meson.build
Translation updates
commit : 29d483fb33229f4322ca6cd040422ac508c678c1
author : Peter Eisentraut <[email protected]>
date : Mon, 23 Sep 2024 12:06:47 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 23 Sep 2024 12:06:47 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 4b069f67b5be4227eb620a74c9900f079f2e59f4
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/ru.po
M src/bin/pg_amcheck/po/fr.po
M src/bin/pg_amcheck/po/ru.po
M src/bin/pg_archivecleanup/po/fr.po
M src/bin/pg_archivecleanup/po/ru.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_checksums/po/fr.po
M src/bin/pg_checksums/po/ru.po
M src/bin/pg_combinebackup/po/LINGUAS
M src/bin/pg_combinebackup/po/fr.po
A src/bin/pg_combinebackup/po/ru.po
M src/bin/pg_config/po/fr.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_config/po/zh_CN.po
M src/bin/pg_controldata/po/fr.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/fr.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetwal/po/fr.po
M src/bin/pg_resetwal/po/ru.po
M src/bin/pg_rewind/po/fr.po
M src/bin/pg_rewind/po/ru.po
M src/bin/pg_test_fsync/po/fr.po
M src/bin/pg_test_fsync/po/ru.po
M src/bin/pg_test_timing/po/fr.po
M src/bin/pg_test_timing/po/ru.po
M src/bin/pg_upgrade/po/fr.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_verifybackup/po/fr.po
M src/bin/pg_verifybackup/po/ru.po
M src/bin/pg_waldump/po/fr.po
M src/bin/pg_waldump/po/ru.po
M src/bin/pg_walsummary/po/LINGUAS
M src/bin/pg_walsummary/po/fr.po
A src/bin/pg_walsummary/po/ru.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/fr.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/fr.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/preproc/po/fr.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/fr.po
M src/pl/plperl/po/ru.po
M src/pl/plpgsql/src/po/fr.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/ru.po
M src/pl/plpython/po/zh_CN.po
M src/pl/tcl/po/fr.po
M src/pl/tcl/po/ru.po
M src/pl/tcl/po/zh_CN.po
Doc: update 17.0 release date.
commit : 64b61fa5d7807a98b5a51024960698894799d936
author : Tom Lane <[email protected]>
date : Fri, 20 Sep 2024 16:19:34 -0400
committer: Tom Lane <[email protected]>
date : Fri, 20 Sep 2024 16:19:34 -0400
Also some trivial copy-editing.
M doc/src/sgml/release-17.sgml
doc PG 17 relnotes: add major features list
commit : 1d7cef2b60b90673eb23e26fdb58dcc3e521ba55
author : Bruce Momjian <[email protected]>
date : Fri, 20 Sep 2024 16:00:10 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 20 Sep 2024 16:00:10 -0400
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Author: Jonathan Katz
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
Doc: explain how to test ADMIN privilege with pg_has_role().
commit : a47ad3a42dddf028a5bff525c83fce3035922a79
author : Tom Lane <[email protected]>
date : Fri, 20 Sep 2024 15:56:34 -0400
committer: Tom Lane <[email protected]>
date : Fri, 20 Sep 2024 15:56:34 -0400
This has always been possible, but the syntax is a bit obscure,
and our user-facing docs were not very helpful. Spell it out
more clearly.
Per complaint from Dominique Devienne. Back-patch to
all supported branches.
Discussion: https://postgr.es/m/CAFCRh-8JNEy+dV4SXFOrWca50u+d=--TO4cq=+ac1oBtfJy4AA@mail.gmail.com
M doc/src/sgml/func.sgml
Fix nbtree pgstats accounting with parallel scans.
commit : fb4f5e58af971aa8e9620d207be96f8056b571b6
author : Peter Geoghegan <[email protected]>
date : Fri, 20 Sep 2024 14:06:30 -0400
committer: Peter Geoghegan <[email protected]>
date : Fri, 20 Sep 2024 14:06:30 -0400
Commit 5bf748b8, which enhanced nbtree ScalarArrayOp execution, made
parallel index scans work with the new design for arrays via explicit
scheduling of primitive index scans. Under this scheme a parallel index
scan with array keys will perform the same number of index descents as
an equivalent serial index scan (barring corner cases where an
individual parallel worker discovers that it can advance the scan's
array keys without anybody needing to perform another descent of the
index to get to the relevant page on the leaf level).
Despite all this, the pgstats accounting wasn't updated; it continued to
increment the total number of index scans for the rel once per _bt_first
call, no matter the details. As a result, the number of (primitive)
index scans could be over-counted during parallel scans.
To fix, delay incrementing the count of index scans until after we've
established that another descent of the index (using either _bt_search
or _bt_endpoint) is required. That way pg_stat_user_tables.idx_scan
always advances in the same way, regardless of whether or not the scan
makes use of parallelism.
Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp
execution.
Author: Peter Geoghegan <[email protected]>
Reviewed-By: Tomas Vondra <[email protected]>
Discussion: https://postgr.es/m/CAH2-Wz=E7XrkvscBN0U6V81NK3Q-dQOmivvbEsjG-zwEfDdFpg@mail.gmail.com
Discussion: https://postgr.es/m/CAH2-WzkRqvaqR2CTNqTZP0z6FuL4-3ED6eQB0yx38XBNj1v-4Q@mail.gmail.com
Backpatch: 17-, where nbtree SAOP execution was enhanced.
M src/backend/access/nbtree/nbtsearch.c
doc PG relnotes: remove warning about commit links in PDF build
commit : a24cd4bf5d0f0bbe86f99eebf0fac261b1ca4536
author : Bruce Momjian <[email protected]>
date : Thu, 19 Sep 2024 18:05:22 -0400
committer: Bruce Momjian <[email protected]>
date : Thu, 19 Sep 2024 18:05:22 -0400
Make paragraph empty instead of removing it.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M doc/src/sgml/stylesheet-fo.xsl
doc PG relnotes: document "Unresolved ID reference found" cause
commit : ff25193e5623bf458bc19fc71f25f7ce02ffccef
author : Bruce Momjian <[email protected]>
date : Thu, 19 Sep 2024 12:01:59 -0400
committer: Bruce Momjian <[email protected]>
date : Thu, 19 Sep 2024 12:01:59 -0400
Backpatch-through: 12
M doc/src/sgml/stylesheet-fo.xsl
doc PG relnotes: rename commit link paragraph for clarity
commit : 95fba23317e680f33c88c7d00cfbbe8b225176d5
author : Bruce Momjian <[email protected]>
date : Thu, 19 Sep 2024 09:47:22 -0400
committer: Bruce Momjian <[email protected]>
date : Thu, 19 Sep 2024 09:47:22 -0400
FYI, during PDF builds, this link type generates a "Unresolved ID
reference found" warning because it is suppressed from the PDF output.
Backpatch-through: 12
M doc/src/sgml/release.sgml
M doc/src/sgml/stylesheet-fo.xsl
Improve Perl script which adds commit links to release notes
commit : 681bbd07cccbbc5b3e3d94b908bb1d5431af16cc
author : Bruce Momjian <[email protected]>
date : Thu, 19 Sep 2024 08:45:32 -0400
committer: Bruce Momjian <[email protected]>
date : Thu, 19 Sep 2024 08:45:32 -0400
Reported-by: Andrew Dunstan
Discussion: https://postgr.es/m/[email protected]
Author: Andrew Dunstan
Backpatch-through: 12
M src/tools/add_commit_links.pl
psql: Fix memory leak with repeated calls of \bind
commit : b0ae6db2088bbd1d16733b359c9c300735e9c21e
author : Michael Paquier <[email protected]>
date : Thu, 19 Sep 2024 16:25:07 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 19 Sep 2024 16:25:07 +0900
Calling \bind repeatedly would cause the memory allocated for the list
of bind parameters to be leaked after each call, as the list is reset
when beginning a single call.
This issue is fixed by making the cleanup of the bind parameter list
more aggressive, refactoring it into a single routine called after
processing a query and before running an individual \bind.
HEAD required more surgery and has been fixed by 87eeadaea143. Issue
introduced by 5b66de3433e2.
Reported-by: Anthonin Bonnefoy
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 16
M src/bin/psql/command.c
M src/bin/psql/common.c
M src/bin/psql/common.h
doc PG relnotes: add paragraph explaining the section symbol
commit : 19b389c60871cd14b07dfb244a519d8cb83988cc
author : Bruce Momjian <[email protected]>
date : Wed, 18 Sep 2024 17:13:19 -0400
committer: Bruce Momjian <[email protected]>
date : Wed, 18 Sep 2024 17:13:19 -0400
And suppress the symbol in print mode, where the section symbol does not
appear.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M doc/src/sgml/release.sgml
M doc/src/sgml/stylesheet-fo.xsl
doc PG relnotes: no relnote footnotes for commit links in PDF
commit : 120f883d7924f38e296d68738ed067f46fd1b303
author : Bruce Momjian <[email protected]>
date : Wed, 18 Sep 2024 16:34:52 -0400
committer: Bruce Momjian <[email protected]>
date : Wed, 18 Sep 2024 16:34:52 -0400
In print output, there are too many commit links for footnotes in the
release notes to be useful.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M doc/src/sgml/stylesheet-fo.xsl
docs: Improve the description of num_timed column in pg_stat_checkpointer.
commit : fa3a022136fc6d7138ad217bfc8ac7e76d6d38f8
author : Fujii Masao <[email protected]>
date : Thu, 19 Sep 2024 02:14:10 +0900
committer: Fujii Masao <[email protected]>
date : Thu, 19 Sep 2024 02:14:10 +0900
The previous documentation stated that num_timed reflects the number of
scheduled checkpoints performed. However, checkpoints may be skipped
if the server has been idle, and num_timed counts both skipped and completed
checkpoints. This commit clarifies the description to make it clear that
the counter includes both skipped and completed checkpoints.
Back-patch to v17 where pg_stat_checkpointer was added.
Author: Fujii Masao
Reviewed-by: Alexander Korotkov
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/monitoring.sgml
Update list of acknowledgments in release notes
commit : 633b609e1c239968e80a645951a28fcded53e44b
author : Peter Eisentraut <[email protected]>
date : Wed, 18 Sep 2024 09:08:31 +0200
committer: Peter Eisentraut <[email protected]>
date : Wed, 18 Sep 2024 09:08:31 +0200
current through 2370582ab14
M doc/src/sgml/release-17.sgml
Don't enter parallel mode when holding interrupts.
commit : 2370582ab14f179eb8edd748d629edf991999989
author : Noah Misch <[email protected]>
date : Tue, 17 Sep 2024 19:53:11 -0700
committer: Noah Misch <[email protected]>
date : Tue, 17 Sep 2024 19:53:11 -0700
Doing so caused the leader to hang in wait_event=ParallelFinish, which
required an immediate shutdown to resolve. Back-patch to v12 (all
supported versions).
Francesco Degrassi
Discussion: https://postgr.es/m/CAC-SaSzHUKT=vZJ8MPxYdC_URPfax+yoA1hKTcF4ROz_Q6z0_Q@mail.gmail.com
M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/select_parallel.out
M src/test/regress/sql/select_parallel.sql
Add missing query ID reporting in extended query protocol
commit : 7db9bfc1f78b2d1d7fe0b3dd6c8036d28075086a
author : Michael Paquier <[email protected]>
date : Wed, 18 Sep 2024 09:59:14 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 18 Sep 2024 09:59:14 +0900
This commit adds query ID reports for two code paths when processing
extended query protocol messages:
- When receiving a bind message, setting it to the first Query retrieved
from a cached cache.
- When receiving an execute message, setting it to the first PlannedStmt
stored in a portal.
An advantage of this method is that this is able to cover all the types
of portals handled in the extended query protocol, particularly these
two when the report done in ExecutorStart() is not enough (neither is an
addition in ExecutorRun(), actually, for the second point):
- Multiple execute messages, with multiple ExecutorRun().
- Portal with execute/fetch messages, like a query with a RETURNING
clause and a fetch size that stores the tuples in a first execute
message going though ExecutorStart() and ExecuteRun(), followed by one
or more execute messages doing only fetches from the tuplestore created
in the first message. This corresponds to the case where
execute_is_fetch is set, for example.
Note that the query ID reporting done in ExecutorStart() is still
necessary, as an EXECUTE requires it. Query ID reporting is optimistic
and more calls to pgstat_report_query_id() don't matter as the first
report takes priority except if the report is forced. The comment in
ExecutorStart() is adjusted to reflect better the reality with the
extended query protocol.
The test added in pg_stat_statements is a courtesy of Robert Haas. This
uses psql's \bind metacommand, hence this part is backpatched down to
v16.
Reported-by: Kaido Vaikla, Erik Wienhold
Author: Sami Imseih
Reviewed-by: Jian He, Andrei Lepikhov, Michael Paquier
Discussion: https://postgr.es/m/CA+427g8DiW3aZ6pOpVgkPbqK97ouBdf18VLiHFesea2jUk3XoQ@mail.gmail.com
Discussion: https://postgr.es/m/CA+TgmoZxtnf_jZ=VqBSyaU8hfUkkwoJCJ6ufy4LGpXaunKrjrg@mail.gmail.com
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 14
M contrib/pg_stat_statements/Makefile
A contrib/pg_stat_statements/expected/extended.out
M contrib/pg_stat_statements/meson.build
A contrib/pg_stat_statements/sql/extended.sql
M src/backend/executor/execMain.c
M src/backend/tcop/postgres.c
Allow ReadStream to be consumed as raw block numbers.
commit : ec1d545c8f7093537ee644bb33137fff91277463
author : Thomas Munro <[email protected]>
date : Wed, 18 Sep 2024 09:20:59 +1200
committer: Thomas Munro <[email protected]>
date : Wed, 18 Sep 2024 09:20:59 +1200
Commits 041b9680 and 6377e12a changed the interface of
scan_analyze_next_block() to take a ReadStream instead of a BlockNumber
and a BufferAccessStrategy, and to return a value to indicate when the
stream has run out of blocks.
This caused integration problems for at least one known extension that
uses specially encoded BlockNumber values that map to different
underlying storage, because acquire_sample_rows() sets up the stream so
that read_stream_next_buffer() reads blocks from the main fork of the
relation's SMgrRelation.
Provide read_stream_next_block(), as a way for such an extension to
access the stream of raw BlockNumbers directly and forward them to its
own ReadBuffer() calls after decoding, as it could in earlier releases.
The new function returns the BlockNumber and BufferAccessStrategy that
were previously passed directly to scan_analyze_next_block().
Alternatively, an extension could wrap the stream of BlockNumbers in
another ReadStream with a callback that performs any decoding required
to arrive at real storage manager BlockNumber values, so that it could
benefit from the I/O combining and concurrency provided by
read_stream.c.
Another class of table access method that does nothing in
scan_analyze_next_block() because it is not block-oriented could use
this function to control the number of block sampling loops. It could
match the previous behavior with "return read_stream_next_block(stream,
&bas) != InvalidBlockNumber".
Ongoing work is expected to provide better ANALYZE support for table
access methods that don't behave like heapam with respect to storage
blocks, but that will be for future releases.
Back-patch to 17.
Reported-by: Mats Kindahl <[email protected]>
Reviewed-by: Mats Kindahl <[email protected]>
Discussion: https://postgr.es/m/CA%2B14425%2BCcm07ocG97Fp%2BFrD9xUXqmBKFvecp0p%2BgV2YYR258Q%40mail.gmail.com
M src/backend/storage/aio/read_stream.c
M src/include/storage/read_stream.h
Repair pg_upgrade for identity sequences with non-default persistence.
commit : f7567f9e53d7a2e17023d3122b706814cdbbb6d3
author : Tom Lane <[email protected]>
date : Tue, 17 Sep 2024 15:53:26 -0400
committer: Tom Lane <[email protected]>
date : Tue, 17 Sep 2024 15:53:26 -0400
Since we introduced unlogged sequences in v15, identity sequences
have defaulted to having the same persistence as their owning table.
However, it is possible to change that with ALTER SEQUENCE, and
pg_dump tries to preserve the logged-ness of sequences when it doesn't
match (as indeed it wouldn't for an unlogged table from before v15).
The fly in the ointment is that ALTER SEQUENCE SET [UN]LOGGED fails
in binary-upgrade mode, because it needs to assign a new relfilenode
which we cannot permit in that mode. Thus, trying to pg_upgrade a
database containing a mismatching identity sequence failed.
To fix, add syntax to ADD/ALTER COLUMN GENERATED AS IDENTITY to allow
the sequence's persistence to be set correctly at creation, and use
that instead of ALTER SEQUENCE SET [UN]LOGGED in pg_dump. (I tried to
make SET [UN]LOGGED work without any pg_dump modifications, but that
seems too fragile to be a desirable answer. This way should be
markedly faster anyhow.)
In passing, document the previously-undocumented SEQUENCE NAME option
that pg_dump also relies on for identity sequences; I see no value
in trying to pretend it doesn't exist.
Per bug #18618 from Anthony Hsu.
Back-patch to v15 where we invented this stuff.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/create_table.sgml
M src/backend/commands/sequence.c
M src/backend/parser/gram.y
M src/backend/parser/parse_utilcmd.c
M src/bin/pg_dump/pg_dump.c
M src/test/regress/expected/identity.out
M src/test/regress/sql/identity.sql
Avoid parallel nbtree index scan hangs with SAOPs.
commit : a24bffc021d99a7809da36b74b8873ef07b92ec0
author : Peter Geoghegan <[email protected]>
date : Tue, 17 Sep 2024 11:10:33 -0400
committer: Peter Geoghegan <[email protected]>
date : Tue, 17 Sep 2024 11:10:33 -0400
Commit 5bf748b8, which enhanced nbtree ScalarArrayOp execution, made
parallel index scans work with the new design for arrays via explicit
scheduling of primitive index scans. A backend that successfully
scheduled the scan's next primitive index scan saved its backend local
array keys in shared memory. Any backend could pick up the scheduled
primitive scan within _bt_first. This scheme decouples scheduling a
primitive scan from starting the scan (by performing another descent of
the index via a _bt_search call from _bt_first) to make things robust.
The scheme had a deadlock hazard, at least when the leader process
participated in the scan. _bt_parallel_seize had a code path that made
backends that were not in an immediate position to start a scheduled
primitive index scan wait for some other backend to do so instead.
Under the right circumstances, the leader process could wait here
forever: the leader would wait for any other backend to start the
primitive scan, while every worker was busy waiting on the leader to
consume tuples from the scan's tuple queue.
To fix, don't wait for a scheduled primitive index scan to be started by
some other eligible backend from within _bt_parallel_seize (when the
calling backend isn't in a position to do so itself). Return false
instead, while recording that the scan has a scheduled primitive index
scan in backend local state. This leaves the backend in the same state
as the existing case where a backend schedules (or tries to schedule)
another primitive index scan from within _bt_advance_array_keys, before
calling _bt_parallel_seize. _bt_parallel_seize already handles that
case by returning false without waiting, and without unsetting the
backend local state. Leaving the backend in this state enables it to
start a previously scheduled primitive index scan once it gets back to
_bt_first.
Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp
execution.
Matthias van de Meent, with tweaks by me.
Author: Matthias van de Meent <[email protected]>
Reported-By: Tomas Vondra <[email protected]>
Reviewed-By: Peter Geoghegan <[email protected]>
Discussion: https://postgr.es/m/CAH2-WzmMGaPa32u9x_FvEbPTUkP5e95i=QxR8054nvCRydP-sw@mail.gmail.com
Backpatch: 17-, where nbtree SAOP execution was enhanced.
M src/backend/access/nbtree/nbtree.c
scripts: add Perl script to add links to release notes
commit : 054a23b67402767ec23452a9ff512025a62a80f8
author : Bruce Momjian <[email protected]>
date : Mon, 16 Sep 2024 13:26:37 -0400
committer: Bruce Momjian <[email protected]>
date : Mon, 16 Sep 2024 13:26:37 -0400
Reported-by: jian he
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M src/tools/RELEASE_CHANGES
A src/tools/add_commit_links.pl
Replace usages of xmlXPathCompile() with xmlXPathCtxtCompile().
commit : b9645dca10995abb54a9e12bee6c9db579229c24
author : Tom Lane <[email protected]>
date : Sun, 15 Sep 2024 13:33:09 -0400
committer: Tom Lane <[email protected]>
date : Sun, 15 Sep 2024 13:33:09 -0400
In existing releases of libxml2, xmlXPathCompile can be driven
to stack overflow because it fails to protect itself against
too-deeply-nested input. While there is an upstream fix as of
yesterday, it will take years for that to propagate into all
shipping versions. In the meantime, we can protect our own
usages basically for free by calling xmlXPathCtxtCompile instead.
(The actual bug is that libxml2 keeps its nesting counter in the
xmlXPathContext, and its parsing code was willing to just skip
counting nesting levels if it didn't have a context. So if we supply
a context, all is well. It seems odd actually that it works at all
to not supply a context, because this means that XPath parsing does
not have access to XML namespace info. Apparently libxml2 never
checks namespaces until runtime? Anyway, this seems like good
future-proofing even if its only immediate effect is to dodge a bug.)
Sadly, this hack only offers protection with libxml2 2.9.11 and newer.
Before that there are multiple similar problems, so if you are
processing untrusted XML it behooves you to get a newer version.
But we have some pretty old libxml2 in the buildfarm, so it seems
impractical to add a regression test to verify this fix.
Per bug #18617 from Jingzhou Fu. Back-patch to all supported
versions.
Discussion: https://postgr.es/m/[email protected]
Discussion: https://gitlab.gnome.org/GNOME/libxml2/-/issues/799
M contrib/xml2/xpath.c
M src/backend/utils/adt/xml.c
Run regression tests with timezone America/Los_Angeles.
commit : 6283ff2018e3dfa74e5b41cceba0642a6b53ca39
author : Tom Lane <[email protected]>
date : Sat, 14 Sep 2024 17:55:02 -0400
committer: Tom Lane <[email protected]>
date : Sat, 14 Sep 2024 17:55:02 -0400
Historically we've used timezone "PST8PDT", but the recent release
2024b of tzdb changes the definition of that zone in a way that
breaks many test cases concerned with dates before 1970. Although
we've not yet adopted 2024b into our own tree, this is already
problematic for people using --with-system-tzdata if their platform
has already adopted 2024b. To work with both older and newer
versions of tzdb, switch to using "America/Los_Angeles", accepting
the ensuing changes in regression test results.
Back-patch to all supported branches.
Per report and patch from Wolfgang Walther.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/set.sgml
M doc/src/sgml/regress.sgml
M src/test/regress/expected/date.out
M src/test/regress/expected/horology.out
M src/test/regress/expected/timestamptz.out
M src/test/regress/pg_regress.c
M src/test/regress/sql/timestamptz.sql
Add commit 7229ebe011df to .git-blame-ignore-revs.
commit : fca91b5c903a0d810492eed5a207032f7ee6e175
author : Alvaro Herrera <[email protected]>
date : Sat, 14 Sep 2024 20:17:30 +0200
committer: Alvaro Herrera <[email protected]>
date : Sat, 14 Sep 2024 20:17:30 +0200
M .git-blame-ignore-revs
doc PG 17 relnotes: adjust SGML format for commit add script
commit : 77120dd08113dcb94c01f581408b50240bd24641
author : Bruce Momjian <[email protected]>
date : Sat, 14 Sep 2024 13:20:02 -0400
committer: Bruce Momjian <[email protected]>
date : Sat, 14 Sep 2024 13:20:02 -0400
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
doc PG 17 relnotes: remove commit link whose comment was removed
commit : 4a898075690781a95159244719d4dcef6fd153da
author : Bruce Momjian <[email protected]>
date : Sat, 14 Sep 2024 12:49:27 -0400
committer: Bruce Momjian <[email protected]>
date : Sat, 14 Sep 2024 12:49:27 -0400
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
Remove obsolete comment in pg_stat_statements.
commit : e3b2c651bcd3230674ea4ea31c987474a00a1c98
author : Tom Lane <[email protected]>
date : Sat, 14 Sep 2024 11:42:31 -0400
committer: Tom Lane <[email protected]>
date : Sat, 14 Sep 2024 11:42:31 -0400
Commit 76db9cb63 removed the use of multiple nesting counters,
but missed one comment describing that arrangement.
Back-patch to v17 where 76db9cb63 came in, just to avoid confusion.
Julien Rouhaud
Discussion: https://postgr.es/m/gfcwh3zjxc2vygltapgo7g6yacdor5s4ynr234b6v2ohhuvt7m@gr42joxalenw
M contrib/pg_stat_statements/pg_stat_statements.c
doc PG 17 relnotes: update to current
commit : 54497e0ed8670f52ceb8dfc5949023a61daeec59
author : Bruce Momjian <[email protected]>
date : Sat, 14 Sep 2024 10:38:14 -0400
committer: Bruce Momjian <[email protected]>
date : Sat, 14 Sep 2024 10:38:14 -0400
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
Improve meson's detection of perl build flags
commit : dc2a660bd983f2675f357d279253256a2aef9836
author : Andrew Dunstan <[email protected]>
date : Sat, 14 Sep 2024 10:26:25 -0400
committer: Andrew Dunstan <[email protected]>
date : Sat, 14 Sep 2024 10:26:25 -0400
The current method of detecting perl build flags breaks if the path to
perl contains a space. This change makes two improvements. First,
instead of getting a list of ldflags and ccdlflags and then trying to
filter those out of the reported ldopts, we tell perl to suppress
reporting those in the first instance. Second, it tells perl to parse
those and output them, one per line. Thus any space on the option in a
file name, for example, is preserved.
Issue reported off-list by Muralikrishna Bandaru
Discussion: https://postgr.es/[email protected]
Backpatch to release 16.
M meson.build
doc PG 17 relnotes: move EXPLAIN items to their own section
commit : 984702d0ee9b196dd0a68d4202a42f0bb14562dd
author : Bruce Momjian <[email protected]>
date : Sat, 14 Sep 2024 09:27:21 -0400
committer: Bruce Momjian <[email protected]>
date : Sat, 14 Sep 2024 09:27:21 -0400
Reported-by: Álvaro Herrera
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
Only define NO_THREAD_SAFE_LOCALE for MSVC plperl when required
commit : 648397b1d409f15612b5bb6f95c5527f94e69807
author : Andrew Dunstan <[email protected]>
date : Sat, 14 Sep 2024 08:37:08 -0400
committer: Andrew Dunstan <[email protected]>
date : Sat, 14 Sep 2024 08:37:08 -0400
Latest versions of Strawberry Perl define USE_THREAD_SAFE_LOCALE, and we
therefore get a handshake error when building against such instances.
The solution is to perform a test to see if USE_THREAD_SAFE_LOCALE is
defined and only define NO_THREAD_SAFE_LOCALE if it isn't.
Backpatch the meson.build fix back to release 16 and apply the same
logic to Mkvcbuild.pm in releases 12 through 16.
Original report of the issue from Muralikrishna Bandaru.
M meson.build
doc PG 17 relnotes: move partition access method item
commit : 4e7b9a1adc4191acc5cca1786312dfacc3395c5f
author : Bruce Momjian <[email protected]>
date : Fri, 13 Sep 2024 18:21:56 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 13 Sep 2024 18:21:56 -0400
Also clarify wording.
Reported-by: Álvaro Herrera
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
doc PG 17 relnotes: add dynamic shared memory registry item
commit : 26cea9fb8232d0ec8b4d637e2aa9558c9c6fb4da
author : Bruce Momjian <[email protected]>
date : Fri, 13 Sep 2024 16:16:55 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 13 Sep 2024 16:16:55 -0400
Reported-by: Nathan Bossart
Discussion: https://postgr.es/m/Ztcuwbs0FGCPOEu9@nathan
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
Allow _h_indexbuild() to be interrupted.
commit : 418c6a2c72d22dd3810d08cd06af6126b8bbd4b1
author : Tom Lane <[email protected]>
date : Fri, 13 Sep 2024 16:16:47 -0400
committer: Tom Lane <[email protected]>
date : Fri, 13 Sep 2024 16:16:47 -0400
When we are building a hash index that is large enough to need
pre-sorting (larger than either maintenance_work_mem or NBuffers),
the initial sorting phase is interruptible, but the insertion
phase wasn't. Add the missing CHECK_FOR_INTERRUPTS().
Per bug #18616 from Alexander Lakhin. Back-patch to all
supported branches.
Pavel Borisov
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/hash/hashsort.c
doc PG 17 relnotes: replace commit hashes with section marks
commit : b9a65a678b68dfab47bff3c9524fc72040a26195
author : Bruce Momjian <[email protected]>
date : Fri, 13 Sep 2024 12:29:31 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 13 Sep 2024 12:29:31 -0400
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
Fix contrib/pageinspect's test for sequences.
commit : 9b3c3c0fc2061789c10e331ab3b04913f2b09531
author : Nathan Bossart <[email protected]>
date : Fri, 13 Sep 2024 10:16:40 -0500
committer: Nathan Bossart <[email protected]>
date : Fri, 13 Sep 2024 10:16:40 -0500
I managed to break this test in two different ways in commit
05036a3155.
First, the output of the new call to tuple_data_split() on the test
sequence is dependent on endianness. This is fixed by setting a
special start value for the test sequence that produces the same
output regardless of the endianness of the machine.
Second, on versions older than v15, the new test case fails under
"force_parallel_mode = regress" with the following error:
ERROR: cannot access temporary tables during a parallel operation
This is because pageinspect's disk-accessing functions are
incorrectly marked PARALLEL SAFE on versions older than v15 (see
commit aeaaf520f4 for details). This one is fixed by changing the
test sequence to be permanent. The only reason it was previously
marked temporary was to avoid needing a DROP SEQUENCE command at
the end of the test. Unlike some other tests in this file, the use
of a permanent sequence here shouldn't result in any test
instability like what was fixed by commit e2933a6e11.
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/ZuOKOut5hhDlf_bP%40nathan
Backpatch-through: 12
M contrib/pageinspect/expected/page.out
M contrib/pageinspect/sql/page.sql
doc PG 17 relnotes: add links to commits
commit : 9f949c9cb25f1bb00b4c123aad80bbbd208333b0
author : Bruce Momjian <[email protected]>
date : Fri, 13 Sep 2024 09:42:39 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 13 Sep 2024 09:42:39 -0400
Copied from SGML comments.
Discussion: https://postgr.es/m/CACJufxF+9YCDce5vzmZY6ZCEeTJsYFG-kPohT9UjKikJX30mGw@mail.gmail.com
Author: jian he
Backpatch-through: 17 only
M doc/src/sgml/postgres.sgml
M doc/src/sgml/release-17.sgml
SQL/JSON: Update example in JSON_QUERY() documentation
commit : 32ccfa0476ce1fbbe0326d87b0850894190017b5
author : Amit Langote <[email protected]>
date : Fri, 13 Sep 2024 16:08:13 +0900
committer: Amit Langote <[email protected]>
date : Fri, 13 Sep 2024 16:08:13 +0900
Commit 2c27346ed684 fixed the behavior of JSON_QUERY() when WITH
CONDITIONAL WRAPPER is used, but the documentation example wasn't
updated to reflect this change. This commit updates the example to
show the correct result.
Per off-list report from Andreas Ulbrich.
Backpatch-through: 17
M doc/src/sgml/func.sgml
Reintroduce support for sequences in pgstattuple and pageinspect.
commit : 6ea7f04b73661a0141fdcbfb590961b02832114d
author : Nathan Bossart <[email protected]>
date : Thu, 12 Sep 2024 16:31:29 -0500
committer: Nathan Bossart <[email protected]>
date : Thu, 12 Sep 2024 16:31:29 -0500
Commit 4b82664156 restricted a number of functions provided by
contrib modules to only relations that use the "heap" table access
method. Sequences always use this table access method, but they do
not advertise as such in the pg_class system catalog, so the
aforementioned commit also (presumably unintentionally) removed
support for sequences from some of these functions. This commit
reintroduces said support for sequences to these functions and adds
a couple of relevant tests.
Co-authored-by: Ayush Vatsa
Reviewed-by: Robert Haas, Michael Paquier, Matthias van de Meent
Discussion: https://postgr.es/m/CACX%2BKaP3i%2Bi9tdPLjF5JCHVv93xobEdcd_eB%2B638VDvZ3i%3DcQA%40mail.gmail.com
Backpatch-through: 12
M contrib/pageinspect/expected/page.out
M contrib/pageinspect/heapfuncs.c
M contrib/pageinspect/sql/page.sql
M contrib/pgstattuple/expected/pgstattuple.out
M contrib/pgstattuple/pgstattuple.c
M contrib/pgstattuple/sql/pgstattuple.sql
Make jsonpath .string() be immutable for datetimes.
commit : cc4fdfa411fa0cd6b27563c37c096bf76120659f
author : Tom Lane <[email protected]>
date : Thu, 12 Sep 2024 14:30:29 -0400
committer: Tom Lane <[email protected]>
date : Thu, 12 Sep 2024 14:30:29 -0400
Discussion of commit ed055d249 revealed that we don't actually
want jsonpath's .string() method to depend on DateStyle, nor
TimeZone either, because the non-"_tz" jsonpath functions are
supposed to be immutable. Potentially we could allow a TimeZone
dependency in the "_tz" variants, but it seems better to just
uniformly define this method as returning the same string that
jsonb text output would do. That's easier to implement too,
saving a couple dozen lines.
Patch by me, per complaint from Peter Eisentraut. Back-patch
to v17 where this feature came in (in 66ea94e8e). Also
back-patch ed055d249 to provide test cases.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/func.sgml
M src/backend/utils/adt/jsonpath_exec.c
M src/test/regress/expected/horology.out
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/sql/horology.sql
M src/test/regress/sql/jsonb_jsonpath.sql
Doc: alphabetize aggregate function table
commit : 2645f6d643d929007fa7d1ed6d2de5155e4d63d8
author : David Rowley <[email protected]>
date : Thu, 12 Sep 2024 22:37:27 +1200
committer: David Rowley <[email protected]>
date : Thu, 12 Sep 2024 22:37:27 +1200
A few recent JSON aggregates have been added without much consideration
to the existing order. Put these back in alphabetical order (with the
exception of the JSONB variant of each JSON aggregate).
Author: Wolfgang Walther <[email protected]>
Reviewed-by: Marlene Reiterer <[email protected]>
Discussion: https://postgr.es/m/6a7b910c-3feb-4006-b817-9b4759cb6bb6%40technowledgy.de
Backpatch-through: 16, where these aggregates were added
M doc/src/sgml/func.sgml
SQL/JSON: Fix JSON_QUERY(... WITH CONDITIONAL WRAPPER)
commit : 2c27346ed6848b6f5505f1c57078a7c1978ae042
author : Amit Langote <[email protected]>
date : Thu, 12 Sep 2024 09:36:31 +0900
committer: Amit Langote <[email protected]>
date : Thu, 12 Sep 2024 09:36:31 +0900
Currently, when WITH CONDITIONAL WRAPPER is specified, array wrappers
are applied even to a single SQL/JSON item if it is a scalar JSON
value, but this behavior does not comply with the standard.
To fix, apply wrappers only when there are multiple SQL/JSON items
in the result.
Reported-by: Peter Eisentraut <[email protected]>
Author: Peter Eisentraut <[email protected]>
Author: Amit Langote <[email protected]>
Reviewed-by: Andrew Dunstan <[email protected]>
Discussion: https://postgr.es/m/8022e067-818b-45d3-8fab-6e0d94d03626%40eisentraut.org
Backpatch-through: 17
M src/backend/utils/adt/jsonpath_exec.c
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_queryfuncs.sql
Remove incorrect Assert.
commit : 7f88e50b455d0db51847fbfe63e53802d4527f3a
author : Tom Lane <[email protected]>
date : Wed, 11 Sep 2024 11:41:47 -0400
committer: Tom Lane <[email protected]>
date : Wed, 11 Sep 2024 11:41:47 -0400
check_agglevels_and_constraints() asserted that if we find an
aggregate function in an EXPR_KIND_FROM_SUBSELECT expression, the
expression must be in a LATERAL subquery. Alexander Lakhin found a
case where that's not so: because of the odd scoping rules for NEW/OLD
within a rule, a reference to NEW/OLD could cause an aggregate to be
considered top-level even though it's in an unmarked sub-select.
The error message that would be thrown seems sufficiently on-point,
so just remove the Assert. (Hence, this is not a bug for production
builds.)
This Assert was added by me in commit eaccfded9 (9.3 era). It looks
like I put it in to cross-check that the new logic for detecting
misplaced aggregates (using agglevelsup) caught the same cases that a
previous check on p_lateral_active did. So there might have been some
related misbehavior before eaccfded9 ... but that's very ancient
history by now, so I didn't dig any deeper.
Per bug #18608 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/parser/parse_agg.c
pg_createsubscriber: minor documentation fixes
commit : 7748c847c332c2231846d913aa81d7e20b4b0241
author : Magnus Hagander <[email protected]>
date : Wed, 11 Sep 2024 16:30:17 +0200
committer: Magnus Hagander <[email protected]>
date : Wed, 11 Sep 2024 16:30:17 +0200
M doc/src/sgml/ref/pg_createsubscriber.sgml
Fix unique key checks in JSON object constructors
commit : 78bc5f711873339df72ee7fc072e41d449fa77ea
author : Tomas Vondra <[email protected]>
date : Wed, 11 Sep 2024 13:21:05 +0200
committer: Tomas Vondra <[email protected]>
date : Wed, 11 Sep 2024 13:21:05 +0200
When building a JSON object, the code builds a hash table of keys, to
allow checking if the keys are unique. The uniqueness check and adding
the new key happens in json_unique_check_key(), but this assumes the
pointer to the key remains valid.
Unfortunately, two places passed pointers to keys in a buffer, while
also appending more data (additional key/value pairs) to the buffer.
With enough data the buffer is resized by enlargeStringInfo(), which
calls repalloc(), invalidating the earlier key pointers.
Due to this the uniqueness check may fail with both false negatives and
false positives, producing JSON objects with duplicate keys or failing
to produce a perfectly valid JSON object.
This affects multiple functions that enforce uniqueness of keys, all
introduced in PG16 with the new SQL/JSON:
- json_object_agg_unique / jsonb_object_agg_unique
- json_object / jsonb_objectagg
Existing regression tests did not detect the issue, simply because the
initial buffer size is 1024 and the objects were small enough not to
require the repalloc.
With a sufficiently large object, AddressSanitizer reported the access
to invalid memory immediately. So would valgrind, of course.
Fixed by copying the key into the hash table memory context, and adding
regression tests with enough data to repalloc the buffer. Backpatch to
16, where the functions were introduced.
Reported by Alexander Lakhin. Investigation and initial fix by Junwang
Zhao, with various improvements and tests by me.
Reported-by: Alexander Lakhin
Author: Junwang Zhao, Tomas Vondra
Backpatch-through: 16
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/CAEG8a3JjH0ReJF2_O7-8LuEbO69BxPhYeXs95_x7+H9AMWF1gw@mail.gmail.com
M src/backend/utils/adt/json.c
M src/test/regress/expected/json.out
M src/test/regress/expected/sqljson.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/sqljson.sql
Fix some whitespace issues in XMLSERIALIZE(... INDENT).
commit : 946f150aa180ec61d37d7a41e43765b4c25ca784
author : Tom Lane <[email protected]>
date : Tue, 10 Sep 2024 16:20:31 -0400
committer: Tom Lane <[email protected]>
date : Tue, 10 Sep 2024 16:20:31 -0400
We must drop whitespace while parsing the input, else libxml2
will include "blank" nodes that interfere with the desired
indentation behavior. The end result is that we didn't indent
nodes separated by whitespace.
Also, it seems that libxml2 may add a trailing newline when working
in DOCUMENT mode. This is semantically insignificant, so strip it.
This is in the gray area between being a bug fix and a definition
change. However, the INDENT option is still pretty new (since v16),
so I think we can get away with changing this in stable branches.
Hence, back-patch to v16.
Jim Jones
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/xml.c
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_1.out
M src/test/regress/expected/xml_2.out
M src/test/regress/sql/xml.sql
SQL/JSON: Avoid initializing unnecessary ON ERROR / ON EMPTY steps
commit : 77aebe9a8d3cccd4c54b43be87a38f2bae614c76
author : Amit Langote <[email protected]>
date : Mon, 9 Sep 2024 11:55:38 +0900
committer: Amit Langote <[email protected]>
date : Mon, 9 Sep 2024 11:55:38 +0900
When the ON ERROR / ON EMPTY behavior is to return NULL, returning
NULL directly from ExecEvalJsonExprPath() suffices. Therefore, there's
no need to create separate steps to check the error/empty flag or
those to evaluate the the constant NULL expression. This speeds up
common cases because the default ON ERROR / ON EMPTY behavior for
JSON_QUERY() and JSON_VALUE() is to return NULL. However, these steps
are necessary if the RETURNING type is a domain, as constraints on the
domain may need to be checked.
Reported-by: Jian He <[email protected]>
Author: Jian He <[email protected]>
Author: Amit Langote <[email protected]>
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
Fix waits of REINDEX CONCURRENTLY for indexes with predicates or expressions
commit : cd6b2ae3e7f64c881cb0159a2f9fc8d475e06d82
author : Michael Paquier <[email protected]>
date : Mon, 9 Sep 2024 13:49:59 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 9 Sep 2024 13:49:59 +0900
As introduced by f9900df5f94, a REINDEX CONCURRENTLY job done for an
index with predicates or expressions would set PROC_IN_SAFE_IC in its
MyProc->statusFlags, causing it to be ignored by other concurrent
operations.
Such concurrent index rebuilds should never be ignored, as a predicate
or an expression could call a user-defined function that accesses a
different table than the table where the index is rebuilt.
A test that uses injection points is added, backpatched down to 17.
Michail has proposed a different test, but I have added something
simpler with more coverage.
Oversight in f9900df5f949.
Author: Michail Nikolaev
Discussion: https://postgr.es/m/CANtu0oj9A3kZVduFTG0vrmGnKB+DCHgEpzOp0qAyOgmks84j0w@mail.gmail.com
Backpatch-through: 14
M src/backend/commands/indexcmds.c
M src/test/modules/injection_points/Makefile
A src/test/modules/injection_points/expected/reindex_conc.out
M src/test/modules/injection_points/meson.build
A src/test/modules/injection_points/sql/reindex_conc.sql
Fix incorrect pg_stat_io output on 32-bit machines.
commit : e69030cb5178347d499bbc549213e950064564fa
author : Tom Lane <[email protected]>
date : Fri, 6 Sep 2024 11:57:57 -0400
committer: Tom Lane <[email protected]>
date : Fri, 6 Sep 2024 11:57:57 -0400
pg_stat_get_io() applied TimestampTzGetDatum twice to the
stat_reset_timestamp value. On 64-bit builds that's harmless because
TimestampTzGetDatum is a no-op, but on 32-bit builds it results in
displaying garbage in the stats_reset column of the pg_stat_io view.
Bug dates to commit a9c70b46d which introduced pg_stat_io, so
back-patch to v16 where that came in.
Bertrand Drouvot
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/pgstatfuncs.c
SQL/JSON: Fix default ON ERROR behavior for JSON_TABLE
commit : 446d5ad7ae7d3bf4fd08904ae54a6399cafb4e7d
author : Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 13:25:14 +0900
committer: Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 13:25:14 +0900
Use EMPTY ARRAY instead of EMPTY.
This change does not affect the runtime behavior of JSON_TABLE(),
which continues to return an empty relation ON ERROR. It only alters
whether the default ON ERROR behavior is shown in the deparsed output.
Reported-by: Jian He <[email protected]>
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
M src/backend/parser/parse_expr.c
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql
SQL/JSON: Fix JSON_TABLE() column deparsing
commit : cd680b39211c5c3c88a143abcac576a22f996d7a
author : Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 13:25:02 +0900
committer: Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 13:25:02 +0900
The deparsing code in get_json_expr_options() unnecessarily emitted
the default column-specific ON ERROR / EMPTY behavior when the
top-level ON ERROR behavior in JSON_TABLE was set to ERROR. Fix that
by not overriding the column-specific default, determined based on
the column's JsonExprOp in get_json_table_columns(), with
JSON_BEHAVIOR_ERROR when that is the top-level ON ERROR behavior.
Note that this only removes redundancy; the current deparsing output
is not incorrect, just redundant.
Reviewed-by: Jian He <[email protected]>
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql
Revert recent SQL/JSON related commits
commit : eef5195f300bb9cf2864d48761c0db2ad93842c1
author : Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 12:51:26 +0900
committer: Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 12:51:26 +0900
Reverts c88ce386c4d, 5067c230b8e, and e4e27976a68, because a few BF
animals didn't like one or all of them.
M src/backend/executor/execExpr.c
M src/backend/parser/parse_expr.c
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql
SQL/JSON: Avoid initializing unnecessary ON ERROR / ON EMPTY steps
commit : e4e27976a687dd641c1c8251fad3a90a08756df8
author : Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 12:04:29 +0900
committer: Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 12:04:29 +0900
When the ON ERROR / ON EMPTY behavior is to return NULL, returning
NULL directly from ExecEvalJsonExprPath() suffices. Therefore, there's
no need to create separate steps to check the error/empty flag or
those to evaluate the the constant NULL expression. This speeds up
common cases because the default ON ERROR / ON EMPTY behavior for
JSON_QUERY() and JSON_VALUE() is to return NULL. However, these steps
are necessary if the RETURNING type is a domain, as constraints on the
domain may need to be checked.
Reported-by: Jian He <[email protected]>
Author: Jian He <[email protected]>
Author: Amit Langote <[email protected]>
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
M src/backend/executor/execExpr.c
SQL/JSON: Fix default ON ERROR behavior for JSON_TABLE
commit : 5067c230b8ee42a01cc77dc5745bc3a78f393af3
author : Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 10:13:03 +0900
committer: Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 10:13:03 +0900
Use EMPTY ARRAY instead of EMPTY.
This change does not affect the runtime behavior of JSON_TABLE(),
which continues to return an empty relation ON ERROR. It only alters
whether the default ON ERROR behavior is shown in the deparsed output.
Reported-by: Jian He <[email protected]>
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
M src/backend/parser/parse_expr.c
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql
SQL/JSON: Fix JSON_TABLE() column deparsing
commit : c88ce386c4d7bfeb437ff31ec7c23c392c862e77
author : Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 10:12:16 +0900
committer: Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 10:12:16 +0900
The deparsing code in get_json_expr_options() unnecessarily emitted
the default column-specific ON ERROR / EMPTY behavior when the
top-level ON ERROR behavior in JSON_TABLE was set to ERROR. Fix that
by not overriding the column-specific default, determined based on
the column's JsonExprOp in get_json_table_columns(), with
JSON_BEHAVIOR_ERROR when that is the top-level ON ERROR behavior.
Note that this only removes redundancy; the current deparsing output
is not incorrect, just redundant.
Reviewed-by: Jian He <[email protected]>
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql
Update comment about ExprState.escontext
commit : fe323438140f69b8122e618387db1beb9ddaf5d3
author : Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 10:12:00 +0900
committer: Amit Langote <[email protected]>
date : Fri, 6 Sep 2024 10:12:00 +0900
The updated comment provides more helpful guidance by mentioning that
escontext should be set when soft error handling is needed.
Reported-by: Jian He <[email protected]>
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
M src/include/nodes/execnodes.h
doc PG 17 relnotes: remove tab complete for MERGE/SPLIT partit.
commit : 35afec71aeb3723df57a6c3da1f98014b51d22e0
author : Bruce Momjian <[email protected]>
date : Thu, 5 Sep 2024 21:48:42 -0400
committer: Bruce Momjian <[email protected]>
date : Thu, 5 Sep 2024 21:48:42 -0400
commit 60ae37a8b
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
Prevent mis-encoding of "trailing junk after numeric literal" errors.
commit : 7dcbf0afa28cc8c3dd83bef0428a18ac177f129e
author : Tom Lane <[email protected]>
date : Thu, 5 Sep 2024 12:42:33 -0400
committer: Tom Lane <[email protected]>
date : Thu, 5 Sep 2024 12:42:33 -0400
Since commit 2549f0661, we reject an identifier immediately following
a numeric literal (without separating whitespace), because that risks
ambiguity with hex/octal/binary integers. However, that patch used
token patterns like "{integer}{ident_start}", which is problematic
because {ident_start} matches only a single byte. If the first
character after the integer is a multibyte character, this ends up
with flex reporting an error message that includes a partial multibyte
character. That can cause assorted bad-encoding problems downstream,
both in the report to the client and in the postmaster log file.
To fix, use {identifier} not {ident_start} in the "junk" token
patterns, so that they will match complete multibyte characters.
This seems generally better user experience quite aside from the
encoding problem: for "123abc" the error message will now say that
the error appeared at or near "123abc" instead of "123a".
While at it, add some commentary about why these patterns exist
and how they work.
Report and patch by Karina Litskevich; review by Pavel Borisov.
Back-patch to v15 where the problem came in.
Discussion: https://postgr.es/m/CACiT8iZ_diop=0zJ7zuY3BXegJpkKK1Av-PU7xh0EDYHsa5+=g@mail.gmail.com
M src/backend/parser/scan.l
M src/fe_utils/psqlscan.l
M src/interfaces/ecpg/preproc/pgc.l
M src/test/regress/expected/numerology.out
Fix inconsistent LWLock tranche name "CommitTsSLRU"
commit : 07b828e9d4aa916f1763774787440d914eea69c4
author : Michael Paquier <[email protected]>
date : Wed, 4 Sep 2024 10:22:19 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 4 Sep 2024 10:22:19 +0900
This term was using an inconsistent casing between the code and the
documentation, using "CommitTsSLRU" in wait_event_names.txt and
"CommitTSSLRU" in the code.
Let's update the term in the code to reflect what's in the
documentation, "CommitTs" being more commonly used, so as
pg_stat_activity shows the same term as the documentation.
Oversight in 53c2a97a9266.
Author: Alexander Lakhin
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 17
M src/backend/storage/lmgr/lwlock.c
Avoid installcheck failure in TAP tests using injection_points
commit : bab1fd9277c2b1ef9ef70552d95a6e16c1f3cad4
author : Michael Paquier <[email protected]>
date : Wed, 4 Sep 2024 08:56:28 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 4 Sep 2024 08:56:28 +0900
These tests depend on the test module injection_points to be installed,
but it may not be available as the contents of src/test/modules/ are not
installed by default.
This commit adds a workaround based on a scan of pg_available_extensions
to check if the extension is available, skipping the test if it is not.
This allows installcheck to work transparently.
There are more tests impacted by this problem on HEAD, but for now this
addresses only the tests that exist on HEAD and v17 as the release is
close by.
Reported-by: Maxim Orlov
Discussion: https://postgr.es/m/CACG=ezZkoT-pFz6a9XnyToiuR-Wg8fGELqHLoyBodr+2h-77qA@mail.gmail.com
Backpatch-through: 17
M src/test/modules/test_misc/t/005_timeouts.pl
M src/test/recovery/t/041_checkpoint_at_promote.pl
Simplify makefiles exporting twice enable_injection_points
commit : ff43b5e70d45c8d39ca7513e10c23367435c9826
author : Michael Paquier <[email protected]>
date : Wed, 4 Sep 2024 08:05:56 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 4 Sep 2024 08:05:56 +0900
This is confusing, as it exports twice the same variable. Oversight in
6782709df81f that has spread in more places afterwards.
Reported-by: Alvaro Herrera, Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 17
M src/test/modules/test_misc/Makefile
M src/test/recovery/Makefile
Stamp 17rc1.
commit : 94f1474e600fdbc6b325f69903eecfeb1f69fcbd
author : Tom Lane <[email protected]>
date : Mon, 2 Sep 2024 16:11:07 -0400
committer: Tom Lane <[email protected]>
date : Mon, 2 Sep 2024 16:11:07 -0400
M configure
M configure.ac
M meson.build
Fix warnings from msgfmt
commit : c96176c48db0dbea2397537f6ab0e098b6b8260c
author : Peter Eisentraut <[email protected]>
date : Mon, 2 Sep 2024 18:03:47 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 2 Sep 2024 18:03:47 +0200
/usr/bin/msgfmt: po/fr.po: warning: PO file header fuzzy
warning: older versions of msgfmt will give an error on this
Apparently, not all versions of msgfmt produce this. Quick fix for
now, more to be researched later.
M src/bin/pg_combinebackup/po/fr.po
M src/bin/pg_walsummary/po/fr.po
Fix rarely-run test for message wording change
commit : e6ec1d6aabe024d0789fe53c711cd5cae47d30ea
author : Peter Eisentraut <[email protected]>
date : Mon, 2 Sep 2024 17:40:32 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 2 Sep 2024 17:40:32 +0200
fixup for 2e6a8047f0
Reported-by: Nazir Bilal Yavuz <[email protected]>
M src/test/modules/xid_wraparound/t/002_limits.pl
Translation updates
commit : 986a3ac497fddac717d40b7cd90296af27f07526
author : Peter Eisentraut <[email protected]>
date : Mon, 2 Sep 2024 12:02:42 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 2 Sep 2024 12:02:42 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: d0110df9f34c2d32cb2652d4477c3135dabe84f7
M src/backend/po/de.po
M src/backend/po/sv.po
M src/bin/pg_amcheck/po/de.po
M src/bin/pg_amcheck/po/fr.po
M src/bin/pg_amcheck/po/ka.po
M src/bin/pg_amcheck/po/sv.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_basebackup/po/ka.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_combinebackup/po/LINGUAS
M src/bin/pg_combinebackup/po/de.po
A src/bin/pg_combinebackup/po/fr.po
M src/bin/pg_combinebackup/po/ka.po
M src/bin/pg_combinebackup/po/sv.po
M src/bin/pg_ctl/po/fr.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/ka.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_resetwal/po/fr.po
M src/bin/pg_rewind/po/de.po
M src/bin/pg_rewind/po/fr.po
M src/bin/pg_rewind/po/ka.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_test_fsync/po/fr.po
M src/bin/pg_test_timing/po/fr.po
M src/bin/pg_upgrade/po/de.po
M src/bin/pg_upgrade/po/fr.po
M src/bin/pg_upgrade/po/ka.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_verifybackup/po/de.po
M src/bin/pg_verifybackup/po/fr.po
M src/bin/pg_verifybackup/po/ka.po
M src/bin/pg_verifybackup/po/sv.po
M src/bin/pg_waldump/po/fr.po
M src/bin/pg_walsummary/po/LINGUAS
A src/bin/pg_walsummary/po/fr.po
M src/bin/psql/po/fr.po
M src/bin/scripts/po/fr.po
M src/bin/scripts/po/ka.po
M src/pl/plperl/po/fr.po
M src/pl/plpgsql/src/po/fr.po
M src/pl/tcl/po/fr.po
Fix unfairness in all-cached parallel seq scan.
commit : 3ed3683618cb6a9b10dc5297751fa8b7fe7e36e1
author : Thomas Munro <[email protected]>
date : Sat, 31 Aug 2024 17:27:38 +1200
committer: Thomas Munro <[email protected]>
date : Sat, 31 Aug 2024 17:27:38 +1200
Commit b5a9b18c introduced block streaming infrastructure with a special
fast path for all-cached scans, and commit b7b0f3f2 connected the
infrastructure up to sequential scans. One of the fast path
micro-optimizations had an unintended consequence: it interfered with
parallel sequential scan's block range allocator (from commit 56788d21),
which has its own ramp-up and ramp-down algorithm when handing out
groups of pages to workers. A scan of an all-cached table could give
extra blocks to one worker, when others had finished. In some plans
(probably already very bad plans, such as the one reported by
Alexander), the unfairness could be magnified.
An internal buffer of 16 block numbers is removed, keeping just a single
block buffer for technical reasons.
Back-patch to 17.
Reported-by: Alexander Lakhin <[email protected]>
Discussion: https://postgr.es/m/63a63690-dd92-c809-0b47-af05459e95d1%40gmail.com
M src/backend/storage/aio/read_stream.c
Stabilize 039_end_of_wal test.
commit : 34226d4ad7efbe85e6721e40a82498dac8ec6211
author : Thomas Munro <[email protected]>
date : Sat, 31 Aug 2024 14:32:08 +1200
committer: Thomas Munro <[email protected]>
date : Sat, 31 Aug 2024 14:32:08 +1200
The first test was sensitive to the insert LSN after setting up the
catalogs, which depended on environmental things like the locales on the
OS and usernames. Switch to a new WAL file before the first test, as a
simple way to put every computer into the same state.
Back-patch to all supported releases.
Reported-by: Anton Voloshin <[email protected]>
Reported-by: Nathan Bossart <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Reviewed-by: Nathan Bossart <[email protected]>
Discussion: https://postgr.es/m/b26aeac2-cb6d-4633-a7ea-945baae83dcf%40postgrespro.ru
M src/test/recovery/t/039_end_of_wal.pl
Clarify restrict_nonsystem_relation_kind description.
commit : 0776724050f47c5ff827693f498cd2604c1ea5d1
author : Masahiko Sawada <[email protected]>
date : Fri, 30 Aug 2024 15:06:07 -0700
committer: Masahiko Sawada <[email protected]>
date : Fri, 30 Aug 2024 15:06:07 -0700
This change improves the description of the
restrict_nonsystem_relation_kind parameter in guc_table.c and the
documentation for better clarity.
Backpatch to 12, where this GUC parameter was introduced.
Reviewed-by: Peter Eisentraut
Discussion: https://postgr.es/m/6a96f1af-22b4-4a80-8161-1f26606b9ee2%40eisentraut.org
Backpatch-through: 12
M doc/src/sgml/config.sgml
M src/backend/utils/misc/guc_tables.c
Make postgres_fdw's query_cancel test less flaky.
commit : 8749d850f962a3fe77b637ef17de9f69e0e9389d
author : Tom Lane <[email protected]>
date : Fri, 30 Aug 2024 16:47:39 -0400
committer: Tom Lane <[email protected]>
date : Fri, 30 Aug 2024 16:47:39 -0400
This test occasionally shows
+WARNING: could not get result of cancel request due to timeout
which appears to be because the cancel request is sometimes unluckily
sent to the remote session between queries, and then it's ignored.
This patch tries to make that less probable in three ways:
1. Use a test query that does not involve remote estimates, so that
no EXPLAINs are sent.
2. Make sure that the remote session is ready-to-go (transaction
started, SET commands sent) before we start the timer.
3. Increase the statement_timeout to 100ms, to give the local
session enough time to plan and issue the query.
We might have to go higher than 100ms to make this adequately
stable in the buildfarm, but let's see how it goes.
Back-patch to v17 where this test was introduced.
Jelte Fennema-Nio and Tom Lane
Discussion: https://postgr.es/m/[email protected]
M contrib/postgres_fdw/expected/query_cancel.out
M contrib/postgres_fdw/sql/query_cancel.sql
Avoid inserting PlaceHolderVars in cases where pre-v16 PG did not.
commit : b43110869fd82b549df5c6ab7ade476d6e414f37
author : Tom Lane <[email protected]>
date : Fri, 30 Aug 2024 12:42:13 -0400
committer: Tom Lane <[email protected]>
date : Fri, 30 Aug 2024 12:42:13 -0400
Commit 2489d76c4 removed some logic from pullup_replace_vars()
that avoided wrapping a PlaceHolderVar around a pulled-up
subquery output expression if the expression could be proven
to go to NULL anyway (because it contained Vars or PHVs of the
pulled-up relation and did not contain non-strict constructs).
But removing that logic turns out to cause performance regressions
in some cases, because the extra PHV blocks subexpression folding,
and will do so even if outer-join reduction later turns it into a
no-op with no phnullingrels bits. This can for example prevent
an expression from being matched to an index.
The reason for always adding a PHV was to ensure we had someplace
to put the varnullingrels marker bits of the Var being replaced.
However, it turns out we can optimize in exactly the same cases that
the previous code did, because we can instead attach the needed
varnullingrels bits to the contained Var(s)/PHV(s).
This is not a complete solution --- it would be even better if we
could remove PHVs after reducing them to no-ops. It doesn't look
practical to back-patch such an improvement, but this change seems
safe and at least gets rid of the performance-regression cases.
Per complaint from Nikhil Raj. Back-patch to v16 where the
problem appeared.
Discussion: https://postgr.es/m/CAG1ps1xvnTZceKK24OUfMKLPvDP2vjT-d+F2AOCWbw_v3KeEgg@mail.gmail.com
M src/backend/optimizer/prep/prepjointree.c
M src/backend/rewrite/rewriteManip.c
M src/test/regress/expected/subselect.out
M src/test/regress/sql/subselect.sql
Update list of acknowledgments in release notes
commit : df51201f34f21ae313076e8f1a475c59a2ff2f5f
author : Peter Eisentraut <[email protected]>
date : Fri, 30 Aug 2024 10:03:48 +0200
committer: Peter Eisentraut <[email protected]>
date : Fri, 30 Aug 2024 10:03:48 +0200
current through df80b1d6cd
M doc/src/sgml/release-17.sgml
Remove duplicate name from list of acknowledgments
commit : df80b1d6cd36c6cc6be7529895c0434e90e911cc
author : Peter Eisentraut <[email protected]>
date : Fri, 30 Aug 2024 08:38:16 +0200
committer: Peter Eisentraut <[email protected]>
date : Fri, 30 Aug 2024 08:38:16 +0200
Reported-by: [email protected]
M doc/src/sgml/release-17.sgml
Correct name in list of acknowledgments
commit : 47b92f8fc522d3c1a75a955c32c492d752316584
author : Peter Eisentraut <[email protected]>
date : Fri, 30 Aug 2024 08:34:39 +0200
committer: Peter Eisentraut <[email protected]>
date : Fri, 30 Aug 2024 08:34:39 +0200
Reported-by: Etsuro Fujita <[email protected]>
M doc/src/sgml/release-17.sgml
Fix mis-deparsing of ORDER BY lists when there is a name conflict.
commit : a7eb633563c6ba8857cf59c7b43b593614537617
author : Tom Lane <[email protected]>
date : Thu, 29 Aug 2024 13:24:17 -0400
committer: Tom Lane <[email protected]>
date : Thu, 29 Aug 2024 13:24:17 -0400
If an ORDER BY item in SELECT is a bare identifier, the parser
first seeks it as an output column name of the SELECT (for SQL92
compatibility). However, ruleutils.c is expecting the SQL99
interpretation where such a name is an input column name. So it's
possible to produce an incorrect display of a view in the (admittedly
pretty ill-advised) case where some other column is renamed in the
SELECT output list to match an ORDER BY column.
This can be fixed by table-qualifying such names in the dumped
view text. To avoid cluttering less-ill-advised queries, we'd
like to do so only when there's an actual name conflict.
That requires passing the current get_query_def call's resultDesc
parameter down to get_variable, so that it can determine what
the output column names are. In hopes of reducing rather than
increasing notational clutter in ruleutils.c, I moved that value
into the deparse_context struct and removed it from the parameter
lists of get_query_def's other subroutines.
I made a few other cosmetic changes while at it:
* Likewise move the colNamesVisible parameter into deparse_context.
* Rename deparse_context's windowTList field to targetList,
since it's no longer used only in connection with WINDOW clauses.
* Replace the special_exprkind field with a bool inGroupBy,
since that was all it was being used for, and the apparent
flexibility of storing a ParseExprKind proved to be illusory.
(We need a separate varInOrderBy field to make this patch work.)
* Remove useless save/restore logic in get_select_query_def.
In principle, this bug is quite old. However, it seems unreachable
before 1b4d280ea, because before that the presence of "new" and "old"
entries in a view's rangetable caused us to always table-qualify every
Var reference in dumped views. Hence, back-patch to v16 where that
came in.
Per bug #18589 from Quynh Tran.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
Message style improvements
commit : f2353dd71724c0d18d5912e105f034b50494bfe9
author : Peter Eisentraut <[email protected]>
date : Thu, 29 Aug 2024 14:33:18 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 29 Aug 2024 14:33:18 +0200
M src/backend/access/transam/varsup.c
M src/backend/access/transam/xact.c
M src/backend/backup/basebackup_incremental.c
M src/backend/commands/copyfromparse.c
M src/backend/commands/subscriptioncmds.c
M src/backend/commands/tablecmds.c
M src/backend/postmaster/walsummarizer.c
M src/backend/replication/logical/logical.c
M src/backend/replication/logical/slotsync.c
M src/backend/replication/pgoutput/pgoutput.c
M src/backend/replication/slot.c
M src/backend/rewrite/rewriteHandler.c
M src/backend/utils/adt/jsonpath_exec.c
M src/backend/utils/misc/guc_tables.c
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/common/parse_manifest.c
M src/test/recovery/t/040_standby_failover_slots_sync.pl
M src/test/regress/expected/copy2.out
M src/test/regress/expected/foreign_key.out
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/expected/updatable_views.out
Disallow USING clause when altering type of generated column
commit : fdbf7e46a46d2ce8a215b37870b14ee2d7cf0fda
author : Peter Eisentraut <[email protected]>
date : Thu, 29 Aug 2024 08:38:29 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 29 Aug 2024 08:38:29 +0200
This does not make sense. It would write the output of the USING
clause into the converted column, which would violate the generation
expression. This adds a check to error out if this is specified.
There was a test for this, but that test errored out for a different
reason, so it was not effective.
Reported-by: Jian He <[email protected]>
Reviewed-by: Yugo NAGATA <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/c7083982-69f4-4b14-8315-f9ddb20b9834%40eisentraut.org
M src/backend/commands/tablecmds.c
M src/test/regress/expected/generated.out
Doc: Fix the ambiguity in the description of failover slots.
commit : 135007a1008c11e849036692ffe180dd7d4b5107
author : Amit Kapila <[email protected]>
date : Thu, 29 Aug 2024 08:45:41 +0530
committer: Amit Kapila <[email protected]>
date : Thu, 29 Aug 2024 08:45:41 +0530
The failover slots ensure a seamless transition of a subscriber after the
standby is promoted. But the docs for it also explain the behavior of
asynchronous replication which can confuse the readers.
Reported-by: Masahiro Ikeda
Backpatch-through: 17
Discussion: https://postgr.es/m/OS3PR01MB6390B660F4198BB9745E0526B18B2@OS3PR01MB6390.jpnprd01.prod.outlook.com
M doc/src/sgml/logical-replication.sgml
Message style improvements
commit : 0be079ec9706eb80f0142b0d7deba245024acdce
author : Peter Eisentraut <[email protected]>
date : Tue, 27 Aug 2024 16:54:10 +0200
committer: Peter Eisentraut <[email protected]>
date : Tue, 27 Aug 2024 16:54:10 +0200
M src/bin/pg_amcheck/pg_amcheck.c
M src/bin/pg_amcheck/t/003_check.pl
M src/bin/pg_combinebackup/pg_combinebackup.c
M src/bin/pg_combinebackup/reconstruct.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_rewind/pg_rewind.c
Fix misplaced translator comments
commit : 203b5ceee88c377110260e8c69083ef24b54fc68
author : Peter Eisentraut <[email protected]>
date : Tue, 27 Aug 2024 16:15:28 +0200
committer: Peter Eisentraut <[email protected]>
date : Tue, 27 Aug 2024 16:15:28 +0200
They did not immediately precede the code they were applying to.
M src/backend/replication/logical/slotsync.c
Fix identation.
commit : c739ae9e288c095cfe1b91ce27a2f2c075ed5da4
author : Masahiko Sawada <[email protected]>
date : Mon, 26 Aug 2024 16:16:09 -0700
committer: Masahiko Sawada <[email protected]>
date : Mon, 26 Aug 2024 16:16:09 -0700
M src/backend/replication/logical/reorderbuffer.c
Fix memory counter update in ReorderBuffer.
commit : dbed2e36625de9d4074243f60f48e04b5ed67810
author : Masahiko Sawada <[email protected]>
date : Mon, 26 Aug 2024 11:00:04 -0700
committer: Masahiko Sawada <[email protected]>
date : Mon, 26 Aug 2024 11:00:04 -0700
Commit 5bec1d6bc5e changed the memory usage updates of the
ReorderBufferTXN to zero all at once by subtracting txn->size, rather
than updating it for each change. However, if TOAST reconstruction
data remained in the transaction when freeing it, there were cases
where it further subtracted the memory counter from zero, resulting in
an assertion failure.
This change calculates the memory size for each change and updates the
memory usage to precisely the amount that has been freed.
Backpatch to v17, where this was introducd.
Reviewed-by: Amit Kapila, Shlok Kyal
Discussion: https://postgr.es/m/CAD21AoAqkNUvicgKPT_dXzNoOwpPkVTg0QPPxEcWmzT0moCJ1g%40mail.gmail.com
Backpatch-through: 17
M contrib/test_decoding/expected/stream.out
M contrib/test_decoding/sql/stream.sql
M src/backend/replication/logical/reorderbuffer.c
Fix nbtree lookahead overflow bug.
commit : 6749d4aabe74ca37ce351f2e318fe1b3bcf2b71c
author : Peter Geoghegan <[email protected]>
date : Mon, 26 Aug 2024 11:29:13 -0400
committer: Peter Geoghegan <[email protected]>
date : Mon, 26 Aug 2024 11:29:13 -0400
Add bounds checking to nbtree's lookahead/skip-within-a-page mechanism.
Otherwise it's possible for cases with lots of before-array-keys tuples
to overflow an int16 variable, causing the mechanism to generate an out
of bounds page offset number.
Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp
execution.
Reported-By: Alexander Lakhin <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch: 17-, where nbtree SAOP execution was enhanced.
M src/backend/access/nbtree/nbtutils.c
pg_upgrade: Message style improvements
commit : 5e58107b0bb5a10b36ba4af4a9f82e6254d75e9f
author : Peter Eisentraut <[email protected]>
date : Mon, 26 Aug 2024 14:38:59 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 26 Aug 2024 14:38:59 +0200
M src/bin/pg_upgrade/check.c
M src/bin/pg_upgrade/info.c
M src/bin/pg_upgrade/t/003_logical_slots.pl
doc PG 17 relnotes: remove ALTER TABLE SPLIT/MERGE PARTITION
commit : 74e3db06a01d1fe6b9f30f71e05e8438d3aaa37b
author : Bruce Momjian <[email protected]>
date : Sun, 25 Aug 2024 22:09:18 -0400
committer: Bruce Momjian <[email protected]>
date : Sun, 25 Aug 2024 22:09:18 -0400
Reverted in commit 84f594da358
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
Revert support for ALTER TABLE ... MERGE/SPLIT PARTITION(S) commands
commit : 84f594da358861cceeaeb7a97bb58f3765eeb284
author : Alexander Korotkov <[email protected]>
date : Sat, 24 Aug 2024 18:48:48 +0300
committer: Alexander Korotkov <[email protected]>
date : Sat, 24 Aug 2024 18:48:48 +0300
This commit reverts 1adf16b8fb, 87c21bb941, and subsequent fixes and
improvements including df64c81ca9, c99ef1811a, 9dfcac8e15, 885742b9f8,
842c9b2705, fcf80c5d5f, 96c7381c4c, f4fc7cb54b, 60ae37a8bc, 259c96fa8f,
449cdcd486, 3ca43dbbb6, 2a679ae94e, 3a82c689fd, fbd4321fd5, d53a4286d7,
c086896625, 4e5d6c4091, 04158e7fa3.
The reason for reverting is security issues related to repeatable name lookups
(CVE-2014-0062). Even though 04158e7fa3 solved part of the problem, there
are still remaining issues, which aren't feasible to even carefully analyze
before the RC deadline.
Reported-by: Noah Misch, Robert Haas
Discussion: https://postgr.es/m/20240808171351.a9.nmisch%40google.com
Backpatch-through: 17
M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/alter_table.sgml
M src/backend/commands/tablecmds.c
M src/backend/parser/gram.y
M src/backend/parser/parse_utilcmd.c
M src/backend/partitioning/partbounds.c
M src/backend/tcop/utility.c
M src/backend/utils/adt/ruleutils.c
M src/bin/psql/tab-complete.c
M src/include/nodes/parsenodes.h
M src/include/parser/kwlist.h
M src/include/partitioning/partbounds.h
M src/include/utils/ruleutils.h
D src/test/isolation/expected/partition-merge.out
D src/test/isolation/expected/partition-split.out
M src/test/isolation/isolation_schedule
D src/test/isolation/specs/partition-merge.spec
D src/test/isolation/specs/partition-split.spec
M src/test/modules/test_ddl_deparse/test_ddl_deparse.c
D src/test/regress/expected/partition_merge.out
D src/test/regress/expected/partition_split.out
M src/test/regress/parallel_schedule
D src/test/regress/sql/partition_merge.sql
D src/test/regress/sql/partition_split.sql
M src/tools/pgindent/typedefs.list
Add list of acknowledgments to release notes
commit : 29e125319896aa5567d5274e8185bb7088e101ae
author : Peter Eisentraut <[email protected]>
date : Sat, 24 Aug 2024 16:15:13 +0200
committer: Peter Eisentraut <[email protected]>
date : Sat, 24 Aug 2024 16:15:13 +0200
This contains all individuals mentioned in the commit messages during
PostgreSQL 17 development.
current through REL_17_BETA3
M doc/src/sgml/release-17.sgml
pg_createsubscriber: Message style improvements
commit : bf886dfdd444ffa8b8bbddd2015de893a6aefb96
author : Peter Eisentraut <[email protected]>
date : Sat, 24 Aug 2024 15:56:32 +0200
committer: Peter Eisentraut <[email protected]>
date : Sat, 24 Aug 2024 15:56:32 +0200
M doc/src/sgml/ref/pg_createsubscriber.sgml
M src/bin/pg_basebackup/pg_createsubscriber.c
Provide feature-test macros for libpq features added in v17.
commit : 79c3012dc2311bdaa4bb135d871d16f103a62966
author : Tom Lane <[email protected]>
date : Fri, 23 Aug 2024 10:12:56 -0400
committer: Tom Lane <[email protected]>
date : Fri, 23 Aug 2024 10:12:56 -0400
As per the policy established in commit 6991e774e, invent macros
that can be tested at compile time to detect presence of new libpq
features. This should make calling code more readable and less
error-prone than checking the libpq version would be (especially
since we don't expose that at compile time; the server version is
an unreliable substitute).
Discussion: https://postgr.es/m/[email protected]
M src/interfaces/libpq/libpq-fe.h
Fix attach of a previously-detached injection point.
commit : 6b1f78d90b5f2475d968e16febee8f9d43730d63
author : Noah Misch <[email protected]>
date : Thu, 22 Aug 2024 00:07:04 -0700
committer: Noah Misch <[email protected]>
date : Thu, 22 Aug 2024 00:07:04 -0700
It's normal for the name in a free slot to match the new name. The
max_inuse mechanism kept simple cases from reaching the problem. The
problem could appear when index 0 was the previously-detached entry and
index 1 is in use. Back-patch to v17, where this code first appeared.
M src/backend/utils/misc/injection_point.c
Avoid repeated table name lookups in createPartitionTable()
commit : f636ab41aba215eaa3303e21a10f12d81357f1f6
author : Alexander Korotkov <[email protected]>
date : Thu, 22 Aug 2024 09:50:48 +0300
committer: Alexander Korotkov <[email protected]>
date : Thu, 22 Aug 2024 09:50:48 +0300
Currently, createPartitionTable() opens newly created table using its name.
This approach is prone to privilege escalation attack, because we might end
up opening another table than we just created.
This commit address the issue above by opening newly created table by its
OID. It appears to be tricky to get a relation OID out of ProcessUtility().
We have to extend TableLikeClause with new newRelationOid field, which is
filled within ProcessUtility() to be further accessed by caller.
Security: CVE-2014-0062
Reported-by: Noah Misch
Discussion: https://postgr.es/m/20240808171351.a9.nmisch%40google.com
Reviewed-by: Pavel Borisov, Dmitry Koval
M src/backend/commands/tablecmds.c
M src/backend/parser/gram.y
M src/backend/tcop/utility.c
M src/include/nodes/parsenodes.h
Disallow creating binary-coercible casts involving range types.
commit : 2366ab246a32fa2f10523768926dcf6afe42080f
author : Tom Lane <[email protected]>
date : Wed, 21 Aug 2024 12:00:03 -0400
committer: Tom Lane <[email protected]>
date : Wed, 21 Aug 2024 12:00:03 -0400
For a long time we have forbidden binary-coercible casts to or from
composite and array types, because such a cast cannot work correctly:
the type OID embedded in the value would need to change, but it won't
in a binary coercion. That reasoning applies equally to range types,
but we overlooked installing a similar restriction here when we
invented range types. Do so now.
Given the lack of field complaints, we won't change this in stable
branches, but it seems not too late for v17.
Per discussion of a problem noted by Peter Eisentraut.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/functioncmds.c
doc: remove llvm-config search from configure documentation
commit : 0c7ec3b3a03b90c6d8afaff01635ed9060d5414d
author : Peter Eisentraut <[email protected]>
date : Wed, 21 Aug 2024 15:11:21 +0200
committer: Peter Eisentraut <[email protected]>
date : Wed, 21 Aug 2024 15:11:21 +0200
As of 4dd29b6833, we no longer attempt to locate any other llvm-config
variant than plain llvm-config in configure-based builds; update the
documentation accordingly. (For Meson-based builds, we still use Meson's
LLVMDependencyConfigTool [0], which runs through a set of possible
suffixes [1], so no need to update the documentation there.)
[0]: https://github.com/mesonbuild/meson/blob/7d28ff29396f9d7043204de8ddc52226b9903811/mesonbuild/dependencies/dev.py#L184
[1]: https://github.com/mesonbuild/meson/blob/7d28ff29396f9d7043204de8ddc52226b9903811/mesonbuild/environment.py#L183
Author: Ole Peder Brandtzæg <[email protected]>
Discussion: https://www.postgresql.org/message-id/20240518224601.gtisttjerylukjr5%40samfundet.no
M doc/src/sgml/installation.sgml
Don't advance origin during apply failure.
commit : 915aafe82a7c31e9f7452e8cedf6371c318388bd
author : Amit Kapila <[email protected]>
date : Wed, 21 Aug 2024 09:08:16 +0530
committer: Amit Kapila <[email protected]>
date : Wed, 21 Aug 2024 09:08:16 +0530
We advance origin progress during abort on successful streaming and
application of ROLLBACK in parallel streaming mode. But the origin
shouldn't be advanced during an error or unsuccessful apply due to
shutdown. Otherwise, it will result in a transaction loss as such a
transaction won't be sent again by the server.
Reported-by: Hou Zhijie
Author: Hayato Kuroda and Shveta Malik
Reviewed-by: Amit Kapila
Backpatch-through: 16
Discussion: https://postgr.es/m/TYAPR01MB5692FAC23BE40C69DA8ED4AFF5B92@TYAPR01MB5692.jpnprd01.prod.outlook.com
M src/backend/replication/logical/worker.c
M src/backend/utils/error/elog.c
M src/include/utils/elog.h
M src/test/subscription/t/021_twophase.pl
Minor wording change in table "JSON Creation Functions"
commit : 5effd5970429cdac56c8219eb4c0b8b047cac320
author : Alvaro Herrera <[email protected]>
date : Tue, 20 Aug 2024 17:53:40 -0400
committer: Alvaro Herrera <[email protected]>
date : Tue, 20 Aug 2024 17:53:40 -0400
For readability. Backpatch to 16.
Author: Erik Wienhold <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/func.sgml
Fix a couple of wait event descriptions.
commit : effc4c9a666cdb19822d7062ba1ef67ddddffb42
author : Nathan Bossart <[email protected]>
date : Tue, 20 Aug 2024 13:43:20 -0500
committer: Nathan Bossart <[email protected]>
date : Tue, 20 Aug 2024 13:43:20 -0500
The descriptions for ProcArrayGroupUpdate and XactGroupUpdate claim
that these events mean we are waiting for the group leader "at end
of a parallel operation," but neither pertains to parallel
operations. This commit reverts these descriptions to their
wording before commit 3048898e73, i.e., "end of a parallel
operation" is changed to "transaction end."
Author: Sameer Kumar
Reviewed-by: Amit Kapila
Discussion: https://postgr.es/m/CAGPeHmh6UMrKQHKCmX%2B5vV5TH9P%3DKw9en3k68qEem6J%3DyrZPUA%40mail.gmail.com
Backpatch-through: 13
M src/backend/utils/activity/wait_event_names.txt
Document limit on the number of out-of-line values per table
commit : 667401dd40c8b99bd91e91f5540defdcb7a4438e
author : John Naylor <[email protected]>
date : Tue, 20 Aug 2024 10:02:34 +0700
committer: John Naylor <[email protected]>
date : Tue, 20 Aug 2024 10:02:34 +0700
Document the hard limit stemming from the size of an OID, and also
mention the perfomance impact that occurs before the hard limit
is reached.
Jakub Wartak and Robert Haas
Backpatch to all supported versions
Discussion: https://postgr.es/m/CAKZiRmwWhp2yxjqJLwbBjHdfbJBcUmmKMNAZyBjjtpgM9AMatQ%40mail.gmail.com
M doc/src/sgml/limits.sgml
doc: Improve vague pg_createsubscriber description
commit : ef3aa800e884ba30f21ed1f36bdc587e67df39e5
author : Bruce Momjian <[email protected]>
date : Mon, 19 Aug 2024 18:27:21 -0400
committer: Bruce Momjian <[email protected]>
date : Mon, 19 Aug 2024 18:27:21 -0400
Discussion: https://postgr.es/m/[email protected]
Author: Euler Taveira
Backpatch-through: 17
M doc/src/sgml/ref/pg_createsubscriber.sgml
Avoid failure to open dropped detached partition
commit : 11f1218ce81ef3ce98389754456ca9365fa10dbe
author : Alvaro Herrera <[email protected]>
date : Mon, 19 Aug 2024 16:09:10 -0400
committer: Alvaro Herrera <[email protected]>
date : Mon, 19 Aug 2024 16:09:10 -0400
When a partition is detached and immediately dropped, a prepared
statement could try to compute a new partition descriptor that includes
it. This leads to this kind of error:
ERROR: could not open relation with OID 457639
Avoid this by skipping the partition in expand_partitioned_rtentry if it
doesn't exist.
Noted by me while investigating bug #18559. Kuntal Gosh helped to
identify the exact failure.
Backpatch to 14, where DETACH CONCURRENTLY was introduced.
Author: Álvaro Herrera <[email protected]>
Reviewed-by: Kuntal Ghosh <[email protected]>
Reviewed-by: Junwang Zhao <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/util/inherit.c
Explain dropdb can't use syscache because of TOAST
commit : de8770b47f1f763378d9d130d69e3a7b8a54684a
author : Tomas Vondra <[email protected]>
date : Mon, 19 Aug 2024 13:31:51 +0200
committer: Tomas Vondra <[email protected]>
date : Mon, 19 Aug 2024 13:31:51 +0200
Add a comment explaining dropdb() can't rely on syscache. The issue with
flattened rows was fixed by commit 0f92b230f88b, but better to have
a clear explanation why the systable scan is necessary. The other places
doing in-place updates on pg_database have the same comment.
Suggestion and patch by Yugo Nagata. Backpatch to 12, same as the fix.
Author: Yugo Nagata
Backpatch-through: 12
Discussion: https://postgr.es/m/CAJTYsWWNkCt+-UnMhg=BiCD3Mh8c2JdHLofPxsW3m2dkDFw8RA@mail.gmail.com
M src/backend/commands/dbcommands.c
Fix regression in TLS session ticket disabling
commit : 19021d28cdf0e84ebc498382826b936df62f5dba
author : Daniel Gustafsson <[email protected]>
date : Mon, 19 Aug 2024 12:55:11 +0200
committer: Daniel Gustafsson <[email protected]>
date : Mon, 19 Aug 2024 12:55:11 +0200
Commit 274bbced disabled session tickets for TLSv1.3 on top of the
already disabled TLSv1.2 session tickets, but accidentally caused
a regression where TLSv1.2 session tickets were incorrectly sent.
Fix by unconditionally disabling TLSv1.2 session tickets and only
disable TLSv1.3 tickets when the right version of OpenSSL is used.
Backpatch to all supported branches.
Reported-by: Cameron Vogt <[email protected]>
Reported-by: Fire Emerald <[email protected]>
Reviewed-by: Jacob Champion <[email protected]>
Discussion: https://postgr.es/m/DM6PR16MB3145CF62857226F350C710D1AB852@DM6PR16MB3145.namprd16.prod.outlook.com
Backpatch-through: v12
M src/backend/libpq/be-secure-openssl.c
Fix harmless LC_COLLATE[_MASK] confusion.
commit : 1cc73d15ea58ddc15f91269493811cef99987cb8
author : Thomas Munro <[email protected]>
date : Mon, 19 Aug 2024 21:21:03 +1200
committer: Thomas Munro <[email protected]>
date : Mon, 19 Aug 2024 21:21:03 +1200
Commit ca051d8b101 called newlocale(LC_COLLATE, ...) instead of
newlocale(LC_COLLATE_MASK, ...), in code reached only on FreeBSD. They
have the same value on that OS, explaining why it worked. Fix.
Back-patch to 14, where ca051d8b101 landed.
M src/backend/utils/adt/pg_locale.c
Fix more holes with SLRU code in need of int64 for segment numbers
commit : b7935bc10b78f3a44567d304df87fad3d53102dd
author : Michael Paquier <[email protected]>
date : Mon, 19 Aug 2024 12:34:52 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 19 Aug 2024 12:34:52 +0900
This is a continuation of c9e24573905b, containing changes included into
the proposed patch that have been missed in the actual commit. I have
managed to miss these diffs while doing a rebase of the original patch.
Thanks to Noah Misch, Peter Eisentraut and Alexander Korotkov for the
pokes.
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 17
M src/backend/access/transam/multixact.c
M src/backend/access/transam/slru.c
Search for SLRU page only in its own bank
commit : fad0da271e006015fcc25724aca2871d6dec04f5
author : Alvaro Herrera <[email protected]>
date : Sun, 18 Aug 2024 20:49:57 -0400
committer: Alvaro Herrera <[email protected]>
date : Sun, 18 Aug 2024 20:49:57 -0400
One of the two slot scans in SlruSelectLRUPage was not walking only the
slots in the specific bank where the buffer could be; change it to do
that.
Oversight in 53c2a97a9266.
Author: Sergey Sargsyan <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/transam/slru.c
ci: Upgrade MacPorts version to 2.10.1.
commit : 4b6aa0cffc04e8a5e1e876f3ba8cb11bd61ac40b
author : Thomas Munro <[email protected]>
date : Mon, 19 Aug 2024 11:47:37 +1200
committer: Thomas Munro <[email protected]>
date : Mon, 19 Aug 2024 11:47:37 +1200
MacPorts version 2.9.3 started failing in our ci_macports_packages.sh
script, for reasons not fully determined, but plausibly linked to the
release of 2.10.1. 2.10.1 seems to work, so let's switch to it.
Back-patch to 15, where CI began.
Reported-by: Peter Eisentraut <[email protected]>
Discussion: https://postgr.es/m/81f104e8-f0a9-43c0-85bd-2bbbf590a5b8%40eisentraut.org
M src/tools/ci/ci_macports_packages.sh
Fix DROP DATABASE for databases with many ACLs
commit : d1da80115004af2a2093479556b45d2fbcfcd571
author : Tomas Vondra <[email protected]>
date : Mon, 19 Aug 2024 00:04:41 +0200
committer: Tomas Vondra <[email protected]>
date : Mon, 19 Aug 2024 00:04:41 +0200
Commit c66a7d75e652 modified DROP DATABASE so that if interrupted, the
database is known to be in an invalid state and can only be dropped.
This is done by setting a flag using an in-place update, so that it's
not lost in case of rollback.
For databases with many ACLs, this may however fail like this:
ERROR: wrong tuple length
This happens because with many ACLs, the pg_database.datacl attribute
gets TOASTed. The dropdb() code reads the tuple from the syscache, which
means it's detoasted. But the in-place update expects the tuple length
to match the on-disk tuple.
Fixed by reading the tuple from the catalog directly, not from syscache.
Report and fix by Ayush Tiwari. Backpatch to 12. The DROP DATABASE fix
was backpatched to 11, but 11 is EOL at this point.
Reported-by: Ayush Tiwari
Author: Ayush Tiwari
Reviewed-by: Tomas Vondra
Backpatch-through: 12
Discussion: https://postgr.es/m/CAJTYsWWNkCt+-UnMhg=BiCD3Mh8c2JdHLofPxsW3m2dkDFw8RA@mail.gmail.com
M src/backend/commands/dbcommands.c
docs: fix incorrect plpgsql error message
commit : a95f13cbfb1f11955c11972ee41cd5c065246d4b
author : Bruce Momjian <[email protected]>
date : Fri, 16 Aug 2024 22:50:54 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 16 Aug 2024 22:50:54 -0400
Change "$1" to "username".
Reported-by: [email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M doc/src/sgml/plpgsql.sgml
doc PG 17 relnotes: fix incorrect reference to huge_page_status
commit : 35af4bd9519bbed6796f291e2d35cf3feffd4a86
author : Bruce Momjian <[email protected]>
date : Fri, 16 Aug 2024 13:11:23 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 16 Aug 2024 13:11:23 -0400
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/ZrTOaaxuG3JRSvwM@pryzbyj2023
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
doc PG 17 relnotes: improve text for pg_walfile_name*()
commit : 6b84ae65fb9af2152ac26675635459069647d555
author : Bruce Momjian <[email protected]>
date : Fri, 16 Aug 2024 13:01:34 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 16 Aug 2024 13:01:34 -0400
Reported-by: Yugo Nagata
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
doc PG 17 relnotes: fix pg_statistic_ext.stxstattarget ref.
commit : 0ed4a84b7cb632d23cec3b8fc92775c91ae3af7f
author : Bruce Momjian <[email protected]>
date : Fri, 16 Aug 2024 12:53:02 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 16 Aug 2024 12:53:02 -0400
Reported-by: Kisoon Kwon
Discussion: https://postgr.es/m/CAGOrKoVhjP_AeKGgzxWjRwdPqKL5Y-3TcVZoaz0bVTPwU8Yz+g@mail.gmail.com
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
Remove incidental md5() function use from test
commit : 47b47a5617fa0c49e5d8788d5f1150c21485f3ff
author : Peter Eisentraut <[email protected]>
date : Fri, 16 Aug 2024 17:14:32 +0200
committer: Peter Eisentraut <[email protected]>
date : Fri, 16 Aug 2024 17:14:32 +0200
To allow test to pass in OpenSSL FIPS mode, similar to 657f5f223e, for
a new test that has been added since.
Reviewed-by: Tomas Vondra <[email protected]>
Discussion: https://www.postgresql.org/message-id/[email protected]
M contrib/pageinspect/expected/brin.out
M contrib/pageinspect/sql/brin.sql
Relax fsyncing at end of a bulk load that was not WAL-logged
commit : 68f199cea3b190ba0bc2c83d92d17e7e1792a141
author : Heikki Linnakangas <[email protected]>
date : Fri, 16 Aug 2024 14:45:37 +0300
committer: Heikki Linnakangas <[email protected]>
date : Fri, 16 Aug 2024 14:45:37 +0300
And improve the comments.
Backpatch to v17 where this was introduced.
Reviewed-by: Noah Misch
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/backend/storage/smgr/bulk_write.c
Fix doc typo: unicode_assigned() return type.
commit : 225483238d3e46669c9d73f8faead7aff567c856
author : Jeff Davis <[email protected]>
date : Wed, 14 Aug 2024 19:05:39 -0700
committer: Jeff Davis <[email protected]>
date : Wed, 14 Aug 2024 19:05:39 -0700
Reported-by: Hironobu SUZUKI
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 17
M doc/src/sgml/func.sgml
Use errmsg_internal for debug messages
commit : 253c49e07599b8df5a51af69035f7d136de55c3a
author : Peter Eisentraut <[email protected]>
date : Tue, 13 Aug 2024 10:01:49 +0200
committer: Peter Eisentraut <[email protected]>
date : Tue, 13 Aug 2024 10:01:49 +0200
Some newer code was applying this inconsistently.
M src/backend/postmaster/walsummarizer.c
Fix creation of partition descriptor during concurrent detach+drop
commit : 0820f80622ed415a88d2c79b04d292ae79023f50
author : Alvaro Herrera <[email protected]>
date : Mon, 12 Aug 2024 18:17:56 -0400
committer: Alvaro Herrera <[email protected]>
date : Mon, 12 Aug 2024 18:17:56 -0400
If a partition undergoes DETACH CONCURRENTLY immediately followed by
DROP, this could cause a problem for a concurrent transaction
recomputing the partition descriptor when running a prepared statement,
because it tries to dereference a pointer to a tuple that's not found in
a catalog scan.
The existing retry logic added in commit dbca3469ebf8 is sufficient to
cope with the overall problem, provided we don't try to dereference a
non-existant heap tuple.
Arguably, the code in RelationBuildPartitionDesc() has been wrong all
along, since no check was added in commit 898e5e3290a7 against receiving
a NULL tuple from the catalog scan; that bug has only become
user-visible with DETACH CONCURRENTLY which was added in branch 14.
Therefore, even though there's no known mechanism to cause a crash
because of this, backpatch the addition of such a check to all supported
branches. In branches prior to 14, this would cause the code to fail
with a "missing relpartbound for relation XYZ" error instead of
crashing; that's okay, because there are no reports of such behavior
anyway.
Author: Kuntal Ghosh <[email protected]>
Reviewed-by: Junwang Zhao <[email protected]>
Reviewed-by: Tender Wang <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/partitioning/partdesc.c
Log more info when wait-for-catchup tests time out.
commit : e57296ed4867b3a3734db9ca621223c30eebb90d
author : Tom Lane <[email protected]>
date : Mon, 12 Aug 2024 13:18:36 -0400
committer: Tom Lane <[email protected]>
date : Mon, 12 Aug 2024 13:18:36 -0400
Cluster.pm's wait_for_catchup and allied subroutines don't provide
enough information to diagnose the problem when a wait times out.
In hopes of debugging some intermittent buildfarm failures, let's
dump the ending state of the relevant system view when that happens.
Add this to v17 too, but not stable branches.
Discussion: https://postgr.es/m/[email protected]
M src/test/perl/PostgreSQL/Test/Cluster.pm
Suppress Coverity warnings about Asserts in get_name_for_var_field.
commit : aed881386aa6a6a542e46d14d3505e4e6f9310a0
author : Tom Lane <[email protected]>
date : Sun, 11 Aug 2024 12:24:56 -0400
committer: Tom Lane <[email protected]>
date : Sun, 11 Aug 2024 12:24:56 -0400
Coverity thinks dpns->plan could be null at these points. That
shouldn't really be possible, but it's easy enough to modify the
Asserts so they'd not core-dump if it were true.
These are new in b919a97a6. Back-patch to v13; the v12 version
of the patch didn't have these Asserts.
M src/backend/utils/adt/ruleutils.c
Allow adjusting session_authorization and role in parallel workers.
commit : 2b8d33f66c134b5f1b0a94a7e40af2fbb6a086b7
author : Tom Lane <[email protected]>
date : Sat, 10 Aug 2024 15:51:28 -0400
committer: Tom Lane <[email protected]>
date : Sat, 10 Aug 2024 15:51:28 -0400
The code intends to allow GUCs to be set within parallel workers
via function SET clauses, but not otherwise. However, doing so fails
for "session_authorization" and "role", because the assign hooks for
those attempt to set the subsidiary "is_superuser" GUC, and that call
falls foul of the "not otherwise" prohibition. We can't switch to
using GUC_ACTION_SAVE for this, so instead add a new GUC variable
flag GUC_ALLOW_IN_PARALLEL to mark is_superuser as being safe to set
anyway. (This is okay because is_superuser has context PGC_INTERNAL
and thus only hard-wired calls can change it. We'd need more thought
before applying the flag to other GUCs; but maybe there are other
use-cases.) This isn't the prettiest fix perhaps, but other
alternatives we thought of would be much more invasive.
While here, correct a thinko in commit 059de3ca4: when rejecting
a GUC setting within a parallel worker, we should return 0 not -1
if the ereport doesn't longjmp. (This seems to have no consequences
right now because no caller cares, but it's inconsistent.) Improve
the comments to try to forestall future confusion of the same kind.
Despite the lack of field complaints, this seems worth back-patching.
Thanks to Nathan Bossart for the idea to invent a new flag,
and for review.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/guc_tables.c
M src/include/utils/guc.h
M src/test/regress/expected/select_parallel.out
M src/test/regress/sql/select_parallel.sql
Lower minimum maintenance_work_mem to 64kB
commit : 2eda3df9ad532a051976937cfc17d6c52bbdacd6
author : John Naylor <[email protected]>
date : Tue, 6 Aug 2024 20:38:33 +0700
committer: John Naylor <[email protected]>
date : Tue, 6 Aug 2024 20:38:33 +0700
Since the introduction of TID store, vacuum uses far less memory in
the common case than in versions 16 and earlier. Invoking multiple
rounds of index vacuuming in turn requires a much larger table. It'd
be a good idea anyway to cover this case in regression testing, and a
lower limit is less painful for slow buildfarm animals. The reason to
do it now is to re-enable coverage of the bugfix in commit 83c39a1f7f.
For consistency, give autovacuum_work_mem the same treatment.
Suggested by Andres Freund
Tested by Melanie Plageman
Backpatch to v17, where TID store was introduced
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/20240722164745.fvaoh6g6zprisqgp%40awork3.anarazel.de
M src/backend/postmaster/autovacuum.c
M src/backend/utils/misc/guc_tables.c
M src/backend/utils/misc/postgresql.conf.sample
doc: Fix name of CRC algorithm in "Reliability" section.
commit : 6bec76faa4bd7eda34f213f0831d77506d66147c
author : Nathan Bossart <[email protected]>
date : Fri, 9 Aug 2024 10:52:37 -0500
committer: Nathan Bossart <[email protected]>
date : Fri, 9 Aug 2024 10:52:37 -0500
This section claims we use CRC-32 for WAL records and two-phase
state files, but we've actually used CRC-32C since v9.5 (commit
5028f22f6e). Fix that.
Reviewed-by: Robert Haas
Discussion: https://postgr.es/m/ZrUFpLP-w2zTAHqq%40nathan
Backpatch-through: 12
M doc/src/sgml/wal.sgml
Fix "failed to find plan for subquery/CTE" errors in EXPLAIN.
commit : 81a12a4477533d7722bd6b6dac88b0e798f8e85b
author : Tom Lane <[email protected]>
date : Fri, 9 Aug 2024 11:21:39 -0400
committer: Tom Lane <[email protected]>
date : Fri, 9 Aug 2024 11:21:39 -0400
To deparse a reference to a field of a RECORD-type output of a
subquery, EXPLAIN normally digs down into the subquery's plan to try
to discover exactly which anonymous RECORD type is meant. However,
this can fail if the subquery has been optimized out of the plan
altogether on the grounds that no rows could pass the WHERE quals,
which has been possible at least since 3fc6e2d7f. There isn't
anything remaining in the plan tree that would help us, so fall back
to printing the field name as "fN" for the N'th column of the record.
(This will actually be the right thing some of the time, since it
matches the column names we assign to RowExprs.)
In passing, fix a comment typo in create_projection_plan, which
I noticed while experimenting with an alternative fix for this.
Per bug #18576 from Vasya B. Back-patch to all supported branches.
Richard Guo and Tom Lane
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/plan/createplan.c
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/rowtypes.out
M src/test/regress/sql/rowtypes.sql
Refuse ATTACH of a table referenced by a foreign key
commit : 344f9f5e2b181331ead4b7bcd792216ecc5f2946
author : Alvaro Herrera <[email protected]>
date : Thu, 8 Aug 2024 19:35:13 -0400
committer: Alvaro Herrera <[email protected]>
date : Thu, 8 Aug 2024 19:35:13 -0400
Trying to attach a table as a partition which is already on the
referenced side of a foreign key on the partitioned table that it is
being attached to, leads to strange behavior: we try to clone the
foreign key from the parent to the partition, but this new FK points to
the partition itself, and the mix of pg_constraint rows and triggers
doesn't behave well.
Rather than trying to untangle the mess (which might be possible given
sufficient time), I opted to forbid the ATTACH. This doesn't seem a
problematic restriction, given that we already fail to create the
foreign key if you do it the other way around, that is, having the
partition first and the FK second.
Backpatch to all supported branches.
Reported-by: Alexander Lakhin <[email protected]>
Reviewed-by: Tender Wang <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Refactor error messages to reduce duplication
commit : 28b953f26343105ebf3a1a212092e2c3c0bb0914
author : Alvaro Herrera <[email protected]>
date : Thu, 8 Aug 2024 15:17:11 -0400
committer: Alvaro Herrera <[email protected]>
date : Thu, 8 Aug 2024 15:17:11 -0400
I also took the liberty of changing
errmsg("COPY DEFAULT only available using COPY FROM")
to
errmsg("COPY %s cannot be used with %s", "DEFAULT", "COPY TO")
because the original wording is unlike all other messages that indicate
option incompatibility. This message was added by commit 9f8377f7a279
(16-era), in whose development thread there was no discussion on this
point.
Backpatch to 17.
M src/backend/commands/copy.c
M src/backend/commands/copyfrom.c
M src/backend/commands/copyto.c
M src/test/regress/expected/copy2.out
Fix pg_rewind debug output to print the source timeline history
commit : a7bf3e66852743503eb32cb38d93c0740dcca00a
author : Heikki Linnakangas <[email protected]>
date : Thu, 8 Aug 2024 10:20:25 +0300
committer: Heikki Linnakangas <[email protected]>
date : Thu, 8 Aug 2024 10:20:25 +0300
getTimelineHistory() is called twice, to read the source and the
target timeline history files. However, the loop to print the file
with the --debug option used the wrong variable when dealing with the
source. As a result, the source's history was always printed as empty.
Spotted while debugging bug #18575, but this does not fix that bug,
just the debugging output. Backpatch to all supported versions.
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/bin/pg_rewind/pg_rewind.c
Revert ECPG's use of pnstrdup()
commit : e9e05c655069139ff1533497073d980994dde290
author : Peter Eisentraut <[email protected]>
date : Wed, 7 Aug 2024 09:21:07 +0200
committer: Peter Eisentraut <[email protected]>
date : Wed, 7 Aug 2024 09:21:07 +0200
Commit 0b9466fce added a dependency on fe_memutils' pnstrdup() inside
informix.c. This adds an exit() path in a library, which we don't
want. (Unlike libpq, the ecpg libraries don't have an automated check
for that, but it makes sense to keep them to a similar standard.) The
ecpg code can already handle failure results from the *strdup() call
by itself.
Author: Jacob Champion <[email protected]>
Discussion: https://www.postgresql.org/message-id/CAOYmi+=pg=W5L1h=3MEP_EB24jaBu2FyATrLXqQHGe7cpuvwyg@mail.gmail.com
M src/interfaces/ecpg/compatlib/informix.c
Fix names of "Visual Studio" and Meson in a documentation sentence.
commit : 75345f6985f2d202e43b4fd5ad9e73908c257445
author : Noah Misch <[email protected]>
date : Wed, 7 Aug 2024 11:43:08 -0700
committer: Noah Misch <[email protected]>
date : Wed, 7 Aug 2024 11:43:08 -0700
Commit 3cffe7946c268be91a340ec9a27081cb93d67d35 missed this. Back-patch
to v17, which introduced this.
Discussion: https://postgr.es/m/CAJ7c6TM7ct0EjoCQaLSVYoxxnEw4xCUFebWj77GktWsqEdyCtQ@mail.gmail.com
M doc/src/sgml/installation.sgml
Fix edge case in plpgsql's make_callstmt_target().
commit : 0dd33a6fcab746d518cec56d2bc0d8ec0edffd32
author : Tom Lane <[email protected]>
date : Wed, 7 Aug 2024 12:54:39 -0400
committer: Tom Lane <[email protected]>
date : Wed, 7 Aug 2024 12:54:39 -0400
If the plancache entry for the CALL statement is already stale,
it's possible for us to fetch an old procedure OID out of it,
and then fail with "cache lookup failed for function NNN".
In ordinary usage this never happens because make_callstmt_target
is called just once immediately after building the plancache
entry. It can be forced however by setting up an erroneous CALL
(that causes make_callstmt_target itself to report an error),
then dropping/recreating the target procedure, then repeating
the erroneous CALL.
To fix, use SPI_plan_get_cached_plan() to fetch the plancache's
plan, rather than assuming we can use SPI_plan_get_plan_sources().
This shouldn't add any noticeable overhead in the normal case,
and in the stale-plan case we'd have had to replan anyway a little
further down.
The other callers of SPI_plan_get_plan_sources() seem OK, because
either they don't need up-to-date plans or they know that the
query was just (re) planned. But add some commentary in hopes
of not falling into this trap again.
Per bug #18574 from Song Hongyu. Back-patch to v14 where this coding
was introduced. (Older branches have comparable code, but it's run
after any required replanning, so there's no issue.)
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/spi.c
M src/pl/plpgsql/src/pl_exec.c
Refactor/reword some error messages to avoid duplicates
commit : 899f39ea25f2ee63a0c557f3908e15b280a4367a
author : Alvaro Herrera <[email protected]>
date : Wed, 7 Aug 2024 11:30:36 -0400
committer: Alvaro Herrera <[email protected]>
date : Wed, 7 Aug 2024 11:30:36 -0400
Also, remove brackets around "EMPTY [ ARRAY ]". An error message is
not the place to state that a keyword is optional.
Backpatch to 17.
M src/backend/executor/execExprInterp.c
M src/backend/parser/parse_expr.c
M src/backend/parser/parse_jsontable.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out
Make fallback MD5 implementation thread-safe on big-endian systems
commit : ffac8ac48e409bbc7c2d9a4b37a1c39908ca24eb
author : Heikki Linnakangas <[email protected]>
date : Wed, 7 Aug 2024 10:43:52 +0300
committer: Heikki Linnakangas <[email protected]>
date : Wed, 7 Aug 2024 10:43:52 +0300
Replace a static scratch buffer with a local variable, because a
static buffer makes the function not thread-safe. This function is
used in client-code in libpq, so it needs to be thread-safe. It was
until commit b67b57a966, which replaced the implementation with the
one from pgcrypto.
Backpatch to v14, where we switched to the new implementation.
Reviewed-by: Robert Haas, Michael Paquier
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/common/md5.c
Stamp 17beta3.
commit : b18b3a8150dbb150124bd345e000d6dc92f3d6dd
author : Tom Lane <[email protected]>
date : Mon, 5 Aug 2024 16:03:01 -0400
committer: Tom Lane <[email protected]>
date : Mon, 5 Aug 2024 16:03:01 -0400
M configure
M configure.ac
M meson.build
Restrict accesses to non-system views and foreign tables during pg_dump.
commit : fdf218f1d52b2c93145f16b28b8374703ae4ef19
author : Masahiko Sawada <[email protected]>
date : Mon, 5 Aug 2024 06:05:30 -0700
committer: Masahiko Sawada <[email protected]>
date : Mon, 5 Aug 2024 06:05:30 -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 doc/src/sgml/ref/pg_dump.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_tables.c
M src/bin/pg_dump/pg_dump.c
M src/include/tcop/tcopprot.h
M src/include/utils/guc_hooks.h
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
Translation updates
commit : 91099bb287ff71c970c72b81e6a190d80a92e760
author : Peter Eisentraut <[email protected]>
date : Mon, 5 Aug 2024 12:12:32 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 5 Aug 2024 12:12:32 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: f1fa38f3bf3e0a5d3a95304dcf6a11acf304577c
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/ja.po
M src/backend/po/pt_BR.po
M src/backend/po/sv.po
M src/bin/initdb/po/es.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/pt_BR.po
M src/bin/initdb/po/sv.po
M src/bin/initdb/po/zh_CN.po
M src/bin/pg_amcheck/po/es.po
M src/bin/pg_amcheck/po/fr.po
M src/bin/pg_amcheck/po/sv.po
M src/bin/pg_archivecleanup/po/es.po
M src/bin/pg_archivecleanup/po/fr.po
M src/bin/pg_archivecleanup/po/ka.po
M src/bin/pg_archivecleanup/po/sv.po
M src/bin/pg_archivecleanup/po/zh_CN.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/ja.po
M src/bin/pg_basebackup/po/ka.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_checksums/po/es.po
M src/bin/pg_checksums/po/fr.po
M src/bin/pg_checksums/po/ka.po
M src/bin/pg_checksums/po/sv.po
M src/bin/pg_combinebackup/po/LINGUAS
M src/bin/pg_combinebackup/po/de.po
A src/bin/pg_combinebackup/po/es.po
M src/bin/pg_combinebackup/po/ja.po
M src/bin/pg_combinebackup/po/ka.po
A src/bin/pg_combinebackup/po/sv.po
M src/bin/pg_config/po/es.po
M src/bin/pg_config/po/fr.po
M src/bin/pg_config/po/ka.po
M src/bin/pg_config/po/sv.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/fr.po
M src/bin/pg_controldata/po/ka.po
M src/bin/pg_controldata/po/sv.po
M src/bin/pg_controldata/po/zh_TW.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_ctl/po/ja.po
M src/bin/pg_ctl/po/ka.po
M src/bin/pg_ctl/po/sv.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/ka.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_resetwal/po/es.po
M src/bin/pg_resetwal/po/ka.po
M src/bin/pg_resetwal/po/sv.po
M src/bin/pg_rewind/po/es.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_test_fsync/po/es.po
M src/bin/pg_test_fsync/po/ka.po
M src/bin/pg_test_fsync/po/sv.po
M src/bin/pg_test_timing/po/es.po
M src/bin/pg_test_timing/po/ka.po
M src/bin/pg_test_timing/po/sv.po
M src/bin/pg_upgrade/po/es.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_verifybackup/po/es.po
M src/bin/pg_verifybackup/po/ka.po
M src/bin/pg_verifybackup/po/sv.po
M src/bin/pg_waldump/po/es.po
M src/bin/pg_waldump/po/ka.po
M src/bin/pg_waldump/po/sv.po
M src/bin/pg_walsummary/po/LINGUAS
A src/bin/pg_walsummary/po/es.po
M src/bin/pg_walsummary/po/ka.po
A src/bin/pg_walsummary/po/sv.po
M src/bin/psql/po/cs.po
M src/bin/psql/po/el.po
M src/bin/psql/po/es.po
M src/bin/psql/po/it.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/sv.po
M src/bin/psql/po/uk.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/fr.po
M src/bin/scripts/po/ko.po
M src/bin/scripts/po/pt_BR.po
M src/bin/scripts/po/sv.po
M src/bin/scripts/po/zh_CN.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/ecpglib/po/sv.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/fr.po
M src/interfaces/ecpg/preproc/po/ja.po
M src/interfaces/ecpg/preproc/po/sv.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/sv.po
M src/pl/plperl/po/es.po
M src/pl/plperl/po/sv.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpgsql/src/po/sv.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/sv.po
M src/pl/tcl/po/es.po
M src/pl/tcl/po/ja.po
M src/pl/tcl/po/sv.po
Fix name of "Visual Studio" in documentation.
commit : c175c9202d730df366f21c1aaac1a165bb98c065
author : Noah Misch <[email protected]>
date : Fri, 2 Aug 2024 12:49:56 -0700
committer: Noah Misch <[email protected]>
date : Fri, 2 Aug 2024 12:49:56 -0700
Back-patch to v17, which introduced this.
Aleksander Alekseev
Discussion: https://postgr.es/m/CAJ7c6TM7ct0EjoCQaLSVYoxxnEw4xCUFebWj77GktWsqEdyCtQ@mail.gmail.com
M doc/src/sgml/installation.sgml
Fix NLS file reference in pg_createsubscriber
commit : ca264553485e3a4e5955e108e571baf0c68c641d
author : Alvaro Herrera <[email protected]>
date : Fri, 2 Aug 2024 12:05:38 -0400
committer: Alvaro Herrera <[email protected]>
date : Fri, 2 Aug 2024 12:05:38 -0400
pg_createsubscriber is referring to a non-existent message translation
file, causing NLS to not work correctly. This command should use the
same file as pg_basebackup.
Author: Kyotaro Horiguchi <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_basebackup/pg_createsubscriber.c
pg_createsubscriber: Fix bogus error message
commit : 8c6ba6e6a834030c80d7e0d2fa28101e9e17a993
author : Alvaro Herrera <[email protected]>
date : Fri, 2 Aug 2024 12:01:10 -0400
committer: Alvaro Herrera <[email protected]>
date : Fri, 2 Aug 2024 12:01:10 -0400
Also some desultory style improvement
M src/bin/pg_basebackup/pg_createsubscriber.c
pg_createsubscriber: Rename option --socket-directory to --socketdir
commit : 83737ef89c69dcf61ecc40cc11aac80e78f46c5a
author : Peter Eisentraut <[email protected]>
date : Thu, 1 Aug 2024 12:09:56 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 1 Aug 2024 12:09:56 +0200
For consistency with the equivalent option in pg_upgrade.
Reviewed-by: Hayato Kuroda <[email protected]>
Reviewed-by: Euler Taveira <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/1ed82b9b-8e20-497d-a2f8-aebdd793d595%40eisentraut.org
M doc/src/sgml/ref/pg_createsubscriber.sgml
M src/bin/pg_basebackup/pg_createsubscriber.c
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl
Update comment in portal.h.
commit : eb39497eed2983caff4a2bb808c8bc1e378b4f68
author : Etsuro Fujita <[email protected]>
date : Thu, 1 Aug 2024 17:45:00 +0900
committer: Etsuro Fujita <[email protected]>
date : Thu, 1 Aug 2024 17:45:00 +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 : 630b81d5cc00fa8bf1cb7e861a3778ed3080e621
author : Tom Lane <[email protected]>
date : Wed, 31 Jul 2024 20:54:31 -0400
committer: Tom Lane <[email protected]>
date : Wed, 31 Jul 2024 20:54:31 -0400
This reverts commit 5887dd4894db5ac1c6411615160555ac6e57e49b.
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 : 5887dd4894db5ac1c6411615160555ac6e57e49b
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 : 3256722d7b7ff64918a0e5fdf6140de355147fe6
author : David Rowley <[email protected]>
date : Thu, 1 Aug 2024 01:26:16 +1200
committer: David Rowley <[email protected]>
date : Thu, 1 Aug 2024 01:26:16 +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
Relax check for return value from second call of pg_strnxfrm().
commit : 10fdc67f81972a03eee928a3b0ae226a78243fad
author : Jeff Davis <[email protected]>
date : Tue, 30 Jul 2024 16:23:20 -0700
committer: Jeff Davis <[email protected]>
date : Tue, 30 Jul 2024 16:23:20 -0700
strxfrm() is not guaranteed to return the exact number of bytes needed
to store the result; it may return a higher value.
Discussion: https://postgr.es/m/[email protected]
Reviewed-by: Heikki Linnakangas
Backpatch-through: 16
M src/backend/access/hash/hashfunc.c
M src/backend/utils/adt/pg_locale.c
M src/backend/utils/adt/varchar.c
Preserve tz when converting to jsonb timestamptz
commit : 0d57dc2f9137de47534cc4db115e182e4093b945
author : Andrew Dunstan <[email protected]>
date : Tue, 30 Jul 2024 07:57:16 -0400
committer: Andrew Dunstan <[email protected]>
date : Tue, 30 Jul 2024 07:57:16 -0400
This removes an inconsistency in the treatment of different datatypes by
the jsonpath timestamp_tz() function. Conversions from data types that
are not timestamp-aware, such as date and timestamp, are now treated
consistently with conversion from those that are such as timestamptz.
Author: David Wheeler
Reviewed-by: Junwang Zhao and Jeevan Chalke
Discussion: https://postgr.es/m/7DE080CE-6D8C-4794-9BD1-7D9699172FAB%40justatheory.com
Backpatch to release 17.
M src/backend/utils/adt/jsonpath_exec.c
M src/test/regress/expected/jsonb_jsonpath.out
pg_createsubscriber: Remove obsolete comment
commit : 71795d1cb41b8144ae8b84bee1e60cfc8321cfd1
author : Peter Eisentraut <[email protected]>
date : Tue, 30 Jul 2024 12:21:20 +0200
committer: Peter Eisentraut <[email protected]>
date : Tue, 30 Jul 2024 12:21:20 +0200
This comment should have been removed by commit b9639138262. There is
no replication slot check on the primary anymore.
Author: Euler Taveira <[email protected]>
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/bin/pg_basebackup/pg_createsubscriber.c
Stabilize xid_wraparound tests
commit : 787ea8c9d812e5ae76b7a8981e5f93cee80c8a36
author : Andrew Dunstan <[email protected]>
date : Tue, 30 Jul 2024 06:17:48 -0400
committer: Andrew Dunstan <[email protected]>
date : Tue, 30 Jul 2024 06:17:48 -0400
The tests had a race condition if autovacuum was set to off. Instead we
create all the tables we are interested in with autovacuum disabled, so
they are only ever touched when in danger of wraparound.
Discussion: https://postgr.es/m/[email protected]
Masahiko Sawada (slightly tweaked by me)
Backpatch to release 17 where these tests were introduced.
M src/test/modules/xid_wraparound/t/001_emergency_vacuum.pl
M src/test/modules/xid_wraparound/t/002_limits.pl
M src/test/modules/xid_wraparound/t/003_wraparounds.pl
pg_createsubscriber: Fix an unpredictable recovery wait time.
commit : e5ba6a5ab62ce05e2a762b4d26f0fd0c52c7b521
author : Amit Kapila <[email protected]>
date : Tue, 30 Jul 2024 14:17:30 +0530
committer: Amit Kapila <[email protected]>
date : Tue, 30 Jul 2024 14:17:30 +0530
The problem is that the tool is using the LSN returned by
pg_create_logical_replication_slot() as recovery_target_lsn. This LSN is
ahead of the current WAL position and the recovery waits until the
publisher writes a WAL record to reach the target and ends the recovery.
On idle systems, this wait time is unpredictable and could lead to failure
in promoting the subscriber. To avoid that, insert a harmless WAL record.
Reported-by: Alexander Lakhin and Tom Lane
Diagnosed-by: Hayato Kuroda
Author: Euler Taveira
Reviewed-by: Hayato Kuroda, Amit Kapila
Backpatch-through: 17
Discussion: https://postgr.es/m/2377319.1719766794%40sss.pgh.pa.us
Discussion: https://postgr.es/m/CA+TgmoYcY+Wb67NAwaHT7MvxCSeV86oSc+va9hHKaasE42ukyw@mail.gmail.com
M src/bin/pg_basebackup/pg_createsubscriber.c
SQL/JSON: Fix casting for integer EXISTS columns in JSON_TABLE
commit : f95c5090d975c3f552823f1f6895193d5da19825
author : Amit Langote <[email protected]>
date : Tue, 30 Jul 2024 10:12:23 +0900
committer: Amit Langote <[email protected]>
date : Tue, 30 Jul 2024 10:12:23 +0900
The current method of coercing the boolean result value of
JsonPathExists() to the target type specified for an EXISTS column,
which is to call the type's input function via json_populate_type(),
leads to an error when the target type is integer, because the
integer input function doesn't recognize boolean literal values as
valid.
Instead use the boolean-to-integer cast function for coercion in that
case so that using integer or domains thereof as type for EXISTS
columns works. Note that coercion for ON ERROR values TRUE and FALSE
already works like that because the parser creates a cast expression
including the cast function, but the coercion of the actual result
value is not handled by the parser.
Tests by Jian He.
Reported-by: Jian He <[email protected]>
Author: Jian He <[email protected]>
Author: Amit Langote <[email protected]>
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
M src/include/executor/execExpr.h
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql
SQL/JSON: Some fixes to JsonBehavior expression casting
commit : 847ee701bd3a6d222ab8f67923e308ee1a70a2f8
author : Amit Langote <[email protected]>
date : Tue, 30 Jul 2024 10:37:56 +0900
committer: Amit Langote <[email protected]>
date : Tue, 30 Jul 2024 10:37:56 +0900
1. Remove the special case handling when casting the JsonBehavior
expressions to types with typmod, like 86d33987 did for the casting
of SQL/JSON constructor functions.
2. Fix casting for fixed-length character and bit string types by
using assignment-level casts. This is again similar to what
86d33987 did, but for ON ERROR / EMPTY expressions.
3. Use runtime coercion for the boolean ON ERROR constants so that
using fixed-length character string types, for example, for an
EXISTS column doesn't cause a "value too long for type
character(n)" when the parser tries to coerce the default ON ERROR
value "false" to that type, that is, even when clause is not
specified.
4. Simplify the conditions of when to use runtime coercion vs
creating the cast expression in the parser itself. jsonb-valued
expressions are now always coerced at runtime and boolean
expressions too if the target type is a string type for the
reasons mentioned above.
New tests are from a patch that Jian He posted. Outputs of some
existing tests change because the coercion now happens at runtime
instead of at parse time.
Reported-by: Jian He <[email protected]>
Author: Jian He <[email protected]>
Author: Amit Langote <[email protected]>
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
M src/backend/parser/parse_expr.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_jsontable.sql
M src/test/regress/sql/sqljson_queryfuncs.sql
Detach syslogger from shared memory
commit : f208a16035fc5d18cee0e7e2fbf176616905f9b0
author : Heikki Linnakangas <[email protected]>
date : Mon, 29 Jul 2024 22:21:34 +0300
committer: Heikki Linnakangas <[email protected]>
date : Mon, 29 Jul 2024 22:21:34 +0300
Commit aafc05de1b removed the calls to detach from shared memory from
syslogger startup. That was not intentional, so put them back.
Author: Rui Zhao
Reviewed-by: Aleksander Alekseev
Backpatch-through: 17
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/backend/postmaster/launch_backend.c
Count individual SQL commands in pg_restore's --transaction-size mode.
commit : 81db073a287842cbf0a17cb32108b214a335670b
author : Tom Lane <[email protected]>
date : Mon, 29 Jul 2024 12:17:24 -0400
committer: Tom Lane <[email protected]>
date : Mon, 29 Jul 2024 12:17:24 -0400
The initial implementation in commit 959b38d77 counted one action
per TOC entry (except for some special cases for multi-blob BLOBS
entries). This assumes that TOC entries are all about equally
complex, but it turns out that that assumption doesn't hold up very
well in binary-upgrade mode. For example, even after the previous
commit I was able to cause backend bloat with tables having many
inherited constraints. There may be other cases too. (Since no
serious problems have been reported with --single-transaction mode,
we can conclude that the backend copes well with psql's regular
restore scripts; but before 959b38d77 we never ran binary-upgrade
restores with multi-command transactions.)
To fix, count multi-command TOC entries as N actions, allowing the
transaction size to be scaled down when we hit a complex TOC entry.
Rather than add a SQL parser to pg_restore, approximate "multi
command" by counting semicolons in the TOC entry's defn string.
This will be fooled by semicolons appearing in string literals ---
but the error is in the conservative direction, so it doesn't seem
worth working harder. The biggest risk is with function/procedure
TOC entries, but we can just explicitly skip those.
(This is undoubtedly a hack, and maybe someday we'll be able to
revert it after fixing the backend's bloat issues or rethinking
what pg_dump emits in binary upgrade mode. But that surely isn't
a project for v17.)
Thanks to Alexander Korotkov for the let's-count-semicolons idea.
Per report from Justin Pryzby. Back-patch to v17 where txn_size mode
was introduced.
Discussion: https://postgr.es/m/ZqEND4ZcTDBmcv31@pryzbyj2023
M src/bin/pg_dump/pg_backup_archiver.c
Reduce number of commands dumpTableSchema emits for binary upgrade.
commit : 2fa989e6a3407b9da625e1524c8694bc028e25ba
author : Tom Lane <[email protected]>
date : Mon, 29 Jul 2024 11:53:49 -0400
committer: Tom Lane <[email protected]>
date : Mon, 29 Jul 2024 11:53:49 -0400
Avoid issuing a separate SQL UPDATE command for each column when
directly manipulating pg_attribute contents in binary upgrade mode.
With the separate updates, we triggered a relcache invalidation with
each update. For a table with N columns, that causes O(N^2) relcache
bloat in txn_size mode because the table's newly-created relcache
entry can't be flushed till end of transaction. Reducing the number
of commands should make it marginally faster as well as avoiding that
problem.
While at it, likewise avoid issuing a separate UPDATE on pg_constraint
for each inherited constraint. This is less exciting, first because
inherited (non-partitioned) constraints are relatively rare, and
second because the backend has a good deal of trouble anyway with
restoring tables containing many such constraints, due to
MergeConstraintsIntoExisting being horribly inefficient. But it seems
more consistent to do it this way here too, and it surely can't hurt.
In passing, fix one place in dumpTableSchema that failed to use ONLY
in ALTER TABLE. That's not a live bug, but it's inconsistent.
Also avoid silently casting away const from string literals.
Per report from Justin Pryzby. Back-patch to v17 where txn_size mode
was introduced.
Discussion: https://postgr.es/m/ZqEND4ZcTDBmcv31@pryzbyj2023
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl
Fix incorrect return value for pg_size_pretty(bigint)
commit : 1e020258e53c87c697615390c42a191344bbb909
author : David Rowley <[email protected]>
date : Sun, 28 Jul 2024 22:23:32 +1200
committer: David Rowley <[email protected]>
date : Sun, 28 Jul 2024 22:23:32 +1200
pg_size_pretty(bigint) would return the value in bytes rather than PB
for the smallest-most bigint value. This happened due to an incorrect
assumption that the absolute value of -9223372036854775808 could be
stored inside a signed 64-bit type.
Here we fix that by instead storing that value in an unsigned 64-bit type.
This bug does exist in versions prior to 15 but the code there is
sufficiently different and the bug seems sufficiently non-critical that
it does not seem worth risking backpatching further.
Author: Joseph Koshakow <[email protected]>
Discussion: https://postgr.es/m/CAAvxfHdTsMZPWEHUrZ=h3cky9Ccc3Mtx2whUHygY+ABP-mCmUw@mail.gmail.com
Backpatch-through: 15
M src/backend/utils/adt/dbsize.c
M src/test/regress/expected/dbsize.out
M src/test/regress/sql/dbsize.sql
libpq: Use strerror_r instead of strerror
commit : 821fbd63eab0c35c034e83d278da7244cf1be463
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
doc PG 17 relnotes: add "()" to PQsocketPoll mention
commit : 7525e4c62f99aca910566ddb0749dbaf944904c5
author : Bruce Momjian <[email protected]>
date : Sun, 28 Jul 2024 04:10:11 -0400
committer: Bruce Momjian <[email protected]>
date : Sun, 28 Jul 2024 04:10:11 -0400
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
Support falling back to non-preferred readline implementation with meson
commit : ed9d0446320050b5506861c0b583e0a24c7cb9d7
author : Heikki Linnakangas <[email protected]>
date : Sat, 27 Jul 2024 13:53:16 +0300
committer: Heikki Linnakangas <[email protected]>
date : Sat, 27 Jul 2024 13:53:16 +0300
To build with -Dreadline=enabled one can use either readline or
libedit. The -Dlibedit_preferred flag is supposed to control the order
of names to lookup. This works fine when either both libraries are
present or -Dreadline is set to auto. However, explicitly enabling
readline with only libedit present, but not setting libedit_preferred,
or alternatively enabling readline with only readline present, but
setting libedit_preferred, too, are both broken. This is because
cc.find_library will throw an error for a not found dependency as soon
as the first required dependency is checked, thus it's impossible to
fallback to the alternative.
Here we only check the second of the two dependencies for
requiredness, thus we only fail when none of the two can be found.
Author: Wolfgang Walther
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut
Reviewed-by: Tristan Partin
Discussion: https://www.postgresql.org/message-id/[email protected]
Backpatch: 16-, where meson support was added
M meson.build
Support absolute bindir/libdir in regression tests with meson
commit : eb6765d57cfabc63bdb02375ec2e788783b88a0f
author : Heikki Linnakangas <[email protected]>
date : Sat, 27 Jul 2024 13:53:14 +0300
committer: Heikki Linnakangas <[email protected]>
date : Sat, 27 Jul 2024 13:53:14 +0300
Passing an absolute bindir/libdir will install the binaries and
libraries to <build>/tmp_install/<bindir> and
<build>/tmp_install/<libdir> respectively.
This path is correctly passed to the regression test suite via
configure/make, but not via meson, yet. This is because the "/"
operator in the following expression throws away the whole left side
when the right side is an absolute path:
test_install_location / get_option('libdir')
This was already correctly handled for dir_prefix, which is likely
absolute as well. This patch handles both bindir and libdir in the
same way - prefixing absolute paths with the tmp_install path
correctly.
Author: Wolfgang Walther
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut
Reviewed-by: Tristan Partin
Discussion: https://www.postgresql.org/message-id/[email protected]
Backpatch: 16-, where meson support was added
M meson.build
Fallback to clang in PATH with meson
commit : a32ffeebfa63dd3e6ee8f9498a7e59ebd8abba8d
author : Heikki Linnakangas <[email protected]>
date : Sat, 27 Jul 2024 13:53:11 +0300
committer: Heikki Linnakangas <[email protected]>
date : Sat, 27 Jul 2024 13:53:11 +0300
Some distributions put clang into a different path than the llvm
binary path.
For example, this is the case on NixOS / nixpkgs, which failed to find
clang with meson before this patch.
Author: Wolfgang Walther
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut
Reviewed-by: Tristan Partin
Discussion: https://www.postgresql.org/message-id/[email protected]
Backpatch: 16-, where meson support was added
M meson.build
Fallback to uuid for ossp-uuid with meson
commit : 469b97c52413adc85bab7d7ee6e0a9cb5adddf30
author : Heikki Linnakangas <[email protected]>
date : Sat, 27 Jul 2024 13:53:08 +0300
committer: Heikki Linnakangas <[email protected]>
date : Sat, 27 Jul 2024 13:53:08 +0300
The upstream name for the ossp-uuid package / pkg-config file is
"uuid". Many distributions change this to be "ossp-uuid" to not
conflict with e2fsprogs.
This lookup fails on distributions which don't change this name, for
example NixOS / nixpkgs. Both "ossp-uuid" and "uuid" are also checked
in configure.ac.
Author: Wolfgang Walther
Reviewed-by: Nazir Bilal Yavuz, Alvaro Herrera, Peter Eisentraut
Reviewed-by: Tristan Partin
Discussion: https://www.postgresql.org/message-id/[email protected]
Backpatch: 16-, where meson support was added
M meson.build
Fix more holes with SLRU code in need of int64 for segment numbers
commit : e367a413b09fece55ce4e08872ce79f328941ddd
author : Michael Paquier <[email protected]>
date : Sat, 27 Jul 2024 07:16:59 +0900
committer: Michael Paquier <[email protected]>
date : Sat, 27 Jul 2024 07:16:59 +0900
This is a continuation of 3937cadfd438, taking care of more areas I have
managed to miss previously.
Reported-by: Noah Misch
Reviewed-by: Noah Misch
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 17
M src/backend/access/transam/multixact.c
Wait for WAL summarization to catch up before creating .partial file.
commit : 53b327f83ea2c820b26a9b51f49f498221bc4379
author : Robert Haas <[email protected]>
date : Fri, 26 Jul 2024 14:50:21 -0400
committer: Robert Haas <[email protected]>
date : Fri, 26 Jul 2024 14:50:21 -0400
When a standby is promoted, CleanupAfterArchiveRecovery() may decide
to rename the final WAL file from the old timeline by adding ".partial"
to the name. If WAL summarization is enabled and this file is renamed
before its partial contents are summarized, WAL summarization breaks:
the summarizer gets stuck at that point in the WAL stream and just
errors out.
To fix that, first make the startup process wait for WAL summarization
to catch up before renaming the file. Generally, this should be quick,
and if it's not, the user can shut off summarize_wal and try again.
To make this fix work, also teach the WAL summarizer that after a
promotion has occurred, no more WAL can appear on the previous
timeline: previously, the WAL summarizer wouldn't switch to the new
timeline until we actually started writing WAL there, but that meant
that when the startup process was waiting for the WAL summarizer, it
was waiting for an action that the summarizer wasn't yet prepared to
take.
In the process of fixing these bugs, I realized that the logic to wait
for WAL summarization to catch up was spread out in a way that made
it difficult to reuse properly, so this code refactors things to make
it easier.
Finally, add a test case that would have caught this bug and the
previously-fixed bug that WAL summarization sometimes needs to back up
when the timeline changes.
Discussion: https://postgr.es/m/CA+TgmoZGEsZodXC4f=XZNkAeyuDmWTSkpkjCEOcF19Am0mt_OA@mail.gmail.com
M src/backend/access/transam/xlog.c
M src/backend/backup/basebackup_incremental.c
M src/backend/postmaster/walsummarizer.c
M src/bin/pg_combinebackup/meson.build
A src/bin/pg_combinebackup/t/008_promote.pl
M src/include/access/xlog.h
M src/include/postmaster/walsummarizer.h
Fix indentation.
commit : f2af1f4559ea74a6133ac36df3204c12e8d12ed3
author : Robert Haas <[email protected]>
date : Fri, 26 Jul 2024 11:58:52 -0400
committer: Robert Haas <[email protected]>
date : Fri, 26 Jul 2024 11:58:52 -0400
M src/backend/postmaster/walsummarizer.c
Fix macro placement in pg_config.h.in
commit : 1272cfb7277f723e01657d4090241f5750b8f932
author : Daniel Gustafsson <[email protected]>
date : Fri, 26 Jul 2024 16:25:56 +0200
committer: Daniel Gustafsson <[email protected]>
date : Fri, 26 Jul 2024 16:25:56 +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
Allow WAL summarization to back up when timeline changes.
commit : c7cfbc5157fec24704ea102f113d97193ffe5f7f
author : Robert Haas <[email protected]>
date : Fri, 26 Jul 2024 09:50:31 -0400
committer: Robert Haas <[email protected]>
date : Fri, 26 Jul 2024 09:50:31 -0400
The old code believed that it was not possible to switch timelines
without first replaying all of the WAL from the old timeline, but
that turns out to be false, as demonstrated by an example from Fujii
Masao. As a result, it assumed that summarization would always
continue from the LSN where summarization previously ended. But in
fact, when a timeline switch occurs without replaying all the WAL
from the previous timeline, we can need to back up to an earlier
LSN. Adjust accordingly.
Discussion: https://postgr.es/m/CA+TgmoZGEsZodXC4f=XZNkAeyuDmWTSkpkjCEOcF19Am0mt_OA@mail.gmail.com
M src/backend/postmaster/walsummarizer.c
pg_createsubscriber: Message style improvements
commit : c0c005070817352e217baa430b04161890d9af5a
author : Peter Eisentraut <[email protected]>
date : Fri, 26 Jul 2024 14:45:13 +0200
committer: Peter Eisentraut <[email protected]>
date : Fri, 26 Jul 2024 14:45:13 +0200
Refactor some messages, improve quoting.
M src/bin/pg_basebackup/pg_createsubscriber.c
Fix using injection points at backend startup in EXEC_BACKEND mode
commit : f19beba3e3acfd804d678af3f768bee069038486
author : Heikki Linnakangas <[email protected]>
date : Fri, 26 Jul 2024 14:55:04 +0300
committer: Heikki Linnakangas <[email protected]>
date : Fri, 26 Jul 2024 14:55:04 +0300
Commit 86db52a506 changed the locking of injection points to use only
atomic ops and spinlocks, to make it possible to define injection
points in processes that don't have a PGPROC entry (yet). However, it
didn't work in EXEC_BACKEND mode, because the pointer to shared memory
area was not initialized until the process "attaches" to all the
shared memory structs. To fix, pass the pointer to the child process
along with other global variables that need to be set up early.
Backpatch-through: 17
M src/backend/postmaster/launch_backend.c
M src/backend/utils/misc/injection_point.c
M src/include/utils/injection_point.h
Fix fallback behavior when server sends an ERROR early at startup
commit : f06a632a77ed27aab087d62bd76bc52be3a2ac6f
author : Heikki Linnakangas <[email protected]>
date : Fri, 26 Jul 2024 14:52:08 +0300
committer: Heikki Linnakangas <[email protected]>
date : Fri, 26 Jul 2024 14:52:08 +0300
With sslmode=prefer, the desired behavior is to completely fail the
connection attempt, *not* fall back to a plaintext connection, if the
server responds to the SSLRequest with an error ('E') response instead
of rejecting SSL with an 'N' response. This was broken in commit
05fd30c0e7.
Reported-by: Jacob Champion
Reviewed-by: Michael Paquier
Discussion: https://www.postgresql.org/message-id/CAOYmi%2Bnwvu21mJ4DYKUa98HdfM_KZJi7B1MhyXtnsyOO-PB6Ww%40mail.gmail.com
Backpatch-through: 17
M src/interfaces/libpq/fe-connect.c
Disable all TLS session tickets
commit : 3df7f44a8c7c456c0a0d4d02a1167e972dc24eaa
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.ac
M meson.build
M src/backend/libpq/be-secure-openssl.c
M src/include/pg_config.h.in
SQL/JSON: Remove useless code in ExecInitJsonExpr()
commit : 8a1a4087bd5fd09f42bcca2c91ff7eceaa2a0eab
author : Amit Langote <[email protected]>
date : Fri, 26 Jul 2024 16:37:59 +0900
committer: Amit Langote <[email protected]>
date : Fri, 26 Jul 2024 16:37:59 +0900
The code was for adding an unconditional JUMP to the next step,
which is unnecessary processing.
Reported-by: Jian He <[email protected]>
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
M src/backend/executor/execExpr.c
SQL/JSON: Respect OMIT QUOTES when RETURNING domains over jsonb
commit : 3c3ccd4ca80136939abf97a7c19b67486dfda3af
author : Amit Langote <[email protected]>
date : Fri, 26 Jul 2024 16:08:13 +0900
committer: Amit Langote <[email protected]>
date : Fri, 26 Jul 2024 16:08:13 +0900
populate_domain() didn't take into account the omit_quotes flag passed
down to json_populate_type() by ExecEvalJsonCoercion() and that led
to incorrect behavior when the RETURNING type is a domain over
jsonb. Fix that by passing the flag by adding a new function
parameter to populate_domain().
Reported-by: Jian He <[email protected]>
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_queryfuncs.sql
SQL/JSON: Improve error-handling of JsonBehavior expressions
commit : d1dc4ae5608d9c0e83d5b5d32de238a7ac3d9a1a
author : Amit Langote <[email protected]>
date : Fri, 26 Jul 2024 16:00:16 +0900
committer: Amit Langote <[email protected]>
date : Fri, 26 Jul 2024 16:00:16 +0900
Instead of returning a NULL when the JsonBehavior expression value
could not be coerced to the RETURNING type, throw the error message
informing the user that it is the JsonBehavior expression that caused
the error with the actual coercion error message shown in its DETAIL
line.
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
M src/backend/executor/execExprInterp.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out
SQL/JSON: Fix error-handling of some JsonBehavior expressions
commit : 79fa052e78804667739bee3f3e220f0ef6783b2c
author : Amit Langote <[email protected]>
date : Fri, 26 Jul 2024 15:59:27 +0900
committer: Amit Langote <[email protected]>
date : Fri, 26 Jul 2024 15:59:27 +0900
To ensure that the errors of executing a JsonBehavior expression that
is coerced in the parser are caught instead of being thrown directly,
pass ErrorSaveContext to ExecInitExprRec() when initializing it.
Also, add a EEOP_JSONEXPR_COERCION_FINISH step to handle the errors
that are caught that way.
Discussion: https://postgr.es/m/CACJufxEo4sUjKCYtda0_qt9tazqqKPmF1cqhW9KBOUeJFqQd2g@mail.gmail.com
Backpatch-through: 17
M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out
Doc: fix misleading syntax synopses for targetlists.
commit : facd89587141451107278601dd4d4a8c4ba5e8a8
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/merge.sgml
M doc/src/sgml/ref/select.sgml
M doc/src/sgml/ref/select_into.sgml
M doc/src/sgml/ref/update.sgml
Document restrictions regarding incremental backups and standbys.
commit : de8b098ce567526e4da7d6e51cfe0fb132123ad7
author : Robert Haas <[email protected]>
date : Thu, 25 Jul 2024 15:45:06 -0400
committer: Robert Haas <[email protected]>
date : Thu, 25 Jul 2024 15:45:06 -0400
If you try to take an incremental backup on a standby and there hasn't
been much system activity, it might fail. Document why this happens.
Also add a hint to the error message you get, to make it more likely
that users will understand what has gone wrong.
Laurenz Albe and Robert Haas
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/backup.sgml
M src/backend/backup/basebackup_incremental.c
pg_createsubscriber: Message improvements
commit : 6622da8d3c7153fce58a35448f37a8869681625c
author : Peter Eisentraut <[email protected]>
date : Thu, 25 Jul 2024 15:25:42 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 25 Jul 2024 15:25:42 +0200
Objects are typically "in" a database, not "on".
M src/bin/pg_basebackup/pg_createsubscriber.c
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl
Remove useless unconstify() call
commit : b5006abcdc18f19b6f2d5a2dfa99302666aa6d63
author : Peter Eisentraut <[email protected]>
date : Thu, 25 Jul 2024 11:38:05 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 25 Jul 2024 11:38:05 +0200
This should have been part of 67c0ef9752 but was apparently forgotten
there.
M src/bin/pg_dump/compress_gzip.c
ci: Pin MacPorts version to 2.9.3.
commit : 5f03da8518ce0df9da2079730b36957e159d3c1e
author : Thomas Munro <[email protected]>
date : Thu, 25 Jul 2024 14:46:01 +1200
committer: Thomas Munro <[email protected]>
date : Thu, 25 Jul 2024 14:46:01 +1200
Commit d01ce180 invented a new way to find the latest MacPorts version.
By bad luck, a new beta release has just been published, and it seems
to lack some packages we need. Go back to searching for this specific
version for now. We still search with a pattern so that we can find the
package for the running version of macOS, but for now we always look for
2.9.3. The code to do that had been anticipated already in a commented
out line, I just didn't expect to have to use it so soon...
Also include the whole MacPorts installation script in the cache key, so
that changes to the script cause a fresh installation. This should make
it a bit easier to reason about the effect of changes on cached state in
github accounts using CI, when we make adjustments.
Back-patch to 15, like d01ce180.
Discussion: https://postgr.es/m/CA%2BhUKGLqJdv6RcwyZ_0H7khxtLTNJyuK%2BvDFzv3uwYbn8hKH6A%40mail.gmail.com
M .cirrus.tasks.yml
M src/tools/ci/ci_macports_packages.sh
ci: Upgrade macOS version from 13 to 14.
commit : f8c1bb2bb90dc023224f414d67fd9d8bf30b455a
author : Thomas Munro <[email protected]>
date : Thu, 25 Jul 2024 11:26:48 +1200
committer: Thomas Munro <[email protected]>
date : Thu, 25 Jul 2024 11:26:48 +1200
1. Previously we were using ghcr.io/cirruslabs/macos-XXX-base:latest
images, but Cirrus has started ignoring that and using a particular
image, currently ghcr.io/cirruslabs/macos-runner:sonoma, for github
accounts using free CI resources (as opposed to dedicated runner
machines, as cfbot uses). Let's just ask for that image anyway, to stay
in sync.
2. Instead of hard-coding a MacPorts installation URL, deduce it from
the running macOS version and the available releases. This removes the
need to keep the ci_macports_packages.sh in sync with .cirrus.task.yml,
and to advance the MacPorts version from time to time.
3. Change the cache key we use to cache the whole macports installation
across builds to include the OS major version, to trigger a fresh
installation when appropriate.
Back-patch to 15 where CI began.
Reviewed-by: Andres Freund <[email protected]>
Discussion: https://postgr.es/m/CA%2BhUKGLqJdv6RcwyZ_0H7khxtLTNJyuK%2BvDFzv3uwYbn8hKH6A%40mail.gmail.com
M .cirrus.tasks.yml
M src/tools/ci/ci_macports_packages.sh
pg_upgrade: Retrieve subscription count more efficiently.
commit : 73de50e13e397da8e98ed59b0fe63a00051a7128
author : Nathan Bossart <[email protected]>
date : Wed, 24 Jul 2024 11:30:33 -0500
committer: Nathan Bossart <[email protected]>
date : Wed, 24 Jul 2024 11:30:33 -0500
Presently, pg_upgrade obtains the number of subscriptions in the
to-be-upgraded cluster by first querying pg_subscription in every
database for the number of subscriptions in only that database.
Then, in count_old_cluster_subscriptions(), it adds all the values
collected in the first step. This is expensive, especially when
there are many databases.
Fortunately, there is a better way to retrieve the subscription
count. Since pg_subscription is a shared catalog, we only need to
connect to a single database and query it once. This commit
modifies pg_upgrade to use that approach, which also allows us to
trim several lines of code. In passing, move the call to
get_db_subscription_count(), which has been renamed to
get_subscription_count(), from get_db_rel_and_slot_infos() to the
dedicated >= v17 section in check_and_dump_old_cluster().
We may be able to make similar improvements to
get_old_cluster_logical_slot_infos(), but that is left as a future
exercise.
Reviewed-by: Michael Paquier, Amit Kapila
Discussion: https://postgr.es/m/ZprQJv_TxccN3tkr%40nathan
Backpatch-through: 17
M src/bin/pg_upgrade/check.c
M src/bin/pg_upgrade/info.c
M src/bin/pg_upgrade/pg_upgrade.h
Fix a missing article in the documentation
commit : 0cc57dca298c86403b6d6bb647f99d542f9d3dca
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 : 2b22543a440d2fa72a1918950d6e67dc1e71b271
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
Doc: Fix the mistakes in the subscription's failover option.
commit : 20aaa634f72ad9617e34546fafbbda3a3832ee45
author : Amit Kapila <[email protected]>
date : Wed, 24 Jul 2024 15:30:58 +0530
committer: Amit Kapila <[email protected]>
date : Wed, 24 Jul 2024 15:30:58 +0530
The documentation incorrectly stated that users could not alter the
subscription's failover option when the two-phase commit is enabled.
The steps to confirm that the standby server is ready for failover were
incorrect.
Author: Shveta Malik, Hou Zhijie
Reviewed-by: Amit Kapila
Discussion: https://postgr.es/m/OS0PR01MB571657B72F8D75BD858DCCE394AD2@OS0PR01MB5716.jpnprd01.prod.outlook.com
Discussion: https://postgr.es/m/CAJpy0uBBk+OZXXqQ00Gai09XR+mDi2=9sMBYY0F+BedoFivaMA@mail.gmail.com
M doc/src/sgml/logical-replication.sgml
M doc/src/sgml/ref/alter_subscription.sgml
Detect integer overflow in array_set_slice().
commit : 657e54a05859d51e0afb6e44557b5e8622ecd1fe
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
Use more consistently int64 for page numbers in SLRU-related code
commit : 165ea79a60774a0e287bfc5dc07363194c6d58df
author : Michael Paquier <[email protected]>
date : Tue, 23 Jul 2024 17:59:20 +0900
committer: Michael Paquier <[email protected]>
date : Tue, 23 Jul 2024 17:59:20 +0900
clog.c, async.c and predicate.c included some SLRU page numbers still
handled as 4-byte integers, while int64 should be used for this purpose.
These holes have been introduced in 4ed8f0913bfd, that has introduced
the use of 8-byte integers for SLRU page numbers, still forgot about the
code paths updated by this commit.
Reported-by: Noah Misch
Author: Aleksander Alekseev, Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 17
M src/backend/access/transam/clog.c
M src/backend/commands/async.c
M src/backend/storage/lmgr/predicate.c
Improve comments in slru.{c,h} about segment name format
commit : 3b279d89cb5c86fa7ac6faaebb3ddadb2dbe0ca8
author : Michael Paquier <[email protected]>
date : Tue, 23 Jul 2024 16:55:09 +0900
committer: Michael Paquier <[email protected]>
date : Tue, 23 Jul 2024 16:55:09 +0900
slru.h described incorrectly how SLRU segment names are formatted
depending on the segment number and if long or short segment names are
used. This commit closes the gap with a better description, fitting
with the reality.
Reported-by: Noah Misch
Author: Aleksander Alekseev
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 17
M src/backend/access/transam/slru.c
M src/include/access/slru.h
Doc: improve description of plpgsql's FETCH and MOVE commands.
commit : db46016304dc1f9ea402eee6d392f704050467df
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
Revert "Test that vacuum removes tuples older than OldestXmin"
commit : 1a3e90948b50abef3a075c5b1d1c59a9d631a187
author : Melanie Plageman <[email protected]>
date : Mon, 22 Jul 2024 16:32:43 -0400
committer: Melanie Plageman <[email protected]>
date : Mon, 22 Jul 2024 16:32:43 -0400
This reverts commit 80c34692e8e674e3b2f150f248ef2002ae2ac3a7.
This test proved to be unstable on the buildfarm, timing out before the
standby could catch up on 32-bit machines where more rows were required
and failing to reliably trigger multiple index vacuum rounds on 64-bit
machines where fewer rows should be required.
Because the instability is only known to be present on versions of
Postgres with TIDStore used for dead TID storage by vacuum, this is only
being reverted on master and REL_17_STABLE.
As having this coverage may be valuable, there is a discussion on the
thread of possible ways to stabilize the test. If that happens, a fixed
test can be committed again.
Backpatch-through: 17
Reported-by: Tom Lane
Discussion: https://postgr.es/m/614152.1721580711%40sss.pgh.pa.us
M src/test/recovery/meson.build
D src/test/recovery/t/043_vacuum_horizon_floor.pl
Initialize wal_level in the initial checkpoint record.
commit : e7dabbcebd445b67a5413d48458b5cf5b4c7930a
author : Robert Haas <[email protected]>
date : Mon, 22 Jul 2024 15:32:43 -0400
committer: Robert Haas <[email protected]>
date : Mon, 22 Jul 2024 15:32:43 -0400
As per Coverity and Tom Lane, commit 402b586d0 (back-patched to v17
as 2b5819e2b) forgot to initialize this new structure member in this
code path.
M src/backend/access/transam/xlog.c
Add missing call to ConditionVariableCancelSleep().
commit : 6c8d2ea7a5fb7f85e5f64994affa33e79c19ddd3
author : Robert Haas <[email protected]>
date : Wed, 17 Jul 2024 14:53:00 -0400
committer: Robert Haas <[email protected]>
date : Wed, 17 Jul 2024 14:53:00 -0400
After calling ConditionVariableSleep() or ConditionVariableTimedSleep()
one or more times, code is supposed to call ConditionVariableCancelSleep()
to remove itself from the waitlist. This code neglected to do so.
As far as I know, that had no observable consequences, but let's make
the code correct.
Discussion: http://postgr.es/m/CA+TgmoYW8eR+KN6zhVH0sin7QH6AvENqw_bkN-bB4yLYKAnsew@mail.gmail.com
M src/backend/postmaster/walsummarizer.c
postgres_fdw: Split out the query_cancel test to its own file
commit : d329a515f490202635443a0a79e974a5019f65a4
author : Alvaro Herrera <[email protected]>
date : Mon, 22 Jul 2024 12:49:57 +0200
committer: Alvaro Herrera <[email protected]>
date : Mon, 22 Jul 2024 12:49:57 +0200
This allows us to skip it in Cygwin, where it's reportedly flaky because
of platform bugs or something.
Backpatch to 17, where the test was introduced by commit 2466d6654f85.
Reported-by: Alexander Lakhin <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M contrib/postgres_fdw/Makefile
M contrib/postgres_fdw/expected/postgres_fdw.out
A contrib/postgres_fdw/expected/query_cancel.out
A contrib/postgres_fdw/expected/query_cancel_1.out
M contrib/postgres_fdw/meson.build
M contrib/postgres_fdw/sql/postgres_fdw.sql
A contrib/postgres_fdw/sql/query_cancel.sql
meson: Add dependency lookups via names used by cmake
commit : 9ac6995d6b1f11eefbf69b61bc4378b814d46dec
author : Andres Freund <[email protected]>
date : Sat, 20 Jul 2024 13:51:08 -0700
committer: Andres Freund <[email protected]>
date : Sat, 20 Jul 2024 13:51:08 -0700
Particularly on windows it's useful to look up dependencies via cmake, instead
of pkg-config. Meson supports doing so. Unfortunately the dependency names
used by various projects often differs between their pkg-config and cmake
files.
This would look a lot neater if we could rely on meson >= 0.60.0...
Reviewed-by: Tristan Partin <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch: 16-, where meson support was added
M meson.build
meson: Add support for detecting ossp-uuid without pkg-config
commit : 1213875b3a994bcede9c302ac85745e709afdfab
author : Andres Freund <[email protected]>
date : Sat, 20 Jul 2024 13:51:08 -0700
committer: Andres Freund <[email protected]>
date : Sat, 20 Jul 2024 13:51:08 -0700
This is necessary as ossp-uuid on windows installs neither a pkg-config nor a
cmake dependency information. Nor is there another supported uuid
implementation available on windows.
Reported-by: Dave Page <[email protected]>
Reviewed-by: Tristan Partin <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch: 16-, where meson support was added
M meson.build
meson: Add support for detecting gss without pkg-config
commit : a850701c7ddfebc5c2bd528a9423739458212bc1
author : Andres Freund <[email protected]>
date : Sat, 20 Jul 2024 13:51:08 -0700
committer: Andres Freund <[email protected]>
date : Sat, 20 Jul 2024 13:51:08 -0700
This is required as MIT Kerberos does provide neither pkg-config nor cmake
dependency information on windows.
Reported-by: Dave Page <[email protected]>
Reviewed-by: Tristan Partin <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch: 16-, where meson support was added
M meson.build
meson: Add missing argument to gssapi.h check
commit : 5b707bb507bdc9b8bf120db1a0f7dad4cdb78e46
author : Andres Freund <[email protected]>
date : Sat, 20 Jul 2024 13:51:08 -0700
committer: Andres Freund <[email protected]>
date : Sat, 20 Jul 2024 13:51:08 -0700
These were missing since the initial introduction of the meson based build, in
e6927270cd18. As-is this is unlikely to cause an issue, but a future commit
will add support for detecting gssapi without use of dependency(), which could
fail due to this.
Discussion: https://postgr.es/m/[email protected]
Backpatch: 16-, where the meson based build was added
M meson.build
Correctly check updatability of columns targeted by INSERT...DEFAULT.
commit : 041a00c4803b982d8433d6e3161ca61e73050658
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 : 3764ee47f78c5a332ee6720bdf2e72c8fc9aac35
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
Test that vacuum removes tuples older than OldestXmin
commit : 80c34692e8e674e3b2f150f248ef2002ae2ac3a7
author : Melanie Plageman <[email protected]>
date : Fri, 19 Jul 2024 10:40:42 -0400
committer: Melanie Plageman <[email protected]>
date : Fri, 19 Jul 2024 10:40:42 -0400
If vacuum fails to prune a tuple killed before OldestXmin, it will
decide to freeze its xmax and later error out in pre-freeze checks.
Add a test reproducing this scenario to the recovery suite which creates
a table on a primary, updates the table to generate dead tuples for
vacuum, and then, during the vacuum, uses a replica to force
GlobalVisState->maybe_needed on the primary to move backwards and
precede the value of OldestXmin set at the beginning of vacuuming the
table.
This commit is separate from the fix in case there are test stability
issues.
Author: Melanie Plageman
Reviewed-by: Peter Geoghegan
Discussion: https://postgr.es/m/CAAKRu_apNU2MPBK96V%2BbXjTq0RiZ-%3DA4ZTaysakpx9jxbq1dbQ%40mail.gmail.com
M src/test/recovery/meson.build
A src/test/recovery/t/043_vacuum_horizon_floor.pl
Ensure vacuum removes all visibly dead tuples older than OldestXmin
commit : fd4f12df5e46793a651f2d0a272f88a6cf4b358c
author : Melanie Plageman <[email protected]>
date : Fri, 19 Jul 2024 10:40:39 -0400
committer: Melanie Plageman <[email protected]>
date : Fri, 19 Jul 2024 10:40:39 -0400
If vacuum fails to remove a tuple with xmax older than
VacuumCutoffs->OldestXmin and younger than GlobalVisState->maybe_needed,
it may attempt to freeze the tuple's xmax and then ERROR out in
pre-freeze checks with "cannot freeze committed xmax".
Fix this by having vacuum always remove tuples older than OldestXmin.
It is possible for GlobalVisState->maybe_needed to precede OldestXmin if
maybe_needed is forced to go backward while vacuum is running. This can
happen if a disconnected standby with a running transaction older than
VacuumCutoffs->OldestXmin reconnects to the primary after vacuum
initially calculates GlobalVisState and OldestXmin.
In back branches starting with 14, the first version using
GlobalVisState, failing to remove tuples older than OldestXmin during
pruning caused vacuum to infinitely loop in lazy_scan_prune(), as
investigated on this [1] thread. After 1ccc1e05ae removed the retry loop
in lazy_scan_prune() and stopped comparing tuples to OldestXmin, the
hang could no longer happen, but we could still attempt to freeze dead
tuples with xmax older than OldestXmin -- resulting in an ERROR.
Fix this by always removing dead tuples with xmax older than
VacuumCutoffs->OldestXmin. This is okay because the standby won't replay
the tuple removal until the tuple is removable. Thus, the worst that can
happen is a recovery conflict.
[1] https://postgr.es/m/20240415173913.4zyyrwaftujxthf2%40awork3.anarazel.de#1b216b7768b5bd577a3d3d51bd5aadee
Back-patch through 14
Author: Melanie Plageman
Reviewed-by: Peter Geoghegan, Robert Haas, Andres Freund, Heikki Linnakangas, and Noah Misch
Discussion: https://postgr.es/m/CAAKRu_bDD7oq9ZwB2OJqub5BovMG6UjEYsoK2LVttadjEqyRGg%40mail.gmail.com
M src/backend/access/heap/pruneheap.c
M src/backend/access/heap/vacuumlazy.c
Move resowner from common JitContext to LLVM specific
commit : b0a8a7ddd3fbfcdd910b3ee8c7fc5e83d421bfeb
author : Heikki Linnakangas <[email protected]>
date : Fri, 19 Jul 2024 10:27:06 +0300
committer: Heikki Linnakangas <[email protected]>
date : Fri, 19 Jul 2024 10:27:06 +0300
Only the LLVM specific code uses it since resource owners were made
extensible in commit b8bff07daa85c837a2747b4d35cd5a27e73fb7b2. This is
new in v17, so backpatch there to keep the branches from diverging
just yet.
Author: Andreas Karlsson <[email protected]>
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/backend/jit/llvm/llvmjit.c
M src/include/jit/jit.h
M src/include/jit/llvmjit.h
postgres_fdw: Avoid "cursor can only scan forward" error.
commit : 935fe79ea1fb76e32807ebc18f46bbbb9b1cf9b2
author : Etsuro Fujita <[email protected]>
date : Fri, 19 Jul 2024 13:15:01 +0900
committer: Etsuro Fujita <[email protected]>
date : Fri, 19 Jul 2024 13:15:01 +0900
Commit d844cd75a disallowed rewind in a non-scrollable cursor to resolve
anomalies arising from such a cursor operation. However, this failed to
take into account the assumption in postgres_fdw that when rescanning a
foreign relation, it can rewind the cursor created for scanning the
foreign relation without specifying the SCROLL option, regardless of its
scrollability, causing this error when it tried to do such a rewind in a
non-scrollable cursor. Fix by modifying postgres_fdw to instead
recreate the cursor, regardless of its scrollability, when rescanning
the foreign relation. (If we had a way to check its scrollability, we
could improve this by rewinding it if it is scrollable and recreating it
if not, but we do not have it, so this commit modifies it to recreate it
in any case.)
Per bug #17889 from Eric Cyr. Devrim Gunduz also reported this problem.
Back-patch to v15 where that commit enforced the prohibition.
Reviewed by Tom Lane.
Discussion: https://postgr.es/m/17889-e8c39a251d258dda%40postgresql.org
Discussion: https://postgr.es/m/b415ac3255f8352d1ea921cf3b7ba39e0587768a.camel%40gunduz.org
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql
Propagate query IDs of utility statements in functions
commit : 38e271d3c2e8c3bfa4d57fd81c3e47b40f1f5eb3
author : Michael Paquier <[email protected]>
date : Fri, 19 Jul 2024 10:21:21 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 19 Jul 2024 10:21:21 +0900
For utility statements defined within a function, the query tree is
copied to a PlannedStmt as utility commands do not require planning.
However, the query ID was missing from the information passed down.
This leads to plugins relying on the query ID like pg_stat_statements to
not be able to track utility statements within function calls. Tests
are added to check this behavior, depending on pg_stat_statements.track.
This is an old bug. Now, query IDs for utilities are compiled using
their parsed trees rather than the query string since v16
(3db72ebcbe20), leading to less bloat with utilities, so backpatch down
only to this version.
Author: Anthonin Bonnefoy
Discussion: https://postgr.es/m/CAO6_XqrGp-uwBqi3vBPLuRULKkddjC7R5QZCgsFren=8E+m2Sg@mail.gmail.com
Backpatch-through: 16
M contrib/pg_stat_statements/expected/level_tracking.out
M contrib/pg_stat_statements/sql/level_tracking.sql
M src/backend/executor/functions.c
Do not summarize WAL if generated with wal_level=minimal.
commit : 2b5819e2b4d6c69676c61ee799fd9590be2308ce
author : Robert Haas <[email protected]>
date : Thu, 18 Jul 2024 12:09:48 -0400
committer: Robert Haas <[email protected]>
date : Thu, 18 Jul 2024 12:09:48 -0400
To do this, we must include the wal_level in the first WAL record
covered by each summary file; so add wal_level to struct Checkpoint
and the payload of XLOG_CHECKPOINT_REDO and XLOG_END_OF_RECOVERY.
This, in turn, requires bumping XLOG_PAGE_MAGIC and, since the
Checkpoint is also stored in the control file, also
PG_CONTROL_VERSION. It's not great to do that so late in the release
cycle, but the alternative seems to ship v17 without robust
protections against this scenario, which could result in corrupted
incremental backups.
A side effect of this patch is that, when a server with
wal_level=replica is started with summarize_wal=on for the first time,
summarization will no longer begin with the oldest WAL that still
exists in pg_wal, but rather from the first checkpoint after that.
This change should be harmless, because a WAL summary for a partial
checkpoint cycle can never make an incremental backup possible when
it would otherwise not have been.
Report by Fujii Masao. Patch by me. Review and/or testing by Jakub
Wartak and Fujii Masao.
Discussion: http://postgr.es/m/[email protected]
M doc/src/sgml/config.sgml
M doc/src/sgml/func.sgml
M src/backend/access/rmgrdesc/xlogdesc.c
M src/backend/access/transam/xlog.c
M src/backend/postmaster/walsummarizer.c
M src/bin/pg_combinebackup/meson.build
A src/bin/pg_combinebackup/t/007_wal_level_minimal.pl
M src/include/access/xlog_internal.h
M src/include/catalog/pg_control.h
Doc: fix minor syntax error in example.
commit : 4cbd8c60223bd28aacb38f8c8921fc5b8a704fcd
author : Tom Lane <[email protected]>
date : Wed, 17 Jul 2024 15:17:52 -0400
committer: Tom Lane <[email protected]>
date : Wed, 17 Jul 2024 15:17:52 -0400
The CREATE TABLE option is GENERATED BY DEFAULT *AS* IDENTITY.
Per bug #18543 from Ondřej Navrátil. Seems to have crept in
in a37bb7c13, so back-patch to v17 where that was added.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ddl.sgml
Use PqMsg_* macros in more places.
commit : 925479b8d83c2fc819e05bf67335255c13d8e8de
author : Nathan Bossart <[email protected]>
date : Wed, 17 Jul 2024 10:51:00 -0500
committer: Nathan Bossart <[email protected]>
date : Wed, 17 Jul 2024 10:51:00 -0500
Commit f4b54e1ed9, which introduced macros for protocol characters,
missed updating a few places. It also did not introduce macros for
messages sent from parallel workers to their leader processes.
This commit adds a new section in protocol.h for those.
Author: Aleksander Alekseev
Discussion: https://postgr.es/m/CAJ7c6TNTd09AZq8tGaHS3LDyH_CCnpv0oOz2wN1dGe8zekxrdQ%40mail.gmail.com
Backpatch-through: 17
M src/backend/access/common/printtup.c
M src/backend/commands/explain.c
M src/backend/replication/walsender.c
M src/backend/tcop/postgres.c
M src/backend/utils/activity/backend_progress.c
M src/include/libpq/protocol.h
Avoid error in recovery test if history file is not yet present
commit : 5d797c896fcf0ef04e4fc3354bc94512e8886cb2
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
SQL/JSON: Rethink c2d93c3802b
commit : 2177306a64137f50158d0d1ce7c4196ff8f05350
author : Amit Langote <[email protected]>
date : Wed, 17 Jul 2024 17:10:57 +0900
committer: Amit Langote <[email protected]>
date : Wed, 17 Jul 2024 17:10:57 +0900
This essentially reverts c2d93c3802b except tests. The problem with
c2d93c3802b was that it only changed the casting behavior for types
with typmod, and had coding issues noted in the post-commit review.
This commit changes coerceJsonFuncExpr() to use assignment-level casts
instead of explicit casts to coerce the result of JSON constructor
functions to the specified or the default RETURNING type. Using
assignment-level casts fixes the problem that using explicit casts was
leading to the wrong typmod / length coercion behavior -- truncating
results longer than the specified length instead of erroring out --
which c2d93c3802b aimed to solve.
That restricts the set of allowed target types to string types, the
same set that's currently allowed.
Discussion: https://postgr.es/m/[email protected]
M src/backend/parser/parse_expr.c
When creating materialized views, use REFRESH to load data.
commit : b4da732fd64e936970f38c792f8b32c4bdf2bcd5
author : Jeff Davis <[email protected]>
date : Tue, 16 Jul 2024 15:41:22 -0700
committer: Jeff Davis <[email protected]>
date : Tue, 16 Jul 2024 15:41:22 -0700
Previously, CREATE MATERIALIZED VIEW ... WITH DATA populated the MV
the same way as CREATE TABLE ... AS.
Instead, reuse the REFRESH logic, which locks down security-restricted
operations and restricts the search_path. This reduces the chance that
a subsequent refresh will fail.
Reported-by: Noah Misch
Backpatch-through: 17
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/createas.c
M src/backend/commands/matview.c
M src/include/commands/matview.h
M src/test/regress/expected/namespace.out
SQL/JSON: Fix a paragraph in JSON_TABLE documentation
commit : b6ed3cf4b07bfff1f166a239b34a75d818458006
author : Amit Langote <[email protected]>
date : Tue, 16 Jul 2024 14:11:10 +0900
committer: Amit Langote <[email protected]>
date : Tue, 16 Jul 2024 14:11:10 +0900
Using <replaceable>text</replaceable> inside parantheses is not a
common or good style, so rephrase a sentence to avoid that style.
Also rephrase the text in that paragraph a bit while at it.
Reported-by: Marcos Pegoraro <[email protected]>
Author: Jian He <[email protected]>
Reviewed-by: Daniel Gustafsson <[email protected]>
Reviewed-by: Peter Eisentraut <[email protected]>
Discussion: https://postgr.es/m/CAB-JLwZqH3Yec6Kz-4-+pa0ZG9QJBsxjJZwYcMZYzEDR_fXnKw@mail.gmail.com
M doc/src/sgml/func.sgml
Fix bad indentation introduced in 43cd30bcd1c
commit : ff3cae4875d3391c591ac5d22693f27f056e62d2
author : Andres Freund <[email protected]>
date : Mon, 15 Jul 2024 15:17:37 -0700
committer: Andres Freund <[email protected]>
date : Mon, 15 Jul 2024 15:17:37 -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
Add missing RestrictSearchPath() calls.
commit : a15b0edb5dd9d2a3731f374b576485799c00431c
author : Jeff Davis <[email protected]>
date : Mon, 15 Jul 2024 12:08:00 -0700
committer: Jeff Davis <[email protected]>
date : Mon, 15 Jul 2024 12:08:00 -0700
Reported-by: Noah Misch
Backpatch-through: 17
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/indexcmds.c
ci: Upgrade to Debian Bookworm
commit : bd40ffd8afd28bea6768b8fd46d02b0ccab3c93a
author : Andres Freund <[email protected]>
date : Mon, 15 Jul 2024 09:26:01 -0700
committer: Andres Freund <[email protected]>
date : Mon, 15 Jul 2024 09:26:01 -0700
Bullseye is getting long in the tooth, upgrade to the current stable version.
Backpatch to all versions with CI support, we don't want to generate CI images
for multiple Debian versions.
Author: Nazir Bilal Yavuz <[email protected]>
Discussion: https://postgr.es/m/CAN55FZ0fY5EFHXLKCO_%3Dp4pwFmHRoVom_qSE_7B48gpchfAqzw%40mail.gmail.com
Backpatch: 15-, where CI was added
M .cirrus.tasks.yml
Fix type confusion in guc_var_compare()
commit : 9b047cc0b2c22b667d5452124a381b33d5a9ff4a
author : Andres Freund <[email protected]>
date : Mon, 15 Jul 2024 09:26:01 -0700
committer: Andres Freund <[email protected]>
date : Mon, 15 Jul 2024 09:26:01 -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
Doc: minor improvements for plpgsql "Transaction Management" section.
commit : 34f457e99a86845e7c1826686921f0daa6a02dfd
author : Tom Lane <[email protected]>
date : Mon, 15 Jul 2024 11:59:43 -0400
committer: Tom Lane <[email protected]>
date : Mon, 15 Jul 2024 11:59:43 -0400
Point out that savepoint commands cannot be issued in PL/pgSQL,
and suggest that exception blocks can usually be used instead.
Add a caveat to the discussion of cursor loops vs. transactions,
pointing out that any locks taken by the cursor query will be lost
at COMMIT. This is implicit in what's already said, but the existing
text leaves the distinct impression that the auto-hold behavior is
transparent, which it's not really.
Per a couple of recent complaints (one unsigned, and one in bug #18531
from Dzmitry Jachnik). Back-patch to v17, just so this makes it into
current docs in less than a year-and-a-half.
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/plpgsql.sgml
Use atomics to avoid locking in InjectionPointRun()
commit : b8bf76cbde39da45224a764e73002196cf011a51
author : Heikki Linnakangas <[email protected]>
date : Mon, 15 Jul 2024 10:21:16 +0300
committer: Heikki Linnakangas <[email protected]>
date : Mon, 15 Jul 2024 10:21:16 +0300
This allows using injection points without having a PGPROC, like early
at backend startup, or in the postmaster.
The injection points facility is new in v17, so backpatch there.
Reviewed-by: Michael Paquier <[email protected]>
Disussion: https://www.postgresql.org/message-id/[email protected]
M src/backend/utils/misc/injection_point.c
M src/tools/pgindent/typedefs.list
Fix unstable tests in partition_merge.sql and partition_split.sql.
commit : 6a700da46e6279a0df6a996fd19c5aabdf7a4b56
author : Fujii Masao <[email protected]>
date : Mon, 15 Jul 2024 14:09:30 +0900
committer: Fujii Masao <[email protected]>
date : Mon, 15 Jul 2024 14:09:30 +0900
The tests added by commit c086896625 were unstable due to
missing schema names when checking pg_tables and pg_indexes.
Backpatch to v17.
Reported by buildfarm.
M src/test/regress/expected/partition_merge.out
M src/test/regress/expected/partition_split.out
M src/test/regress/sql/partition_merge.sql
M src/test/regress/sql/partition_split.sql
Fix tablespace handling in MERGE/SPLIT partition commands.
commit : 929390e4d860b641f72aece70280e66114bffbd0
author : Fujii Masao <[email protected]>
date : Mon, 15 Jul 2024 13:11:51 +0900
committer: Fujii Masao <[email protected]>
date : Mon, 15 Jul 2024 13:11:51 +0900
As commit ca4103025d stated, new partitions without a specified tablespace
should inherit the parent relation's tablespace. However, previously,
ALTER TABLE MERGE PARTITIONS and ALTER TABLE SPLIT PARTITION commands
always created new partitions in the default tablespace, ignoring
the parent's tablespace. This commit ensures new partitions inherit
the parent's tablespace.
Backpatch to v17 where these commands were introduced.
Author: Fujii Masao
Reviewed-by: Masahiko Sawada
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/alter_table.sgml
M src/backend/commands/tablecmds.c
M src/test/regress/expected/partition_merge.out
M src/test/regress/expected/partition_split.out
M src/test/regress/sql/partition_merge.sql
M src/test/regress/sql/partition_split.sql
Avoid unhelpful internal error for incorrect recursive-WITH queries.
commit : cf588e10f664be37a0804e9a8662facd0e163800
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
Use correct collate.windows.win1252.out
commit : 5ea9f66616801d0b4be6ce49c74e45bb4f325359
author : Andrew Dunstan <[email protected]>
date : Sat, 13 Jul 2024 16:19:10 -0400
committer: Andrew Dunstan <[email protected]>
date : Sat, 13 Jul 2024 16:19:10 -0400
I inadvertently missed backporting this to Release 17 from commit 291c420747
per offlist reminder from Alexander Lakhin.
M src/test/regress/expected/collate.windows.win1252.out
Fix new assertion for MERGE view_name ... DO NOTHING.
commit : 0d3b35c367c21fcfe437b689919bf153f85e2e25
author : Noah Misch <[email protected]>
date : Sat, 13 Jul 2024 08:09:33 -0700
committer: Noah Misch <[email protected]>
date : Sat, 13 Jul 2024 08:09:33 -0700
Such queries don't expand automatically updatable views, and ModifyTable
uses the wholerow attribute unconditionally. The user-visible behavior
is fine, so change to more-specific assertions. Commit
d5f788b41dc2cbdde6e7694c70dda54d829a5ed5 added the wrong assertion.
Back-patch to v17, where commit 5f2e179bd31e5f5803005101eb12a8d7bf8db8f3
introduced MERGE view_name.
Reported by Alexander Lakhin.
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/nodeModifyTable.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql
Don't lose partitioned table reltuples=0 after relhassubclass=f.
commit : f5bb46fb2e65f951fe22c166756dab9743b33a8a
author : Noah Misch <[email protected]>
date : Sat, 13 Jul 2024 08:09:33 -0700
committer: Noah Misch <[email protected]>
date : Sat, 13 Jul 2024 08:09:33 -0700
ANALYZE sets relhassubclass=f when a partitioned table no longer has
partitions. An ANALYZE doing that proceeded to apply the inplace update
of pg_class.reltuples to the old pg_class tuple instead of the new
tuple, losing that reltuples=0 change if the ANALYZE committed.
Non-partitioning inheritance trees were unaffected. Back-patch to v14,
where commit 375aed36ad83f0e021e9bdd3a0034c0c992c66dc introduced
maintenance of partitioned table pg_class.reltuples.
Reported by Alexander Lakhin.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/analyze.c
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
Make sure to run pg_isready on correct port
commit : dd12eb33aff94dabee03d32a98d80dfa434805a6
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 : 3c1c82d4066e19a2841fb5f0529452de0d4d65b2
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 : 0340eefd9ba4a6bbaaac07a78c058ffff181fc11
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/expected/constraints.out
M src/test/regress/sql/constraints.sql
Fix ALTER TABLE DETACH for inconsistent indexes
commit : 30ca4e1ab1ffc1d7c4d5fe4afc800d946a585d96
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/constraints.out
M src/test/regress/sql/constraints.sql
Fix unstable test in 040_pg_createsubscriber.
commit : ae4e072bad5ff254a4fcfe876aae849acdaf8c3d
author : Amit Kapila <[email protected]>
date : Fri, 12 Jul 2024 09:35:46 +0530
committer: Amit Kapila <[email protected]>
date : Fri, 12 Jul 2024 09:35:46 +0530
The slot synchronization failed because the local slot's (created during
slot synchronization) catalog_xmin on standby is ahead of remote slot.
This happens because the INSERT before slot synchronization results in the
generation of a new xid that could be replicated to the standby. Now
before the xmin of the physical slot on the primary catches up via
hot_standby_feedback, the test has created a logical slot that got some
prior value of catalog_xmin.
To fix this we could try to ensure that the physical slot's catalog_xmin
is caught up to latest value before creating a logical slot but we took a
simpler path to move the INSERT after synchronizing the logical slot.
Reported-by: Alexander Lakhin as per buildfarm
Diagnosed-by: Amit Kapila, Hou Zhijie, Alexander Lakhin
Author: Hou Zhijie
Backpatch-through: 17
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl
Fix possibility of logical decoding partial transaction changes.
commit : 068674f4ab44f2c891b6841432687958e8e9c9a6
author : Masahiko Sawada <[email protected]>
date : Thu, 11 Jul 2024 22:48:21 +0900
committer: Masahiko Sawada <[email protected]>
date : Thu, 11 Jul 2024 22:48:21 +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
M contrib/test_decoding/meson.build
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/snapbuild.h
Make our back branches compatible with libxml2 2.13.x.
commit : a9747be272889833958ec6d93e3034baab569d2f
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
Use diff's --strip-trailing-cr flag where appropriate on Windows
commit : 4506d18a9891c70ce977047e2b4ffc05bef65165
author : Andrew Dunstan <[email protected]>
date : Wed, 10 Jul 2024 09:53:47 -0400
committer: Andrew Dunstan <[email protected]>
date : Wed, 10 Jul 2024 09:53:47 -0400
Test result files might be checked out using Unix or Windows style line
endings, depening on git flags, so on Windows we use the
--strip-trailing-cr flag to tell diff to ignore line endings
differences.
The flag is added to the diff invocation for the test_json_parser module
tests and the pg_bsd_indent tests. in pg_regress.c we replace the
current use of the "-w" flag, which ignore all white space differences,
with this one which only ignores line end differences.
Discussion: https://postgr.es/m/[email protected]
M src/test/modules/test_json_parser/t/003_test_semantic.pl
M src/test/regress/pg_regress.c
M src/tools/pg_bsd_indent/t/001_pg_bsd_indent.pl
doc: Update track_io_timing documentation to mention pg_stat_io.
commit : 0248762b2a8e5c825ab845797aa14647c74be166
author : Fujii Masao <[email protected]>
date : Wed, 10 Jul 2024 15:56:07 +0900
committer: Fujii Masao <[email protected]>
date : Wed, 10 Jul 2024 15:56:07 +0900
The I/O timing information collected when track_io_timing is
enabled is now documented to appear in the pg_stat_io view,
which was previously not mentioned.
This commit also enhances the description of track_io_timing
to clarify that it monitors not only block read and write
but also block extend and fsync operations. Additionally,
the description of track_wal_io_timing has been improved
to mention both WAL write and WAL fsync monitoring.
Backpatch to v16 where pg_stat_io was added.
Author: Hajime Matsunaga
Reviewed-by: Melanie Plageman, Nazir Bilal Yavuz, Fujii Masao
Discussion: https://postgr.es/m/TYWPR01MB10742EE4A6F34C33061429D38A4D52@TYWPR01MB10742.jpnprd01.prod.outlook.com
M doc/src/sgml/config.sgml
M doc/src/sgml/monitoring.sgml
Prevent CRLF conversion of inputs in json_parser test module
commit : e72f787ea6b287ed624c1f5be71eb13e405b1577
author : Andrew Dunstan <[email protected]>
date : Tue, 9 Jul 2024 17:29:48 -0400
committer: Andrew Dunstan <[email protected]>
date : Tue, 9 Jul 2024 17:29:48 -0400
Do this by opening the file in PG_BINARY_R mode. This prevents us from
getting wrong byte count from stat().
Per complaint from Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch to rlease 17 where this code was introduced
M src/test/modules/test_json_parser/test_json_parser_incremental.c
M src/test/modules/test_json_parser/test_json_parser_perf.c
Fix missing invalidations for search_path cache.
commit : d3e076549b99d1130053223adb9c1fa909d75dc0
author : Jeff Davis <[email protected]>
date : Tue, 9 Jul 2024 11:27:10 -0700
committer: Jeff Davis <[email protected]>
date : Tue, 9 Jul 2024 11:27:10 -0700
Reported-by: Noah Misch
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 17
M src/backend/catalog/namespace.c
SQL/JSON: Various improvements to SQL/JSON query function docs
commit : ce416fadb4b694ba32e228b8296d8f10f39640c0
author : Amit Langote <[email protected]>
date : Tue, 9 Jul 2024 16:12:22 +0900
committer: Amit Langote <[email protected]>
date : Tue, 9 Jul 2024 16:12:22 +0900
1. Remove the keyword SELECT from the examples to be consistent
with the examples of other JSON-related functions listed on the
same page.
2. Add <synopsis> tags around the functions' syntax definition
3. Capitalize function names in the syntax synopsis and the examples
4. Use <itemizedlist> lists for dividing the descriptions of
individual functions into bullet points
5. Significantly rewrite the description of wrapper clauses of
JSON_QUERY
6. Significantly rewrite the descriptions of ON ERROR / EMPTY
clauses of JSON_QUERY() and JSON_VALUE() functions
7. Add a note about how JSON_VALUE() and JSON_QUERY() differ when
returning a JSON null result
8. Move the description of the PASSING clause from the descriptions
of individual functions into the top paragraph
And other miscellaneous text improvements, typo fixes.
Suggested-by: Thom Brown <[email protected]>
Suggested-by: David G. Johnston <[email protected]>
Reviewed-by: Jian He <[email protected]>
Reviewed-by: Erik Rijkers <[email protected]>
Discussion: https://postgr.es/m/CAA-aLv7Dfy9BMrhUZ1skcg=OdqysWKzObS7XiDXdotJNF0E44Q@mail.gmail.com
Discussion: https://postgr.es/m/CAKFQuwZNxNHuPk44zDF7z8qZec1Aof10aA9tWvBU5CMhEKEd8A@mail.gmail.com
M doc/src/sgml/func.sgml
Fix limit block handling in pg_wal_summary_contents().
commit : ab4129091ccc15c3e899878e8bd6733577f83bba
author : Fujii Masao <[email protected]>
date : Tue, 9 Jul 2024 09:26:54 +0900
committer: Fujii Masao <[email protected]>
date : Tue, 9 Jul 2024 09:26:54 +0900
Previously, pg_wal_summary_contents() had two issues,
causing discrepancies between pg_wal_summary_contents()
and the pg_walsummary command on the same WAL summary file:
(1) It did not emit the limit block when that's the only data for
a particular relation fork.
(2) It emitted the same limit block multiple times if the list of
block numbers was long enough.
This commit fixes these issues.
Backpatch to v17 where pg_wal_summary_contents() was added.
Author: Fujii Masao
Reviewed-by: Robert Haas
Discussion: https://postgr.es/m/[email protected]
M src/backend/backup/walsummaryfuncs.c
Symlink pg_replslot robustly on Windows in pg_basebackup test
commit : d3e213ae1359f0bcfa9c446166d187811a7db8bc
author : Andrew Dunstan <[email protected]>
date : Mon, 8 Jul 2024 13:46:21 -0400
committer: Andrew Dunstan <[email protected]>
date : Mon, 8 Jul 2024 13:46:21 -0400
This reverts commit e9f15bc9. Instead of a hacky solution that didn't
work on Windows, we avoid trying to move the directory possibly across
drives, and instead remove it and recreate it in the new location.
Discussion: https://postgr.es/m/[email protected]
Backpatch to release 14 like the previous patch.
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
Choose ports for test servers less likely to result in conflicts
commit : e68cf81bfea4561518d6b890f75e7aad70b6fbb1
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/PostgreSQL/Test/Cluster.pm
Force nodes for SSL tests to start in TCP mode
commit : e4754f780f5e8917dbddc1c92036deb259143433
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/SSL/Server.pm
Fix scale clamping in numeric round() and trunc().
commit : 7a8977d2587f48c545acd9dab9c76ad24eb09eea
author : Dean Rasheed <[email protected]>
date : Mon, 8 Jul 2024 17:51:23 +0100
committer: Dean Rasheed <[email protected]>
date : Mon, 8 Jul 2024 17:51:23 +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
Typo fix
commit : d4f8517b0b9436fa3478851024870d8ee0b67801
author : Amit Langote <[email protected]>
date : Mon, 8 Jul 2024 22:11:57 +0900
committer: Amit Langote <[email protected]>
date : Mon, 8 Jul 2024 22:11:57 +0900
Reported-by: Junwang Zhao <[email protected]>
Discussion: https://postgr.es/m/CAEG8a3KPi=LayiTwJ11ikF7bcqnZUrcj8NgX0V8nO1mQKZ9GfQ@mail.gmail.com
Backpatch-through: 17
M src/common/jsonapi.c
Fix outdated comment after removal of direct SSL fallback
commit : 5afebbe529abc896d4a3c5a092427c28f6be21ab
author : Heikki Linnakangas <[email protected]>
date : Mon, 8 Jul 2024 12:44:45 +0300
committer: Heikki Linnakangas <[email protected]>
date : Mon, 8 Jul 2024 12:44:45 +0300
The option to fall back from direct SSL to negotiated SSL or a
plaintext connection was removed in commit fb5718f35f.
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/interfaces/libpq/fe-connect.c
Fix right-anti-joins when the inner relation is proven unique
commit : cccab85c2bea213ff03f47a9262d0d78275bd2af
author : Richard Guo <[email protected]>
date : Mon, 8 Jul 2024 10:17:12 +0900
committer: Richard Guo <[email protected]>
date : Mon, 8 Jul 2024 10:17:12 +0900
For an inner_unique join, we always assume that the executor will stop
scanning for matches after the first match. Therefore, for a mergejoin
that is inner_unique and whose mergeclauses are sufficient to identify a
match, we set the skip_mark_restore flag to true, indicating that the
executor need not do mark/restore calls. However, merge-right-anti-join
did not get this memo and continues scanning the inner side for matches
after the first match. If there are duplicates in the outer scan, we
may incorrectly skip matching some inner tuples, which can lead to wrong
results.
Here we fix this issue by ensuring that merge-right-anti-join also
advances to next outer tuple after the first match in inner_unique
cases. This also saves cycles by avoiding unnecessary scanning of inner
tuples after the first match.
Although hash-right-anti-join does not suffer from this wrong results
issue, we apply the same change to it as well, to help save cycles for
the same reason.
Per bug #18522 from Antti Lampinen, and bug #18526 from Feliphe Pozzer.
Back-patch to v16 where right-anti-join was introduced.
Author: Richard Guo
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/nodeHashjoin.c
M src/backend/executor/nodeMergejoin.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Re-enable autoruns for for cmd.exe on Windows
commit : fa1a63dffcd7113d990b3a50d7e697c7852dc9c5
author : Michael Paquier <[email protected]>
date : Mon, 8 Jul 2024 09:35:10 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 8 Jul 2024 09:35:10 +0900
This acts as a revert of b83747a8a65b and 9886744a361b. As pointed out
by Noah, HEAD and REL_17_STABLE are in a weird state where the code
paths adding /D would limit the spawn of child processes, but we still
have code paths where the spawn of more than one child process would be
possible.
Let's remove these /D switches for now, to bring back the code into a
state consistent with how autorun is configured on a Windows host.
Reported-by: Noah Misch
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 17
M src/bin/pg_ctl/pg_ctl.c
M src/test/regress/pg_regress.c
Fix incorrect sentinel byte logic in GenerationRealloc()
commit : 84a9d38006280f092b2b3f14841e4156c7a6e80d
author : David Rowley <[email protected]>
date : Sat, 6 Jul 2024 14:00:06 +1200
committer: David Rowley <[email protected]>
date : Sat, 6 Jul 2024 14:00:06 +1200
This only affects MEMORY_CONTEXT_CHECKING builds.
This fixes an off-by-one issue in GenerationRealloc() where the
fast-path code which tries to reuse the existing allocation if the
existing chunk is >= the new requested size. The code there thought it
was always ok to use the existing chunk, but when oldsize == size there
isn't enough space to store the sentinel byte. If both sizes matched
exactly set_sentinel() would overwrite the first byte beyond the chunk
and then subsequent GenerationRealloc() calls could then fail the
Assert(chunk->requested_size < oldsize) check which is trying to ensure
the chunk is large enough to store the sentinel.
The same issue does not exist in aset.c as the sentinel checking code
only adds a sentinel byte if there's enough space in the chunk.
Reported-by: Alexander Lakhin <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 16, where the problem was introduced by 0e480385e
M src/backend/utils/mmgr/generation.c
Cope with <regex.h> name clashes.
commit : 9c273679b36b2c7c9ae13889ec6a5a3892842a6b
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 PG 17 relnotes: fix psql connection cancelation item
commit : 8af6958957f4762a52314d12c2bba14fccb35a51
author : Bruce Momjian <[email protected]>
date : Fri, 5 Jul 2024 16:51:56 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 5 Jul 2024 16:51:56 -0400
Reported-by: Matthias van de Meent
Discussion: https://postgr.es/m/CAEze2WiprrENrFQqeXij2XyLAdoZaFTFLGC8sE=V8c1yrWn+2A@mail.gmail.com
Backpatch-through: 17 only
M doc/src/sgml/release-17.sgml
Doc: small improvements in discussion of geometric data types.
commit : 7f9c71519143b6aec71df068e022ddbe33bcc0d3
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
Fix copy/paste mistake in comment
commit : e72f841cbec12b60dbfcde6e4aaeec8ecab987c4
author : Alvaro Herrera <[email protected]>
date : Thu, 4 Jul 2024 13:57:47 +0200
committer: Alvaro Herrera <[email protected]>
date : Thu, 4 Jul 2024 13:57:47 +0200
Backpatch to 17
Author: Yugo NAGATA <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/interfaces/libpq/fe-cancel.c
Remove bogus assertion in pg_atomic_monotonic_advance_u64
commit : 3a9d0d774d90c41bd60a8fb85685092d3e0bc30f
author : Alvaro Herrera <[email protected]>
date : Thu, 4 Jul 2024 13:25:31 +0200
committer: Alvaro Herrera <[email protected]>
date : Thu, 4 Jul 2024 13:25:31 +0200
This code wanted to ensure that the 'exchange' variable passed to
pg_atomic_compare_exchange_u64 has correct alignment, but apparently
platforms don't actually require anything that doesn't come naturally.
While messing with pg_atomic_monotonic_advance_u64: instead of using
Max() to determine the value to return, just use
pg_atomic_compare_exchange_u64()'s return value to decide; also, use
pg_atomic_compare_exchange_u64 instead of the _impl version; also remove
the unnecessary underscore at the end of variable name "target".
Backpatch to 17, where this code was introduced by commit bf3ff7bf83bc.
Reported-by: Alexander Lakhin <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/include/port/atomics.h
M src/include/port/atomics/arch-ppc.h
M src/include/port/atomics/arch-x86.h
M src/include/port/atomics/generic-gcc.h
M src/include/port/atomics/generic-sunpro.h
doc: Specify when ssl_prefer_server_ciphers was added
commit : 1c9acb14ae0c16dacb9d2823b59589e8f523d1a6
author : Daniel Gustafsson <[email protected]>
date : Thu, 4 Jul 2024 12:10:12 +0200
committer: Daniel Gustafsson <[email protected]>
date : Thu, 4 Jul 2024 12:10:12 +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
SQL/JSON: Fix some obsolete comments.
commit : 290a6d800d90d36a4a1d45655c944695102fabd1
author : Amit Langote <[email protected]>
date : Fri, 28 Jun 2024 15:09:59 +0900
committer: Amit Langote <[email protected]>
date : Fri, 28 Jun 2024 15:09:59 +0900
JSON_OBJECT(), JSON_OBJETAGG(), JSON_ARRAY(), and JSON_ARRAYAGG()
added in 7081ac46ace are not transformed into direct calls to
user-defined functions as the comments claim. Fix by mentioning
instead that they are transformed into JsonConstructorExpr nodes,
which may call them, for example, for the *AGG() functions.
Reported-by: Alexander Lakhin <[email protected]>
Discussion: https://postgr.es/m/058c856a-e090-ac42-ff00-ffe394f52a87%40gmail.com
Backpatch-through: 16
M src/backend/parser/parse_expr.c
Fix typo in GetRunningTransactionData()
commit : 619f76cce11dc51458eb4ea81b0e48d15d0b2d07
author : Alexander Korotkov <[email protected]>
date : Thu, 4 Jul 2024 02:05:27 +0300
committer: Alexander Korotkov <[email protected]>
date : Thu, 4 Jul 2024 02:05:27 +0300
e85662df44 made GetRunningTransactionData() calculate the oldest running
transaction id within the current database. However, because of the typo,
the new code uses oldestRunningXid instead of oldestDatabaseRunningXid
in comparison before updating oldestDatabaseRunningXid. This commit fixes
that issue.
Reported-by: Noah Misch
Discussion: https://postgr.es/m/20240630231816.bf.nmisch%40google.com
Backpatch-through: 17
M src/backend/storage/ipc/procarray.c
Avoid 0-length memcpy to NULL with EXEC_BACKEND
commit : 95219c020c3c8c59079f264386141065865a810e
author : Heikki Linnakangas <[email protected]>
date : Wed, 3 Jul 2024 15:58:14 +0300
committer: Heikki Linnakangas <[email protected]>
date : Wed, 3 Jul 2024 15:58:14 +0300
memcpy(NULL, src, 0) is forbidden by POSIX, even though every
production version of libc allows it. Let's be tidy.
Per report from Thomas Munro, running UBSan with EXEC_BACKEND.
Backpatch to v17, where this code was added.
Discussion: https://www.postgresql.org/message-id/CA%2BhUKG%2Be-dV7YWBzfBZXsgovgRuX5VmvmOT%[email protected]
M src/backend/postmaster/launch_backend.c
Tighten check for --forkchild argument when spawning child process
commit : 1906b1e0ad96010f2ab07f96e36488e0dc058594
author : Heikki Linnakangas <[email protected]>
date : Wed, 3 Jul 2024 15:53:30 +0300
committer: Heikki Linnakangas <[email protected]>
date : Wed, 3 Jul 2024 15:53:30 +0300
Commit aafc05de1b removed all the other --fork* arguments. Altough
this is inconsequential, backpatch to v17 since this is new.
Author: Nathan Bossart
Discussion: https://www.postgresql.org/message-id/ZnCCEN0l3qWv-XpW@nathan
M src/backend/main/main.c
Fix the testcase introduced in commit 81d20fbf7a.
commit : 14387ab0650377a0a349a3d2d57b8cb9d0a067c5
author : Amit Kapila <[email protected]>
date : Wed, 3 Jul 2024 14:57:07 +0530
committer: Amit Kapila <[email protected]>
date : Wed, 3 Jul 2024 14:57:07 +0530
The failed test was syncing failover replication slot to standby to test
that we remove such slots after the standby is converted to subscriber by
pg_createsubscriber.
In one of the buildfarm members, the sync of the slot failed because the
LSN on the standby was before the syncslot's LSN. We need to wait for
standby to catch up before trying to sync the slot with
pg_sync_replication_slots().
The other buildfarm failed because autovacuum generated a xid which is
replicated to the standby at some random point making slots at primary
lag behind standby during slot sync.
Both these failures wouldn't have occurred if we had used built-in
slotsync worker as it would have waited for the standby to sync with
primary but for this test, it is sufficient to use
pg_sync_replication_slots().
Reported-by: Alexander Lakhin as per buildfarm
Author: Kuroda Hayato
Reviewed-by: Amit Kapila
Backpatch-through: 17
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/OSBPR01MB25528300C71FDD83EA1DCA12F5DD2@OSBPR01MB2552.jpnprd01.prod.outlook.com
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl
Drop pre-existing subscriptions from the converted subscriber.
commit : 622cb84d69be91931568bee180cae7c484a7f026
author : Amit Kapila <[email protected]>
date : Tue, 2 Jul 2024 11:20:06 +0530
committer: Amit Kapila <[email protected]>
date : Tue, 2 Jul 2024 11:20:06 +0530
We don't need the pre-existing subscriptions on the newly formed
subscriber by using pg_createsubscriber. The apply workers corresponding
to these subscriptions can connect to other publisher nodes and either get
some unwarranted data or can lead to ERRORs in connecting to such nodes.
Author: Kuroda Hayato
Reviewed-by: Amit Kapila, Shlok Kyal, Vignesh C
Backpatch-through: 17
Discussion: https://postgr.es/m/OSBPR01MB25526A30A1FBF863ACCDDA3AF5C92@OSBPR01MB2552.jpnprd01.prod.outlook.com
M src/bin/pg_basebackup/pg_createsubscriber.c
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl
Remove unused structure member in pg_createsubscriber.c.
commit : ca522e2a896cf65339fd24e1e80eb8dcf6ad6729
author : Amit Kapila <[email protected]>
date : Tue, 2 Jul 2024 10:15:11 +0530
committer: Amit Kapila <[email protected]>
date : Tue, 2 Jul 2024 10:15:11 +0530
Author: Kuroda Hayato
Backpatch-through: 17
Discussion: https://postgr.es/m/OSBPR01MB25526A30A1FBF863ACCDDA3AF5C92@OSBPR01MB2552.jpnprd01.prod.outlook.com
M src/bin/pg_basebackup/pg_createsubscriber.c
Update release notes to reflect recent commit 0f934b0739.
commit : 58c5f60eb8ced48eef05dcb16a6133d7d07c519f
author : Amit Kapila <[email protected]>
date : Tue, 2 Jul 2024 09:17:41 +0530
committer: Amit Kapila <[email protected]>
date : Tue, 2 Jul 2024 09:17:41 +0530
Author: Hou Zhijie
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/OS3PR01MB57187B959C1ECC78B0C7C91A94D32@OS3PR01MB5718.jpnprd01.prod.outlook.com
M doc/src/sgml/release-17.sgml
Preserve CurrentMemoryContext across notify and sinval interrupts.
commit : 31f8d620b287258a34a35c25868896a46deea14f
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
Fix copy-paste mistake in PQcancelCreate
commit : 6d2ac554911d874e4d0609f5b2c5f34a1226ee0c
author : Alvaro Herrera <[email protected]>
date : Mon, 1 Jul 2024 13:58:22 +0200
committer: Alvaro Herrera <[email protected]>
date : Mon, 1 Jul 2024 13:58:22 +0200
When an OOM occurred, this function was incorrectly setting a status of
CONNECTION_BAD on the passed in PGconn instead of on the newly created
PGcancelConn.
Mistake introduced with 61461a300c1c. Backpatch to 17.
Author: Jelte Fennema-Nio <[email protected]>
Reported-by: Noah Misch <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/interfaces/libpq/fe-cancel.c
Rename standby_slot_names to synchronized_standby_slots.
commit : 0f934b0739ad28e8e20d8ad22ca80538544ce28a
author : Amit Kapila <[email protected]>
date : Mon, 1 Jul 2024 11:02:04 +0530
committer: Amit Kapila <[email protected]>
date : Mon, 1 Jul 2024 11:02:04 +0530
The standby_slot_names GUC allows the specification of physical standby
slots that must be synchronized before the logical walsenders associated
with logical failover slots. However, for this purpose, the GUC name is
too generic.
Author: Hou Zhijie
Reviewed-by: Bertrand Drouvot, Masahiko Sawada
Backpatch-through: 17
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/config.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/logical-replication.sgml
M doc/src/sgml/logicaldecoding.sgml
M doc/src/sgml/release-17.sgml
M src/backend/replication/logical/slotsync.c
M src/backend/replication/slot.c
M src/backend/replication/walsender.c
M src/backend/utils/misc/guc_tables.c
M src/backend/utils/misc/postgresql.conf.sample
M src/include/replication/slot.h
M src/include/replication/walsender_private.h
M src/include/utils/guc_hooks.h
M src/test/recovery/t/040_standby_failover_slots_sync.pl
M src/tools/pgindent/typedefs.list
Further weaken new pg_createsubscriber test on Windows.
commit : 55c309fc5b08c39f9d27b2a2fa098fde69368b58
author : Tom Lane <[email protected]>
date : Sun, 30 Jun 2024 23:20:57 -0400
committer: Tom Lane <[email protected]>
date : Sun, 30 Jun 2024 23:20:57 -0400
Also omit backslashes (\) in the generated database names on Windows.
As before, perhaps we can revert this after updating affected
buildfarm animals.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl
Adapt REL_17_STABLE to its new status as a stable branch
commit : 10ee893d786a34e7e1b7c5ac49b529ef5f28af0d
author : Michael Paquier <[email protected]>
date : Mon, 1 Jul 2024 08:05:35 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 1 Jul 2024 08:05:35 +0900
Per the checklist in RELEASE_CHANGES for the creation of a new stable
branch, this commit does the following things:
- Arm gen_node_support.pl's nodetag ABI stability, based on the contents
of nodetags.h.
- Update URLs of top-level README and Makefile to point to the new
stable version.
In passing, this fixes an incorrect comment in release-17.sgml.
M Makefile
M README.md
M doc/src/sgml/release-17.sgml
M src/backend/nodes/gen_node_support.pl
Run pgperltidy
commit : 7dcc6f8e6d7a0eb0ce90802311278723843b4bbd
author : Michael Paquier <[email protected]>
date : Mon, 1 Jul 2024 07:35:01 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 1 Jul 2024 07:35:01 +0900
This is required before the creation of a new branch. pgindent is
clean, as well as is reformat-dat-files.
perltidy version is v20230309, as documented in pgindent's README.
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl
M src/bin/pg_combinebackup/t/003_timeline.pl
M src/bin/pg_combinebackup/t/004_manifest.pl
M src/bin/pg_combinebackup/t/005_integrity.pl
M src/bin/pg_combinebackup/t/006_db_file_copy.pl
M src/bin/pg_rewind/t/003_extrafiles.pl
M src/bin/pg_verifybackup/t/003_corruption.pl
M src/test/recovery/t/009_twophase.pl
Temporarily(?) weaken new pg_createsubscriber test on Windows.
commit : 54508209178bc73a497c460bd0ffd1645dceb1a2
author : Tom Lane <[email protected]>
date : Sun, 30 Jun 2024 17:33:06 -0400
committer: Tom Lane <[email protected]>
date : Sun, 30 Jun 2024 17:33:06 -0400
Don't include double-quotes (") in the generated database names
on Windows. Doing so tickles a bug in older versions of IPC::Run,
which fail to quote command line arguments correctly for that
platform. Possibly we can revert this after updating affected
buildfarm animals.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl
Add PG_TEST_PG_COMBINEBACKUP_MODE
commit : 35a7b288b975f8b13084307c4b610e3bed5ca046
author : Tomas Vondra <[email protected]>
date : Sun, 30 Jun 2024 19:26:12 +0200
committer: Tomas Vondra <[email protected]>
date : Sun, 30 Jun 2024 19:26:12 +0200
Introduces an environment variable PG_TEST_PG_COMBINEBACKUP_MODE, that
determines copy mode used by pg_combinebackup in TAP tests. Defaults to
"--copy" but may be set to "--clone" or "--copy-file-range" to use the
alternative stategies.
Reported-by: Peter Eisentraut
Discussion: https://postgr.es/m/48da4a1f-ccd9-4988-9622-24f37b1de2b4%40eisentraut.org
M src/bin/pg_combinebackup/t/002_compare_backups.pl
M src/bin/pg_combinebackup/t/003_timeline.pl
M src/bin/pg_combinebackup/t/004_manifest.pl
M src/bin/pg_combinebackup/t/005_integrity.pl
M src/bin/pg_combinebackup/t/006_db_file_copy.pl
M src/test/perl/PostgreSQL/Test/Cluster.pm
Add pg_combinebackup --copy option
commit : a9577bae6b5c88c6865597aacd33b93d1b17e497
author : Tomas Vondra <[email protected]>
date : Sun, 30 Jun 2024 19:20:02 +0200
committer: Tomas Vondra <[email protected]>
date : Sun, 30 Jun 2024 19:20:02 +0200
Introduces --copy as an alternative to --clone and --copy-file-range.
This option simply picks the default mode to copy files, as if none of
the options was specified. This makes pg_combinebackup options more
consistent with pg_upgrade, and it makes testing simpler.
Reported-by: Peter Eisentraut
Discussion: https://postgr.es/m/48da4a1f-ccd9-4988-9622-24f37b1de2b4%40eisentraut.org
M doc/src/sgml/ref/pg_combinebackup.sgml
M src/bin/pg_combinebackup/pg_combinebackup.c
Add headers needed by pg_combinebackup --clone
commit : e99e840b82756bc6858222d97453639cef929b53
author : Tomas Vondra <[email protected]>
date : Sun, 30 Jun 2024 19:02:00 +0200
committer: Tomas Vondra <[email protected]>
date : Sun, 30 Jun 2024 19:02:00 +0200
The code for file cloning existed, but was not reachable as it relied on
constants from missing headers. Due to that, on Linux --clone always
failed with
error: file cloning not supported on this platform
Fixed by including the missing headers to relevant places. Adding the
headers revealed a couple compile errors in copy_file_clone(), so fix
those too.
Reported-by: Peter Eisentraut
Discussion: https://postgr.es/m/48da4a1f-ccd9-4988-9622-24f37b1de2b4%40eisentraut.org
M src/bin/pg_combinebackup/copy_file.c
M src/bin/pg_combinebackup/pg_combinebackup.c
Make pg_createsubscriber warn if publisher has two-phase commit enabled.
commit : 917754557cc0002bb042341720a7ce18fe5b0a09
author : Tom Lane <[email protected]>
date : Sun, 30 Jun 2024 14:24:14 -0400
committer: Tom Lane <[email protected]>
date : Sun, 30 Jun 2024 14:24:14 -0400
pg_createsubscriber currently always sets up logical replication
with two-phase commit disabled. Improving that is not going to
happen for v17. In the meantime, document the deficiency, and
adjust pg_createsubscriber so that it will emit a warning if
the source installation has max_prepared_transactions > 0.
Hayato Kuroda (some mods by Amit Kapila and me), per complaint from
Noah Misch
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/pg_createsubscriber.sgml
M src/bin/pg_basebackup/pg_createsubscriber.c
Make pg_createsubscriber more wary about quoting connection parameters.
commit : b3f5ccebd79d9c7b73f4e04611cdf31fdf87420b
author : Tom Lane <[email protected]>
date : Sun, 30 Jun 2024 13:45:24 -0400
committer: Tom Lane <[email protected]>
date : Sun, 30 Jun 2024 13:45:24 -0400
The original coding here could fail with database names, user names,
etc that contain spaces or other special characters.
As partial test coverage, extend the 040_pg_createsubscriber.pl
test script so that it uses a generated database name containing
funny characters.
Hayato Kuroda (some mods by me), per complaint from Noah Misch
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_basebackup/pg_createsubscriber.c
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl
Fix .gitignore for new injection suite.
commit : db0c96cc18aec417101e37e59fcc53d4bf647915
author : Noah Misch <[email protected]>
date : Fri, 28 Jun 2024 11:17:50 -0700
committer: Noah Misch <[email protected]>
date : Fri, 28 Jun 2024 11:17:50 -0700
Commit c35f419d6efbdf1a050250d84b687e6705917711 missed this.
M src/test/modules/injection_points/.gitignore
Remove configuration-dependent output from new inplace-inval test.
commit : b99414de90520e9605dff9cb645a2a228876862f
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
pgindent, because I forgot to do that.
commit : b48f275f18d7da4f4863888ad047cbd699698880
author : Robert Haas <[email protected]>
date : Fri, 28 Jun 2024 10:45:51 -0400
committer: Robert Haas <[email protected]>
date : Fri, 28 Jun 2024 10:45:51 -0400
Commit 065583cf460f980a182498941ac52810f709a897 should have
included these changes.
M src/backend/postmaster/walsummarizer.c
SQL/JSON: Always coerce JsonExpr result at runtime
commit : 716bd12d22c53d1943d41309f2dd061ec601dd5e
author : Amit Langote <[email protected]>
date : Fri, 28 Jun 2024 21:58:13 +0900
committer: Amit Langote <[email protected]>
date : Fri, 28 Jun 2024 21:58:13 +0900
Instead of looking up casts at parse time for converting the result
of JsonPath* query functions to the specified or the default
RETURNING type, always perform the conversion at runtime using either
the target type's input function or the function
json_populate_type().
There are two motivations for this change:
1. json_populate_type() coerces to types with typmod such that any
string values that exceed length limit cause an error instead of
silent truncation, which is necessary to be standard-conforming.
2. It was possible to end up with a cast expression that doesn't
support soft handling of errors causing bugs in the of handling
ON ERROR clause.
JsonExpr.coercion_expr which would store the cast expression is no
longer necessary, so remove.
Bump catversion because stored rules change because of the above
removal.
Reported-by: Alvaro Herrera <[email protected]>
Reviewed-by: Jian He <[email protected]>
Discussion: Discussion: https://postgr.es/m/202405271326.5a5rprki64aw%40alvherre.pgsql
M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
M src/backend/jit/llvm/llvmjit_expr.c
M src/backend/nodes/nodeFuncs.c
M src/backend/parser/parse_expr.c
M src/backend/utils/adt/jsonfuncs.c
M src/include/catalog/catversion.h
M src/include/executor/execExpr.h
M src/include/nodes/execnodes.h
M src/include/nodes/primnodes.h
M src/include/utils/jsonfuncs.h
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_jsontable.sql
M src/test/regress/sql/sqljson_queryfuncs.sql
SQL/JSON: Fix coercion of constructor outputs to types with typmod
commit : c2d93c3802b205d135d1ae1d7ac167d74e08a274
author : Amit Langote <[email protected]>
date : Fri, 28 Jun 2024 21:37:14 +0900
committer: Amit Langote <[email protected]>
date : Fri, 28 Jun 2024 21:37:14 +0900
Ensure SQL/JSON constructor functions that allow specifying the
target type using the RETURNING clause perform implicit cast to
that type. This ensures that output values that exceed the specified
length produce an error rather than being silently truncated. This
behavior conforms to the SQL standard.
Reported-by: Alvaro Herrera <[email protected]>
Reviewed-by: Jian He <[email protected]>
Discussion: https://postgr.es/m/202405271326.5a5rprki64aw%40alvherre.pgsql
M src/backend/parser/parse_expr.c
M src/test/regress/expected/sqljson.out
M src/test/regress/sql/sqljson.sql
Prevent summarizer hang when summarize_wal turned off and back on.
commit : 065583cf460f980a182498941ac52810f709a897
author : Robert Haas <[email protected]>
date : Tue, 25 Jun 2024 15:42:36 -0400
committer: Robert Haas <[email protected]>
date : Tue, 25 Jun 2024 15:42:36 -0400
Before this commit, when the WAL summarizer started up or recovered
from an error, it would resume summarization from wherever it left
off. That was OK normally, but wrong if summarize_wal=off had been
turned off temporary, allowing some WAL to be removed, and then turned
back on again. In such cases, the WAL summarizer would simply hang
forever. This commit changes the reinitialization sequence for WAL
summarizer to rederive the starting position in the way we were
already doing at initial startup, fixing the problem.
Per report from Israel Barth Rubio. Reviewed by Tom Lane.
Discussion: http://postgr.es/m/CA+TgmoYN6x=YS+FoFOS6=nr6=qkXZFWhdiL7k0oatGwug2hcuA@mail.gmail.com
M src/backend/access/transam/xlog.c
M src/backend/postmaster/walsummarizer.c
M src/include/postmaster/walsummarizer.h
SQL/JSON: Validate values in ON ERROR/EMPTY clauses
commit : 55e56c84da99fe7becda2194563f48bb3083c2d1
author : Amit Langote <[email protected]>
date : Fri, 28 Jun 2024 13:59:57 +0900
committer: Amit Langote <[email protected]>
date : Fri, 28 Jun 2024 13:59:57 +0900
Currently, the grammar allows any supported values in the ON ERROR
and ON EMPTY clauses for SQL/JSON functions, regardless of whether
the values are appropriate for the function. This commit ensures
that during parse analysis, the provided value is checked for
validity for the given function and throws a syntax error if it is
not.
While at it, this fixes some omissions in the documentation of the
ON ERROR/EMPTY clauses for JSON_TABLE().
Reported-by: Jian He <[email protected]>
Reviewed-by: Jian He <[email protected]>
Discussion: https://postgr.es/m/CACJufxFgWGqpESSYzyJ6tSurr3vFYBSNEmCfkGyB_dMdptFnZQ%40mail.gmail.com
M doc/src/sgml/func.sgml
M src/backend/parser/parse_expr.c
M src/backend/parser/parse_jsontable.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_jsontable.sql
M src/test/regress/sql/sqljson_queryfuncs.sql
SQL/JSON: Prevent ON EMPTY for EXISTS columns in JSON_TABLE()
commit : e3c1393efc31ac70de7b68e9a283ec3f2d7f9bd2
author : Amit Langote <[email protected]>
date : Fri, 28 Jun 2024 13:59:13 +0900
committer: Amit Langote <[email protected]>
date : Fri, 28 Jun 2024 13:59:13 +0900
Due to an oversight in de3600452b61, the ON EMPTY clause was
incorrectly allowed in the EXISTS column. Fix the grammar to prevent
this.
Discussion: https://postgr.es/m/CA%2BHiwqHh3YDXTpccgAo4CdfV9Mhy%2Bmg%3Doh6t8rfM5uLW1BJN4g%40mail.gmail.com
M src/backend/parser/gram.y
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/sql/sqljson_jsontable.sql
Update modules/injection_points/.gitignore
commit : 0ad8153c1f4c7129ff19e8a41d142001d35c8514
author : Michael Paquier <[email protected]>
date : Fri, 28 Jun 2024 13:41:39 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 28 Jun 2024 13:41:39 +0900
Thinko in c35f419d6efb, where an isolation test has been added to the
module.
M src/test/modules/injection_points/.gitignore
Fix comments in heaptuple.c
commit : 526b54ece3f6b0bc474c0498d94780a38a6648a2
author : Michael Paquier <[email protected]>
date : Fri, 28 Jun 2024 13:30:47 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 28 Jun 2024 13:30:47 +0900
Since e27f4ee0a701, fastgetattr() and heap_getattr() are not macros, but
inlined functions.
Author: Junwang Zhao
Reviewed-by: Stepan Neretin
Discussion: https://postgr.es/m/CAEG8a3JS-JKWWyOcM7BU=vPqFXa3W7mZSHnvc3CBqx=tC+3SCA@mail.gmail.com
M src/backend/access/common/heaptuple.c
Improve locking around InjectionPointRun()
commit : d85fc4be11b38afd6d3abb586a6799299ed29470
author : Michael Paquier <[email protected]>
date : Fri, 28 Jun 2024 12:31:29 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 28 Jun 2024 12:31:29 +0900
As coded, an injection point could be loaded into the local cache
without the LWLock InjectionPointLock taken, hence a point detached and
re-attached concurrently of a point running calling InjectionPointRun()
may finish by loading a callback it did no set initially. Based on all
the cases discussed until now on the lists, it is fine to delay the lock
release until the callback is run, so let's do that.
While on it, remove a useless LWLockRelease() called before an error in
InjectionPointAttach().
Per discussion with Heikki Linnakangas and Noah Misch.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/misc/injection_point.c
Remove comment about xl_heap_inplace "AT END OF STRUCT".
commit : 4a7f91b3d3141e8898211a5b145b3c210b05c288
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 : f9f47f0d93d1a493a3365625f96026c7b18d7cf5
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 : 5b823b179e5e8ab32f140658698ca08f8c83f06e
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 : 0cecc908e9749101b5e93ba58d76a62c9f226f9e
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
Lock owned sequences during ALTER TABLE SET { LOGGED | UNLOGGED }.
commit : f88cdb36c457f673a1966a22883ce47e565a37db
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
These commands already make the persistence of owned sequences follow
owned table persistence changes. They didn't lock those sequences.
They lost the effect of nextval() calls that other sessions make after
the ALTER TABLE command, before the ALTER TABLE transaction commits.
Fix by acquiring the same lock that ALTER SEQUENCE SET { LOGGED |
UNLOGGED } acquires. This might cause more deadlocks. Back-patch to
v15, where commit 344d62fb9a978a72cf8347f0369b9ee643fd0b31 introduced
unlogged sequences.
Reviewed (in an earlier version) by Robert Haas.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/sequence.c
Expand comments and add an assertion in nodeModifyTable.c.
commit : d5f788b41dc2cbdde6e7694c70dda54d829a5ed5
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
Add an injection_points isolation test suite.
commit : c35f419d6efbdf1a050250d84b687e6705917711
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
Make the isolation harness recognize injection_points wait events as a
type of blocked state. Test an extant inplace-update bug.
Reviewed by Robert Haas and Michael Paquier.
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/heap/heapam.c
M src/backend/utils/adt/waitfuncs.c
M src/test/modules/injection_points/Makefile
A src/test/modules/injection_points/expected/inplace.out
M src/test/modules/injection_points/meson.build
A src/test/modules/injection_points/specs/inplace.spec
Create waitfuncs.c for pg_isolation_test_session_is_blocked().
commit : abfbd13af0e971e8789bc89e7c83ad53a85fa74b
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
The next commit makes the function inspect an additional non-lock
contention source, so it no longer fits in lockfuncs.c.
Reviewed by Robert Haas.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/Makefile
M src/backend/utils/adt/lockfuncs.c
M src/backend/utils/adt/meson.build
A src/backend/utils/adt/waitfuncs.c
Add wait event type "InjectionPoint", a custom type like "Extension".
commit : bb93640a681c2cc709e9836e169c8f3eb556df57
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
Both injection points and customization of type "Extension" are new in
v17, so this just changes a detail of an unreleased feature.
Reported by Robert Haas. Reviewed by Michael Paquier.
Discussion: https://postgr.es/m/CA+TgmobfMU5pdXP36D5iAwxV5WKE_vuDLtp_1QyH+H5jMMt21g@mail.gmail.com
M doc/src/sgml/monitoring.sgml
M doc/src/sgml/xfunc.sgml
M src/backend/storage/ipc/ipci.c
M src/backend/utils/activity/generate-wait_event_types.pl
M src/backend/utils/activity/wait_event.c
M src/backend/utils/activity/wait_event_funcs.c
M src/backend/utils/activity/wait_event_names.txt
M src/include/storage/lwlocklist.h
M src/include/utils/wait_event.h
M src/test/modules/injection_points/injection_points.c
M src/test/regress/expected/sysviews.out
M src/test/regress/sql/sysviews.sql
M src/tools/pgindent/typedefs.list
Improve test coverage for changes to inplace-updated catalogs.
commit : 0844b3968985447ed0a6937cfc8639e379da2fe6
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
M src/test/recovery/t/027_stream_regress.pl
A src/test/regress/expected/database.out
M src/test/regress/expected/merge.out
M src/test/regress/parallel_schedule
A src/test/regress/sql/database.sql
M src/test/regress/sql/merge.sql
Make TAP todo_start effects the same under Meson and prove_check.
commit : 22a4b104ba70f6f486197ab28a28cd9bcdd4f4ad
author : Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:04 -0700
committer: Noah Misch <[email protected]>
date : Thu, 27 Jun 2024 19:21:04 -0700
This could have caused spurious failures only on SPARC Linux, because
today's only todo_start tests for that platform. Back-patch to v16,
where Meson support first appeared.
Reviewed by Robert Haas.
Discussion: https://postgr.es/m/[email protected]
M src/tools/testwrap
SQL/JSON: Document behavior when input document is not jsonb
commit : 473a352fb393519f22cd4d31839ad3d74b1aeea1
author : Amit Langote <[email protected]>
date : Fri, 28 Jun 2024 09:42:13 +0900
committer: Amit Langote <[email protected]>
date : Fri, 28 Jun 2024 09:42:13 +0900
The input document to functions JSON_EXISTS(), JSON_QUERY(),
JSON_VALUE(), and JSON_TABLE() can be specified as character or
UTF8-encoded bytea strings. These are automatically converted to
jsonb with an implicit cast before being passed to the jsonpath
machinery.
In the current implementation, errors that occur when parsing the
specified string into a valid JSON document are thrown
unconditionally. This means they are not subject to the explicit or
implicit ON ERROR clause of those functions, which is a standard-
conforming behavior. Add a note to the documentation to mention
that.
Reported-by: Markus Winand
Discussion: https://postgr.es/m/F7DD1442-265C-4220-A603-CB0DEB77E91D%40winand.at
M doc/src/sgml/func.sgml
Avoid crashing when a JIT-inlined backend function throws an error.
commit : 5d6c64d290978dab76c00460ba809156874be035
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 : cbfbda78413a5b2f4807e029407dcc98a0e63162
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 : ecbf6ac51df27275fb0db493bf163ef98ac00c6a
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
Fix thinkos in comments
commit : a2dff271ebe2a0547d46e90dcb02c088cf2f031c
author : Alvaro Herrera <[email protected]>
date : Thu, 27 Jun 2024 19:51:47 +0200
committer: Alvaro Herrera <[email protected]>
date : Thu, 27 Jun 2024 19:51:47 +0200
The first one was noticed by Tender Wang and introduced with
8aba9322511f; the other one was newly introduced with dbca3469ebf8.
M src/backend/executor/execPartition.c
Drop the temporary tuple slots allocated by pgoutput.
commit : 3e53492aa7084bceaa92757c90e067d79768797e
author : Amit Kapila <[email protected]>
date : Thu, 27 Jun 2024 11:35:00 +0530
committer: Amit Kapila <[email protected]>
date : Thu, 27 Jun 2024 11:35:00 +0530
In pgoutput, when converting the child table's tuple format to match the
parent table's, we temporarily create a new slot to store the converted
tuple. However, we missed to drop such temporary slots, leading to
resource leakage.
Reported-by: Bowen Shi
Author: Hou Zhijie
Reviewed-by: Amit Kapila
Backpatch-through: 15
Discussion: https://postgr.es/m/CAM_vCudv8dc3sjWiPkXx5F2b27UV7_YRKRbtSCcE-pv=cVACGA@mail.gmail.com
M src/backend/replication/pgoutput/pgoutput.c
Fix overflow with pgstats DSA reference count
commit : 7467939ea226ebc5608285486501b136b642c02b
author : Michael Paquier <[email protected]>
date : Thu, 27 Jun 2024 09:44:47 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 27 Jun 2024 09:44:47 +0900
When pgstats is initialized for a backend, it uses dsa_attach_in_place()
without a "segment" provided. Hence, no callback is registered to
automatically release the DSA attached once a backend exits. Not doing
any cleanup causes the reference count of the pgstats DSA to
continuously increment, at some point overflowing it (the more the
number of connections, the faster it is to reach this state). Once the
reference count overflows and then gets back to 0, new backends are not
able to attach to the pgstats DSA, failing startup.
This issue is resolved by adding in the pgstats shutdown hook a call to
dsa_release_in_place(), ensuring that the DSA attached at backend
startup is correctly released, keeping the reference count at bay.
The author of this patch has been able to see this issue on a server
with a long uptime and a high connection turnover.
Issue introduced by 5891c7a8ed8f, so backpatch down to 15.
Author: Anthonin Bonnefoy
Discussion: https://postgr.es/m/CAO6_XqqJbJBL=M7Ym13TcB4Xnq58vRa2jcC+gwEPBgbAda6B1Q@mail.gmail.com
Backpatch-through: 15
M src/backend/utils/activity/pgstat_shmem.c
Fix bugs in MultiXact truncation
commit : b1ffe3ff0b7ed87b34ae0fc6eba71bf032e41b59
author : Heikki Linnakangas <[email protected]>
date : Fri, 21 Jun 2024 18:31:15 +0300
committer: Heikki Linnakangas <[email protected]>
date : Fri, 21 Jun 2024 18:31:15 +0300
1. TruncateMultiXact() performs the SLRU truncations in a critical
section. Deleting the SLRU segments calls ForwardSyncRequest(), which
will try to compact the request queue if it's full
(CompactCheckpointerRequestQueue()). That in turn allocates memory,
which is not allowed in a critical section. Backtrace:
TRAP: failed Assert("CritSectionCount == 0 || (context)->allowInCritSection"), File: "../src/backend/utils/mmgr/mcxt.c", Line: 1353, PID: 920981
postgres: autovacuum worker template0(ExceptionalCondition+0x6e)[0x560a501e866e]
postgres: autovacuum worker template0(+0x5dce3d)[0x560a50217e3d]
postgres: autovacuum worker template0(ForwardSyncRequest+0x8e)[0x560a4ffec95e]
postgres: autovacuum worker template0(RegisterSyncRequest+0x2b)[0x560a50091eeb]
postgres: autovacuum worker template0(+0x187b0a)[0x560a4fdc2b0a]
postgres: autovacuum worker template0(SlruDeleteSegment+0x101)[0x560a4fdc2ab1]
postgres: autovacuum worker template0(TruncateMultiXact+0x2fb)[0x560a4fdbde1b]
postgres: autovacuum worker template0(vac_update_datfrozenxid+0x4b3)[0x560a4febd2f3]
postgres: autovacuum worker template0(+0x3adf66)[0x560a4ffe8f66]
postgres: autovacuum worker template0(AutoVacWorkerMain+0x3ed)[0x560a4ffe7c2d]
postgres: autovacuum worker template0(+0x3b1ead)[0x560a4ffecead]
postgres: autovacuum worker template0(+0x3b620e)[0x560a4fff120e]
postgres: autovacuum worker template0(+0x3b3fbb)[0x560a4ffeefbb]
postgres: autovacuum worker template0(+0x2f724e)[0x560a4ff3224e]
/lib/x86_64-linux-gnu/libc.so.6(+0x27c8a)[0x7f62cc642c8a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85)[0x7f62cc642d45]
postgres: autovacuum worker template0(_start+0x21)[0x560a4fd16f31]
To fix, bail out in CompactCheckpointerRequestQueue() without doing
anything, if it's called in a critical section. That covers the above
call path, as well as any other similar cases where
RegisterSyncRequest might be called in a critical section.
2. After fixing that, another problem became apparent: Autovacuum
process doing that truncation can deadlock with the checkpointer
process. TruncateMultiXact() sets "MyProc->delayChkptFlags |=
DELAY_CHKPT_START". If the sync request queue is full and cannot be
compacted, the process will repeatedly sleep and retry, until there is
room in the queue. However, if the checkpointer is trying to start a
checkpoint at the same time, and is waiting for the DELAY_CHKPT_START
processes to finish, the queue will never shrink.
More concretely, the autovacuum process is stuck here:
#0 0x00007fc934926dc3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x000056220b24348b in WaitEventSetWaitBlock (set=0x56220c2e4b50, occurred_events=0x7ffe7856d040, nevents=1, cur_timeout=<optimized out>) at ../src/backend/storage/ipc/latch.c:1570
#2 WaitEventSetWait (set=0x56220c2e4b50, timeout=timeout@entry=10, occurred_events=<optimized out>, occurred_events@entry=0x7ffe7856d040, nevents=nevents@entry=1,
wait_event_info=wait_event_info@entry=150994949) at ../src/backend/storage/ipc/latch.c:1516
#3 0x000056220b243224 in WaitLatch (latch=<optimized out>, latch@entry=0x0, wakeEvents=wakeEvents@entry=40, timeout=timeout@entry=10, wait_event_info=wait_event_info@entry=150994949)
at ../src/backend/storage/ipc/latch.c:538
#4 0x000056220b26cf46 in RegisterSyncRequest (ftag=ftag@entry=0x7ffe7856d0a0, type=type@entry=SYNC_FORGET_REQUEST, retryOnError=true) at ../src/backend/storage/sync/sync.c:614
#5 0x000056220af9db0a in SlruInternalDeleteSegment (ctl=ctl@entry=0x56220b7beb60 <MultiXactMemberCtlData>, segno=segno@entry=11350) at ../src/backend/access/transam/slru.c:1495
#6 0x000056220af9dab1 in SlruDeleteSegment (ctl=ctl@entry=0x56220b7beb60 <MultiXactMemberCtlData>, segno=segno@entry=11350) at ../src/backend/access/transam/slru.c:1566
#7 0x000056220af98e1b in PerformMembersTruncation (oldestOffset=<optimized out>, newOldestOffset=<optimized out>) at ../src/backend/access/transam/multixact.c:3006
#8 TruncateMultiXact (newOldestMulti=newOldestMulti@entry=3221225472, newOldestMultiDB=newOldestMultiDB@entry=4) at ../src/backend/access/transam/multixact.c:3201
#9 0x000056220b098303 in vac_truncate_clog (frozenXID=749, minMulti=<optimized out>, lastSaneFrozenXid=749, lastSaneMinMulti=3221225472) at ../src/backend/commands/vacuum.c:1917
#10 vac_update_datfrozenxid () at ../src/backend/commands/vacuum.c:1760
#11 0x000056220b1c3f76 in do_autovacuum () at ../src/backend/postmaster/autovacuum.c:2550
#12 0x000056220b1c2c3d in AutoVacWorkerMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at ../src/backend/postmaster/autovacuum.c:1569
and the checkpointer is stuck here:
#0 0x00007fc9348ebf93 in clock_nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007fc9348fe353 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x000056220b40ecb4 in pg_usleep (microsec=microsec@entry=10000) at ../src/port/pgsleep.c:50
#3 0x000056220afb43c3 in CreateCheckPoint (flags=flags@entry=108) at ../src/backend/access/transam/xlog.c:7098
#4 0x000056220b1c6e86 in CheckpointerMain (startup_data=<optimized out>, startup_data_len=<optimized out>) at ../src/backend/postmaster/checkpointer.c:464
To fix, add AbsorbSyncRequests() to the loops where the checkpointer
waits for DELAY_CHKPT_START or DELAY_CHKPT_COMPLETE operations to
finish.
Backpatch to v14. Before that, SLRU deletion didn't call
RegisterSyncRequest, which avoided this failure. I'm not sure if there
are other similar scenarios on older versions, but we haven't had
any such reports.
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/backend/access/transam/xlog.c
M src/backend/postmaster/checkpointer.c
doc PG 17 relnotes: fix system catalog name mistake
commit : f92fd1830715ac2039443756475169a45cae2874
author : Bruce Momjian <[email protected]>
date : Wed, 26 Jun 2024 15:08:06 -0400
committer: Bruce Momjian <[email protected]>
date : Wed, 26 Jun 2024 15:08:06 -0400
Reported-by: David G. Johnston
Discussion: https://postgr.es/m/CAKFQuwYgkaOuao4DXuQwhbg+vyu4Xb5TGpuDNDOfMa0AftyweQ@mail.gmail.com
Backpatch-through: master
M doc/src/sgml/release-17.sgml
doc PG 17 relnotes: add item about pg_collation column renames
commit : d537b2e037e580b03c284bf3fcb02be6c3d5c8f2
author : Bruce Momjian <[email protected]>
date : Wed, 26 Jun 2024 13:13:46 -0400
committer: Bruce Momjian <[email protected]>
date : Wed, 26 Jun 2024 13:13:46 -0400
Reported-by: David G. Johnston
Discussion: https://postgr.es/m/CAKFQuwYRw30QaWrSsL57k3L_=zdQ4JTgY9pGnnhm42B7fGJX1A@mail.gmail.com
Backpatch-through: master
M doc/src/sgml/release-17.sgml
Use PqMsg_* macros in fe-auth.c.
commit : 32f07991b728c25bcd2543ef22ec96105e558477
author : Nathan Bossart <[email protected]>
date : Wed, 26 Jun 2024 11:25:38 -0500
committer: Nathan Bossart <[email protected]>
date : Wed, 26 Jun 2024 11:25:38 -0500
Commit f4b54e1ed9, which introduced macros for protocol characters,
missed updating a few places in fe-auth.c.
Author: Jelte Fennema-Nio
Discussion: https://postgr.es/m/CAGECzQSoPHtZ4xe0raJ6FYSEiPPS%2BYWXBhOGo%2BY1YecLgknF3g%40mail.gmail.com
M src/interfaces/libpq/fe-auth.c
Fix nbtree array unsatisfied inequality check.
commit : 486c2ea25c5e7e248c31b2dbb5db8ebcd3c7d813
author : Peter Geoghegan <[email protected]>
date : Wed, 26 Jun 2024 10:45:52 -0400
committer: Peter Geoghegan <[email protected]>
date : Wed, 26 Jun 2024 10:45:52 -0400
_bt_advance_array_keys didn't take sufficient care at the point where it
decides whether to start a new primitive index scan based on a call to
_bt_check_compare against finaltup (a call with the scan direction
flipped around). The final decision was conditioned on rules about how
the scan key offset sktrig that initially triggered array advancement
(passed to _bt_advance_array_keys from its _bt_checkkeys caller)
compared to the offset set by its own _bt_check_compare finaltup call.
This approach was faulty, in that it allowed _bt_advance_array_keys to
incorrectly start a new primitive index scan, that landed on the same
leaf page (on assert-enabled builds it led to an assertion failure).
In general, scans with array keys are expected to never have to read the
same leaf page more than once (barring cases involving cursors, and
cases where the scan restores a marked position for the inner side of a
merge join). This principle was established by commit 5bf748b8.
To fix, make the final decision based on whether the scan key offset set
by the _bt_check_compare finaltup call is an offset to an inequality
strategy scan key. An unsatisfied required inequality strategy scan key
indicates that all of the scan's required equality strategy scan keys
must also be satisfied by finaltup (not just by caller's tuple), and
that there is a decent chance that _bt_first will be able to reposition
the scan to a position many leaf pages ahead of the current leaf page.
Oversight in commit 5bf748b8.
Discussion: https://postgr.es/m/CAH2-Wz=DyHbcg7o6zXqzyiin8WE8vzk4tvU8Lrnh-a=EAvO0TQ@mail.gmail.com
M src/backend/access/nbtree/nbtutils.c
Fix partition pruning setup during DETACH CONCURRENTLY
commit : dbca3469ebf8ac523f401dd0c2eaffd9df64078f
author : Alvaro Herrera <[email protected]>
date : Wed, 26 Jun 2024 13:40:26 +0200
committer: Alvaro Herrera <[email protected]>
date : Wed, 26 Jun 2024 13:40:26 +0200
When detaching partition in concurrent mode, it's possible for partition
descriptors to not match the set that was recently seen when the plan
was made, causing an assertion failure or (in production builds) failure
to construct a working plan. The case that was reported involves
prepared statements, but I think it may be possible to hit this bug
without that too.
The problem is that CreatePartitionPruneState is constructing a
PartitionPruneState under the assumption that new partitions can be
added, but never removed, but it turns out that this isn't true: a
prepared statement gets replanned when the DETACH CONCURRENTLY session
sends out its invalidation message, but if the invalidation message
arrives after ExecInitAppend started, we would build a partition
descriptor without the partition, and then CreatePartitionPruneState
would refuse to work with it.
CreatePartitionPruneState already contains code to deal with the new
descriptor having more partitions than before (and behaving for the
extra partitions as if they had been pruned), but doesn't have code to
deal with less partitions than before, and it is naïve about the case
where the number of partitions is the same. We could simply add that a
new stanza for less partitions than before, and in simple testing it
works to do that; but it's possible to press the test scripts even
further and hit the case where one partition is added and a partition is
removed quickly enough that we see the same number of partitions, but
they don't actually match, causing hangs during execution.
To cope with both these problems, we now memcmp() the arrays of
partition OIDs, and do a more elaborate mapping (relying on the fact
that both OID arrays are in partition-bounds order) if they're not
identical.
This fix was already pushed in backbranches earlier.
Reported-by: yajun Hu <[email protected]>
Reviewed-by: Tender Wang <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/execPartition.c
Improve comment in gram.y.
commit : 1bf29f51fa1a15bd5d28e64070e6e8d105338fc3
author : Tom Lane <[email protected]>
date : Tue, 25 Jun 2024 17:53:41 -0400
committer: Tom Lane <[email protected]>
date : Tue, 25 Jun 2024 17:53:41 -0400
"As so-and-so" isn't bad English, but it has a faintly archaic
whiff to it, and confuses some non-native speakers. Write
"Like so-and-so" instead.
Per complaint from Tatsuo Ishii.
Discussion: https://postgr.es/m/20240623.130154.1867056921698616251.t-ishii@sranhm.sra.co.jp.sranhm
M src/backend/parser/gram.y
Stamp 17beta2.
commit : 23c5a0e7d43bc925c6001538f04a458933a11fc1
author : Joe Conway <[email protected]>
date : Mon, 24 Jun 2024 17:24:14 -0400
committer: Joe Conway <[email protected]>
date : Mon, 24 Jun 2024 17:24:14 -0400
M configure
M configure.ac
M meson.build
Revert "Fix partition pruning setup during DETACH CONCURRENTLY"
commit : b0ea16528cda1f3a993bbfeb2b93eed9762af4e6
author : Alvaro Herrera <[email protected]>
date : Mon, 24 Jun 2024 17:20:21 +0200
committer: Alvaro Herrera <[email protected]>
date : Mon, 24 Jun 2024 17:20:21 +0200
This reverts commit 27162a64b386; this branch is in code freeze due to a
nearing release. We can commit again after the release is out.
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/execPartition.c
Fix partition pruning setup during DETACH CONCURRENTLY
commit : 27162a64b386a1f639a4f2b96c7cc3b1db192d92
author : Alvaro Herrera <[email protected]>
date : Mon, 24 Jun 2024 15:56:32 +0200
committer: Alvaro Herrera <[email protected]>
date : Mon, 24 Jun 2024 15:56:32 +0200
When detaching partition in concurrent mode, it's possible for partition
descriptors to not match the set that was recently seen when the plan
was made, causing an assertion failure or (in production builds) failure
to construct a working plan. The case that was reported involves
prepared statements, but I think it may be possible to hit this bug
without that too.
The problem is that CreatePartitionPruneState is constructing a
PartitionPruneState under the assumption that new partitions can be
added, but never removed, but it turns out that this isn't true: a
prepared statement gets replanned when the DETACH CONCURRENTLY session
sends out its invalidation message, but if the invalidation message
arrives after ExecInitAppend started, we would build a partition
descriptor without the partition, and then CreatePartitionPruneState
would refuse to work with it.
CreatePartitionPruneState already contains code to deal with the new
descriptor having more partitions than before (and behaving for the
extra partitions as if they had been pruned), but doesn't have code to
deal with less partitions than before, and it is naïve about the case
where the number of partitions is the same. We could simply add that a
new stanza for less partitions than before, and in simple testing it
works to do that; but it's possible to press the test scripts even
further and hit the case where one partition is added and a partition is
removed quickly enough that we see the same number of partitions, but
they don't actually match, causing hangs during execution.
To cope with both these problems, we now memcmp() the arrays of
partition OIDs, and do a more elaborate mapping (relying on the fact
that both OID arrays are in partition-bounds order) if they're not
identical.
Backpatch to 14, where DETACH CONCURRENTLY appeared.
Reported-by: yajun Hu <[email protected]>
Reviewed-by: Tender Wang <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/execPartition.c
Translation updates
commit : f7f4e7e6fa576761f5330963cb7af686957589b4
author : Peter Eisentraut <[email protected]>
date : Mon, 24 Jun 2024 13:11:27 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 24 Jun 2024 13:11:27 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 4409d73e450606ff15b428303d706f1d15c1f597
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/ja.po
M src/backend/po/ka.po
M src/bin/initdb/po/de.po
M src/bin/initdb/po/ja.po
M src/bin/initdb/po/ka.po
M src/bin/pg_amcheck/po/de.po
M src/bin/pg_amcheck/po/ja.po
M src/bin/pg_amcheck/po/ka.po
M src/bin/pg_archivecleanup/po/de.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/ja.po
M src/bin/pg_basebackup/po/ka.po
M src/bin/pg_checksums/po/de.po
M src/bin/pg_combinebackup/po/de.po
M src/bin/pg_combinebackup/po/ja.po
M src/bin/pg_combinebackup/po/ka.po
M src/bin/pg_config/po/de.po
M src/bin/pg_controldata/po/de.po
M src/bin/pg_controldata/po/ja.po
M src/bin/pg_ctl/po/de.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/ja.po
M src/bin/pg_dump/po/ka.po
M src/bin/pg_resetwal/po/de.po
M src/bin/pg_rewind/po/de.po
M src/bin/pg_rewind/po/ja.po
M src/bin/pg_rewind/po/ka.po
M src/bin/pg_test_fsync/po/de.po
M src/bin/pg_test_fsync/po/ja.po
M src/bin/pg_test_timing/po/de.po
M src/bin/pg_upgrade/po/de.po
M src/bin/pg_upgrade/po/ja.po
M src/bin/pg_upgrade/po/ka.po
M src/bin/pg_verifybackup/po/de.po
M src/bin/pg_verifybackup/po/ja.po
M src/bin/pg_verifybackup/po/ka.po
M src/bin/pg_waldump/po/de.po
M src/bin/pg_walsummary/po/de.po
M src/bin/pg_walsummary/po/ja.po
M src/bin/psql/po/de.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ka.po
M src/bin/scripts/po/de.po
M src/bin/scripts/po/ja.po
M src/bin/scripts/po/ka.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ka.po
M src/pl/tcl/po/de.po
M src/pl/tcl/po/ja.po
M src/pl/tcl/po/ka.po
Remove extra comment at TableAmRoutine.scan_analyze_next_block
commit : 70a845c04a47645b58f8276a6b3ab201ea8ec426
author : Alexander Korotkov <[email protected]>
date : Sat, 22 Jun 2024 16:13:08 +0300
committer: Alexander Korotkov <[email protected]>
date : Sat, 22 Jun 2024 16:13:08 +0300
The extra comment was accidentally copied here by 6377e12a from
heapam_scan_analyze_next_block().
Reported-by: Matthias van de Meent
Discussion: https://postgr.es/m/CAEze2WjC5PiweG-4oe0hB_Zr59iF3tRE1gURm8w4Cg5b6JEBGw%40mail.gmail.com
M src/include/access/tableam.h
doc PG 17 relnotes: wording improvements, add links, merge item
commit : a8ffa32377a765fc8d3c4354cdd5a258f596c810
author : Bruce Momjian <[email protected]>
date : Fri, 21 Jun 2024 12:08:14 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 21 Jun 2024 12:08:14 -0400
Backpatch-through: master
M doc/src/sgml/release-17.sgml
Fix relcache invalidation when relfilelocator is updated
commit : 441ef5e1badcc3695de4a865cffb30f0e5057893
author : Heikki Linnakangas <[email protected]>
date : Fri, 21 Jun 2024 17:13:10 +0300
committer: Heikki Linnakangas <[email protected]>
date : Fri, 21 Jun 2024 17:13:10 +0300
In commit af0e7deb4a, I removed a call to RelationCloseSmgr(), because
the dangling SMgrRelation was no longer an issue. However, we still
need the call when the relation's relfilelocator changes, so that the
new relfilelocator takes effect immediately.
Reported-by: Alexander Lakhin <[email protected]>
Discussion: https://www.postgresql.org/message-id/987b1c8c-8c91-4847-ca0e-879f421680ff%40gmail.com
M src/backend/utils/cache/relcache.c
doc PG 17 relnotes: add link to enable_group_by_reordering GUC
commit : 90fe7b74df976324d7c0b3d203b25b7333447ca3
author : Bruce Momjian <[email protected]>
date : Fri, 21 Jun 2024 10:11:12 -0400
committer: Bruce Momjian <[email protected]>
date : Fri, 21 Jun 2024 10:11:12 -0400
Backpatch-through: master
M doc/src/sgml/release-17.sgml
Add doc entry for the new GUC paramenter enable_group_by_reordering
commit : 82e79ee46b1c880cb7376cf4399c9883c1ddfaea
author : Alexander Korotkov <[email protected]>
date : Fri, 21 Jun 2024 15:39:13 +0300
committer: Alexander Korotkov <[email protected]>
date : Fri, 21 Jun 2024 15:39:13 +0300
0452b461bc4 adds alternative orderings of group-by keys during the query
optimization. This new feature is controlled by the new GUC parameter
enable_group_by_reordering, which accidentally came without the documentation.
This commit adds the missing documentation for that GUC.
Reported-by: Bruce Momjian
Discussion: https://postgr.es/m/ZnDx2FYlba_OafQd%40momjian.us
Author: Andrei Lepikhov
Reviewed-by: Pavel Borisov, Alexander Korotkov
M doc/src/sgml/config.sgml
Prevent access of uninitialized memory in radix tree nodes
commit : fd49e8f32325c675d9bb6e26fcdbe9754249932f
author : John Naylor <[email protected]>
date : Fri, 21 Jun 2024 14:59:11 +0700
committer: John Naylor <[email protected]>
date : Fri, 21 Jun 2024 14:59:11 +0700
RT_NODE_16_SEARCH_EQ() performs comparisions using vector registers
on x64-64 and aarch64. We apply a mask to the resulting bitfield
to eliminate irrelevant bits that may be set. This ensures correct
behavior, but Valgrind complains of the partially-uninitialised
values. So far the warnings have only occurred on aarch64, which
explains why this hasn't been seen earlier.
To fix this warning, initialize the whole fixed-sized part of the nodes
upon allocation, rather than just do the minimum initialization to
function correctly. The initialization for node48 is a bit different
in that the 256-byte slot index array must be populated with "invalid
index" rather than zero. Experimentation has shown that compilers
tend to emit code that uselessly memsets that array twice. To avoid
pessimizing this path, swap the order of the slot_idxs[] and isset[]
arrays so we can initialize with two non-overlapping memset calls.
Reported by Tomas Vondra
Analysis and patch by Tom Lane, reviewed by Masahiko Sawada. I
investigated the behavior of memset calls to overlapping regions,
leading to the above tweaks to node48 as discussed in the thread.
Discussion: https://postgr.es/m/120c63ad-3d12-415f-a7bf-3da451c31bf6%40enterprisedb.com
M src/include/lib/radixtree.h
pg_combinebackup: Error message improvements
commit : c5c82123d3050c3a5eef0f51e9783f1cc5004ba0
author : Peter Eisentraut <[email protected]>
date : Fri, 21 Jun 2024 09:40:44 +0200
committer: Peter Eisentraut <[email protected]>
date : Fri, 21 Jun 2024 09:40:44 +0200
Make the wordings of some file-related error messages more like those
used in other files.
M src/bin/pg_combinebackup/backup_label.c
M src/bin/pg_combinebackup/copy_file.c
M src/bin/pg_combinebackup/load_manifest.c
M src/bin/pg_combinebackup/pg_combinebackup.c
M src/bin/pg_combinebackup/reconstruct.c
M src/bin/pg_combinebackup/write_manifest.c
Remove redundant newlines from error messages
commit : aea79883c57a522f0234d135fe0a3de19178a964
author : Peter Eisentraut <[email protected]>
date : Fri, 21 Jun 2024 09:29:34 +0200
committer: Peter Eisentraut <[email protected]>
date : Fri, 21 Jun 2024 09:29:34 +0200
M src/bin/pg_combinebackup/pg_combinebackup.c
Fix make build on MinGW
commit : 58445651dbc6182e1ff4100f6428ba6a261407f9
author : Peter Eisentraut <[email protected]>
date : Fri, 21 Jun 2024 08:17:23 +0200
committer: Peter Eisentraut <[email protected]>
date : Fri, 21 Jun 2024 08:17:23 +0200
Revert a couple of the simplifications done in commit 721856ff24b
because platforms without ln -s, where LN_S='cp -pR', such as MinGW,
required the specific previous incantations.
Reported-by: Noah Misch <[email protected]>
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/backend/Makefile
parse_manifest: Use const char *
commit : 02bbc3c83aec597e4b8c873916e9e29f3d02b132
author : Peter Eisentraut <[email protected]>
date : Fri, 21 Jun 2024 07:50:02 +0200
committer: Peter Eisentraut <[email protected]>
date : Fri, 21 Jun 2024 07:50:02 +0200
This adapts the manifest parsing code to take advantage of the
const-ified jsonapi.
Reviewed-by: Andrew Dunstan <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/f732b014-f614-4600-a437-dba5a2c3738b%40eisentraut.org
M src/backend/backup/basebackup_incremental.c
M src/bin/pg_combinebackup/load_manifest.c
M src/bin/pg_combinebackup/load_manifest.h
M src/bin/pg_verifybackup/pg_verifybackup.c
M src/common/parse_manifest.c
M src/include/common/parse_manifest.h
jsonapi: Use const char *
commit : 15cd9a3881b030a1a4bddc809f038f86ec27e66d
author : Peter Eisentraut <[email protected]>
date : Fri, 21 Jun 2024 07:50:02 +0200
committer: Peter Eisentraut <[email protected]>
date : Fri, 21 Jun 2024 07:50:02 +0200
Apply const qualifiers to char * arguments and fields throughout the
jsonapi. This allows the top-level APIs such as
pg_parse_json_incremental() to declare their input argument as const.
It also reduces the number of unconstify() calls.
Reviewed-by: Andrew Dunstan <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/f732b014-f614-4600-a437-dba5a2c3738b%40eisentraut.org
M src/backend/utils/adt/jsonfuncs.c
M src/common/jsonapi.c
M src/include/common/jsonapi.h
jsonapi: Use size_t
commit : 0b06bf9fa972e2964401622f1bb4c611dbe92bd5
author : Peter Eisentraut <[email protected]>
date : Fri, 21 Jun 2024 07:50:02 +0200
committer: Peter Eisentraut <[email protected]>
date : Fri, 21 Jun 2024 07:50:02 +0200
Use size_t instead of int for object sizes in the jsonapi. This makes
the API better self-documenting.
Reviewed-by: Andrew Dunstan <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/f732b014-f614-4600-a437-dba5a2c3738b%40eisentraut.org
M src/common/jsonapi.c
M src/common/parse_manifest.c
M src/include/common/jsonapi.h
M src/include/common/parse_manifest.h
Doc: Generated columns are skipped for logical replication.
commit : 7a089f6e6a14ca3a5dc8822c393c6620279968b9
author : Amit Kapila <[email protected]>
date : Fri, 21 Jun 2024 09:55:25 +0530
committer: Amit Kapila <[email protected]>
date : Fri, 21 Jun 2024 09:55:25 +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
doc PG 17 relnotes: remove mention of undocumented GUC
commit : 95cabf542f04b634303f899600ea62fb256a08c2
author : Bruce Momjian <[email protected]>
date : Thu, 20 Jun 2024 19:53:01 -0400
committer: Bruce Momjian <[email protected]>
date : Thu, 20 Jun 2024 19:53:01 -0400
GUC is trace_connection_negotiation. If it is undocumented, we should
not mention it in the release notes.
Backpatch-through: master
M doc/src/sgml/release-17.sgml
Don't throw an error if a queued AFTER trigger no longer exists.
commit : e6d0d16adf7fb7e715314d5068db4b875c3edf00
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
pg_combinebackup: Fix small mistake in --help output
commit : ab4346ebbfef44db857321d74bc0c31e03a72514
author : Peter Eisentraut <[email protected]>
date : Thu, 20 Jun 2024 11:49:01 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 20 Jun 2024 11:49:01 +0200
It was not showing that the --output option takes an argument.
M src/bin/pg_combinebackup/pg_combinebackup.c
pg_createsubscriber: Indent --help output correctly
commit : d048a327890851f37c8a0d0b8522cb8064ad7cfc
author : Peter Eisentraut <[email protected]>
date : Thu, 20 Jun 2024 11:42:40 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 20 Jun 2024 11:42:40 +0200
It was using 1 space indent instead of the 2 spaces used everywhere
else.
M src/bin/pg_basebackup/pg_createsubscriber.c
pg_dump: Fix weird error message composition
commit : 3639d08e2f36f76e9a626c60b534c7fe204f329c
author : Peter Eisentraut <[email protected]>
date : Thu, 20 Jun 2024 11:36:38 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 20 Jun 2024 11:36:38 +0200
The previous way could make it look like "stdin" was the actual input
file name. Write it as two separate messages instead.
M src/bin/pg_dump/filter.c
Fix redundancy in error messages
commit : 16a3415440ecf2f5cd02848fc05cbfe040ce14c2
author : Peter Eisentraut <[email protected]>
date : Thu, 20 Jun 2024 11:17:21 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 20 Jun 2024 11:17:21 +0200
pg_log_error() already prints the program name, so we don't need to
print it again inside the message.
M src/bin/pg_combinebackup/pg_combinebackup.c
M src/bin/pg_walsummary/pg_walsummary.c
Unify some error messages
commit : 95b44bb025b5d13c673662af68a218bd1873861f
author : Peter Eisentraut <[email protected]>
date : Thu, 20 Jun 2024 11:10:26 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 20 Jun 2024 11:10:26 +0200
M contrib/pg_prewarm/autoprewarm.c
M src/backend/postmaster/bgworker.c
meson: Fix import library name in Windows
commit : c61c0cb3a99285db36806b592bd8c540c98757e5
author : Peter Eisentraut <[email protected]>
date : Thu, 20 Jun 2024 08:09:28 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 20 Jun 2024 08:09:28 +0200
This changes the import library name from 'postgres.exe.lib' to
'postgres.lib', which is what it was with the old MSVC build system.
Extension builds use that name.
Bug: #18513
Reported-by: Muralikrishna Bandaru <[email protected]>
M meson.build
M src/backend/meson.build
Fix comment in pg_upgrade.h.
commit : 832dc19ea681a54c153228a96112bea68dbff022
author : Nathan Bossart <[email protected]>
date : Wed, 19 Jun 2024 16:12:18 -0500
committer: Nathan Bossart <[email protected]>
date : Wed, 19 Jun 2024 16:12:18 -0500
Contrary to what the comment for the "check" struct member claims,
'pg_upgrade --check' performs only the checks and does not ask the
user for permission to make changes.
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/ZnHk7ci5IuTWVc_c%40nathan
M src/bin/pg_upgrade/pg_upgrade.h
SQL/JSON: Correctly enforce the default ON EMPTY behavior
commit : 03ec203164119f11f0eab4c83c97a8527e2b108d
author : Amit Langote <[email protected]>
date : Wed, 19 Jun 2024 15:22:59 +0900
committer: Amit Langote <[email protected]>
date : Wed, 19 Jun 2024 15:22:59 +0900
Currently, when the ON EMPTY clause is not present, the ON ERROR
clause (implicit or explicit) dictates the behavior when jsonpath
evaluation in ExecEvalJsonExprPath() results in an empty sequence.
That is an oversight in the commit 6185c9737c.
This commit fixes things so that a NULL is returned instead in that
case which is the default behavior when the ON EMPTY clause is not
present.
Reported-by: Markus Winand
Discussion: https://postgr.es/m/F7DD1442-265C-4220-A603-CB0DEB77E91D%40winand.at
M src/backend/parser/parse_expr.c
M src/test/regress/expected/sqljson_jsontable.out
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_jsontable.sql
M src/test/regress/sql/sqljson_queryfuncs.sql
SQL/JSON: Correct jsonpath variable name matching
commit : 0f271e8e8d9c8db0ea86c0d12b3221009b81d8bf
author : Amit Langote <[email protected]>
date : Wed, 19 Jun 2024 15:22:06 +0900
committer: Amit Langote <[email protected]>
date : Wed, 19 Jun 2024 15:22:06 +0900
Previously, GetJsonPathVar() allowed a jsonpath expression to
reference any prefix of a PASSING variable's name. For example, the
following query would incorrectly work:
SELECT JSON_QUERY(context_item, jsonpath '$xy' PASSING val AS xyz);
The fix ensures that the length of the variable name mentioned in a
jsonpath expression matches exactly with the name of the PASSING
variable before comparing the strings using strncmp().
Reported-by: Alvaro Herrera (off-list)
Discussion: https://postgr.es/m/CA+HiwqFGkLWMvELBH6E4SQ45qUHthgcRH6gCJL20OsYDRtFx_w@mail.gmail.com
M src/backend/executor/execExpr.c
M src/backend/utils/adt/jsonpath_exec.c
M src/include/utils/jsonpath.h
M src/test/regress/expected/sqljson_queryfuncs.out
M src/test/regress/sql/sqljson_queryfuncs.sql
doc PG 17 relnotes: properly wrap SGML text
commit : 5e05a0e9924e97c24be13c75e4ba12c60bd0e4ad
author : Bruce Momjian <[email protected]>
date : Tue, 18 Jun 2024 22:41:49 -0400
committer: Bruce Momjian <[email protected]>
date : Tue, 18 Jun 2024 22:41:49 -0400
Backpatch-through: master
M doc/src/sgml/release-17.sgml
doc PG 17 relnotes: add links to documentation sections
commit : 5ade0b8f80cdbb715bc3904ac7d4281a75817911
author : Bruce Momjian <[email protected]>
date : Tue, 18 Jun 2024 22:09:41 -0400
committer: Bruce Momjian <[email protected]>
date : Tue, 18 Jun 2024 22:09:41 -0400
Also slightly improve markup instructions. Indentation is still needed.
Backpatch-through: master
M doc/src/sgml/release-17.sgml
M doc/src/sgml/release.sgml
Fix possible Assert failure in cost_memoize_rescan
commit : aa901a37cf8aaf36b0dabaaea42ea3d068fe3448
author : David Rowley <[email protected]>
date : Wed, 19 Jun 2024 10:20:24 +1200
committer: David Rowley <[email protected]>
date : Wed, 19 Jun 2024 10:20:24 +1200
In cost_memoize_rescan(), when calculating the hit_ratio using the calls
and ndistinct estimations, if the value that was set in
MemoizePath.calls had not been processed through clamp_row_est(), then it
was possible that it was set to some non-integer value which could result
in ndistinct being 1 higher than calls due to estimate_num_groups()
performing clamp_row_est() on its input_rows. This could result in
hit_ratio values slightly below 0.0, which would cause an Assert failure.
The value of MemoizePath.calls comes from the final parameter in the
create_memoize_path() function, of which we only have one true caller of.
That caller passes outer_path->rows. All the core code I looked at
always seems to call clamp_row_est() on the Path.rows, so there might
have been no issues with any core Paths causing troubles here. The bug
report was about a CustomPath with a non-clamped row estimated.
The misbehavior as a result of this seems to be mostly limited to the
Assert() failing. Aside from that, it seems the Memoize costs would
just come out slightly higher than they should have, which is likely
fairly harmless.
Reported-by: Kohei KaiGai <[email protected]>
Discussion: https://postgr.es/m/CAOP8fzZnTU+N64UYJYogb1hN-5hFP+PwTb3m_cnGAD7EsQwrKw@mail.gmail.com
Reviewed-by: Richard Guo
Backpatch-through: 14, where Memoize was introduced
M src/backend/optimizer/util/pathnode.c
Fix incorrect punctuation in error message
commit : 5603e119f4bd4818f8fa432ffc177c3caf9efeb6
author : Peter Eisentraut <[email protected]>
date : Tue, 18 Jun 2024 14:53:11 +0200
committer: Peter Eisentraut <[email protected]>
date : Tue, 18 Jun 2024 14:53:11 +0200
M src/backend/utils/adt/timestamp.c
M src/test/regress/expected/window.out
Fix typo in 029_stats_restart.pl
commit : ae482a7ec521e09bb0dbfc261da6e6170a5ac29f
author : Michael Paquier <[email protected]>
date : Tue, 18 Jun 2024 12:51:36 +0900
committer: Michael Paquier <[email protected]>
date : Tue, 18 Jun 2024 12:51:36 +0900
Oversight in 16acf7f1aaea, where the test has been introduced. Issue
noticed while scanning this area of the tree.
M src/test/recovery/t/029_stats_restart.pl
doc PG 17 relnotes: update to current
commit : 82ed67a5fe826044bf361ad0425283d05f3dcf95
author : Bruce Momjian <[email protected]>
date : Mon, 17 Jun 2024 15:05:05 -0400
committer: Bruce Momjian <[email protected]>
date : Mon, 17 Jun 2024 15:05:05 -0400
Backpatch-through: master
M doc/src/sgml/release-17.sgml
doc PG 17 relnotes: Fix sslnegotation typo
commit : a6685c5e362eab5d04b8ffe65fff7cfbd21b6034
author : Andres Freund <[email protected]>
date : Mon, 17 Jun 2024 11:53:07 -0700
committer: Andres Freund <[email protected]>
date : Mon, 17 Jun 2024 11:53:07 -0700
I was confused with copy-pasting the parameter name didn't work...
M doc/src/sgml/release-17.sgml
Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRENTLY.
commit : 92c49d1062f7094f56b80c603233fa4a0ffe2f8b
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/backend/access/spgist/spgxlog.c
M src/include/access/spgist_private.h
M src/include/access/spgxlog.h
Remove recordExtensionInitPriv[Worker]'s ownerId argument.
commit : ba26d156636c84a9674e49dbdfe788b6291985f2
author : Tom Lane <[email protected]>
date : Mon, 17 Jun 2024 13:00:53 -0400
committer: Tom Lane <[email protected]>
date : Mon, 17 Jun 2024 13:00:53 -0400
In the wake of the previous commit, we're not doing anything
with that argument. Hence, revert the portions of 534287403
that added that argument and taught the callers to pass it.
Passing the ownerId requires additional syscache lookups in
some code paths, which'd be fine if we were doing anything
useful with the info, but it seems inadvisable if we're not.
Committed separately since there's some thought that we might
want to un-revert this in future, in case it's decided that
storing the original owner ID explicitly in pg_init_privs
is worth doing.
Discussion: https://postgr.es/m/CAMT0RQSVgv48G5GArUvOVhottWqZLrvC5wBzBa4HrUdXe9VRXw@mail.gmail.com
M src/backend/catalog/aclchk.c
Improve tracking of role dependencies of pg_init_privs entries.
commit : 35dd40d34cbdf5aa3e0f5b3493c33d00abb26456
author : Tom Lane <[email protected]>
date : Mon, 17 Jun 2024 12:55:10 -0400
committer: Tom Lane <[email protected]>
date : Mon, 17 Jun 2024 12:55:10 -0400
Commit 534287403 invented SHARED_DEPENDENCY_INITACL entries in
pg_shdepend, but installed them only for non-owner roles mentioned
in a pg_init_privs entry. This turns out to be the wrong thing,
because there is nothing to cue REASSIGN OWNED to go and update
pg_init_privs entries when the object's ownership is reassigned.
That leads to leaving dangling entries in pg_init_privs, as
reported by Hannu Krosing. Instead, install INITACL entries for
all roles mentioned in pg_init_privs entries (except pinned roles),
and change ALTER OWNER to not touch them, just as it doesn't
touch pg_init_privs entries.
REASSIGN OWNED will now substitute the new owner OID for the old
in pg_init_privs entries. This feels like perhaps not quite the
right thing, since pg_init_privs ought to be a historical record
of the state of affairs just after CREATE EXTENSION. However,
it's hard to see what else to do, if we don't want to disallow
dropping the object's original owner. In any case this is
better than the previous do-nothing behavior, and we're unlikely
to come up with a superior solution in time for v17.
While here, tighten up some coding rules about how ACLs in
pg_init_privs should never be null or empty. There's not any
obvious reason to allow that, and perhaps asserting that it's
not so will catch some bugs. (We were previously inconsistent
on the point, with some code paths taking care not to store
empty ACLs and others not.)
This leaves recordExtensionInitPrivWorker not doing anything
with its ownerId argument, but we'll deal with that separately.
catversion bump forced because of change of expected contents
of pg_shdepend when pg_init_privs entries exist.
Discussion: https://postgr.es/m/CAMT0RQSVgv48G5GArUvOVhottWqZLrvC5wBzBa4HrUdXe9VRXw@mail.gmail.com
M doc/src/sgml/catalogs.sgml
M src/backend/catalog/aclchk.c
M src/backend/catalog/pg_shdepend.c
M src/backend/utils/adt/acl.c
M src/include/catalog/catversion.h
M src/include/catalog/dependency.h
M src/include/utils/acl.h
M src/test/modules/test_pg_dump/expected/test_pg_dump.out
M src/test/modules/test_pg_dump/sql/test_pg_dump.sql
Teach jsonpath string() to unwrap in lax mode
commit : 653d3969bb013f14c4a6884a253ad9676caf8166
author : Andrew Dunstan <[email protected]>
date : Mon, 17 Jun 2024 10:31:29 -0400
committer: Andrew Dunstan <[email protected]>
date : Mon, 17 Jun 2024 10:31:29 -0400
This was an ommission in commit 66ea94e, and brings it into compliance
with both other methods and the standard.
Per complaint from David Wheeler.
Author: David Wheeler, Jeevan Chalke
Reviewed-by: Chapman Flack
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/func.sgml
M src/backend/utils/adt/jsonpath_exec.c
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/sql/jsonb_jsonpath.sql
pg_createsubscriber: Remove failover replication slots on subscriber
commit : 81d20fbf7a03f5e385700c90aec883c96b32ddc6
author : Peter Eisentraut <[email protected]>
date : Mon, 17 Jun 2024 12:12:49 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 17 Jun 2024 12:12:49 +0200
After running pg_createsubscriber, these replication slots have no use
on subscriber, so drop them.
Author: Euler Taveira <[email protected]>
Reviewed-by: Hayato Kuroda <[email protected]>
Discussion: https://www.postgresql.org/message-id/776c5cac-5ef5-4001-b1bc-5b698bc0c62a%40app.fastmail.com
M doc/src/sgml/ref/pg_createsubscriber.sgml
M src/bin/pg_basebackup/pg_createsubscriber.c
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl
pg_createsubscriber: Remove replication slot check on primary
commit : b96391382626306c301b67cbd2d28313d96741f3
author : Peter Eisentraut <[email protected]>
date : Mon, 17 Jun 2024 10:48:17 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 17 Jun 2024 10:48:17 +0200
It used to check if the replication slot exists and is active on
primary. This check might fail on slow hosts because the replication
slot might not be active at the time of this check.
The current code obtains the replication slot name from the
primary_slot_name on standby and assumes the replication slot exists
and is active on primary. If it doesn't exist, this tool will log an
error and continue.
Author: Euler Taveira <[email protected]>
Reviewed-by: Hayato Kuroda <[email protected]>
Discussion: https://www.postgresql.org/message-id/776c5cac-5ef5-4001-b1bc-5b698bc0c62a%40app.fastmail.com
M src/bin/pg_basebackup/pg_createsubscriber.c
pg_createsubscriber: Only --recovery-timeout controls the end of recovery process
commit : 04c8634c0c4d636540c9283efdd695558403dc4e
author : Peter Eisentraut <[email protected]>
date : Mon, 17 Jun 2024 09:42:51 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 17 Jun 2024 09:42:51 +0200
It used to check if the target server is connected to the primary
server (send required WAL) to rapidly react when the process won't
succeed. This code is not enough to guarantee that the recovery
process will complete. There is a window between the walreceiver
shutdown and the pg_is_in_recovery() returns false that can reach
NUM_CONN_ATTEMPTS attempts and fails.
Instead, rely only on the --recovery-timeout option to give up the
process after the specified number of seconds.
This should help with buildfarm failures on slow machines.
Author: Euler Taveira <[email protected]>
Reviewed-by: Hayato Kuroda <[email protected]>
Discussion: https://www.postgresql.org/message-id/776c5cac-5ef5-4001-b1bc-5b698bc0c62a%40app.fastmail.com
M doc/src/sgml/ref/pg_createsubscriber.sgml
M src/bin/pg_basebackup/pg_createsubscriber.c
M src/bin/pg_basebackup/t/040_pg_createsubscriber.pl
Make regress function make_tuple_indirect() able to handle plain attributes
commit : 8f1888eb6d6023b80525fbf7a8a1053daa6eb31e
author : Michael Paquier <[email protected]>
date : Mon, 17 Jun 2024 14:26:27 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 17 Jun 2024 14:26:27 +0900
The function has been introduced in 368202501539 to test at a low level
the new kinds of external toast datums, and would fail on OOM when
dealing with a plain storage attribute. The existing tests of
indirect_toast do not test this case, still the error generated was
confusing.
Author: Alexander Lakhin
Discussion: https://postgr.es/m/[email protected]
M src/test/regress/regress.c
doc: Mention modules/injection_points as example for injection points
commit : faaa0d279899f037b4a6472a00fcd14a321e64c7
author : Michael Paquier <[email protected]>
date : Mon, 17 Jun 2024 13:49:40 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 17 Jun 2024 13:49:40 +0900
This should have been added in 49cd2b93d7db, that introduced the module.
Reported-by: Jian He
Discussion: https://postgr.es/m/CACJufxF+Vfj2Oz2kBR5v1bjHeZxvs63cLogm70v9Uto1Rqiieg@mail.gmail.com
M doc/src/sgml/xfunc.sgml
Add Windows file version information to test_json_parser programs.
commit : 645bda2a7155fff57cc3da2ab923202187c72957
author : Noah Misch <[email protected]>
date : Sun, 16 Jun 2024 12:29:30 -0700
committer: Noah Misch <[email protected]>
date : Sun, 16 Jun 2024 12:29:30 -0700
M src/test/modules/test_json_parser/Makefile
Remove use of %z in sscanf.
commit : 8866ed9560576de9dec628d5bfdb1571ec8d8ef0
author : Noah Misch <[email protected]>
date : Sun, 16 Jun 2024 12:29:25 -0700
committer: Noah Misch <[email protected]>
date : Sun, 16 Jun 2024 12:29:25 -0700
As in 9d7ded0f4277f5c0063eca8e871a34e2355a8371, it causes warnings on
some MinGW compilers.
M src/test/modules/test_json_parser/test_json_parser_incremental.c
Convert confusing macros in multixact.c to static inline functions
commit : 0099b9408e8c74158976c888854e0caafd6c052a
author : Heikki Linnakangas <[email protected]>
date : Sun, 16 Jun 2024 20:47:07 +0300
committer: Heikki Linnakangas <[email protected]>
date : Sun, 16 Jun 2024 20:47:07 +0300
The macros were confused about the argument data types. All the
arguments were called 'xid', and some of the macros included casts to
TransactionId, even though the arguments were actually either
MultiXactIds or MultiXactOffsets. It compiles to the same thing,
because TransactionId, MultiXactId and MultiXactOffset are all
typedefs of uint32, but it was highly misleading.
Author: Maxim Orlov <[email protected]>
Discussion: https://www.postgresql.org/message-id/CACG%3DezbLUG-OD1osAW3OchOMxZtdxHh2itYR9Zhh-a13wEBEQw%40mail.gmail.com
Discussion: https://www.postgresql.org/message-id/ff143b24-a093-40da-9833-d36b83726bdf%40iki.fi
M src/backend/access/transam/multixact.c
doc: fix typo in create role manual.
commit : 92aff003d7f20810d7c8fbe13cbe5fb041cc6242
author : Tatsuo Ishii <[email protected]>
date : Sun, 16 Jun 2024 16:21:46 +0900
committer: Tatsuo Ishii <[email protected]>
date : Sun, 16 Jun 2024 16:21:46 +0900
There was a small mistake in the create role manual.
Author: Satoru Koizumi
Reviewed-by: David G. Johnston
Discussion: https://postgr.es/m/flat/20240616.112523.1208348667552014162.t-ishii%40sranhm.sra.co.jp
Backpatch-through: 16
M doc/src/sgml/ref/create_role.sgml
Clean out column-level pg_init_privs entries when dropping tables.
commit : 76618097a6c027ec603a3dd143f61098e3fb9794
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 misc_sanity test to accept SHARED_DEPENDENCY_INITACL entries.
commit : 01aa88f71208c2af143b044553b89df4438de33e
author : Tom Lane <[email protected]>
date : Fri, 14 Jun 2024 15:29:09 -0400
committer: Tom Lane <[email protected]>
date : Fri, 14 Jun 2024 15:29:09 -0400
Oversight in 534287403. We missed this up to now because the
core regression tests create no such entries (at least up to
this test), so the only way to see the failure is to do
"make installcheck" in an installation where some other DB
has such entries. I happened to do that just now ...
M src/test/regress/expected/misc_sanity.out
M src/test/regress/sql/misc_sanity.sql
Reintroduce dead tuple counter in pg_stat_progress_vacuum.
commit : f1affb67055c9b3f31a7ee7eb521a9ba64fff488
author : Masahiko Sawada <[email protected]>
date : Fri, 14 Jun 2024 10:08:15 +0900
committer: Masahiko Sawada <[email protected]>
date : Fri, 14 Jun 2024 10:08:15 +0900
Commit 667e65aac3 changed both num_dead_tuples and max_dead_tuples
columns to dead_tuple_bytes and max_dead_tuple_bytes columns,
respectively. But as per discussion, the number of dead tuples
collected still provides meaningful insights for users.
This commit reintroduces the column for the count of dead tuples,
renamed as num_dead_item_ids. It avoids confusion with the number of
dead tuples removed by VACUUM, which includes dead heap-only tuples
but excludes any pre-existing LP_DEAD items left behind by
opportunistic pruning.
Bump catalog version.
Reviewed-by: Peter Geoghegan, Álvaro Herrera, Andrey Borodin
Discussion: https://postgr.es/m/CAD21AoBL5sJE9TRWPyv%2Bw7k5Ee5QAJqDJEDJBUdAaCzGWAdvZw%40mail.gmail.com
M doc/src/sgml/monitoring.sgml
M src/backend/access/heap/vacuumlazy.c
M src/backend/catalog/system_views.sql
M src/include/catalog/catversion.h
M src/include/commands/progress.h
M src/test/regress/expected/rules.out
Fix parsing of ignored operators in websearch_to_tsquery().
commit : 56a8296212b68267dc2bddeb1fb40a893b1aadb3
author : Tom Lane <[email protected]>
date : Thu, 13 Jun 2024 20:34:42 -0400
committer: Tom Lane <[email protected]>
date : Thu, 13 Jun 2024 20:34:42 -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
doc: Fix description WAL summarizer in glossary
commit : d872e1b4730b793c9d72c80b65feb988269104e2
author : Michael Paquier <[email protected]>
date : Fri, 14 Jun 2024 09:28:11 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 14 Jun 2024 09:28:11 +0900
The WAL summarizer is an auxiliary process.
Oversight in 7b1dbf0a8d1d.
Author: Masahiro Ikeda
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/glossary.sgml
doc: Fix description WAL writer in glossary
commit : 3c992361cda184ff635a516832dcc54c569ea6ec
author : Michael Paquier <[email protected]>
date : Fri, 14 Jun 2024 09:26:32 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 14 Jun 2024 09:26:32 +0900
The WAL writer is an auxiliary process, but its description in the
glossary did not match that.
This is inexact since d3014fff4cd4.
Author: Masahiro Ikeda
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 15
M doc/src/sgml/glossary.sgml
Improve the granularity of PQsocketPoll's timeout parameter.
commit : 105024a47238e33647d346264b4f6fe68a7287ed
author : Tom Lane <[email protected]>
date : Thu, 13 Jun 2024 15:14:32 -0400
committer: Tom Lane <[email protected]>
date : Thu, 13 Jun 2024 15:14:32 -0400
Commit f5e4dedfa exposed libpq's internal function PQsocketPoll
without a lot of thought about whether that was an API we really
wanted to chisel in stone. The main problem with it is the use of
time_t to specify the timeout. While we do want an absolute time
so that a loop around PQsocketPoll doesn't have problems with
timeout slippage, time_t has only 1-second resolution. That's
already problematic for libpq's own internal usage --- for example,
pqConnectDBComplete has long had a kluge to treat "connect_timeout=1"
as 2 seconds so that it doesn't accidentally round to nearly zero.
And it's even less likely to be satisfactory for external callers.
Hence, let's change this while we still can.
The best idea seems to be to use an int64 count of microseconds since
the epoch --- basically the same thing as the backend's TimestampTz,
but let's use the standard Unix epoch (1970-01-01) since that's more
likely for clients to be easy to calculate. Millisecond resolution
would be plenty for foreseeable uses, but maybe the day will come that
we're glad we used microseconds.
Also, since time(2) isn't especially helpful for computing timeouts
defined this way, introduce a new function PQgetCurrentTimeUSec
to get the current time in this form.
Remove the hack in pqConnectDBComplete, so that "connect_timeout=1"
now means what you'd expect.
We can also remove the "#include <time.h>" that f5e4dedfa added to
libpq-fe.h, since there's no longer a need for time_t in that header.
It seems better for v17 not to enlarge libpq-fe.h's include footprint
from what it's historically been, anyway.
I also failed to resist the temptation to do some wordsmithing
on PQsocketPoll's documentation.
Patch by me, per complaint from Dominique Devienne.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/libpq.sgml
M src/bin/psql/command.c
M src/interfaces/libpq/exports.txt
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/fe-misc.c
M src/interfaces/libpq/libpq-fe.h
M src/interfaces/libpq/libpq-int.h
M src/tools/pgindent/typedefs.list
When replanning a plpgsql "simple expression", check it's still simple.
commit : 6dfac24401b7143ad5c75f991c18105e1267f88e
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/expected/plpgsql_simple.out
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/sql/plpgsql_simple.sql
Clamp result of MultiXactMemberFreezeThreshold
commit : c425113eebb7dbc7f0031ed97b32f267a9cac75f
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 : f83908798f78c4cafda217ca875602c88ea2ae28
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
M src/bin/pg_verifybackup/t/003_corruption.pl
Add postgres_inc to meson check for Python.h
commit : 11b9b8ce44a8cc80cbef6ade2b5ae7438227da79
author : Andrew Dunstan <[email protected]>
date : Thu, 13 Jun 2024 07:30:10 -0400
committer: Andrew Dunstan <[email protected]>
date : Thu, 13 Jun 2024 07:30:10 -0400
Required for Cygwin.
Backpatch to release 16.
M meson.build
Fix documentation of initdb --show option
commit : a41106dab72cbcaa02fce8bda8965d04e85f2d3a
author : Peter Eisentraut <[email protected]>
date : Thu, 13 Jun 2024 11:52:35 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 13 Jun 2024 11:52:35 +0200
It wasn't in the documentation at all (even though we document all the
other debugging-like options). Also, change the --help output to show
that it exits after showing, similar to other options.
M doc/src/sgml/ref/initdb.sgml
M src/bin/initdb/initdb.c
Add missing source files to nls.mk
commit : ad8877cb513733d8bb98d24770a094b81c27e4c5
author : Peter Eisentraut <[email protected]>
date : Thu, 13 Jun 2024 10:17:36 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 13 Jun 2024 10:17:36 +0200
Files in common/ and fe_utils/ that contain translatable strings need
to be listed in the nls.mk files of the programs that use them. (Not
great, but that's the way it works for now.) This usually requires
some manual analysis which is done about once during each major
release beta period. This time, I wrote a hackish script that figures
some of this out more automatically, so this update is a bit larger as
it also includes some files that were missed in the past.
M src/bin/initdb/nls.mk
M src/bin/pg_amcheck/nls.mk
M src/bin/pg_archivecleanup/nls.mk
M src/bin/pg_basebackup/nls.mk
M src/bin/pg_checksums/nls.mk
M src/bin/pg_combinebackup/nls.mk
M src/bin/pg_config/nls.mk
M src/bin/pg_controldata/nls.mk
M src/bin/pg_ctl/nls.mk
M src/bin/pg_dump/nls.mk
M src/bin/pg_resetwal/nls.mk
M src/bin/pg_rewind/nls.mk
M src/bin/pg_test_fsync/nls.mk
M src/bin/pg_test_timing/nls.mk
M src/bin/pg_upgrade/nls.mk
M src/bin/pg_verifybackup/nls.mk
M src/bin/pg_waldump/nls.mk
M src/bin/pg_walsummary/nls.mk
M src/bin/psql/nls.mk
M src/bin/scripts/nls.mk
libpq: Some message style normalization
commit : 6ac5600a36c1950e1470ccb16038e6b8ca4e6eba
author : Peter Eisentraut <[email protected]>
date : Thu, 13 Jun 2024 07:10:35 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 13 Jun 2024 07:10:35 +0200
M src/interfaces/libpq/fe-cancel.c
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/fe-exec.c
Harmonize pg_bsd_indent parameter names.
commit : 99b99285e5438ee8b0c065db58e87e6577158d22
author : Peter Geoghegan <[email protected]>
date : Wed, 12 Jun 2024 18:04:10 -0400
committer: Peter Geoghegan <[email protected]>
date : Wed, 12 Jun 2024 18:04:10 -0400
Make sure that function declarations use names that exactly match the
corresponding names from function definitions in pg_bsd_indent.
This commit was written with help from clang-tidy, by mechanically
applying the same rules as similar clean-up commits.
Discussion: https://postgr.es/m/CAH2-WzkaBS8w-vCbG5M5Bx7XikC0WhNLJV_+Z_YAWW9Kef6OBQ@mail.gmail.com
M src/tools/pg_bsd_indent/args.c
M src/tools/pg_bsd_indent/indent.c
Harmonize function parameter names for Postgres 17.
commit : 6207f08f700ddc874765919202727fb0171b5403
author : Peter Geoghegan <[email protected]>
date : Wed, 12 Jun 2024 17:01:51 -0400
committer: Peter Geoghegan <[email protected]>
date : Wed, 12 Jun 2024 17:01:51 -0400
Make sure that function declarations use names that exactly match the
corresponding names from function definitions in a few places. These
inconsistencies were all introduced during Postgres 17 development.
pg_bsd_indent still has a couple of similar inconsistencies, which I
(pgeoghegan) have left untouched for now.
This commit was written with help from clang-tidy, by mechanically
applying the same rules as similar clean-up commits (the earliest such
commit was commit 035ce1fe).
M src/backend/access/brin/brin.c
M src/backend/access/heap/vacuumlazy.c
M src/backend/backup/basebackup_incremental.c
M src/backend/backup/basebackup_zstd.c
M src/backend/commands/tablecmds.c
M src/backend/optimizer/path/joinrels.c
M src/backend/parser/parse_expr.c
M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
M src/backend/utils/adt/jsonpath_exec.c
M src/bin/pg_combinebackup/copy_file.c
M src/bin/pg_combinebackup/reconstruct.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_dump/pg_restore.c
M src/include/access/heapam.h
M src/include/common/unicode_case.h
M src/include/common/unicode_category.h
M src/include/libpq/libpq.h
M src/include/postmaster/postmaster.h
M src/include/storage/bufmgr.h
M src/include/storage/fd.h
M src/include/storage/read_stream.h
M src/include/storage/smgr.h
M src/include/utils/guc.h
M src/include/utils/jsonpath.h
M src/include/utils/pg_locale.h
M src/include/utils/resowner.h
M src/include/utils/tuplesort.h
libpq: Add missing gettext markers
commit : a0fe90efef91fcd578a85a0f0c5bcab55285b1d7
author : Peter Eisentraut <[email protected]>
date : Wed, 12 Jun 2024 15:31:31 +0200
committer: Peter Eisentraut <[email protected]>
date : Wed, 12 Jun 2024 15:31:31 +0200
Follow-up to 87d2801d4b: That commit restored some lost error
messages, but they ended up in a place where xgettext wouldn't find
them. Rather than elevating ENCRYPTION_NEGOTIATION_FAILED() to a
gettext trigger, it's easiest for now to put in some explicit
libpq_gettext() calls in the couple of call sites.
M src/interfaces/libpq/fe-connect.c
libpq: Remove a gettext marker
commit : d112ea46813277351b577ee586c6e84e7de8ab27
author : Peter Eisentraut <[email protected]>
date : Wed, 12 Jun 2024 08:43:43 +0200
committer: Peter Eisentraut <[email protected]>
date : Wed, 12 Jun 2024 08:43:43 +0200
This one error message is just a workaround for a missing OpenSSL
error string. But OpenSSL does not have gettext support, so we don't
need to provide it in our workaround either. That way, the
user-facing behavior is consistent whether the user has a fixed
OpenSSL or not.
M src/interfaces/libpq/fe-secure-openssl.c
Fix typo in error message
commit : f376996bb7fe621ac53279a81d475b214e492018
author : Peter Eisentraut <[email protected]>
date : Wed, 12 Jun 2024 04:48:39 +0200
committer: Peter Eisentraut <[email protected]>
date : Wed, 12 Jun 2024 04:48:39 +0200
M src/interfaces/libpq/fe-connect.c
Fix segmentation fault in test_tidstore.
commit : 18404ea60141a2e2eaf58a5ebbd2b99f7a0cd442
author : Masahiko Sawada <[email protected]>
date : Wed, 12 Jun 2024 09:56:13 +0900
committer: Masahiko Sawada <[email protected]>
date : Wed, 12 Jun 2024 09:56:13 +0900
The do_set_block_offsets() and other functions accessing the tidstore
did not check if the tidstore was NULL. This led to a segmentation
fault when these functions are called without calling the
test_create().
This commit adds NULL checks in relevant functions of test_tidstore to
raise an error instead if the tidstore is not initialized.
Bug: #18483
Reported-by: Alexander Kozhemyakin
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/18483-30bfff42de238000%40postgresql.org
M src/test/modules/test_tidstore/test_tidstore.c
Fix infer_arbiter_indexes() to not assume resultRelation is 1.
commit : 915de706d28c433283e9dc63701e8f978488a2b9
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
Fix creation of partition descriptor during concurrent detach
commit : c2fab70248d8b9f129d2333c91b7a6e279a591e3
author : Alvaro Herrera <[email protected]>
date : Tue, 11 Jun 2024 11:38:45 +0200
committer: Alvaro Herrera <[email protected]>
date : Tue, 11 Jun 2024 11:38:45 +0200
When a partition is being detached in concurrent mode, it is possible
for find_inheritance_children_extended() to return that partition in the
list, and immediately after that receive an invalidation message that
sets its relpartbound to NULL just before we read it. (This can happen
because table_open() reads invalidation messages.) Currently we raise
an error
ERROR: missing relpartbound for relation %u
about the situation, but that's bogus because the table is no longer a
partition, so we shouldn't be complaining about it. A better reaction
is to retry the find_inheritance_children_extended call to get a new
list, which will no longer have the partition being detached.
Noticed while investigating bug #18377.
Backpatch to 14, where DETACH CONCURRENTLY appeared.
Discussion: https://postgr.es/m/[email protected]
M src/backend/partitioning/partdesc.c
Fix an assert in CheckPointReplicationSlots().
commit : d1ffcc7fa3c54de8b2a677a3e503fc808c7b419c
author : Amit Kapila <[email protected]>
date : Tue, 11 Jun 2024 10:51:34 +0530
committer: Amit Kapila <[email protected]>
date : Tue, 11 Jun 2024 10:51:34 +0530
Commit e0b2eed047 assumed that the confirmed_flush LSN can't go backward.
However, it is possible that confirmed_flush LSN can go backward
temporarily when the client acknowledges a prior value of flush location.
This can happen when the client (subscriber in this case) acknowledges an
LSN it doesn't have to do anything for (say for DDLs) and thus didn't
store persistently. After restart, the client sends the prior value of
flush LSN which it had stored persistently and the server updates the
confirmed_flush LSN with that value.
The fix is to remove the assumption and not allow the prior value of
confirmed_flush LSN to be flushed to the disk.
Author: Vignesh C
Reviewed-by: Amit Kapila, Shlok Kyal
Discussion: https://postgr.es/m/CALDaNm3hgow2+oEov5jBk4iYP5eQrUCF1yZtW7+dV3J__p4KLQ@mail.gmail.com
M src/backend/replication/slot.c
Doc: Fix ambuiguity in column lists.
commit : 3470391e169ed46fa646ea39ade4b9b6898adb17
author : Amit Kapila <[email protected]>
date : Tue, 11 Jun 2024 09:39:52 +0530
committer: Amit Kapila <[email protected]>
date : Tue, 11 Jun 2024 09:39:52 +0530
The behavior for columns added later to the table for publications with no
specified column lists was not clear.
Reported-by: Koen De Groote
Author: Peter Smith
Reviewed-by: Vignesh C, Laurenz Albe
Backpatch-through: 15
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/logical-replication.sgml
doc: Mention all options equivalent to pg_dump --filter patterns.
commit : c50d4f4028e5518511b9bfc3a17860a90dc88357
author : Dean Rasheed <[email protected]>
date : Mon, 10 Jun 2024 14:55:41 +0100
committer: Dean Rasheed <[email protected]>
date : Mon, 10 Jun 2024 14:55:41 +0100
In the documentation for pg_dump's new --filter option, added by
commit a5cf808be5, each object pattern should match some other
existing pg_dump option, but some had been omitted, so add them.
Noted by Daniel Gustafsson, reviewed by Ayush Vatsa.
Discussion: https://postgr.es/m/CAEZATCWtVUt51B6BjTUQoS4dcNyOBj%2B04ngL7HSH3ehBXTUt%3Dw%40mail.gmail.com
M doc/src/sgml/ref/pg_dump.sgml
Fix comment about cross-checking the varnullingrels
commit : 3cb19f45a3f58fb482999be5fae6ecad74f7fa27
author : Richard Guo <[email protected]>
date : Mon, 10 Jun 2024 13:05:20 +0900
committer: Richard Guo <[email protected]>
date : Mon, 10 Jun 2024 13:05:20 +0900