Stamp 15.7.
commit : 4a53584cf2d676e685d899d01cde18c075fbeca7
author : Tom Lane <[email protected]>
date : Mon, 6 May 2024 16:23:18 -0400
committer: Tom Lane <[email protected]>
date : Mon, 6 May 2024 16:23:18 -0400
M configure
M configure.ac
Last-minute updates for release notes.
commit : 7b2ac0f6039f0f64d80c7488f0f718094cfb89a2
author : Tom Lane <[email protected]>
date : Mon, 6 May 2024 12:27:26 -0400
committer: Tom Lane <[email protected]>
date : Mon, 6 May 2024 12:27:26 -0400
Security: CVE-2024-4317
M doc/src/sgml/release-15.sgml
Fix privilege checks in pg_stats_ext and pg_stats_ext_exprs.
commit : 9cc2b62894de6a8b3d78d20bcd1a6647a7553a6c
author : Nathan Bossart <[email protected]>
date : Mon, 6 May 2024 09:00:13 -0500
committer: Nathan Bossart <[email protected]>
date : Mon, 6 May 2024 09:00:13 -0500
The catalog view pg_stats_ext fails to consider privileges for
expression statistics. The catalog view pg_stats_ext_exprs fails
to consider privileges and row-level security policies. To fix,
restrict the data in these views to table owners or roles that
inherit privileges of the table owner. It may be possible to apply
less restrictive privilege checks in some cases, but that is left
as a future exercise. Furthermore, for pg_stats_ext_exprs, do not
return data for tables with row-level security enabled, as is
already done for pg_stats_ext.
On the back-branches, a fix-CVE-2024-4317.sql script is provided
that will install into the "share" directory. This file can be
used to apply the fix to existing clusters.
Bumps catversion on 'master' branch only.
Reported-by: Lukas Fittl
Reviewed-by: Noah Misch, Tomas Vondra, Tom Lane
Security: CVE-2024-4317
Backpatch-through: 14
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/system-views.sgml
M src/backend/catalog/Makefile
A src/backend/catalog/fix-CVE-2024-4317.sql
M src/backend/catalog/system_views.sql
M src/test/regress/expected/rules.out
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Translation updates
commit : 3672c6cdfd7cb2cb82837cf4a341bf7c0a60bd59
author : Peter Eisentraut <[email protected]>
date : Mon, 6 May 2024 12:10:46 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 6 May 2024 12:10:46 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 141c2cc465bc7bd1e2d43243cf81215b0b14abd4
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/ja.po
M src/backend/po/ru.po
M src/backend/po/uk.po
M src/bin/pg_checksums/po/ru.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_rewind/po/ru.po
M src/bin/psql/po/de.po
M src/bin/psql/po/es.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/de.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/ru.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/ru.po
Release notes for 16.3, 15.7, 14.12, 13.15, 12.19.
commit : ac7049dbf33943d5ecbadfdb0f2091fa4ff88748
author : Tom Lane <[email protected]>
date : Sun, 5 May 2024 13:31:09 -0400
committer: Tom Lane <[email protected]>
date : Sun, 5 May 2024 13:31:09 -0400
M doc/src/sgml/release-15.sgml
Throw a more on-point error for publications depending on columns.
commit : 5f4a1a0a7758bb3bd0cfa58a48a1537bb2c0024b
author : Tom Lane <[email protected]>
date : Thu, 2 May 2024 17:36:31 -0400
committer: Tom Lane <[email protected]>
date : Thu, 2 May 2024 17:36:31 -0400
Same as 42b041243, except that the trouble case is a publication
WHERE clause that depends on a column.
Again reported by Alexander Lakhin. Back-patch to v15 where
we added publication WHERE clauses.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
doc: Fix description of deterministic flag of CREATE COLLATION
commit : da55e4cd1f407d0ea70d505f7aec06c6e1dfe518
author : Peter Eisentraut <[email protected]>
date : Thu, 2 May 2024 08:21:18 +0200
committer: Peter Eisentraut <[email protected]>
date : Thu, 2 May 2024 08:21:18 +0200
The documentation said that you need to pick a suitable LC_COLLATE
setting in addition to setting the DETERMINISTIC flag. This would
have been correct if the libc provider supported nondeterministic
collations, but since it doesn't, you actually need to set the LOCALE
option.
Reviewed-by: Kashif Zeeshan <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/a71023c2-0ae0-45ad-9688-cf3b93d0d65b%40eisentraut.org
M doc/src/sgml/ref/create_collation.sgml
Disable run condition optimization for some WindowFuncs
commit : 7e5d20bbd13fae7522003f7c3655c9165fb1b3e7
author : David Rowley <[email protected]>
date : Wed, 1 May 2024 16:35:37 +1200
committer: David Rowley <[email protected]>
date : Wed, 1 May 2024 16:35:37 +1200
94985c210 added code to detect when WindowFuncs were monotonic and
allowed additional quals to be "pushed down" into the subquery to be
used as WindowClause runConditions in order to short-circuit execution
in nodeWindowAgg.c.
The Node representation of runConditions wasn't well selected and
because we do qual pushdown before planning the subquery, the planning
of the subquery could perform subquery pull-up of nested subqueries.
For WindowFuncs with args, the arguments could be changed after pushing
the qual down to the subquery.
This was made more difficult by the fact that the code duplicated the
WindowFunc inside an OpExpr to include in the WindowClauses runCondition
field. This could result in duplication of subqueries and a pull-up of
such a subquery could result in another initplan parameter being issued
for the 2nd version of the subplan. This could result in errors such as:
ERROR: WindowFunc not found in subplan target lists
Here in the backbranches, we don't have the flexibility to improve the
Node representation to resolve this, so instead we just disable the
runCondition optimization for ntile() unless the argument is a Const,
(v16 only) and likewise for count(expr) (both v15 and v16). count(*) is
unaffected. All other window functions which support this optimization
all take zero arguments and therefore are unaffected.
Bug: #18170
Reported-by: Zuming Jiang
Discussion: https://postgr.es/m/[email protected]
Backpatch-through 15 (master will be fixed independently)
M src/backend/utils/adt/int8.c
M src/backend/utils/adt/windowfuncs.c
M src/test/regress/expected/window.out
M src/test/regress/sql/window.sql
Fix parallel vacuum buffer usage reporting.
commit : faba2f8f35df8cd07cd2205b0bb4815a10c38b14
author : Masahiko Sawada <[email protected]>
date : Wed, 1 May 2024 12:34:01 +0900
committer: Masahiko Sawada <[email protected]>
date : Wed, 1 May 2024 12:34:01 +0900
A parallel worker's buffer usage is accumulated to its pgBufferUsage
and then is accumulated into the leader's one at the end of the
parallel vacuum. However, since the leader process used to use
dedicated VacuumPage{Hit, Miss, Dirty} globals for the buffer usage
reporting, the worker's buffer usage was not included, leading to an
incorrect buffer usage report.
To fix the problem, this commit makes vacuum use pgBufferUsage
instruments for buffer usage reporting instead of VacuumPage{Hit,
Miss, Dirty} globals. These global variables are still used by ANALYZE
command and autoanalyze.
This also fixes the buffer usage report of vacuuming on temporary
tables, since the buffers dirtied by MarkLocalBufferDirty() were not
tracked by the VacuumPageDirty variable.
Parallel vacuum was introduced in 13, but the buffer usage reporting
for VACUUM command with the VERBOSE option was implemented in
15. So backpatch to 15.
Reported-by: Anthonin Bonnefoy
Author: Anthonin Bonnefoy
Reviewed-by: Alena Rybakina, Masahiko Sawada
Discussion: https://postgr.es/m/CAO6_XqrQk+QZQcYs_C6nk0cMfHuUWk85vT9CrcA1NffFbAVE2A@mail.gmail.com
Backpatch-through: 15
M src/backend/access/heap/vacuumlazy.c
Ensure we allocate NAMEDATALEN bytes for names in Index Only Scans
commit : 52f21f928732418b333232a36fb02890f9c87b52
author : David Rowley <[email protected]>
date : Wed, 1 May 2024 13:22:16 +1200
committer: David Rowley <[email protected]>
date : Wed, 1 May 2024 13:22:16 +1200
As an optimization, we store "name" columns as cstrings in btree
indexes.
Here we modify it so that Index Only Scans convert these cstrings back
to names with NAMEDATALEN bytes rather than storing the cstring in the
tuple slot, as was happening previously.
Bug: #17855
Reported-by: Alexander Lakhin
Reviewed-by: Alexander Lakhin, Tom Lane
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12, all supported versions
M src/backend/executor/nodeIndexonlyscan.c
M src/include/catalog/pg_opclass.dat
M src/include/nodes/execnodes.h
M src/test/regress/expected/index_including.out
M src/test/regress/sql/index_including.sql
Disallow converting a table to a view within an outer SQL command.
commit : bf379b555c06034bcd1be384cc145d8264213f41
author : Tom Lane <[email protected]>
date : Tue, 30 Apr 2024 15:22:55 -0400
committer: Tom Lane <[email protected]>
date : Tue, 30 Apr 2024 15:22:55 -0400
We have long disallowed all forms of ALTER TABLE if the table is
already opened by some outer SQL command in the same session.
This has the same purpose as obtaining AccessExclusiveLock, but
since a session's own locks don't conflict the lock only blocks use
of the table by other sessions, not our own. Without this check,
the ALTER might confuse the outer SQL command since any previous
inspection of the table would potentially become invalid.
However, the RelisBecomingView code path in DefineQueryRewrite never
got that memo, and assumed that AccessExclusiveLock is sufficient
for performing something morally equivalent to a rather invasive
ALTER TABLE. Unsurprisingly, this can confuse an outer command
that is trying to do something with the table.
This was submitted as a security issue, but the security team
has been unable to identify any consequence worse than a null
pointer dereference (from trying to access rd_tableam methods
that the relation no longer has). Therefore, in accordance
with our usual policy, it's not security material and should
just be fixed as a routine bug.
Fix by disallowing the operation if the table is open locally,
exactly as ALTER TABLE does it.
Per an anonymous security researcher, via Bundesamt für Sicherheit
in der Informationstechnik.
Patch v12-v15 only. In v16 and later, we removed this code
altogether (cf. commit b23cd185f), so that there's no issue.
M src/backend/rewrite/rewriteDefine.c
Close race condition between datfrozen and relfrozen updates.
commit : 7c5915c4b16c965124a36615ec54cca501a212a9
author : Noah Misch <[email protected]>
date : Mon, 29 Apr 2024 10:24:56 -0700
committer: Noah Misch <[email protected]>
date : Mon, 29 Apr 2024 10:24:56 -0700
vac_update_datfrozenxid() did multiple loads of relfrozenxid and
relminmxid from buffer memory, and it assumed each would get the same
value. Not so if a concurrent vac_update_relstats() did an inplace
update. Commit 2d2e40e3befd8b9e0d2757554537345b15fa6ea2 fixed the same
kind of bug in vac_truncate_clog(). Today's bug could cause the
rel-level field and XIDs in the rel's rows to precede the db-level
field. A cluster having such values should VACUUM affected tables.
Back-patch to v12 (all supported versions).
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/vacuum.c
Throw a more on-point error for functions depending on columns.
commit : 9b41d1d634aa9a3a36a21c5624b25c8475fd51ee
author : Tom Lane <[email protected]>
date : Sun, 28 Apr 2024 14:34:21 -0400
committer: Tom Lane <[email protected]>
date : Sun, 28 Apr 2024 14:34:21 -0400
ALTER COLUMN TYPE wasn't expecting to find any pg_proc objects
depending on the column whose type is to be altered. That indeed
wasn't possible when this code was written, but it is possible
since we introduced new-style SQL function bodies.
It's about as difficult to fix this case as it is to fix dependent
views, and we've been punting on those for years, so I don't feel
too awful about punting for functions too. (I sure wouldn't risk
back-patching such code.) So just throw a more user-facing error.
Also, adjust some of the existing comments to reflect that these
are all pretty much the same issue.
(This patch also fixes it so we will tolerate finding such a
dependency during ALTER COLUMN SET EXPRESSION; in that, we need
not do anything to the function, so no error is wanted. That
problem is new in HEAD.)
Per bug #18449 from Alexander Lakhin. Back-patch to v14 where
we added new-style SQL functions.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
Detect more overflows in timestamp[tz]_pl_interval.
commit : e6e3ee5b7e2346c19824b391bcd1fcc30baee2ec
author : Tom Lane <[email protected]>
date : Sun, 28 Apr 2024 13:42:13 -0400
committer: Tom Lane <[email protected]>
date : Sun, 28 Apr 2024 13:42:13 -0400
In commit 25cd2d640 I (tgl) opined that "The additions of the months
and microseconds fields could also overflow, of course. However,
I believe we need no additional checks there; the existing range
checks should catch such cases". This is demonstrably wrong however
for the microseconds field, and given that discovery it seems prudent
to be paranoid about the months addition as well.
Report and patch by Joseph Koshakow. As before, back-patch to all
supported branches. (However, the test case doesn't work before
v15 because we didn't allow wider-than-int32 numbers in interval
literals. A variant test could probably be built that fits within
that restriction, but it didn't seem worth the trouble.)
Discussion: https://postgr.es/m/CAAvxfHf77sRHKoEzUw9_cMYSpbpNS2C+J_+8Dq4+0oi8iKopeA@mail.gmail.com
M src/backend/utils/adt/timestamp.c
M src/test/regress/expected/horology.out
M src/test/regress/sql/horology.sql
Fix the missing table sync due to improper invalidation handling.
commit : 28a8cc457b022a68b01ae0c12fba73ad16764ec4
author : Amit Kapila <[email protected]>
date : Thu, 25 Apr 2024 10:33:04 +0530
committer: Amit Kapila <[email protected]>
date : Thu, 25 Apr 2024 10:33:04 +0530
We missed performing table sync if the invalidation happened while the
non-ready tables list was being prepared. This occurs because the sync
state was set to valid at the end of non-ready table list preparation
irrespective of the invalidations processed while the list is being
prepared.
Fix it by changing the boolean variable to a tri-state enum and by setting
table state to valid only if no invalidations have occurred while the list
is being prepared.
Reprted-by: Alexander Lakhin
Diagnosed-by: Alexander Lakhin
Author: Vignesh C
Reviewed-by: Hou Zhijie, Alexander Lakhin, Ajin Cherian, Amit Kapila
Backpatch-through: 15
Discussion: https://postgr.es/m/[email protected]
M src/backend/replication/logical/tablesync.c
M src/tools/pgindent/typedefs.list
Doc: fix minor oversight in ALTER DEFAULT PRIVILEGES ref page.
commit : 5e85bc3b0189d01734dcda49e26bd32aff46bcf2
author : Tom Lane <[email protected]>
date : Wed, 24 Apr 2024 10:18:16 -0400
committer: Tom Lane <[email protected]>
date : Wed, 24 Apr 2024 10:18:16 -0400
Since schemas have more than one kind of privilege, we should
use the synopsis form that shows the privilege being possibly
repeated.
Yugo Nagata
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/alter_default_privileges.sgml
doc: Correct jsonpath string literal escapes description
commit : feb19bf5081fba785ba120c365e0b7e8aa85ecaf
author : Peter Eisentraut <[email protected]>
date : Wed, 24 Apr 2024 11:31:47 +0200
committer: Peter Eisentraut <[email protected]>
date : Wed, 24 Apr 2024 11:31:47 +0200
The paragraph describing the JavaScript string literals allowed in
jsonpath expressions unnecessarily mentions JSON by erroneously
listing \v as allowed by JSON and mentioning the \xNN and \u{N...}
backslash escapes as deviations from JSON when in fact both are
accepted by ECMAScript/JavaScript. Fix this by only referring to
JavaScript.
Author: Erik Wienhold <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/[email protected]
M doc/src/sgml/json.sgml
createdb: compare strategy case-insensitive
commit : 276b7888f161bb149217a55008d7f7c17126f9a4
author : Tomas Vondra <[email protected]>
date : Sun, 21 Apr 2024 21:22:11 +0200
committer: Tomas Vondra <[email protected]>
date : Sun, 21 Apr 2024 21:22:11 +0200
When specifying the createdb strategy, the documentation suggests valid
options are FILE_COPY and WAL_LOG, but the code does case-sensitive
comparison and accepts only "file_copy" and "wal_log" as valid.
Fixed by doing a case-insensitive comparison using pg_strcasecmp(), same
as for other string parameters nearby.
While at it, apply fmtId() to a nearby "locale_provider". This already
did the comparison in case-insensitive way, but the value would not be
double-quoted, confusing the parser and the error message.
Backpatch to 15, where the strategy was introduced.
Backpatch-through: 15
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/dbcommands.c
M src/bin/scripts/createdb.c
M src/bin/scripts/t/020_createdb.pl
Make postgres_fdw request remote time zone 'GMT' not 'UTC'.
commit : 6c85e3359be03592c7bf4b66a348153cae4701a4
author : Tom Lane <[email protected]>
date : Sun, 21 Apr 2024 13:46:20 -0400
committer: Tom Lane <[email protected]>
date : Sun, 21 Apr 2024 13:46:20 -0400
This should have the same results for all practical purposes.
The advantage of selecting 'GMT' is that it's guaranteed to work
even when the remote system's timezone database is missing
entries, because pg_tzset() hard-wires handling of that,
at least in 9.2 and later.
(It seems like it would be a good idea to similarly hard-wire
correct handling of 'UTC', but that'll be a little more invasive
than I want to consider back-patching. Leave that for another
day when we're not in feature freeze.)
Per trouble report from Adnan Dautovic. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/[email protected]
M contrib/postgres_fdw/connection.c
createdb: Correct parameter name in SGML docs
commit : 722f17049729600e3a885b1c1d975a0b0fa2e1e4
author : Tomas Vondra <[email protected]>
date : Sat, 20 Apr 2024 18:54:09 +0200
committer: Tomas Vondra <[email protected]>
date : Sat, 20 Apr 2024 18:54:09 +0200
Commit 9c08aea6a309 introduced -S/--strategy option, but forgot to
rename the parameter when copying the -T/--template bit.
M doc/src/sgml/ref/createdb.sgml
Doc: document cases where queryid is stable
commit : 38daca854adbc2980393daab160a2d657bd010d6
author : David Rowley <[email protected]>
date : Sat, 20 Apr 2024 13:54:46 +1200
committer: David Rowley <[email protected]>
date : Sat, 20 Apr 2024 13:54:46 +1200
The documents were clear that queryid should not be assumed to be stable
between major versions but said nothing about minor versions and left
the reader to guess if that was implied by the mention of the
instability of queryid between major versions.
Here we give minor versions an explicit mention to indicate queryid can
generally be assumed stable between minor versions.
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/CAApHDvpYGE6h0cD9UO-eHySPynPj1L3J%3DHxT%2BA7Ud8_Yo6AuzA%40mail.gmail.com
Backpatch-through: 12
M doc/src/sgml/pgstatstatements.sgml
Doc: Remove mention of @ and ~ GiST operators
commit : af715a6f39ad8ab885b1fbfe63672ce0fcb2d662
author : Daniel Gustafsson <[email protected]>
date : Fri, 19 Apr 2024 14:50:10 +0200
committer: Daniel Gustafsson <[email protected]>
date : Fri, 19 Apr 2024 14:50:10 +0200
These operators were removed by 2f70fdb0644c in the v14 cycle but they were
accidentally left in the table of build-in operator classes. Backpatch down
to v14 where the operators where removed.
Author: Aleksander Alekseev <[email protected]>
Reported-by: Colin Caine <[email protected]>
Discussion: https://postgr.es/m/CADwQTQbbr2UQ_fpbyc+8ay=RwEYgYk=TZxH3+RHDqAQfoG+EWA@mail.gmail.com
Backpatch-through: v14
M doc/src/sgml/gist.sgml
Fix MSVC recipe for ecpg regression tests, redux.
commit : f7e8917481b5d84714a1399ede0086a6520bc577
author : Tom Lane <[email protected]>
date : Fri, 19 Apr 2024 01:07:16 -0400
committer: Tom Lane <[email protected]>
date : Fri, 19 Apr 2024 01:07:16 -0400
Forgot to inject -DCMDLINESYM=123 ...
Per buildfarm.
Discussion: https://postgr.es/m/[email protected]
M src/tools/msvc/ecpg_regression.proj
Fix MSVC recipe for ecpg regression tests.
commit : 1e7b1b026d8270d5c70ecc60ecccc748c5d99727
author : Tom Lane <[email protected]>
date : Thu, 18 Apr 2024 20:47:37 -0400
committer: Tom Lane <[email protected]>
date : Thu, 18 Apr 2024 20:47:37 -0400
While back-patching commit 6f0cef935, I forgot that the MSVC
build scripts would also need adjustment in the back branches.
This is a blind attempt at a fix, but it's basically copying
nearby code so I think it will work.
Per buildfarm (via Andrew Dunstan)
Discussion: https://postgr.es/m/[email protected]
M src/tools/msvc/ecpg_regression.proj
Fix assorted bugs in ecpg's macro mechanism.
commit : 25f937217200740d800113953c375691e985f2d3
author : Tom Lane <[email protected]>
date : Tue, 16 Apr 2024 12:31:32 -0400
committer: Tom Lane <[email protected]>
date : Tue, 16 Apr 2024 12:31:32 -0400
The code associated with EXEC SQL DEFINE was unreadable and full of
bugs, notably:
* It'd attempt to free a non-malloced string if the ecpg program
tries to redefine a macro that was defined on the command line.
* Possible memory stomp if user writes "-D=foo".
* Undef'ing or redefining a macro defined on the command line would
change the state visible to the next file, when multiple files are
specified on the command line. (While possibly that could have been
an intentional choice, the code clearly intends to revert to the
original macro state; it's just failing to consider this interaction.)
* Missing "break" in defining a new macro meant that redefinition
of an existing name would cause an extra entry to be added to the
definition list. While not immediately harmful, a subsequent undef
would result in the prior entry becoming visible again.
* The interactions with input buffering are subtle and were entirely
undocumented.
It's not that surprising that we hadn't noticed these bugs,
because there was no test coverage at all of either the -D
command line switch or multiple input files. This patch adds
such coverage (in a rather hacky way I guess).
In addition to the code bugs, the user documentation was confused
about whether the -D switch defines a C macro or an ecpg one, and
it failed to mention that you can write "-Dsymbol=value".
These problems are old, so back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ecpg.sgml
M doc/src/sgml/ref/ecpg-ref.sgml
M src/interfaces/ecpg/preproc/ecpg.c
M src/interfaces/ecpg/preproc/pgc.l
M src/interfaces/ecpg/preproc/type.h
M src/interfaces/ecpg/test/expected/sql-define.c
M src/interfaces/ecpg/test/expected/sql-define.stderr
M src/interfaces/ecpg/test/expected/sql-define.stdout
M src/interfaces/ecpg/test/sql/Makefile
M src/interfaces/ecpg/test/sql/define.pgc
A src/interfaces/ecpg/test/sql/define_prelim.pgc
Fix generation of EC join conditions at the wrong plan level.
commit : 5aacfa64e5dae1a26a5ad5192877683695de2e77
author : Tom Lane <[email protected]>
date : Tue, 16 Apr 2024 11:22:39 -0400
committer: Tom Lane <[email protected]>
date : Tue, 16 Apr 2024 11:22:39 -0400
get_baserel_parampathinfo previously assumed without checking that
the results of generate_join_implied_equalities "necessarily satisfy
join_clause_is_movable_into". This turns out to be wrong in the
presence of outer joins, because the generated clauses could include
Vars that mustn't be evaluated below a relevant outer join. That
led to applying clauses at the wrong plan level and possibly getting
incorrect query results. We must check each clause's nullable_relids,
and really the right thing to do is test join_clause_is_movable_into.
However, trying to fix it that way exposes an oversight in
equivclass.c: it wasn't careful about marking join clauses for
appendrel children with the correct clause_relids. That caused the
modified get_baserel_parampathinfo code to reject some clauses it
still needs to accept. (See parallel commit for HEAD/v16 for more
commentary about that.)
Per bug #18429 from Benoît Ryder. This misbehavior existed for
a long time before commit 2489d76c4, so patch v12-v15 this way.
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/path/equivclass.c
M src/backend/optimizer/util/relnode.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
xml2: Replace deprecated routines with recommended ones
commit : 689ba4f1c4067005af0a71ba0cc52365474c4e4a
author : Michael Paquier <[email protected]>
date : Tue, 16 Apr 2024 12:26:10 +0900
committer: Michael Paquier <[email protected]>
date : Tue, 16 Apr 2024 12:26:10 +0900
Some functions are used in the tree and are currently marked as
deprecated by upstream. This commit refreshes the code to use the
recommended functions, leading to the following changes:
- xmlSubstituteEntitiesDefault() is gone, and needs to be replaced with
XML_PARSE_NOENT for the paths doing the parsing.
- xmlParseMemory() -> xmlReadMemory().
These functions, as well as more functions setting global states, have
been officially marked as deprecated by upstream in August 2022. Their
replacements exist since the 2001-ish area, as far as I have checked,
so that should be safe.
This has been originally applied as 65c5864d7fac without a backpatch,
and this has come up as well when working on 400928b83. Per request
from Tom Lane, for new buildfarm member indri that is able to see
deprecation warnings with xmlSubstituteEntitiesDefault() in 16 and older
stable branches.
Author: Dmitry Koval
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]
Bakpatch-through: 12
M contrib/xml2/xpath.c
M contrib/xml2/xslt_proc.c
Fix type-checking of RECORD-returning functions in FROM, redux.
commit : 09989ba84734c07d045ec379c9424508a52ac604
author : Tom Lane <[email protected]>
date : Mon, 15 Apr 2024 12:56:56 -0400
committer: Tom Lane <[email protected]>
date : Mon, 15 Apr 2024 12:56:56 -0400
Commit 2ed8f9a01 intended to institute a policy that if a
RangeTblFunction has a coldeflist, then the function return type is
certainly RECORD, and we should use the coldeflist as the source of
truth about what the columns of the record type are. When the
original function has been folded to a constant, inspection of the
constant might give a different answer. This situation will lead to
a tuple-type-mismatch error at execution, but up until that point we
need to consistently believe the coldeflist, or we'll have problems
from different bits of code reaching different conclusions.
expandRTE didn't get that memo though, and would try to produce a
tupdesc based on the constant in this situation, leading to an
assertion failure. (Desultory testing suggests that non-assert
builds often manage to give the expected error, although I also
saw a "cache lookup failed for type 0" error, and it seems at
least possible that a crash could happen.)
Some other callers of get_expr_result_type and get_expr_result_tupdesc
were also being incautious about this. While none of them seem to
have actual bugs, they're working harder than necessary in this case,
besides which it seems safest to have an explicit policy of not using
those functions on an RTE with a coldeflist. Adjust the code
accordingly, and add commentary to funcapi.c about this policy.
Also fix an obsolete comment that claimed "get_expr_result_type()
doesn't know how to extract type info from a RECORD constant".
That hasn't been true since commit d57534740.
Per bug #18422 from Alexander Lakhin.
As with the previous commit, back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/catalog/dependency.c
M src/backend/optimizer/prep/prepjointree.c
M src/backend/optimizer/util/clauses.c
M src/backend/parser/parse_relation.c
M src/backend/utils/fmgr/funcapi.c
M src/test/regress/expected/rangefuncs.out
M src/test/regress/sql/rangefuncs.sql
Update nbits_set in brin_bloom_union
commit : 3cd4135119be0dda37ef810353a3ef2e4444970e
author : Tomas Vondra <[email protected]>
date : Sun, 14 Apr 2024 17:58:59 +0200
committer: Tomas Vondra <[email protected]>
date : Sun, 14 Apr 2024 17:58:59 +0200
Properly update the number of bits set in the bitmap after merging the
filters in brin_bloom_union.
This is mostly harmless, as the counter is used only in the output
function, which means pageinspect may show incorrect information about
the BRIN summary. The counter does not affect correctness.
Discovered while adding a regression test comparing indexes built with
and without parallelism. The parallel index builds exercise the union
procedure when merging results from workers, which is otherwise very
hard to do in a test. Which is why this went unnoticed until now.
Backpatch through 14, where the BRIN bloom opclasses were introduced.
Backpatch-through: 14
Discussion: https://postgr.es/m/1df00a66-db5a-4e66-809a-99b386a06d86%40enterprisedb.com
M src/backend/access/brin/brin_bloom.c
freespace: Don't return blocks past the end of the main fork.
commit : 7c490a18b75b895c757a5340c33e05ca44a178f9
author : Noah Misch <[email protected]>
date : Sat, 13 Apr 2024 08:34:20 -0700
committer: Noah Misch <[email protected]>
date : Sat, 13 Apr 2024 08:34:20 -0700
GetPageWithFreeSpace() callers assume the returned block exists in the
main fork, failing with "could not read block" errors if that doesn't
hold. Make that assumption reliable now. It hadn't been guaranteed,
due to the weak WAL and data ordering of participating components. Most
operations on the fsm fork are not WAL-logged. Relation extension is
not WAL-logged. Hence, an fsm-fork block on disk can reference a
main-fork block that no WAL record has initialized. That could happen
after an OS crash, a replica promote, or a PITR restore. wal_log_hints
makes the trouble easier to hit; a replica promote or PITR ending just
after a relevant fsm-fork FPI_FOR_HINT may yield this broken state. The
v16 RelationAddBlocks() mechanism also makes the trouble easier to hit,
since it bulk-extends even without extension lock waiters. Commit
917dc7d2393ce680dea7a59418be9ff341df3c14 stopped trouble around
truncation, but vectors involving PageIsNew() pages remained.
This implementation adds a RelationGetNumberOfBlocks() call when the
cached relation size doesn't confirm a block exists. We've been unable
to identify a benchmark that slows materially, but this may show up as
additional time in lseek(). An alternative without that overhead would
be a new ReadBufferMode such that ReadBufferExtended() returns NULL
after a 0-byte read, with all other errors handled normally. However,
each GetFreeIndexPage() caller would then need code for the return-NULL
case. Back-patch to v14, due to earlier versions not caching relation
size and the absence of a pre-v16 problem report.
Ronan Dunklau. Reported by Ronan Dunklau.
Discussion: https://postgr.es/m/1878547.tdWV9SEqCh%40aivenlaptop
M src/backend/storage/freespace/README
M src/backend/storage/freespace/freespace.c
M src/backend/storage/smgr/smgr.c
M src/test/recovery/t/008_fsm_truncation.pl
Doc: fix bogus to_date() examples.
commit : 268e723b12fad75a8171b2f3fcfaaa7881751911
author : Tom Lane <[email protected]>
date : Thu, 11 Apr 2024 11:09:00 -0400
committer: Tom Lane <[email protected]>
date : Thu, 11 Apr 2024 11:09:00 -0400
November doesn't have 31 days. Remarkably, this thinko
has escaped detection since commit 3f1998727.
Noted by Y. Saburov.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/func.sgml
Fix WaitEventSet resource leak in WaitLatchOrSocket().
commit : b82dca2a5a929c2b65174a073194a9cfb080052f
author : Etsuro Fujita <[email protected]>
date : Thu, 11 Apr 2024 19:05:02 +0900
committer: Etsuro Fujita <[email protected]>
date : Thu, 11 Apr 2024 19:05:02 +0900
This function would have the same issue we solved in commit 501cfd07d:
If an error is thrown after calling CreateWaitEventSet(), the file
descriptor (on epoll- or kqueue-based systems) or handles (on Windows)
that the WaitEventSet contains are leaked.
Like that commit, use PG_TRY-PG_FINALLY (PG_TRY-PG_CATCH in v12) to make
sure the WaitEventSet is freed properly.
Back-patch to all supported versions, but as we do not have this issue
in HEAD (cf. commit 50c67c201), no need to apply this patch to it.
Discussion: https://postgr.es/m/CAPmGK16MqdDoD8oatp8SQWaEa4vS3nfQqDN_Sj9YRuu5J3Lj9g%40mail.gmail.com
M src/backend/storage/ipc/latch.c
Fix plpgsql's handling of -- comments following expressions.
commit : d85db0a8e95cb7284a288d18f6fe48afde65c9f9
author : Tom Lane <[email protected]>
date : Wed, 10 Apr 2024 15:45:59 -0400
committer: Tom Lane <[email protected]>
date : Wed, 10 Apr 2024 15:45:59 -0400
Up to now, read_sql_construct() has collected all the source text from
the statement or expression's initial token up to the character just
before the "until" token. It normally tries to strip trailing
whitespace from that, largely for neatness. If there was a "-- text"
comment after the expression, this resulted in removing the newline
that terminates the comment, which creates a hazard if we try to paste
the collected text into a larger SQL construct without inserting a
newline after it. In particular this caused our handling of CASE
constructs to fail if there's a comment after a WHEN expression.
Commit 4adead1d2 noticed a similar problem with cursor arguments,
and worked around it through the rather crude hack of suppressing
the whitespace-trimming behavior for those. Rather than do that
and leave the hazard open for future hackers to trip over, let's
fix it properly. pl_scanner.c already has enough infrastructure
to report the end location of the expression's last token, so
we can copy up to that location and never collect any trailing
whitespace or comment to begin with.
Erik Wienhold and Tom Lane, per report from Michal Bartak.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAAVzF_FjRoi8fOVuLCZhQJx6HATQ7MKm=aFOHWZODFnLmjX-xA@mail.gmail.com
M src/pl/plpgsql/src/expected/plpgsql_control.out
M src/pl/plpgsql/src/pl_gram.y
M src/pl/plpgsql/src/pl_scanner.c
M src/pl/plpgsql/src/plpgsql.h
M src/pl/plpgsql/src/sql/plpgsql_control.sql
M src/test/regress/expected/plpgsql.out
M src/test/regress/sql/plpgsql.sql
Doc: Update ulinks to RFC documents to avoid redirect
commit : ef124d0952e18f1c7a7e9f99b2d10e2f0737c24a
author : Daniel Gustafsson <[email protected]>
date : Wed, 10 Apr 2024 13:53:25 +0200
committer: Daniel Gustafsson <[email protected]>
date : Wed, 10 Apr 2024 13:53:25 +0200
The tools.ietf.org site has been decommissioned and replaced by a
number of sites serving various purposes. Links to RFCs and BCPs
are now 301 redirected to their new respective IETF sites. Since
this serves no purpose and only adds network overhead, update our
links to the new locations.
Backpatch to all supported versions.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: v12
M doc/src/sgml/acronyms.sgml
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/charset.sgml
M doc/src/sgml/client-auth.sgml
M doc/src/sgml/datatype.sgml
M doc/src/sgml/ecpg.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/json.sgml
M doc/src/sgml/libpq.sgml
M doc/src/sgml/pgcrypto.sgml
M doc/src/sgml/protocol.sgml
M doc/src/sgml/ref/psql-ref.sgml
M doc/src/sgml/textsearch.sgml
M doc/src/sgml/uuid-ossp.sgml
Fix illegal attribute propagation in LLVM JIT.
commit : 74992929a79e2606fbc4d579c3fad04a890eda04
author : Thomas Munro <[email protected]>
date : Wed, 10 Apr 2024 10:46:15 +1200
committer: Thomas Munro <[email protected]>
date : Wed, 10 Apr 2024 10:46:15 +1200
Commit 72559438 started copying more attributes from AttributeTemplate
to the functions we generate on the fly. In the case of deform
functions, which return void, this meant that "noundef", from
AttributeTemplate's return value (a Datum) was copied to a void type.
Older LLVM releases were OK with that, but LLVM 18 crashes.
Update our llvm_copy_attributes() function to skip copying the attribute
for the return value, if the target function returns void.
Thanks to Dmitry Dolgov for help chasing this down.
Back-patch to all supported releases, like 72559438.
Reported-by: Pavel Stehule <[email protected]>
Reviewed-by: Dmitry Dolgov <[email protected]>
Discussion: https://postgr.es/m/CAFj8pRACpVFr7LMdVYENUkScG5FCYMZDDdSGNU-tch%2Bw98OxYg%40mail.gmail.com
M src/backend/jit/llvm/llvmjit.c
doc: Remove stray comma from list of psql options
commit : 6304ee667759852083197c425668ae381ba82c22
author : Daniel Gustafsson <[email protected]>
date : Tue, 9 Apr 2024 23:39:38 +0200
committer: Daniel Gustafsson <[email protected]>
date : Tue, 9 Apr 2024 23:39:38 +0200
Back in 7.2 the list of options had short options and long options
on the same line separated by comma, but since 7.3 they are listed
separate lines. The comma on -X was left behind so fix by removing
and backpatching all the way.
Reported-by: [email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: v12
M doc/src/sgml/ref/psql-ref.sgml
In psql, avoid leaking a PGresult after a query is cancelled.
commit : 4f1d33d707fbdf38296ed8b262ae1ea3dcde2b18
author : Tom Lane <[email protected]>
date : Mon, 8 Apr 2024 17:00:07 -0400
committer: Tom Lane <[email protected]>
date : Mon, 8 Apr 2024 17:00:07 -0400
After a query cancel, the tail end of ExecQueryAndProcessResults
took care to clear any not-yet-read PGresults; but it forgot about
the one it has already read. There would only be such a result
when handling a multi-command string made with "\;", so that you'd
have to cancel an earlier command in such a string to reach the
bug at all. Even then, there would only be leakage of a single
PGresult per cancel, so it's not surprising nobody noticed this.
But a leak is a leak.
Noted while re-reviewing 90f517821, but this is independent of that:
it dates to 7844c9918. Back-patch to v15 where that came in.
M src/bin/psql/common.c
simplehash: Free collisions array in SH_STAT
commit : dcb7cf945c88eabce7f8350023b8184266d96a12
author : Andres Freund <[email protected]>
date : Sun, 7 Apr 2024 19:00:11 -0700
committer: Andres Freund <[email protected]>
date : Sun, 7 Apr 2024 19:00:11 -0700
While SH_STAT() is only used for debugging, the allocated array can be large,
and therefore should be freed.
It's unclear why coverity started warning now.
Reported-by: Tom Lane <[email protected]>
Reported-by: Coverity
Discussion: https://postgr.es/m/[email protected]
Backpatch: 12-
M src/include/lib/simplehash.h
Doc: update documentation about EXCLUDE constraint elements.
commit : e2663a63c3b9459651f9370a971966d4fcfe0332
author : Tom Lane <[email protected]>
date : Sun, 7 Apr 2024 15:36:08 -0400
committer: Tom Lane <[email protected]>
date : Sun, 7 Apr 2024 15:36:08 -0400
What the documentation calls an exclude_element is an index_elem
according to gram.y, and it allows all the same options that
a CREATE INDEX column specification does. The COLLATE patch
neglected to update the CREATE/ALTER TABLE docs about that,
and later the opclass-parameters patch made the same oversight.
Add those options to the syntax synopses, and polish the
associated text a bit.
Back-patch to v13 where opclass parameters came in. We could
update v12 with just the COLLATE omission, but it doesn't quite
seem worth the trouble at this point.
Shihao Zhong, reviewed by Daniel Vérité, Shubham Khanna and myself
Discussion: https://postgr.es/m/CAGRkXqShbVyB8E3gapfdtuwiWTiK=Q67Qb9qwxu=+-w0w46EBA@mail.gmail.com
M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/ref/create_table.sgml
Don't clobber test exit code at cleanup in LDAP/Kerberors tests
commit : a9c20c85c73a41d3736f142743fa1a01df1e04b6
author : Heikki Linnakangas <[email protected]>
date : Sun, 7 Apr 2024 20:21:27 +0300
committer: Heikki Linnakangas <[email protected]>
date : Sun, 7 Apr 2024 20:21:27 +0300
If the test script die()d before running the first test, the whole test
was interpreted as SKIPped rather than failed. The PostgreSQL::Cluster
module got this right.
Backpatch to all supported versions.
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/test/kerberos/t/001_auth.pl
M src/test/ldap/t/001_auth.pl
Improve check in LDAP test to find the OpenLDAP installation
commit : c8df46b65705c87ab5b76cefe1ff69aed72095bf
author : Heikki Linnakangas <[email protected]>
date : Sun, 7 Apr 2024 20:21:21 +0300
committer: Heikki Linnakangas <[email protected]>
date : Sun, 7 Apr 2024 20:21:21 +0300
If the OpenLDAP installation directory is not found, set $setup to 0
so that the LDAP tests are skipped. The macOS checks were already
doing that, but the checks on other OS's were not. While we're at it,
improve the error message when the tests are skipped, to specify
whether the OS is supported at all, or if we just didn't find the
installation directory.
This was accidentally "working" without this, i.e. we were skipping
the tests if the OpenLDAP installation was not found, because of a bug
in the LdapServer test module: the END block clobbered the exit code
so if the script die()s before running the first subtest, the whole
test script was marked as SKIPped. The next commit will fix that bug,
but we need to fix the setup code first.
These checks should probably go into configure/meson, but this is
better than nothing and allows fixing the bug in the END block.
Backpatch to all supported versions.
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/test/ldap/t/001_auth.pl
Fix ecpg's mechanism for detecting unsupported cases in the grammar.
commit : f159f1814156764d20a27b63d334ab302e68e59a
author : Tom Lane <[email protected]>
date : Thu, 4 Apr 2024 15:31:53 -0400
committer: Tom Lane <[email protected]>
date : Thu, 4 Apr 2024 15:31:53 -0400
ecpg wants to emit a warning if it parses a SQL construct that the
backend can parse but will immediately throw a FEATURE_NOT_SUPPORTED
error for. The way it was testing for this was to see if the string
ERRCODE_FEATURE_NOT_SUPPORTED appeared anywhere in the gram.y code.
This is, of course, not nearly good enough, as there are plenty of
rules in gram.y that throw that error only conditionally. There was
a hack dating to 2008 to suppress the warning in one rule that
doesn't even exist anymore, but nothing for other cases we've created
since then. End result was that you could get "unsupported feature
will be passed to server" warnings while compiling perfectly good SQL
code in ecpg. Somehow we'd not heard complaints about this, but
it was exposed by the recent addition of an ecpg test for a SQL/JSON
construct.
To fix, suppress the warning if the rule contains any "if" statement.
Manual comparison of gram.y with the generated preproc.y file shows
that the warning is now emitted only in rules where it's sensible.
This problem has existed for a long time, so back-patch to all
supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/interfaces/ecpg/preproc/parse.pl
Fix bogus coding in ExecAppendAsyncEventWait().
commit : 3f96d113ff84787b490e974d9cd6da69c15687f9
author : Etsuro Fujita <[email protected]>
date : Thu, 4 Apr 2024 17:25:02 +0900
committer: Etsuro Fujita <[email protected]>
date : Thu, 4 Apr 2024 17:25:02 +0900
No configured-by-FDW events would result in "return" directly out of a
PG_TRY block, making the exception stack dangling. Repair.
Oversight in commit 501cfd07d; back-patch to v14, like that commit, but
as we do not have this issue in HEAD (cf. commit 50c67c201), no need to
apply this patch to it.
In passing, improve a comment about the handling of in-process requests
in a postgres_fdw.c function called from this function.
Alexander Pyhalov, with comment adjustment/improvement by me.
Discussion: https://postgr.es/m/425fa29a429b21b0332737c42a4fdc70%40postgrespro.ru
M contrib/postgres_fdw/postgres_fdw.c
M src/backend/executor/nodeAppend.c
Fix the parameters order for TableAmRoutine.relation_copy_for_cluster()
commit : c2faf48fa3b262f57cb999a3ab1e00e8d46176cd
author : Alexander Korotkov <[email protected]>
date : Wed, 3 Apr 2024 21:29:18 +0300
committer: Alexander Korotkov <[email protected]>
date : Wed, 3 Apr 2024 21:29:18 +0300
Specify OldTable first, NewTable second as used by
table_relation_copy_for_cluster() and as implemented in
heapam_relation_copy_for_cluster().
Backpatch to PostgreSQL 12, where TableAmRoutine was introduced.
Discussion: https://postgr.es/m/ME3P282MB3166860D4911AE82F92DF7C5B63F2%40ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM
Author: Japin Li
Reviewed-by: Pavel Borisov
Backpatch-through: 12
M src/include/access/tableam.h
Avoid deadlock during orphan temp table removal.
commit : 4fb56a734d4c40c75ccfd8c4b2948266b8bf6e5d
author : Tom Lane <[email protected]>
date : Tue, 2 Apr 2024 14:59:04 -0400
committer: Tom Lane <[email protected]>
date : Tue, 2 Apr 2024 14:59:04 -0400
If temp tables have dependencies (such as sequences) then it's
possible for autovacuum's cleanup of orphan temp tables to deadlock
against an incoming backend that's trying to clean out the temp
namespace for its own use. That can happen because RemoveTempRelations'
performDeletion call can visit objects within the namespace in
an order different from the order in which a per-table deletion
will visit them.
To fix, observe that performDeletion will begin by taking an exclusive
lock on the temp namespace (even though it won't actually delete it).
So, if we can get a shared lock on the namespace, we can be sure we're
not running concurrently with RemoveTempRelations, while also not
conflicting with ordinary use of the namespace. This requires
introducing a conditional version of LockDatabaseObject, but that's no
big deal. (It's surprising we've got along without that this long.)
Report and patch by Mikhail Zhilin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/postmaster/autovacuum.c
M src/backend/storage/lmgr/lmgr.c
M src/include/storage/lmgr.h
Avoid "unused variable" warning on non-USE_SSL_ENGINE platforms.
commit : 98e427af9f59f2515ed67b97c64c9fec16fa7211
author : Tom Lane <[email protected]>
date : Mon, 1 Apr 2024 19:01:18 -0400
committer: Tom Lane <[email protected]>
date : Mon, 1 Apr 2024 19:01:18 -0400
If we are building with openssl but USE_SSL_ENGINE didn't get set,
initialize_SSL's variable "pkey" is declared but used nowhere.
Apparently this combination hasn't been exercised in the buildfarm
before now, because I've not seen this warning before, even though
the code has been like this a long time. Move the declaration
to silence the warning (and remove its useless initialization).
Per buildfarm member sawshark. Back-patch to all supported branches.
M src/interfaces/libpq/fe-secure-openssl.c
Avoid possible longjmp-induced logic error in PLy_trigger_build_args.
commit : 08bdf0a4798bbbbc401bd951cd9553f3c6de2de7
author : Tom Lane <[email protected]>
date : Mon, 1 Apr 2024 15:15:03 -0400
committer: Tom Lane <[email protected]>
date : Mon, 1 Apr 2024 15:15:03 -0400
The "pltargs" variable wasn't marked volatile, which makes it unsafe
to change its value within the PG_TRY block. It looks like the worst
outcome would be to fail to release a refcount on Py_None during an
(improbable) error exit, which would likely go unnoticed in the field.
Still, it's a bug. A one-liner fix could be to mark pltargs volatile,
but on the whole it seems cleaner to arrange things so that we don't
change its value within PG_TRY.
Per report from Xing Guo. This has been there for quite awhile,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/CACpMh+DLrk=fDv07MNpBT4J413fDAm+gmMXgi8cjPONE+jvzuw@mail.gmail.com
M src/pl/plpython/plpy_exec.c
Fix unnecessary use of moving-aggregate mode with non-moving frame.
commit : 03561a6c7bbfe305b941d46f7bafb3cdd4793982
author : Tom Lane <[email protected]>
date : Wed, 27 Mar 2024 13:39:03 -0400
committer: Tom Lane <[email protected]>
date : Wed, 27 Mar 2024 13:39:03 -0400
When a plain aggregate is used as a window function, and the window
frame start is specified as UNBOUNDED PRECEDING, the frame's head
cannot move so we do not need to use moving-aggregate mode. The check
for that was put into initialize_peragg(), failing to notice that
ExecInitWindowAgg() calls that function before it's filled in
winstate->frameOptions. Since makeNode() would have zeroed the field,
this didn't provoke uninitialized-value complaints, nor would the
erroneous decision have resulted in more than a little inefficiency.
Still, it's wrong, so move the initialization of
winstate->frameOptions earlier to make it work properly.
While here, also fix a thinko in a comment. Both errors crept in in
commit a9d9acbf2 which introduced the moving-aggregate mode.
Spotted by Vallimaharajan G. Back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/executor/nodeWindowAgg.c
Fix failure of ALTER FOREIGN TABLE SET SCHEMA to move sequences.
commit : b48eda4e54810aa1d8dd2af7c6763fd414d8e0a1
author : Tom Lane <[email protected]>
date : Tue, 26 Mar 2024 15:28:16 -0400
committer: Tom Lane <[email protected]>
date : Tue, 26 Mar 2024 15:28:16 -0400
Ordinary ALTER TABLE SET SCHEMA will also move any owned sequences
into the new schema. We failed to do likewise for foreign tables,
because AlterTableNamespaceInternal believed that only certain
relkinds could have indexes, owned sequences, or constraints.
We could simply add foreign tables to that relkind list, but it
seems likely that the same oversight could be made again in
future. Instead let's remove the relkind filter altogether.
These functions shouldn't cost much when there are no objects
that they need to process, and surely this isn't an especially
performance-critical case anyway.
Per bug #18407 from Vidushi Gupta. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_data.out
M src/test/regress/sql/foreign_data.sql
Allow "make check"-style testing to work with musl C library.
commit : 3c3f4fd741d0c795470a61d12c285af9acdcea0e
author : Tom Lane <[email protected]>
date : Tue, 26 Mar 2024 11:44:49 -0400
committer: Tom Lane <[email protected]>
date : Tue, 26 Mar 2024 11:44:49 -0400
The musl dynamic linker saves a pointer to the process' environment
value of LD_LIBRARY_PATH very early in startup. When we move/clobber
the environment to make more room for ps status strings, we clobber
that value and thereby prevent libraries from being found via
LD_LIBRARY_PATH, which breaks the use of a temporary installation
for testing purposes. To fix, stop collecting usable space for
ps status if we notice that the variable we are about to clobber
is LD_LIBRARY_PATH. This will result in some reduction in how long
the ps status can be, but it's only likely to occur in temporary
test contexts, so it doesn't seem like a big problem. In any case,
we don't have to do it if we see we are on glibc, which surely is
where the majority of our Linux testing is done.
Thomas Munro, Bruce Momjian, and Tom Lane, per report from Wolfgang
Walther. Back-patch to all supported branches, with the hope that
we'll set up a buildfarm animal to test on this platform.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/misc/ps_status.c
ci: macos: Choose python version
commit : 897efe0f39bee8ced11871ac65cc8d28d9b8ea1e
author : Andres Freund <[email protected]>
date : Mon, 25 Mar 2024 13:06:58 -0700
committer: Andres Freund <[email protected]>
date : Mon, 25 Mar 2024 13:06:58 -0700
The CI base image used to have a python3 with headers etc installed in PATH,
but doesn't anymore. Instead of relying on a specific version in the base
image, explicitly install one ourselves.
On 16 and HEAD this lead to a build without python support, but on 15 CI
failed, due to explicitly enabled python3 support.
M .cirrus.tasks.yml
Clarify comment for LogicalTapeSetBlocks().
commit : b74e4a08b9835e18a14fd3f23e19ddd460ed5b88
author : Jeff Davis <[email protected]>
date : Mon, 25 Mar 2024 11:51:44 -0700
committer: Jeff Davis <[email protected]>
date : Mon, 25 Mar 2024 11:51:44 -0700
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 13
M src/backend/utils/sort/logtape.c
amcheck: Normalize index tuples containing uncompressed varlena
commit : 0d466bce9ee19a5f7ef6c2964376aa6572ef76fd
author : Alexander Korotkov <[email protected]>
date : Sat, 23 Mar 2024 23:00:06 +0200
committer: Alexander Korotkov <[email protected]>
date : Sat, 23 Mar 2024 23:00:06 +0200
It might happen that the varlena value wasn't compressed by index_form_tuple()
due to current storage parameters. If compression is currently enabled, we
need to compress such values to match index tuple coming from the heap.
Backpatch to all supported versions.
Discussion: https://postgr.es/m/flat/7bdbe559-d61a-4ae4-a6e1-48abdf3024cc%40postgrespro.ru
Author: Andrey Borodin
Reviewed-by: Alexander Lakhin, Michael Zhilin, Jian He, Alexander Korotkov
Backpatch-through: 12
M contrib/amcheck/expected/check_btree.out
M contrib/amcheck/sql/check_btree.sql
M contrib/amcheck/verify_nbtree.c
amcheck: Support for different header sizes of short varlena datum
commit : 54e6184db3613e868ca7f042aebe69393fd73b96
author : Alexander Korotkov <[email protected]>
date : Sat, 23 Mar 2024 22:59:56 +0200
committer: Alexander Korotkov <[email protected]>
date : Sat, 23 Mar 2024 22:59:56 +0200
In the heap, tuples may contain short varlena datum with both 1B header and 4B
headers. But the corresponding index tuple should always have such varlena's
with 1B headers. So, for fingerprinting, we need to convert.
Backpatch to all supported versions.
Discussion: https://postgr.es/m/flat/7bdbe559-d61a-4ae4-a6e1-48abdf3024cc%40postgrespro.ru
Author: Michael Zhilin
Reviewed-by: Alexander Lakhin, Andrey Borodin, Jian He, Alexander Korotkov
Backpatch-through: 12
M contrib/amcheck/expected/check_btree.out
M contrib/amcheck/sql/check_btree.sql
M contrib/amcheck/verify_nbtree.c
Fix dumping role comments when using --no-role-passwords
commit : 12128be623fdfd1f15167a477d7de46744fb9bca
author : Daniel Gustafsson <[email protected]>
date : Thu, 21 Mar 2024 23:31:57 +0100
committer: Daniel Gustafsson <[email protected]>
date : Thu, 21 Mar 2024 23:31:57 +0100
Commit 9a83d56b38c added support for allowing pg_dumpall to dump
roles without including passwords, which accidentally made dumps
omit COMMENTs on roles. This fixes it by using pg_authid to get
the comment.
Backpatch to all supported versions. Patch simultaneously written
independently by Álvaro and myself.
Author: Álvaro Herrera <[email protected]>
Author: Daniel Gustafsson <[email protected]>
Reported-by: Bartosz Chroł <[email protected]>
Discussion: https://postgr.es/m/AS8P194MB1271CDA0ADCA7B75FCD8E767F7332@AS8P194MB1271.EURP194.PROD.OUTLOOK.COM
Discussion: https://postgr.es/m/CAEP4nAz9V4H41_4ESJd1Gf0v%3DdevkqO1%3Dpo91jUw-GJSx8Hxqg%40mail.gmail.com
Backpatch-through: v12
M src/bin/pg_dump/pg_dumpall.c
Review wording on tablespaces w.r.t. partitioned tables
commit : ea299d78251144a99f9fe16cd619386919f8312b
author : Alvaro Herrera <[email protected]>
date : Wed, 20 Mar 2024 15:28:14 +0100
committer: Alvaro Herrera <[email protected]>
date : Wed, 20 Mar 2024 15:28:14 +0100
Remove a redundant comment, and document pg_class.reltablespace properly
in catalogs.sgml.
After commits a36c84c3e4a9, 87259588d0ab and others.
Backpatch to 12.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/catalogs.sgml
M src/backend/commands/tablecmds.c
Fix EXPLAIN Bitmap heap scan to count pages with no visible tuples
commit : d3d95f5839952d5bfa089a318a9d11809eb48ac2
author : Heikki Linnakangas <[email protected]>
date : Mon, 18 Mar 2024 14:04:17 +0200
committer: Heikki Linnakangas <[email protected]>
date : Mon, 18 Mar 2024 14:04:17 +0200
Previously, bitmap heap scans only counted lossy and exact pages for
explain when there was at least one visible tuple on the page.
heapam_scan_bitmap_next_block() returned true only if there was a
"valid" page with tuples to be processed. However, the lossy and exact
page counters in EXPLAIN should count the number of pages represented
in a lossy or non-lossy way in the constructed bitmap, regardless of
whether or not the pages ultimately contained visible tuples.
Backpatch to all supported versions.
Author: Melanie Plageman
Discussion: https://www.postgresql.org/message-id/CAAKRu_ZwCwWFeL_H3ia26bP2e7HiKLWt0ZmGXPVwPO6uXq0vaA@mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAAKRu_bxrXeZ2rCnY8LyeC2Ls88KpjWrQ%[email protected]
M src/backend/executor/nodeBitmapHeapscan.c
M src/test/regress/expected/partition_prune.out
Fix EXPLAIN output for subplans in MERGE.
commit : 89ee14a2f22b2353a6cf9d193c54504b4d3131f5
author : Dean Rasheed <[email protected]>
date : Sun, 17 Mar 2024 10:20:20 +0000
committer: Dean Rasheed <[email protected]>
date : Sun, 17 Mar 2024 10:20:20 +0000
Given a subplan in a MERGE query, EXPLAIN would sometimes fail to
properly display expressions involving Params referencing variables in
other parts of the plan tree.
This would affect subplans outside the topmost join plan node, for
which expansion of Params would go via the top-level ModifyTable plan
node. The problem was that "inner_tlist" for the ModifyTable node's
deparse_namespace was set to the join node's targetlist, but
"inner_plan" was set to the ModifyTable node itself, rather than the
join node, leading to incorrect results when descending to the
referenced variable.
Fix and backpatch to v15, where MERGE was introduced.
Discussion: https://postgr.es/m/CAEZATCWAv-sZuH%2BwG5xJ-%2BGt7qGNGX8wUQd3XYydMFDKgRB9nw%40mail.gmail.com
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/merge.out
M src/test/regress/sql/merge.sql
Make INSERT-from-multiple-VALUES-rows handle domain target columns.
commit : 7c61d23422afece255ed47c84876fb062f40d451
author : Tom Lane <[email protected]>
date : Thu, 14 Mar 2024 14:57:16 -0400
committer: Tom Lane <[email protected]>
date : Thu, 14 Mar 2024 14:57:16 -0400
Commit a3c7a993d fixed some cases involving target columns that are
arrays or composites by applying transformAssignedExpr to the VALUES
entries, and then stripping off any assignment ArrayRefs or
FieldStores that the transformation added. But I forgot about domains
over arrays or composites :-(. Such cases would either fail with
surprising complaints about mismatched datatypes, or insert unexpected
coercions that could lead to odd results. To fix, extend the
stripping logic to get rid of CoerceToDomain if it's atop an ArrayRef
or FieldStore.
While poking at this, I realized that there's a poorly documented and
not-at-all-tested behavior nearby: we coerce each VALUES column to
the domain type separately, and rely on the rewriter to merge those
operations so that the domain constraints are checked only once.
If that merging did not happen, it's entirely possible that we'd get
unexpected domain constraint failures due to checking a
partially-updated container value. There's no bug there, but while
we're here let's improve the commentary about it and add some test
cases that explicitly exercise that behavior.
Per bug #18393 from Pablo Kharo. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/parser/analyze.c
M src/backend/parser/parse_target.c
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/insert.out
M src/test/regress/sql/insert.sql
doc: Improve a couple of places in the MERGE docs.
commit : a875743ff40226f4096140efc506bd909da2a21f
author : Dean Rasheed <[email protected]>
date : Wed, 13 Mar 2024 13:12:37 +0000
committer: Dean Rasheed <[email protected]>
date : Wed, 13 Mar 2024 13:12:37 +0000
In the synopsis, make the syntax for merge_update consistent with the
syntax for a plain UPDATE command. It was missing the optional "ROW"
keyword that can be used in a multi-column assignment, and the option
to assign from a multi-column subquery, both of which have been
supported by MERGE since it was introduced.
In the parameters section for the with_query parameter, mention that
WITH RECURSIVE isn't supported, since this is different from plain
INSERT, UPDATE, and DELETE commands. While at it, move that entry to
the top of the list, for consistency with the other pages.
Back-patch to v15, where MERGE was introduced.
Discussion: https://postgr.es/m/CAEZATCWoQyWkMFfu7JXXQr8dA6%3DgxjhYzgpuBP2oz0QoJTxGWw%40mail.gmail.com
M doc/src/sgml/ref/merge.sgml
Fix confusion about the return rowtype of SQL-language procedures.
commit : 6f66fadad91b61f2f3415aafe14f52c2e5e6ad88
author : Tom Lane <[email protected]>
date : Tue, 12 Mar 2024 18:16:10 -0400
committer: Tom Lane <[email protected]>
date : Tue, 12 Mar 2024 18:16:10 -0400
There is a very ancient hack in check_sql_fn_retval that allows a
single SELECT targetlist entry of composite type to be taken as
supplying all the output columns of a function returning composite.
(This is grotty and fundamentally ambiguous, but it's really hard
to do nested composite-returning functions without it.)
As far as I know, that doesn't cause any problems in ordinary
functions. It's disastrous for procedures however. All procedures
that have any output parameters are labeled with prorettype RECORD,
and the CALL code expects it will get back a record with one column
per output parameter, regardless of whether any of those parameters
is composite. Doing something else leads to an assertion failure
or core dump.
This is simple enough to fix: we just need to not apply that rule
when considering procedures. However, that requires adding another
argument to check_sql_fn_retval, which at least in principle might be
getting called by external callers. Therefore, in the back branches
convert check_sql_fn_retval into an ABI-preserving wrapper around a
new function check_sql_fn_retval_ext.
Per report from Yahor Yuzefovich. This has been broken since we
implemented procedures, so back-patch to all supported branches.
Discussion: https://postgr.es/m/CABz5gWHSjj2df6uG0NRiDhZ_Uz=Y8t0FJP-_SVSsRsnrQT76Gg@mail.gmail.com
M src/backend/catalog/pg_proc.c
M src/backend/executor/functions.c
M src/backend/optimizer/util/clauses.c
M src/include/executor/functions.h
M src/test/regress/expected/create_procedure.out
M src/test/regress/sql/create_procedure.sql
Disconnect if socket cannot be put into non-blocking mode
commit : 4fce5f970d584114ba9f981b367eb7720621cc50
author : Heikki Linnakangas <[email protected]>
date : Tue, 12 Mar 2024 10:18:32 +0200
committer: Heikki Linnakangas <[email protected]>
date : Tue, 12 Mar 2024 10:18:32 +0200
Commit 387da18874 moved the code to put socket into non-blocking mode
from socket_set_nonblocking() into the one-time initialization
function, pq_init(). In socket_set_nonblocking(), there indeed was a
risk of recursion on failure like the comment said, but in pq_init(),
ERROR or FATAL is fine. There's even another elog(FATAL) just after
this, if setting FD_CLOEXEC fails.
Note that COMMERROR merely logged the error, it did not close the
connection, so if putting the socket to non-blocking mode failed we
would use the connection anyway. You might not immediately notice,
because most socket operations in a regular backend wait for the
socket to become readable/writable anyway. But e.g. replication will
be quite broken.
Backpatch to all supported versions.
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/backend/libpq/pqcomm.c
doc: add missing word "the"
commit : 68ec19305ec1ef538c1deffd2575da8083c9f034
author : Bruce Momjian <[email protected]>
date : Mon, 11 Mar 2024 13:31:13 -0400
committer: Bruce Momjian <[email protected]>
date : Mon, 11 Mar 2024 13:31:13 -0400
Reported-by: [email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M doc/src/sgml/high-availability.sgml
Fix incorrect accessing of pfree'd memory in Memoize
commit : 74530804fcb7a36175fa1268928cba98aa9e6cff
author : David Rowley <[email protected]>
date : Mon, 11 Mar 2024 18:21:23 +1300
committer: David Rowley <[email protected]>
date : Mon, 11 Mar 2024 18:21:23 +1300
For pass-by-reference types, the code added in 0b053e78b, which aimed to
resolve a memory leak, was overly aggressive in resetting the per-tuple
memory context which could result in pfree'd memory being accessed
resulting in failing to find previously cached results in the hash
table.
What was happening was prepare_probe_slot() was switching to the
per-tuple memory context and calling ExecEvalExpr(). ExecEvalExpr() may
have required a memory allocation. Both MemoizeHash_hash() and
MemoizeHash_equal() were aggressively resetting the per-tuple context
and after determining the hash value, the context would have gotten reset
before MemoizeHash_equal() was called. This could have resulted in
MemoizeHash_equal() looking at pfree'd memory.
This is less likely to have caused issues on a production build as some
other allocation would have had to have reused the pfree'd memory to
overwrite it. Otherwise, the original contents would have been intact.
However, this clearly caused issues on MEMORY_CONTEXT_CHECKING builds.
Author: Tender Wang, Andrei Lepikhov
Reported-by: Tender Wang (using SQLancer)
Reviewed-by: Andrei Lepikhov, Richard Guo, David Rowley
Discussion: https://postgr.es/m/CAHewXNnT6N6UJkya0z-jLFzVxcwGfeRQSfhiwA+NyLg-x8iGew@mail.gmail.com
Backpatch-through: 14, where Memoize was added
M src/backend/executor/nodeMemoize.c
M src/test/regress/expected/memoize.out
M src/test/regress/sql/memoize.sql
Backpatch missing check_stack_depth() to some recursive functions
commit : 84788ee5b4ee5a7ee7543c8dce9f270101f352f1
author : Alexander Korotkov <[email protected]>
date : Fri, 16 Feb 2024 16:02:00 +0200
committer: Alexander Korotkov <[email protected]>
date : Fri, 16 Feb 2024 16:02:00 +0200
Backpatch changes from d57b7cc333, 75bcba6cbd to all supported branches per
proposal of Egor Chindyaskin.
Discussion: https://postgr.es/m/DE5FD776-A8CD-4378-BCFA-3BF30F1F6D60%40mail.ru
M src/backend/catalog/dependency.c
M src/backend/catalog/heap.c
M src/backend/commands/tablecmds.c
M src/backend/optimizer/util/clauses.c
M src/backend/utils/adt/jsonpath_exec.c
Fix deparsing of Consts in postgres_fdw ORDER BY
commit : ab64b275ad8f3bd15a3aa77308620fad80e07b62
author : David Rowley <[email protected]>
date : Mon, 11 Mar 2024 12:28:11 +1300
committer: David Rowley <[email protected]>
date : Mon, 11 Mar 2024 12:28:11 +1300
For UNION ALL queries where a union child query contained a foreign
table, if the targetlist of that query contained a constant, and the
top-level query performed an ORDER BY which contained the column for the
constant value, then postgres_fdw would find the EquivalenceMember with
the Const and then try to produce an ORDER BY containing that Const.
This caused problems with INT typed Consts as these could appear to be
requests to order by an ordinal column position rather than the constant
value. This could lead to either an error such as:
ERROR: ORDER BY position <int const> is not in select list
or worse, if the constant value is a valid column, then we could just
sort by the wrong column altogether.
Here we fix this issue by just not including these Consts in the ORDER
BY clause.
In passing, add a new section for testing ORDER BY in the postgres_fdw
tests and move two existing tests which were misplaced in the WHERE
clause testing section into it.
Reported-by: Michał Kłeczek
Reviewed-by: Ashutosh Bapat, Richard Guo
Bug: #18381
Discussion: https://postgr.es/m/0714C8B8-8D82-4ABB-9F8D-A0C3657E7B6E%40kleczek.org
Discussion: https://postgr.es/m/18381-137456acd168bf93%40postgresql.org
Backpatch-through: 12, oldest supported version
M contrib/postgres_fdw/deparse.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
Cope with a deficiency in OpenSSL 3.x's error reporting.
commit : 0fe82e45cbedbe840f00d834cc6cae55593ef8cf
author : Tom Lane <[email protected]>
date : Thu, 7 Mar 2024 19:37:51 -0500
committer: Tom Lane <[email protected]>
date : Thu, 7 Mar 2024 19:37:51 -0500
In OpenSSL 3.0.0 and later, ERR_reason_error_string randomly refuses
to provide a string for error codes representing system errno values
(e.g., "No such file or directory"). There is a poorly-documented way
to extract the errno from the SSL error code in this case, so do that
and apply strerror, rather than falling back to reporting the error
code's numeric value as we were previously doing.
Problem reported by David Zhang, although this is not his proposed
patch; it's instead based on a suggestion from Heikki Linnakangas.
Back-patch to all supported branches, since any of them are likely
to be used with recent OpenSSL.
Discussion: https://postgr.es/m/[email protected]
M src/backend/libpq/be-secure-openssl.c
M src/interfaces/libpq/fe-secure-openssl.c
Fix handling of self-modified tuples in MERGE.
commit : b5c645d2a2652070ac128a42cf0d7b34403a6cfe
author : Dean Rasheed <[email protected]>
date : Thu, 7 Mar 2024 09:53:31 +0000
committer: Dean Rasheed <[email protected]>
date : Thu, 7 Mar 2024 09:53:31 +0000
When an UPDATE or DELETE action in MERGE returns TM_SelfModified,
there are 2 possible causes:
1). The target tuple was already updated or deleted by the current
command. This can happen if the target row joins to more than one
source row, and the SQL standard explicitly says that this must be
an error.
2). The target tuple was already updated or deleted by a later command
in the current transaction. This can happen if the tuple is
modified by a BEFORE trigger or a volatile function used in the
query, and should be an error for the same reason that it is in a
plain UPDATE or DELETE command.
In MERGE's primary error handling block, it failed to check for (2),
causing it to return a misleading error message in such cases.
In the secondary error handling block, following a concurrent update
from another session, it failed to check for (1), causing it to
silently ignore target rows joined to more than one source row,
instead of reporting an error.
Fix this, and add tests for both of these cases.
Per report from Wenjiang Zhang. Back-patch to v15, where MERGE was
introduced.
Discussion: https://postgr.es/m/tencent_41DE0FF443FE14B94A5898D373792109E408%40qq.com
M src/backend/executor/nodeModifyTable.c
M src/test/isolation/expected/merge-update.out
M src/test/isolation/specs/merge-update.spec
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
Revert "Fix parallel-safety check of expressions and predicate for index builds"
commit : e82b64a92cf5650e618b26b85ca5c0f090286bb4
author : Michael Paquier <[email protected]>
date : Thu, 7 Mar 2024 08:31:04 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 7 Mar 2024 08:31:04 +0900
This reverts commit eae7be600be7, following a discussion with Tom Lane,
due to concerns that this impacts the decisions made by the planner for
the number of workers spawned based on the inlining and const-folding of
index expressions and predicate for cases that would have worked until
this commit.
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M src/backend/optimizer/plan/planner.c
M src/backend/utils/cache/lsyscache.c
M src/include/utils/lsyscache.h
M src/test/regress/expected/btree_index.out
M src/test/regress/sql/btree_index.sql
Fix type-checking of RECORD-returning functions in FROM.
commit : 3b671dcf53d1e1f5a08f8a4cd204207a8c1a065e
author : Tom Lane <[email protected]>
date : Wed, 6 Mar 2024 14:41:13 -0500
committer: Tom Lane <[email protected]>
date : Wed, 6 Mar 2024 14:41:13 -0500
In the corner case where a function returning RECORD has been
simplified to a RECORD constant or an inlined ROW() expression,
ExecInitFunctionScan failed to cross-check the function's result
rowtype against the coldeflist provided by the calling query.
That happened because get_expr_result_type is able to extract a
tupdesc from such expressions, which led ExecInitFunctionScan to
ignore the coldeflist. (Instead, it used the extracted tupdesc
to check the function's output, which of course always succeeds.)
I have not been able to demonstrate any really serious consequences
from this, because if some column of the result is of the wrong
type and is directly referenced by a Var of the calling query,
CheckVarSlotCompatibility will catch it. However, we definitely do
fail to report the case where the function returns more columns than
the coldeflist expects, and in the converse case where it returns
fewer columns, we get an assert failure (but, seemingly, no worse
results in non-assert builds).
To fix, always build the expected tupdesc from the coldeflist if there
is one, and consult get_expr_result_type only when there isn't one.
Also remove the failing Assert, even though it is no longer reached
after this fix. It doesn't seem to be adding anything useful, since
later checking will deal with cases with the wrong number of columns.
The only other place I could find that is doing something similar
is inline_set_returning_function. There's no live bug there because
we cannot be looking at a Const or RowExpr, but for consistency
change that code to agree with ExecInitFunctionScan.
Per report from PetSerAl. After some debate I've concluded that
this should be back-patched. There is a small risk that somebody
has been relying on such a case not throwing an error, but I judge
this outweighed by the risk that I've missed some way in which the
failure to cross-check has worse consequences than sketched above.
Discussion: https://postgr.es/m/CAKygsHSerA1eXsJHR9wft3Gn3wfHQ5RfP8XHBzF70_qcrrRvEg@mail.gmail.com
M src/backend/executor/nodeFunctionscan.c
M src/backend/optimizer/util/clauses.c
M src/test/regress/expected/rangefuncs.out
M src/test/regress/sql/rangefuncs.sql
Fix parallel-safety check of expressions and predicate for index builds
commit : 50b5913a87c9c2d67330d82429f6dda61441d40c
author : Michael Paquier <[email protected]>
date : Wed, 6 Mar 2024 17:24:06 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 6 Mar 2024 17:24:06 +0900
As coded, the planner logic that calculates the number of parallel
workers to use for a parallel index build uses expressions and
predicates from the relcache, which are flattened for the planner by
eval_const_expressions().
As reported in the bug, an immutable parallel-unsafe function flattened
in the relcache would become a Const, which would be considered as
parallel-safe, even if the predicate or the expressions including the
function are not safe in parallel workers. Depending on the expressions
or predicate used, this could cause the parallel build to fail.
Tests are included that check parallel index builds with parallel-unsafe
predicate and expressions. Two routines are added to lsyscache.h to be
able to retrieve expressions and predicate of an index from its pg_index
data.
Reported-by: Alexander Lakhin
Author: Tender Wang
Reviewed-by: Jian He, Michael Paquier
Discussion: https://postgr.es/m/CAHewXN=UaAaNn9ruHDH3Os8kxLVmtWqbssnf=dZN_s9=evHUFA@mail.gmail.com
Backpatch-through: 12
M src/backend/optimizer/plan/planner.c
M src/backend/utils/cache/lsyscache.c
M src/include/utils/lsyscache.h
M src/test/regress/expected/btree_index.out
M src/test/regress/sql/btree_index.sql
Fix incorrectly reported stats kind in "can't happen" ERROR
commit : 164fe7a6e1f34a56d91c0130daddbbe6a8e8392f
author : David Rowley <[email protected]>
date : Tue, 5 Mar 2024 16:18:19 +1300
committer: David Rowley <[email protected]>
date : Tue, 5 Mar 2024 16:18:19 +1300
The error message(s) were reporting the stats kind of 'f', which is not
correct as that's for the "dependencies" statistics kind.
Reported-by: Horst Reiterer
Reviewed-by: Richard Guo
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12, where MCV extended stats were added.
M src/backend/statistics/extended_stats.c
M src/backend/statistics/mcv.c
Fix integer underflow in shared memory debugging
commit : 55ea12a2827791b7fb3f30b207a122a35df951d8
author : Daniel Gustafsson <[email protected]>
date : Thu, 29 Feb 2024 12:19:52 +0100
committer: Daniel Gustafsson <[email protected]>
date : Thu, 29 Feb 2024 12:19:52 +0100
dsa_dump would print a large negative number instead of zero for
segment bin 0. Fix by explicitly checking for underflow and add
special case for bin 0. Backpatch to all supported versions.
Author: Ian Ilyasov <[email protected]>
Reviewed-by: Robert Haas <[email protected]>
Discussion: https://postgr.es/m/GV1P251MB1004E0D09D117D3CECF9256ECD502@GV1P251MB1004.EURP251.PROD.OUTLOOK.COM
Backpatch-through: v12
M src/backend/utils/mmgr/dsa.c
Fix mis-rounding and overflow hazards in date_bin().
commit : db8855b66f5cfd9761b1763fdc6b8d93179607df
author : Tom Lane <[email protected]>
date : Wed, 28 Feb 2024 14:00:30 -0500
committer: Tom Lane <[email protected]>
date : Wed, 28 Feb 2024 14:00:30 -0500
In the case where the target timestamp is before the origin timestamp
and their difference is already an exact multiple of the stride, the
code incorrectly subtracted the stride anyway.
Also detect several integer-overflow cases that previously produced
bogus results. (The submitted patch tried to avoid overflow, but
I'm not convinced it's right, and problematic cases are so far out of
the plausibly-useful range that they don't seem worth sweating over.
Let's just use overflow-detecting arithmetic and throw errors.)
timestamp_bin() and timestamptz_bin() are basically identical and
so had identical bugs. Fix both.
Report and patch by Moaaz Assali, adjusted some by me. Back-patch
to v14 where date_bin() was introduced.
Discussion: https://postgr.es/m/CALkF+nvtuas-2kydG-WfofbRSJpyODAJWun==W-yO5j2R4meqA@mail.gmail.com
M src/backend/utils/adt/timestamp.c
M src/test/regress/expected/timestamp.out
M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/timestamp.sql
M src/test/regress/sql/timestamptz.sql
Revise MERGE documentation
commit : 172d7f7e666ee0612b7d56d7b73a7ebc98476a66
author : Alvaro Herrera <[email protected]>
date : Mon, 26 Feb 2024 18:19:03 +0100
committer: Alvaro Herrera <[email protected]>
date : Mon, 26 Feb 2024 18:19:03 +0100
Add a note about the additional privileges required after the fix in
4989ce72644b (wording per Tom Lane); also change marked-up mentions of
"target_table_name" to be simply "the target table" or the like. Also,
note that "join_condition" is scouted for requisite privileges.
Backpatch to 15.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/merge.sgml
Back-patch test modifications that were done as part of b6df0798a5.
commit : b5abeb751419a49ab61e93e4ba21583fa9a5e09b
author : Amit Kapila <[email protected]>
date : Mon, 26 Feb 2024 09:17:28 +0530
committer: Amit Kapila <[email protected]>
date : Mon, 26 Feb 2024 09:17:28 +0530
This commit fixes the intermittent buildfarm failures in 031_column_list.
I missed to back-patch while committing b6df0798a5 in the HEAD.
Diagnosed-by: Amit Kapila
Author: Vignesh C
Backpatch-through: 15
Discussion: https://postgr.es/m/[email protected]
M src/test/subscription/t/031_column_list.pl
Promote assertion about !ReindexIsProcessingIndex to runtime error.
commit : 940489b46769eb2d2997227053ab6ca76a2ac857
author : Tom Lane <[email protected]>
date : Sun, 25 Feb 2024 16:15:07 -0500
committer: Tom Lane <[email protected]>
date : Sun, 25 Feb 2024 16:15:07 -0500
When this assertion was installed (in commit d2f60a3ab), I thought
it was only for catching server logic errors that caused accesses to
catalogs that were undergoing index rebuilds. However, it will also
fire in case of a user-defined index expression that attempts to
access its own table. We occasionally see reports of people trying
to do that, and typically getting unintelligible low-level errors
as a result. We can provide a more on-point message by making this
a regular runtime check.
While at it, adjust the similar error check in
systable_beginscan_ordered to use the same message text. That one
is (probably) not reachable without a coding bug, but we might as
well use a translatable message if we have one.
Per bug #18363 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/index/genam.c
M src/backend/access/index/indexam.c
Doc: fix minor typos in two ECPG function descriptions.
commit : c3fdf13a53cee3488c07f2c8fe796c21949bc66b
author : Tom Lane <[email protected]>
date : Sun, 25 Feb 2024 15:29:09 -0500
committer: Tom Lane <[email protected]>
date : Sun, 25 Feb 2024 15:29:09 -0500
Noted by Aidar Imamov.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ecpg.sgml
Avoid dangling-pointer problem with partitionwise joins under GEQO.
commit : 37bbe3d3acd62bad24493356a98579bd92c8f563
author : Tom Lane <[email protected]>
date : Fri, 23 Feb 2024 15:21:53 -0500
committer: Tom Lane <[email protected]>
date : Fri, 23 Feb 2024 15:21:53 -0500
build_child_join_sjinfo creates a derived SpecialJoinInfo in
the short-lived GEQO context, but afterwards the semi_rhs_exprs
from that may be used in a UniquePath for a child base relation.
This breaks the expectation that all base-relation-level structures
are in the planning-lifespan context, leading to use of a dangling
pointer with probable ensuing crash later on in create_unique_plan.
To fix, copy the expression trees when making a UniquePath.
Per bug #18360 from Alexander Lakhin. This has been broken since
partitionwise joins were added, so back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/util/pathnode.c
MERGE ... DO NOTHING: require SELECT privileges
commit : 90ad85db6a4e06c517c72de84e725c0222e0c529
author : Alvaro Herrera <[email protected]>
date : Wed, 21 Feb 2024 17:18:52 +0100
committer: Alvaro Herrera <[email protected]>
date : Wed, 21 Feb 2024 17:18:52 +0100
Verify that a user running MERGE with a DO NOTHING clause has
privileges to read the table, even if no columns are referenced. Such
privileges were already required if the ON clause or any of the WHEN
conditions referenced any column at all, so there's no functional change
in practice.
This change fixes an assertion failure in the case where no column is
referenced by the command and the WHEN clauses are all DO NOTHING.
Backpatch to 15, where MERGE was introduced.
Reported-by: Alena Rybakina <[email protected]>
Reported-by: Alexander Lakhin <[email protected]>
Discussion: https://postgr.es/m/[email protected]
M src/backend/parser/parse_merge.c
M src/test/regress/expected/merge.out
M src/test/regress/sql/merge.sql
doc: Fix link to pg_ident_file_mappings view
commit : 6ed995b13e1e0232a0e8b2f076831b7f76764ecd
author : Daniel Gustafsson <[email protected]>
date : Wed, 21 Feb 2024 09:08:28 +0100
committer: Daniel Gustafsson <[email protected]>
date : Wed, 21 Feb 2024 09:08:28 +0100
Commit a2c84990bea7 accidentally used the link for pg_hba_file_rules
when linking to pg_ident_file_mappings. Backpatch to v16 where this
was introduced.
Author: Erik Wienhold <[email protected]>
Discussion: https://postgr.es/m/qt5hvgvfi4qzlgml2dfssaut2t2x5nwf7b5l63fklr7fpxwm6g@hle3mtglpm4y
Backpatch-through: v16
M doc/src/sgml/func.sgml
Doc: improve explanation of type interval, especially extract().
commit : 6d03e8109250c1d23aa10f8ae01b21469b0f8be2
author : Tom Lane <[email protected]>
date : Tue, 20 Feb 2024 14:35:12 -0500
committer: Tom Lane <[email protected]>
date : Tue, 20 Feb 2024 14:35:12 -0500
The explanation of interval's behavior in datatype.sgml wasn't wrong
exactly, but it was unclear, partly because it buried the lede about
there being three internal fields. Rearrange and wordsmith for more
clarity.
The discussion of extract() claimed that input of type date was
handled by casting, but actually there's been a separate SQL function
taking date for a very long time. Also, it was mostly silent about
how interval inputs are handled, but there are several field types
for which it seems useful to be specific.
Improve discussion of justify_days()/justify_hours() too.
In passing, remove vertical space in some groups of examples,
as there was little consistency about whether to have such space
or not. (I only did this within the datetime functions section;
there are some related inconsistencies elsewhere.)
Per discussion of bug #18348 from Michael Bondarenko. There
may be some code changes coming out of that discussion too,
but we likely won't back-patch them. This docs-only patch
seems useful to back-patch, though I only carried it back to
v13 because it didn't apply easily in v12.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/datatype.sgml
M doc/src/sgml/func.sgml
Doc: correct minor error in back-branch release notes.
commit : 98be9404d384ef5d3dc72f3e6d890205bc4eb1b1
author : Tom Lane <[email protected]>
date : Tue, 20 Feb 2024 11:58:28 -0500
committer: Tom Lane <[email protected]>
date : Tue, 20 Feb 2024 11:58:28 -0500
Commits 1b2c6b756 et al affected the core BRIN "bloom" opclasses,
not contrib/bloom. This only corrected a bad assertion so it's not
too significant to end users, but since we documented it we should
do so accurately.
Spotted by Takatsuka Haruka.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/release-15.sgml
Fix incorrect pruning of NULL partition for boolean IS NOT clauses
commit : 1b3495e29db6c7ca32a88d5546e7813efa71cbbb
author : David Rowley <[email protected]>
date : Tue, 20 Feb 2024 12:50:34 +1300
committer: David Rowley <[email protected]>
date : Tue, 20 Feb 2024 12:50:34 +1300
Partition pruning wrongly assumed that, for a table partitioned on a
boolean column, a clause in the form "boolcol IS NOT false" and "boolcol
IS NOT true" could be inverted to correspondingly become "boolcol IS true"
and "boolcol IS false". These are not equivalent as the NOT version
matches the opposite boolean value *and* NULLs. This incorrect assumption
meant that partition pruning pruned away partitions that could contain
NULL values.
Here we fix this by correctly not pruning partitions which could store
NULLs.
To be affected by this, the table must be partitioned by a NULLable boolean
column and queries would have to contain "boolcol IS NOT false" or "boolcol
IS NOT true". This could result in queries filtering out NULL values
with a LIST partitioned table and "ERROR: invalid strategy number 0"
for RANGE and HASH partitioned tables.
Reported-by: Alexander Lakhin
Bug: #18344
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
Doc: fix typo in SECURITY LABEL synopsis.
commit : 517010bd49931f75d0058811c7fa9d4f1a1493d3
author : Tom Lane <[email protected]>
date : Mon, 19 Feb 2024 14:17:11 -0500
committer: Tom Lane <[email protected]>
date : Mon, 19 Feb 2024 14:17:11 -0500
One case missed its trailing "|".
Reported by Tim Needham.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/security_label.sgml
ecpg: Fix zero-termination of string generated by intoasc()
commit : b5cb6022bbf0a748220a1086aa398214dfca7c6d
author : Michael Paquier <[email protected]>
date : Mon, 19 Feb 2024 11:38:47 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 19 Feb 2024 11:38:47 +0900
intoasc(), a wrapper for PGTYPESinterval_to_asc that converts an
interval to its textual representation, used a plain memcpy() when
copying its result. This could miss a zero-termination in the result
string, leading to an incorrect result.
The routines in informix.c do not provide the length of their result
buffer, which would allow a replacement of strcpy() to safer strlcpy()
calls, but this requires an ABI breakage and that cannot happen in
back-branches.
Author: Oleg Tselebrovskiy
Reviewed-by: Ashutosh Bapat
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 12
M src/interfaces/ecpg/compatlib/informix.c
M src/interfaces/ecpg/test/compat_informix/.gitignore
M src/interfaces/ecpg/test/compat_informix/Makefile
A src/interfaces/ecpg/test/compat_informix/intoasc.pgc
M src/interfaces/ecpg/test/ecpg_schedule
A src/interfaces/ecpg/test/expected/compat_informix-intoasc.c
A src/interfaces/ecpg/test/expected/compat_informix-intoasc.stderr
A src/interfaces/ecpg/test/expected/compat_informix-intoasc.stdout
Remove non-existing file from .gitattributes
commit : 1d577f2eaa88b1d4caab3e859a01d25ecd9f81c5
author : Peter Eisentraut <[email protected]>
date : Fri, 16 Feb 2024 11:39:09 +0100
committer: Peter Eisentraut <[email protected]>
date : Fri, 16 Feb 2024 11:39:09 +0100
The file was removed by ac25173cdbc.
Author: Jelte Fennema-Nio <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/CAGECzQQGzbroAXi%2BYicp3HvcCo4%3Dg84kaOgjuvQ5MW9F0ubOGg%40mail.gmail.com
M .gitattributes
Doc: improve a couple of comments in postgresql.conf.sample.
commit : ed1b0ade703ab49196277c3f5dd6a1bb6f2d2170
author : Tom Lane <[email protected]>
date : Thu, 15 Feb 2024 16:45:03 -0500
committer: Tom Lane <[email protected]>
date : Thu, 15 Feb 2024 16:45:03 -0500
Clarify comments associated with max_parallel_workers and
related settings.
Per bug #18343 from Christopher Kline.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/misc/postgresql.conf.sample
doc: Remove links to further reading from pgcrypto docs
commit : ac54734b24c5635c4e0c15c9989221774b065f62
author : Daniel Gustafsson <[email protected]>
date : Wed, 14 Feb 2024 11:05:10 +0100
committer: Daniel Gustafsson <[email protected]>
date : Wed, 14 Feb 2024 11:05:10 +0100
The pgcrypto docs contained a set of links for useful reading and
technical references. These sets of links were however not actively
curated and had stale content and dead links. Rather than investing
time into maintining these, this removes them altogether since there
are lots of resources online which are actively maintained.
Backpatch to all supported versions since these links have been in
the docs for a long time.
Reported-by: Hanefi Onaldi <[email protected]>
Reviewed-by: Magnus Hagander <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: v12
M doc/src/sgml/pgcrypto.sgml
Fix 'mmap' DSM implementation with allocations larger than 4 GB
commit : d46c269612c78b5688487e07f74f3e875755effe
author : Heikki Linnakangas <[email protected]>
date : Tue, 13 Feb 2024 21:23:41 +0200
committer: Heikki Linnakangas <[email protected]>
date : Tue, 13 Feb 2024 21:23:41 +0200
Fixes bug #18341. Backpatch to all supported versions.
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/backend/storage/ipc/dsm_impl.c
Skip .DS_Store files in server side utils
commit : 29f00523808ac1d646cf51f9fe199e61ce5631e7
author : Daniel Gustafsson <[email protected]>
date : Tue, 13 Feb 2024 13:47:12 +0100
committer: Daniel Gustafsson <[email protected]>
date : Tue, 13 Feb 2024 13:47:12 +0100
The macOS Finder application creates .DS_Store files in directories
when opened, which creates problems for serverside utilities which
expect all files to be PostgreSQL specific files. Skip these files
when encountered in pg_checksums, pg_rewind and pg_basebackup.
This was extracted from a larger patchset for skipping hidden files
and system files, where the concencus was to just skip these. Since
this is equally likely to happen in every version, backpatch to all
supported versions.
Reported-by: Mark Guertin <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Reviewed-by: Tobias Bussmann <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: v12
M doc/src/sgml/protocol.sgml
M doc/src/sgml/ref/pg_basebackup.sgml
M doc/src/sgml/ref/pg_rewind.sgml
M src/backend/backup/basebackup.c
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/bin/pg_checksums/pg_checksums.c
M src/bin/pg_checksums/t/002_actions.pl
M src/bin/pg_rewind/filemap.c
M src/bin/pg_rewind/t/003_extrafiles.pl
Remove race condition in pg_get_expr().
commit : 26c89d10543ad832bd4d2ce6eb00948575c2db07
author : Tom Lane <[email protected]>
date : Fri, 9 Feb 2024 12:29:41 -0500
committer: Tom Lane <[email protected]>
date : Fri, 9 Feb 2024 12:29:41 -0500
Since its introduction, pg_get_expr() has intended to silently
return NULL if called with an invalid relation OID, as can happen
when scanning the catalogs concurrently with relation drops.
However, there is a race condition: we check validity of the OID
at the start, but it could get dropped just afterward, leading to
failures. This is the cause of some intermittent instability we're
seeing in a proposed new test case, and presumably it's a hazard in
the field as well.
We can fix this by AccessShareLock-ing the target relation for the
duration of pg_get_expr(). Since we don't require any permissions
on the target relation, this is semantically a bit undesirable. But
it turns out that the set_relation_column_names() subroutine already
takes a transient AccessShareLock on that relation, and has done since
commit 2ffa740be in 2012. Given the lack of complaints about that, it
seems like there should be no harm in holding the lock a bit longer.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/ruleutils.c
Avoid concurrent calls to bindtextdomain().
commit : 806f98951511715fb36a70a582e87e1c40293407
author : Tom Lane <[email protected]>
date : Fri, 9 Feb 2024 11:21:08 -0500
committer: Tom Lane <[email protected]>
date : Fri, 9 Feb 2024 11:21:08 -0500
We previously supposed that it was okay for different threads to
call bindtextdomain() concurrently (cf. commit 1f655fdc3).
It now emerges that there's at least one gettext implementation
in which that triggers an abort() crash, so let's stop doing that.
Add mutexes guarding libpq's and ecpglib's calls, which are the
only ones that need worry about multithreaded callers.
Note: in libpq, we could perhaps have piggybacked on
default_threadlock() to avoid defining a new mutex variable.
I judge that not terribly safe though, since libpq_gettext could
be called from code that is holding the default mutex. If that
were the first such call in the process, it'd fail. An extra
mutex is cheap insurance against unforeseen interactions.
Per bug #18312 from Christian Maurer. Back-patch to all
supported versions.
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]
M src/interfaces/ecpg/ecpglib/misc.c
M src/interfaces/libpq/fe-misc.c
Clean up Windows-specific mutex code in libpq and ecpglib.
commit : 9f041b041feb3361748496e5813cd3a5b034361c
author : Tom Lane <[email protected]>
date : Fri, 9 Feb 2024 11:11:39 -0500
committer: Tom Lane <[email protected]>
date : Fri, 9 Feb 2024 11:11:39 -0500
Fix pthread-win32.h and pthread-win32.c to provide a more complete
emulation of POSIX pthread mutexes: define PTHREAD_MUTEX_INITIALIZER
and make sure that pthread_mutex_lock() can operate on a mutex
object that's been initialized that way. Then we don't need the
duplicative platform-specific logic in default_threadlock() and
pgtls_init(), which we'd otherwise need yet a third copy of for
an upcoming bug fix.
Also, since default_threadlock() supposes that pthread_mutex_lock()
cannot fail, try to ensure that that's actually true, by getting
rid of the malloc call that was formerly involved in initializing
an emulated mutex. We can define an extra state for the spinlock
field instead.
Also, replace the similar code in ecpglib/misc.c with this version.
While ecpglib's version at least had a POSIX-compliant API, it
also had the potential of failing during mutex init (but here,
because of CreateMutex failure rather than malloc failure). Since
all of misc.c's callers ignore failures, it seems like a wise idea
to avoid failures here too.
A further improvement in this area could be to unify libpq's and
ecpglib's implementations into a src/port/pthread-win32.c file.
But that doesn't seem like a bug fix, so I'll desist for now.
In preparation for the aforementioned bug fix, back-patch to all
supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/interfaces/ecpg/ecpglib/misc.c
M src/interfaces/ecpg/include/ecpg-pthread-win32.h
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/fe-secure-openssl.c
M src/interfaces/libpq/pthread-win32.c
M src/port/pthread-win32.h
Fix wrong logic in TransactionIdInRecentPast()
commit : 503299b7f728409874adc2f5df9d42857700b046
author : Alexander Korotkov <[email protected]>
date : Thu, 8 Feb 2024 12:45:26 +0200
committer: Alexander Korotkov <[email protected]>
date : Thu, 8 Feb 2024 12:45:26 +0200
The TransactionIdInRecentPast() should return false for all the transactions
older than TransamVariables->oldestClogXid. However, the function contains
a bug in comparison FullTransactionId to TransactionID allowing full
transactions between nextXid - 2^32 and oldestClogXid - 2^31.
This commit fixes TransactionIdInRecentPast() by turning the oldestClogXid into
FullTransactionId first, then performing the comparison.
Backpatch to all supported versions.
Reported-by: Egor Chindyaskin
Bug: 18212
Discussion: https://postgr.es/m/18212-547307f8adf57262%40postgresql.org
Author: Karina Litskevich
Reviewed-by: Kyotaro Horiguchi
Backpatch-through: 12
M src/backend/utils/adt/xid8funcs.c
Fix propagation of persistence to sequences in ALTER TABLE / ADD COLUMN
commit : d17a3a4c6a34f61a3d4d9faa7a70c14d8d0c0ffb
author : Peter Eisentraut <[email protected]>
date : Fri, 9 Feb 2024 07:57:31 +0100
committer: Peter Eisentraut <[email protected]>
date : Fri, 9 Feb 2024 07:57:31 +0100
Fix for 344d62fb9a9: That commit introduced unlogged sequences and
made it so that identity/serial sequences automatically get the
persistence level of their owning table. But this works only for
CREATE TABLE and not for ALTER TABLE / ADD COLUMN. The latter would
always create the sequence as logged (default), independent of the
persistence setting of the table. This is fixed here.
Note: It is allowed to change the persistence of identity sequences
directly using ALTER SEQUENCE. So mistakes in existing databases can
be fixed manually.
Reviewed-by: Ashutosh Bapat <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/c4b6e2ed-bcdf-4ea7-965f-e49761094827%40eisentraut.org
M src/backend/parser/parse_utilcmd.c
M src/test/regress/expected/identity.out
M src/test/regress/sql/identity.sql
doc: Remove superfluous bracket in synopsis
commit : 27c3a41f3cfbfc3ab471fd85b4885d39f7c42ae6
author : Daniel Gustafsson <[email protected]>
date : Thu, 8 Feb 2024 12:19:34 +0100
committer: Daniel Gustafsson <[email protected]>
date : Thu, 8 Feb 2024 12:19:34 +0100
Commit 9c08aea6a30 accidentally added one too many end brackets
in the synopsis for CREATE DATABASE .. strategy = strat. Fix by
removing. Backpatch to v15 where it was introduced.
Reported-by: [email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: v15
M doc/src/sgml/ref/create_database.sgml