Stamp 13.11.
commit : 2faab87390b03929a8cbb5a9336a04faa45a27c5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2023 17:17:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2023 17:17:31 -0400
M configure
M configure.in
Last-minute updates for release notes.
commit : aeed67f1af446dd425e2c8d6db97ea29c25b8887
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2023 12:38:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2023 12:38:08 -0400
Security: CVE-2023-2454, CVE-2023-2455
M doc/src/sgml/release-13.sgml
Adjust sepgsql expected output for 681d9e462 et al.
commit : feb9e7fbbc3f9607fbc01c071537488f8dbfab73
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2023 11:24:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2023 11:24:47 -0400
Security: CVE-2023-2454
M contrib/sepgsql/expected/ddl.out
Handle RLS dependencies in inlined set-returning functions properly.
commit : b8e28f04f7f339d4285852960e6455de75dbf9b3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2023 10:12:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 May 2023 10:12:44 -0400
If an SRF in the FROM clause references a table having row-level
security policies, and we inline that SRF into the calling query,
we neglected to mark the plan as potentially dependent on which
role is executing it. This could lead to later executions in the
same session returning or hiding rows that should have been hidden
or returned instead.
Our thanks to Wolfgang Walther for reporting this problem.
Stephen Frost and Tom Lane
Security: CVE-2023-2455
M src/backend/optimizer/util/clauses.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Replace last PushOverrideSearchPath() call with set_config_option().
commit : 2212f7db80e9397825dea5f4947397665a7f60b8
author : Noah Misch <noah@leadboat.com>
date : Mon, 8 May 2023 06:14:07 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 8 May 2023 06:14:07 -0700
The two methods don't cooperate, so set_config_option("search_path",
...) has been ineffective under non-empty overrideStack. This defect
enabled an attacker having database-level CREATE privilege to execute
arbitrary code as the bootstrap superuser. While that particular attack
requires v13+ for the trusted extension attribute, other attacks are
feasible in all supported versions.
Standardize on the combination of NewGUCNestLevel() and
set_config_option("search_path", ...). It is newer than
PushOverrideSearchPath(), more-prevalent, and has no known
disadvantages. The "override" mechanism remains for now, for
compatibility with out-of-tree code. Users should update such code,
which likely suffers from the same sort of vulnerability closed here.
Back-patch to v11 (all supported versions).
Alexander Lakhin. Reported by Alexander Lakhin.
Security: CVE-2023-2454
M contrib/seg/Makefile
A contrib/seg/expected/security.out
A contrib/seg/sql/security.sql
M src/backend/catalog/namespace.c
M src/backend/commands/schemacmds.c
M src/test/regress/expected/namespace.out
M src/test/regress/sql/namespace.sql
Translation updates
commit : c8cdde66de612e3694ed8e17d581487f5d71becd
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 8 May 2023 14:36:07 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 8 May 2023 14:36:07 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 5880bed52cbf5fb44921c4a42b23e3251575dcdb
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/initdb/po/es.po
M src/bin/initdb/po/ru.po
M src/bin/pg_archivecleanup/po/es.po
M src/bin/pg_basebackup/po/es.po
M src/bin/pg_checksums/po/es.po
M src/bin/pg_config/po/es.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/ja.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_dump/po/uk.po
M src/bin/pg_resetwal/po/es.po
M src/bin/pg_rewind/po/es.po
M src/bin/pg_test_fsync/po/es.po
M src/bin/pg_test_timing/po/es.po
M src/bin/pg_upgrade/po/es.po
M src/bin/pg_verifybackup/po/es.po
M src/bin/pg_verifybackup/po/ru.po
M src/bin/pg_waldump/po/es.po
M src/bin/pg_waldump/po/uk.po
M src/bin/psql/po/es.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/uk.po
M src/bin/scripts/po/es.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/es.po
M src/pl/plperl/po/ru.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/de.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/po/es.po
Release notes for 15.3, 14.8, 13.11, 12.15, 11.20.
commit : 2ec03d418eaf0f6d6f0da39767797b485a33286f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 May 2023 12:36:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 May 2023 12:36:12 -0400
M doc/src/sgml/release-13.sgml
Fix typo with wait event for SLRU buffer of commit timestamps
commit : cedcc41918477fed31edff7f86820be87e8fa993
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 5 May 2023 21:26:02 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 5 May 2023 21:26:02 +0900
This wait event was documented as "CommitTsBuffer" since its
introduction, but the code named it "CommitTSBuffer". This commit fixes
the code to follow the term documented, which is also more consistent
with the naming of the other wait events used for commit timestamps.
Introduced by 5da1493.
Author: Alexander Lakhin
Discussion: https://postgr.es/m/e8c38840-596a-83d6-bd8d-cebc51111572@gmail.com
Backpatch-through: 13
M src/backend/storage/lmgr/lwlock.c
Fix prove_installcheck when used with PGXS
commit : 6704944779cfbc420fdefc6992ccb6a048ddc4a5
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 5 May 2023 06:29:49 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 5 May 2023 06:29:49 +0200
Commit 153e215677 added the portlock directory. This is created in
$ENV{top_builddir} if it is set. Under PGXS, top_builddir points into
the installation directory, which is not necessarily writable and in
any case inappropriate to use by a test suite. The cause of the
problem is that the prove_installcheck target in Makefile.global
exports top_builddir, which isn't useful (since no other Perl code
actually reads it) and breaks this use case. The reason this code is
there is probably that is has been dragged around with various other
changes, in particular a0fc813266, but without a real purpose of its
own. By just removing the exporting of top_builddir in
prove_installcheck, the portlock directory then ends up under
tmp_check in the build directory, which is more suitable.
Reviewed-by: Andrew Dunstan <andrew@dunslane.net>
Discussion: https://www.postgresql.org/message-id/78d1cfa6-0065-865d-584b-cde6d8c18aff@enterprisedb.com
M src/Makefile.global.in
Move return statements out of PG_TRY blocks.
commit : 800531846ef7da5f4a234fbb6fd65a91c7ecb33f
author : Nathan Bossart <nathan@postgresql.org>
date : Wed, 3 May 2023 11:32:43 -0700
committer: Nathan Bossart <nathan@postgresql.org>
date : Wed, 3 May 2023 11:32:43 -0700
If we exit a PG_TRY block early via "continue", "break", "goto", or
"return", we'll skip unwinding its exception stack. This change
moves a couple of such "return" statements in PL/Python out of
PG_TRY blocks. This was introduced in d0aa965c0a and affects all
supported versions.
We might also be able to add compile-time checks to prevent
recurrence, but that is left as a future exercise.
Reported-by: Mikhail Gribkov, Xing Guo
Author: Xing Guo
Reviewed-by: Michael Paquier, Andres Freund, Tom Lane
Discussion: https://postgr.es/m/CAMEv5_v5Y%2B-D%3DCO1%2Bqoe16sAmgC4sbbQjz%2BUtcHmB6zcgS%2B5Ew%40mail.gmail.com
Discussion: https://postgr.es/m/CACpMh%2BCMsGMRKFzFMm3bYTzQmMU5nfEEoEDU2apJcc4hid36AQ%40mail.gmail.com
Backpatch-through: 11 (all supported versions)
M src/pl/plpython/plpy_exec.c
In array_position()/array_positions(), beware of empty input array.
commit : 9a72f499a4b61c34e3ae7759c209e92e0cfef6e1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 May 2023 11:48:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 May 2023 11:48:23 -0400
These functions incautiously fetched the array's first lower bound
even when the array is zero-dimensional, thus fetching the word
after the allocated array space. While almost always harmless,
with very bad luck this could result in SIGSEGV. Fix by adding
an early exit for empty input.
Per bug #17920 from Alexander Lakhin.
Discussion: https://postgr.es/m/17920-f7c228c627b6d02e%40postgresql.org
M src/backend/utils/adt/array_userfuncs.c
Tighten array dimensionality checks in Python -> SQL array conversion.
commit : 0e6354ed97833a15a6a7dfa328298ad02e0947e3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 May 2023 11:00:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 May 2023 11:00:33 -0400
Like plperl before f47004add, plpython wasn't being sufficiently
careful about checking that list-of-list structures represent
rectangular arrays, so that it would accept some cases in which
different parts of the "array" are nested to different depths.
This was exacerbated by Python's weak distinction between
sequences and lists, so that in some cases strings could get
treated as though they are lists (and burst into individual
characters) even though a different ordering of the upper-level
list would give a different result.
Some of this behavior was unreachable (without risking a crash)
before 81eaaf65e. It seems like a good idea to clean it all up
in the same releases, rather than shipping a non-crashing but
nonetheless visibly buggy behavior in the name of minimal change.
Hence, back-patch.
Per bug #17912 and further testing by Alexander Lakhin.
Discussion: https://postgr.es/m/17912-82ceed78731d9cdc@postgresql.org
M src/pl/plpython/expected/plpython_types.out
M src/pl/plpython/expected/plpython_types_3.out
M src/pl/plpython/plpy_typeio.c
M src/pl/plpython/sql/plpython_types.sql
Doc: clarify behavior of row-limit arguments in the PLs' SPI wrappers.
commit : b00bae2e9103b4cd4fc97141b3aba2fa0ce532a8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 May 2023 17:55:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 May 2023 17:55:01 -0400
plperl, plpython, and pltcl all provide query-execution functions
that are thin wrappers around SPI_execute() or its variants.
The SPI functions document their row-count limit arguments clearly,
as "maximum number of rows to return, or 0 for no limit". However
the PLs' documentation failed to explain this special behavior of
zero, so that a reader might well assume it means "fetch zero
rows". Improve that.
Daniel Gustafsson and Tom Lane, per report from Kieran McCusker
Discussion: https://postgr.es/m/CAGgUQ6H6qYScctOhktQ9HLFDDoafBKHyUgJbZ6q_dOApnzNTXg@mail.gmail.com
M doc/src/sgml/plperl.sgml
M doc/src/sgml/plpython.sgml
M doc/src/sgml/pltcl.sgml
Tighten array dimensionality checks in Perl -> SQL array conversion.
commit : ee24b5e792e091b216db20b765d1dcb718abfdfc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Apr 2023 13:06:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Apr 2023 13:06:44 -0400
plperl_array_to_datum() wasn't sufficiently careful about checking
that nested lists represent a rectangular array structure; it would
accept inputs such as "[1, []]". This is a bit related to the
PL/Python bug fixed in commit 81eaaf65e, but it doesn't seem to
provide any direct route to a memory stomp. Instead the likely
failure mode is for makeMdArrayResult to be passed fewer Datums than
the claimed array dimensionality requires, possibly leading to a wild
pointer dereference and SIGSEGV.
Per report from Alexander Lakhin. It's been broken for a long
time, so back-patch to all supported branches.
Discussion: https://postgr.es/m/5ebae5e4-d401-fadf-8585-ac3eaf53219c@gmail.com
M src/pl/plperl/expected/plperl_array.out
M src/pl/plperl/plperl.c
M src/pl/plperl/sql/plperl_array.sql
Handle zero-length sublist correctly in Python -> SQL array conversion.
commit : 7dcd9998c19d7e1a86bc0d76167e429455e3db5f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 28 Apr 2023 12:24:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 28 Apr 2023 12:24:29 -0400
If PLySequence_ToArray came across a zero-length sublist, it'd compute
the overall array size as zero, possibly leading to a memory clobber.
(This would likely qualify as a security bug, were it not that plpython
is an untrusted language already.)
I think there are other corner-case issues in this code as well, notably
that the error messages don't match the core code and for some ranges
of array sizes you'd get "invalid memory alloc request size" rather than
the intended message about array size.
Really this code has no business doing its own array size calculation
at all, so remove the faulty code in favor of using ArrayGetNItems().
Per bug #17912 from Alexander Lakhin. Bug seems to have come in with
commit 94aceed31, so back-patch to all supported branches.
Discussion: https://postgr.es/m/17912-82ceed78731d9cdc@postgresql.org
M src/pl/plpython/expected/plpython_types.out
M src/pl/plpython/expected/plpython_types_3.out
M src/pl/plpython/plpy_typeio.c
M src/pl/plpython/sql/plpython_types.sql
Fix crashes with CREATE SCHEMA AUTHORIZATION and schema elements
commit : 7e95a33b42e76d34053bfc9c2845d43753a2e7b3
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 28 Apr 2023 19:29:40 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 28 Apr 2023 19:29:40 +0900
CREATE SCHEMA AUTHORIZATION with appended schema elements can lead to
crashes when comparing the schema name of the query with the schemas
used in the qualification of some clauses in the elements' queries.
The origin of the problem is that the transformation routine for the
elements listed in a CREATE SCHEMA query uses as new, expected, schema
name the one listed in CreateSchemaStmt itself. However, depending on
the query, CreateSchemaStmt.schemaname may be NULL, being computed
instead from the role specification of the query given by the
AUTHORIZATION clause, that could be either:
- A user name string, with the new schema name being set to the same
value as the role given.
- Guessed from CURRENT_ROLE, SESSION_ROLE or CURRENT_ROLE, with a new
schema name computed from the security context where CREATE SCHEMA is
running.
Regression tests are added for CREATE SCHEMA with some appended elements
(some of them with schema qualifications), covering also some role
specification patterns.
While on it, this simplifies the context structure used during the
transformation of the elements listed in a CREATE SCHEMA query by
removing the fields for the role specification and the role type. They
were not used, and for the role specification this could be confusing as
the schema name may by extracted from that at the beginning of
CreateSchemaCommand().
This issue exists for a long time, so backpatch down to all the versions
supported.
Reported-by: Song Hongyu
Author: Michael Paquier
Reviewed-by: Richard Guo
Discussion: https://postgr.es/m/17909-f65c12dfc5f0451d@postgresql.org
Backpatch-through: 11
M src/backend/commands/schemacmds.c
M src/backend/parser/parse_utilcmd.c
M src/include/parser/parse_utilcmd.h
A src/test/regress/expected/create_schema.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
A src/test/regress/sql/create_schema.sql
Prevent underflow in KeepLogSeg().
commit : be40dd63e00d4ccb1bc10cab5c086a6e544c3a30
author : Nathan Bossart <nathan@postgresql.org>
date : Thu, 27 Apr 2023 13:43:48 -0700
committer: Nathan Bossart <nathan@postgresql.org>
date : Thu, 27 Apr 2023 13:43:48 -0700
The call to XLogGetReplicationSlotMinimumLSN() might return a
greater LSN than the one given to the function. Subsequent segment
number calculations might then underflow, which could result in
unexpected behavior when removing or recyling WAL files. This was
introduced with max_slot_wal_keep_size in c655077639. To fix, skip
the block of code for replication slots if the LSN is greater.
Reported-by: Xu Xingwang
Author: Kyotaro Horiguchi
Reviewed-by: Junwang Zhao
Discussion: https://postgr.es/m/17903-4288d439dee856c6%40postgresql.org
Backpatch-through: 13
M src/backend/access/transam/xlog.c
In hstore_plpython, avoid crashing when return value isn't a mapping.
commit : de2dfa0538f4b2c75c5368c21cf4f187dc8bb501
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Apr 2023 11:55:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 27 Apr 2023 11:55:06 -0400
Python 3 changed the behavior of PyMapping_Check(), breaking the
test in plpython_to_hstore() that verifies whether a function result
to be transformed is acceptable. A backwards-compatible fix is to
first verify that the object doesn't pass PySequence_Check().
Perhaps accidentally, our other uses of PyMapping_Check() already
follow uses of PySequence_Check(), so that no other bugs were
created by this change.
Per bug #17908 from Alexander Lakhin. Back-patch to all supported
branches.
Dmitry Dolgov and Tom Lane
Discussion: https://postgr.es/m/17908-3f19a125d56a11d6@postgresql.org
M contrib/hstore_plpython/expected/hstore_plpython.out
M contrib/hstore_plpython/hstore_plpython.c
M contrib/hstore_plpython/sql/hstore_plpython.sql
Fix vacuum_cost_delay check for balance calculation.
commit : b95f36f8613166171f221ef5f4cd6fb583605c91
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Tue, 25 Apr 2023 13:54:10 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Tue, 25 Apr 2023 13:54:10 +0200
Commit 1021bd6a89 excluded autovacuum workers from cost-limit balance
calculations when per-relation options were set. The code checks for
limit and cost_delay being greater than zero, but since cost_delay can
be set to -1 the test needs to check for greater than or zero.
Backpatch to all supported branches since 1021bd6a89 was backpatched
all the way at the time.
Author: Masahiko Sawada <sawada.mshk@gmail.com>
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/CAD21AoBS7o6Ljt_vfqPQPf67AhzKu3fR0iqk8B=vVYczMugKMQ@mail.gmail.com
Backpatch-through: v11 (all supported branches)
M src/backend/postmaster/autovacuum.c
Fix memory leakage in plpgsql DO blocks that use cast expressions.
commit : bfa691087eacc6e0fbf1a0d8ee392c3d2ff3cb34
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 24 Apr 2023 14:19:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 24 Apr 2023 14:19:46 -0400
Commit 04fe805a1 modified plpgsql so that datatype casts make use of
expressions cached by plancache.c, in place of older code where these
expression trees were managed by plpgsql itself. However, I (tgl)
forgot that we use a separate, shorter-lived cast info hashtable in
DO blocks. The new mechanism thus resulted in session-lifespan
leakage of the plancache data once a DO block containing one or more
casts terminated. To fix, split the cast hash table into two parts,
one that tracks only the plancache's CachedExpressions and one that
tracks the expression state trees generated from them. DO blocks need
their own expression state trees and hence their own version of the
second hash table, but there's no reason they can't share the
CachedExpressions with regular plpgsql functions.
Per report from Ajit Awekar. Back-patch to v12 where the issue
was introduced.
Ajit Awekar and Tom Lane
Discussion: https://postgr.es/m/CAHv6PyrNaqdvyWUspzd3txYQguFTBSnhx+m6tS06TnM+KWc_LQ@mail.gmail.com
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/plpgsql.h
Remove duplicate lines of code
commit : 50b23e4374775749e35f84469a9cd080928ef333
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Mon, 24 Apr 2023 11:16:17 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Mon, 24 Apr 2023 11:16:17 +0200
Commit 6df7a9698bb accidentally included two identical prototypes for
default_multirange_selectivi() and commit 086cf1458c6 added a break;
statement where one was already present, thus duplicating it. While
there is no bug caused by this, fix by removing the duplicated lines
as they provide no value.
Backpatch the fix for duplicate prototypes to v14 and the duplicate
break statement fix to all supported branches to avoid backpatching
hazards due to the removal.
Reported-by: Anton Voloshin <a.voloshin@postgrespro.ru>
Discussion: https://postgr.es/m/0e69cb60-0176-f6d0-7e15-6478b7d85724@postgrespro.ru
M src/interfaces/ecpg/preproc/variable.c
Validate ltree siglen GiST option to be int-aligned
commit : 48c6825d0ec8a5021e95aea666944e9345ceb77d
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 23 Apr 2023 13:58:25 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 23 Apr 2023 13:58:25 +0300
Unaligned siglen could lead to an unaligned access to subsequent key fields.
Backpatch to 13, where opclass options were introduced.
Reported-by: Alexander Lakhin
Bug: 17847
Discussion: https://postgr.es/m/17847-171232970bea406b%40postgresql.org
Reviewed-by: Tom Lane, Pavel Borisov, Alexander Lakhin
Backpatch-through: 13
M contrib/ltree/expected/ltree.out
M contrib/ltree/ltree_gist.c
M contrib/ltree/sql/ltree.sql
M doc/src/sgml/ltree.sgml
Fix custom validators call in build_local_reloptions()
commit : 02191136cb25670dc9f086248f7b495d68c965d5
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 23 Apr 2023 13:55:49 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 23 Apr 2023 13:55:49 +0300
We need to call them only when validate == true.
Backpatch to 13, where opclass options were introduced.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/2656633.1681831542%40sss.pgh.pa.us
Reviewed-by: Tom Lane, Pavel Borisov
Backpatch-through: 13
M src/backend/access/common/reloptions.c
Avoid character classification in regex escape parsing.
commit : 79a66c617ae3e9e0258087c6e3209b021badda4b
author : Jeff Davis <jdavis@postgresql.org>
date : Fri, 21 Apr 2023 08:19:41 -0700
committer: Jeff Davis <jdavis@postgresql.org>
date : Fri, 21 Apr 2023 08:19:41 -0700
For regex escape sequences, just test directly for the relevant ASCII
characters rather than using locale-sensitive character
classification.
This fixes an assertion failure when a locale considers a non-ASCII
character, such as "൧", to be a digit.
Reported-by: Richard Guo
Discussion: https://postgr.es/m/CAMbWs49Q6UoKGeT8pBkMtJGJd+16CBFZaaWUk9Du+2ERE5g_YA@mail.gmail.com
Backpatch-through: 11
M src/backend/regex/regc_lex.c
Use --strip-unneeded when stripping static libraries with GNU strip.
commit : 6dce37203410b011c0ccae40acf2649f79c38242
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 20 Apr 2023 18:12:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 20 Apr 2023 18:12:32 -0400
We've long used "--strip-unneeded" for shared libraries but plain
"-x" for static libraries when stripping symbols with GNU strip.
There doesn't seem to be any really good reason for that though,
since --strip-unneeded produces smaller output (as "-x" alone
does not remove debug symbols). Moreover it seems that
llvm-strip, although it identifies as GNU strip, misbehaves when
given "-x" for this purpose. It's unclear whether that's
intentional or a bug in llvm-strip, but in any case it seems like
changing to use --strip-unneeded in all cases should be a win.
Note that this doesn't change our behavior when dealing with
non-GNU strip.
Per gripes from Ed Maste and Palle Girgensohn. Back-patch,
in case anyone wants to use llvm-strip with stable branches.
Discussion: https://postgr.es/m/17898-5308d09543463266@postgresql.org
Discussion: https://postgr.es/m/20230420153338.bbj2g5jiyy3afhjz@awork3.anarazel.de
M config/programs.m4
M configure
Update time zone data files to tzdata release 2023c.
commit : 87d8ec3e47e4da80ede7765d03a5d7433f8811d6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Apr 2023 14:46:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 18 Apr 2023 14:46:39 -0400
DST law changes in Egypt, Greenland, Morocco, and Palestine.
When observing Moscow time, Europe/Kirov and Europe/Volgograd now
use the abbreviations MSK/MSD instead of numeric abbreviations,
for consistency with other timezones observing Moscow time.
Also, America/Yellowknife is no longer distinct from America/Edmonton;
this affects some pre-1948 timestamps in that area.
M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt
ecpg: Fix handling of strings in ORACLE compat code with SQLDA
commit : e9e457d22d264308bd709ac034b23a6c5716432a
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 18 Apr 2023 11:20:51 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 18 Apr 2023 11:20:51 +0900
When compiled with -C ORACLE, ecpg_get_data() had a one-off issue where
it would incorrectly store the null terminator byte to str[-1] when
varcharsize is 0, which is something that can happen when using SQLDA.
This would eat 1 byte from the previous field stored, corrupting the
results generated.
All the callers of ecpg_get_data() estimate and allocate enough storage
for the data received, and the fix of this commit relies on this
assumption. Note that this maps to the case where no padding or
truncation is required.
This issue has been introduced by 3b7ab43 with the Oracle compatibility
option, so backpatch down to v11.
Author: Kyotaro Horiguchi
Discussion: https://postgr.es/m/20230410.173500.440060475837236886.horikyota.ntt@gmail.com
Backpatch-through: 11
M src/interfaces/ecpg/ecpglib/data.c
M src/interfaces/ecpg/test/compat_oracle/char_array.pgc
M src/interfaces/ecpg/test/expected/compat_oracle-char_array.c
M src/interfaces/ecpg/test/expected/compat_oracle-char_array.stderr
M src/interfaces/ecpg/test/expected/compat_oracle-char_array.stdout
Avoid trying to write an empty WAL record in log_newpage_range().
commit : 86874a6dfc8b1878bede18437b1709fbe485a911
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Apr 2023 14:22:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Apr 2023 14:22:06 -0400
If the last few pages in the specified range are empty (all zero),
then log_newpage_range() could try to emit an empty WAL record
containing no FPIs. This at least upsets an Assert in
ReserveXLogInsertLocation, and might perhaps have bad real-world
consequences in non-assert builds.
This has been broken since log_newpage_range() was introduced,
but the case was hard if not impossible to hit before commit 3d6a98457
decided it was okay to leave VM and FSM pages intentionally zero.
Nonetheless, it seems prudent to back-patch. log_newpage_range()
was added in v12 but later back-patched, so this affects all
supported branches.
Matthias van de Meent, per report from Justin Pryzby
Discussion: https://postgr.es/m/ZD1daibg4RF50IOj@telsasoft.com
M src/backend/access/transam/xloginsert.c
Fix assignment to array of domain over composite, redux.
commit : 7428aecddf18edc25237eb41257ef023032ce4ad
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Apr 2023 12:01:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 15 Apr 2023 12:01:39 -0400
Commit 3e310d837 taught isAssignmentIndirectionExpr() to look through
CoerceToDomain nodes. That's not sufficient, because since commit
04fe805a1 it's been possible for the planner to simplify
CoerceToDomain to RelabelType when the domain has no constraints
to enforce. So we need to look through RelabelType too.
Per bug #17897 from Alexander Lakhin. Although 3e310d837 was
back-patched to v11, it seems sufficient to apply this change
to v12 and later, since 04fe805a1 came in in v12.
Dmitry Dolgov
Discussion: https://postgr.es/m/17897-4216c546c3874044@postgresql.org
M src/backend/executor/execExpr.c
M src/test/regress/expected/domain.out
M src/test/regress/sql/domain.sql
doc: PQinitOpenSSL and PQinitSSL are obsolete in OpenSSL 1.1.0+
commit : 36f49be80856ee46a5ff39c5dc8a7418df63be3d
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Fri, 14 Apr 2023 10:15:50 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Fri, 14 Apr 2023 10:15:50 +0200
Starting with OpenSSL 1.1.0 there is no need to call PQinitOpenSSL
or PQinitSSL to avoid duplicate initialization of OpenSSL. Add a
note to the documentation to explain this.
Backpatch to all supported versions as older OpenSSL versions are
equally likely to be used for all branches.
Reported-by: Sebastien Flaesch <sebastien.flaesch@4js.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/DBAP191MB12895BFFEC4B5FE0460D0F2FB0459@DBAP191MB1289.EURP191.PROD.OUTLOOK.COM
Backpatch-through: 11, all supported versions
M doc/src/sgml/libpq.sgml
Fix incorrect partition pruning logic for boolean partitioned tables
commit : 6848f0c67c60dc721c4e4527778f83e2c8c08d01
author : David Rowley <drowley@postgresql.org>
date : Fri, 14 Apr 2023 16:22:11 +1200
committer: David Rowley <drowley@postgresql.org>
date : Fri, 14 Apr 2023 16:22:11 +1200
The partition pruning logic assumed that "b IS NOT true" was exactly the
same as "b IS FALSE". This is not the case when considering NULL values.
Fix this so we correctly include any partition which could hold NULL
values for the NOT case.
Additionally, this fixes a bug in the partition pruning code which handles
partitioned tables partitioned like ((NOT boolcol)). This is a seemingly
unlikely schema design, and it was untested and also broken.
Here we add tests for the ((NOT boolcol)) case and insert some actual data
into those tables and verify we do get the correct rows back when running
queries. I've also adjusted the existing boolpart tests to include some
data and verify we get the correct results too.
Both the bugs being fixed here could lead to incorrect query results with
fewer rows being returned than expected. No additional rows could have
been returned accidentally.
In passing, remove needless ternary expression. It's more simple just to
pass !is_not_clause to makeBoolConst(). It makes sense to do this so the
code is consistent with the bug fix in the "else if" condition just below.
David Kimura did submit a patch to fix the first of the issues here, but
that's not what's being committed here.
Reported-by: David Kimura
Reviewed-by: Richard Guo, David Kimura
Discussion: https://postgr.es/m/CAHnPFjQ5qxs6J_p+g8=ww7GQvfn71_JE+Tygj0S7RdRci1uwPw@mail.gmail.com
Backpatch-through: 11, all supported versions
M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
Fix parallel-safety marking when moving initplans to another node.
commit : 96c698e3ff8b4bc4ba19dcaf0f7e6429ad4e8dfc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Apr 2023 10:46:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Apr 2023 10:46:30 -0400
Our policy since commit ab77a5a45 has been that a plan node having
any initplans is automatically not parallel-safe. (This could be
relaxed, but not today.) clean_up_removed_plan_level neglected
this, and could attach initplans to a parallel-safe child plan
node without clearing the plan's parallel-safe flag. That could
lead to "subplan was not initialized" errors at runtime, in case
an initplan referenced another one and only the referencing one
got transmitted to parallel workers.
The fix in clean_up_removed_plan_level is trivial enough.
materialize_finished_plan also moves initplans from one node
to another, but it's okay because it already copies the source
node's parallel_safe flag. The other place that does this kind
of thing is standard_planner's hack to inject a top-level Gather
when debug_parallel_query is active. But that's actually dead
code given that we're correctly enforcing the "initplans aren't
parallel safe" rule, so just replace it with an Assert that
there are no initplans.
Also improve some related comments.
Normally we'd add a regression test case for this sort of bug.
The mistake itself is already reached by existing tests, but there
is accidentally no visible problem. The only known test case that
creates an actual failure seems too indirect and fragile to justify
keeping it as a regression test (not least because it fails to fail
in v11, though the bug is clearly present there too).
Per report from Justin Pryzby. Back-patch to all supported branches.
Discussion: https://postgr.es/m/ZDVt6MaNWkRDO1LQ@telsasoft.com
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/plan/setrefs.c
M src/backend/optimizer/plan/subselect.c
M src/backend/optimizer/util/pathnode.c
For Kerberos testing, disable DNS lookups
commit : 154bcce3ba9d9817bdb5bd628b611d56fc434c46
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 7 Apr 2023 19:36:10 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 7 Apr 2023 19:36:10 -0400
Similar to 8dff2f224, this disables DNS lookups by the Kerberos library
to look up the KDC and the realm while the Kerberos tests are running.
In some environments, these lookups can take a long time and end up
timing out and causing tests to fail. Further, since this isn't really
our domain, we shouldn't be sending out these DNS requests during our
tests.
M src/test/kerberos/t/001_auth.pl
For Kerberos testing, disable reverse DNS lookup
commit : cd018a2b3f2479377ec62e9d8f738c603df24192
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 7 Apr 2023 19:36:10 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 7 Apr 2023 19:36:10 -0400
In our Kerberos test suite, there isn't much need to worry about the
normal canonicalization that Kerberos provides by looking up the reverse
DNS for the IP address connected to, and in some cases it can actively
cause problems (eg: a captive portal wifi where the normally not
resolvable localhost address used ends up being resolved anyway, and
not to the domain we are using for testing, causing the entire
regression test to fail with errors about not being able to get a TGT
for the remote realm for cross-realm trust).
Therefore, disable it by adding rdns = false into the krb5.conf that's
generated for the test.
Reviewed-By: Heikki Linnakangas
Discussion: https://postgr.es/m/Y/QD2zDkDYQA1GQt@tamriel.snowman.net
M src/test/kerberos/t/001_auth.pl
Stabilize just-added regression test cases.
commit : 16188d88ecc604a2dd68d717811fcfd6a112526f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Apr 2023 18:13:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Apr 2023 18:13:49 -0400
The tests added by commits 029dea882 et al turn out to produce
different output under -DRANDOMIZE_ALLOCATED_MEMORY. This is
not a bug exactly: that flag causes coerce_type() to invoke
the input function twice when coercing an unknown-type literal
to a specific type. So you get tsqueryin's bleat about an empty
tsquery twice. Revise the test query to avoid that.
Discussion: https://postgr.es/m/20230406213813.uep7plg6lvcywujo@awork3.anarazel.de
M src/test/regress/expected/tsearch.out
M src/test/regress/sql/tsearch.sql
Fix ts_headline() edge cases for empty query and empty search text.
commit : b7d6c51d4693765354a1f60e6eb45010bddf023d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Apr 2023 15:52:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 6 Apr 2023 15:52:37 -0400
tsquery's GETQUERY() macro is only safe to apply to a tsquery
that is known non-empty; otherwise it gives a pointer to garbage.
Before commit 5a617d75d, ts_headline() avoided this pitfall, but
only in a very indirect, nonobvious way. (hlCover could not reach
its TS_execute call, because if the query contains no lexemes
then hlFirstIndex would surely return -1.) After that commit,
it fell into the trap, resulting in weird errors such as
"unrecognized operator" and/or valgrind complaints. In HEAD,
fix this by not calling TS_execute_locations() at all for an
empty query. In the back branches, add a defensive check to
hlCover() --- that's not fixing any live bug, but I judge the
code a bit too fragile as-is.
Also, both mark_hl_fragments() and mark_hl_words() were careless
about the possibility of empty search text: in the cases where
no match has been found, they'd end up telling mark_fragment() to
mark from word indexes 0 to 0 inclusive, even when there is no
word 0. This is harmless since we over-allocated the prs->words
array, but it does annoy valgrind. Fix so that the end index is -1
and thus mark_fragment() will do nothing in such cases.
Bottom line is that this fixes a live bug in HEAD, but in the
back branches it's only getting rid of a valgrind nitpick.
Back-patch anyway.
Per report from Alexander Lakhin.
Discussion: https://postgr.es/m/c27f642d-020b-01ff-ae61-086af287c4fd@gmail.com
M src/backend/tsearch/wparser_def.c
M src/test/regress/expected/tsearch.out
M src/test/regress/sql/tsearch.sql
Fix another issue with ENABLE/DISABLE TRIGGER on partitioned tables.
commit : b02bf1e46048ff4b8e9138fb0d5c1fa442fd7380
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 5 Apr 2023 12:56:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 5 Apr 2023 12:56:30 -0400
In v13 and v14, the ENABLE/DISABLE TRIGGER USER variant malfunctioned
on cloned triggers, failing to find the clones because it thought they
were system triggers. Other variants of ENABLE/DISABLE TRIGGER would
improperly apply a superuserness check. Fix by adjusting the is-it-
a-system-trigger check to match reality in those branches. (As far
as I can find, this is the only place that got it wrong.)
There's no such bug in v15/HEAD, because we revised the catalog
representation of system triggers to be what this code was expecting.
However, add the test case to these branches anyway, because this area
is visibly pretty fragile. Also remove an obsoleted comment.
The recent v15/HEAD commit 6949b921d fixed a nearby bug. I now see
that my commit message for that was inaccurate: the behavior of
recursing to clone triggers is older than v15, but it didn't apply
to the case in v13/v14 because in those branches parent partitioned
tables have no pg_trigger entries for foreign-key triggers. But add
the test case from that commit to v13/v14, just to show what is
happening there.
Per bug #17886 from DzmitryH.
Discussion: https://postgr.es/m/17886-5406d5d828aa4aa3@postgresql.org
M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
doc: Update error messages in RLS examples
commit : ba8fd17be04a763d0249d64f56659183ce86b1f6
author : John Naylor <john.naylor@postgresql.org>
date : Wed, 5 Apr 2023 14:16:19 +0700
committer: John Naylor <john.naylor@postgresql.org>
date : Wed, 5 Apr 2023 14:16:19 +0700
Since 8b9e9644d, the messages for failed permissions checks report
"table" where appropriate, rather than "relation".
Backpatch to all supported branches
M doc/src/sgml/ddl.sgml
doc: Add more details about pg_stat_get_xact_blocks_{fetched,hit}
commit : f7a057ac7eb1d9b2257d703b0958d82e30d17e13
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 5 Apr 2023 07:59:54 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 5 Apr 2023 07:59:54 +0900
The explanation describing the dependency to system read() calls for
these two functions has been removed in ddfc2d9. And after more
discussion about d69c404, we have concluded that adding more details
makes them easier to understand.
While on it, use the term "block read requests" (maybe found in cache)
rather than "buffers fetched" and "buffer hits".
Per discussion with Melanie Plageman, Kyotaro Horiguchi, Bertrand
Drouvot and myself.
Discussion: https://postgr.es/m/CAAKRu_ZmdiScT4q83OAbfmR5AH-L5zWya3SXjaxiJvhCob-e2A@mail.gmail.com
Backpatch-through: 11
M doc/src/sgml/monitoring.sgml
Reject system columns as elements of foreign keys.
commit : bfb993b1bbd137b5ea0a4f14bddd57ac46dac494
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 Mar 2023 11:18:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 Mar 2023 11:18:49 -0400
Up through v11 it was sensible to use the "oid" system column as
a foreign key column, but since that was removed there's no visible
usefulness in making any of the remaining system columns a foreign
key. Moreover, since the TupleTableSlot rewrites in v12, such cases
actively fail because of implicit assumptions that only user columns
appear in foreign keys. The lack of complaints about that seems
like good evidence that no one is trying to do it. Hence, rather
than trying to repair those assumptions (of which there are at least
two, maybe more), let's just forbid the case up front.
Per this patch, a system column in either the referenced or
referencing side of a foreign key will draw this error; however,
putting one in the referenced side would have failed later anyway,
since we don't allow unique indexes to be made on system columns.
Per bug #17877 from Alexander Lakhin. Back-patch to v12; the
case still appears to work in v11, so we shouldn't break it there.
Discussion: https://postgr.es/m/17877-4bcc658e33df6de1@postgresql.org
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Ensure acquire_inherited_sample_rows sets its output parameters.
commit : 65266d90f85cb819711d91172c4600feeb3f19f5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 Mar 2023 10:08:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 Mar 2023 10:08:40 -0400
The totalrows/totaldeadrows outputs were left uninitialized in cases
where we find no analyzable child tables of a partitioned table. This
could lead to setting the partitioned table's pg_class.reltuples value
to garbage. It's not clear that that would have any very bad effects
in practice, but fix it anyway because it's making valgrind unhappy.
Reported and diagnosed by Alexander Lakhin (bug #17880).
Discussion: https://postgr.es/m/17880-9282037c923d856e@postgresql.org
M src/backend/commands/analyze.c
Fix List memory issue in transformColumnDefinition
commit : 8d684c44511a5302a0f6c88feef51866a0f8f591
author : David Rowley <drowley@postgresql.org>
date : Fri, 31 Mar 2023 12:14:31 +1300
committer: David Rowley <drowley@postgresql.org>
date : Fri, 31 Mar 2023 12:14:31 +1300
When calling generateSerialExtraStmts(), we would pass in the
constraint->options. In some cases, generateSerialExtraStmts() would
modify the referenced List to remove elements from it, but doing so is
invalid without assigning the list back to all variables that point to it.
In the particular reported problem case, the List became empty, in which
cases it became NIL, but the passed in constraint->options didn't get to
find out about that and was left pointing to free'd memory.
To fix this, just perform a list_copy() inside generateSerialExtraStmts().
We could just do a list_copy() just before we perform the delete from the
list, however, that seems less robust. Let's make sure the generated
CreateSeqStmt gets a completely different copy of the list to be safe.
Bug: #17879
Reported-by: Fei Changhong
Diagnosed-by: Fei Changhong
Discussion: https://postgr.es/m/17879-b7dfb5debee58ff5@postgresql.org
Backpatch-through: 11, all supported versions
M src/backend/parser/parse_utilcmd.c
Fix dereference of dangling pointer in GiST index buffering build.
commit : 2adb6adad5f804dbd4f4240bb07e7ffbe6153b6a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 29 Mar 2023 11:31:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 29 Mar 2023 11:31:30 -0400
gistBuildCallback tried to fetch the size of an index tuple that
might have already been freed by gistProcessEmptyingQueue.
While this seems to usually be harmless in production builds,
in principle it could result in a SIGSEGV, or more likely a bogus
value for indtuplesSize leading to poor page-split decisions later
in the build.
The memory management here is confusing and could stand to be
refactored, but for the moment it seems to be enough to fetch
the tuple size sooner. AFAICT the indtuples[Size] totals aren't
used in between these places; even if they were, the updated
values shouldn't be any worse to use. So just move the
incrementing of the totals up.
It's not very clear why our valgrind-using buildfarm animals
haven't noticed this problem, because the relevant code path
does seem to be exercised according to the code coverage report.
I think the reason that we didn't fix this bug after the first
report is that I'd wanted to try to understand that better.
However, now that it's been re-discovered let's just be pragmatic
and fix it already.
Original report by Alexander Lakhin (bug #16329),
later rediscovered by Egor Chindyaskin (bug #17874).
Patch by Alexander Lakhin (commentary by Pavel Borisov and me).
Back-patch to all supported branches.
Discussion: https://postgr.es/m/16329-7a6aa9b6fa1118a1@postgresql.org
Discussion: https://postgr.es/m/17874-63ca6c7ce42d2103@postgresql.org
M src/backend/access/gist/gistbuild.c
doc: Fix XML_CATALOG_FILES env var for Apple Silicon machines
commit : 9850ef9fc123e479562011ae308bdabe5bfc04c3
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Mon, 27 Mar 2023 21:35:24 +0200
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Mon, 27 Mar 2023 21:35:24 +0200
Homebrew changed the prefix for Apple Silicon based machines, so
our advice for XML_CATALOG_FILES needs to mention both. More info
on the Homebrew change can be found at:
https://github.com/Homebrew/brew/issues/9177
This is backpatch of commits 4c8d65408 and 5a91c7975, the latter
which contained a small fix based on a report from Dagfinn Ilmari
Mannsåker.
Author: Julien Rouhaud <julien.rouhaud@free.fr>
Discussion: https://postgr.es/m/20230327082441.h7pa2vqiobbyo7rd@jrouhaud
M doc/src/sgml/docguide.sgml
Reject attempts to alter composite types used in indexes.
commit : 29a20ff0617ab60acbb8d71b6b59f9035c86a4f8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 27 Mar 2023 15:04:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 27 Mar 2023 15:04:02 -0400
find_composite_type_dependencies() ignored indexes, which is a poor
decision because an expression index could have a stored column of
a composite (or other container) type even when the underlying table
does not. Teach it to detect such cases and error out. We have to
work a bit harder than for other relations because the pg_depend entry
won't identify the specific index column of concern, but it's not much
new code.
This does not address bug #17872's original complaint that dropping
a column in such a type might lead to violations of the uniqueness
property that a unique index is supposed to ensure. That seems of
much less concern to me because it won't lead to crashes.
Per bug #17872 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/17872-d0fbb799dc3fd85d@postgresql.org
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Fix oversights in array manipulation.
commit : 1bbbe14607c3590c977dc0aeddfdc10680f6bd39
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 Mar 2023 13:41:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 Mar 2023 13:41:06 -0400
The nested-arrays code path in ExecEvalArrayExpr() used palloc to
allocate the result array, whereas every other array-creating function
has used palloc0 since 18c0b4ecc. This mostly works, but unused bits
past the end of the nulls bitmap may end up undefined. That causes
valgrind complaints with -DWRITE_READ_PARSE_PLAN_TREES, and could
cause planner misbehavior as cited in 18c0b4ecc. There seems no very
good reason why we should strive to avoid palloc0 in just this one case,
so fix it the easy way with s/palloc/palloc0/.
While looking at that I noted that we also failed to check for overflow
of "nbytes" and "nitems" while summing the sizes of the sub-arrays,
potentially allowing a crash due to undersized output allocation.
For "nbytes", follow the policy used by other array-munging code of
checking for overflow after each addition. (As elsewhere, the last
addition of the array's overhead space doesn't need an extra check,
since palloc itself will catch a value between 1Gb and 2Gb.)
For "nitems", there's no very good reason to sum the inputs at all,
since we can perfectly well use ArrayGetNItems' result instead of
ignoring it.
Per discussion of this bug, also remove redundant zeroing of the
nulls bitmap in array_set_element and array_set_slice.
Patch by Alexander Lakhin and myself, per bug #17858 from Alexander
Lakhin; thanks also to Richard Guo. These bugs are a dozen years old,
so back-patch to all supported branches.
Discussion: https://postgr.es/m/17858-8fd287fd3663d051@postgresql.org
M src/backend/executor/execExprInterp.c
M src/backend/utils/adt/arrayfuncs.c
Ignore generated columns during apply of update/delete.
commit : be52fff91dc9682386f3371308121c2a5be5922e
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 23 Mar 2023 11:21:13 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 23 Mar 2023 11:21:13 +0530
We fail to apply updates and deletes when the REPLICA IDENTITY FULL is
used for the table having generated columns. We didn't use to ignore
generated columns while doing tuple comparison among the tuples from
the publisher and subscriber during apply of updates and deletes.
Author: Onder Kalaci
Reviewed-by: Shi yu, Amit Kapila
Backpatch-through: 12
Discussion: https://postgr.es/m/CACawEhVQC9WoofunvXg12aXtbqKnEgWxoRx3+v8q32AWYsdpGg@mail.gmail.com
M src/backend/executor/execReplication.c
M src/test/subscription/t/100_bugs.pl
doc: Add description of some missing monitoring functions
commit : 4a1e9e7a1391bd4584b7b760c29b6807e9f0182b
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 22 Mar 2023 18:32:06 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 22 Mar 2023 18:32:06 +0900
This commit adds some documentation about two monitoring functions:
- pg_stat_get_xact_blocks_fetched()
- pg_stat_get_xact_blocks_hit()
The description of these functions has been removed in ddfc2d9, later
simplified by 5f2b089, assuming that all the functions whose
descriptions were removed are used in system views. Unfortunately, some
of them were are not used in any system views, so they lacked
documentation.
This gap exists in the docs for a long time, so backpatch all the way
down.
Reported-by: Michael Paquier
Author: Bertrand Drouvot
Reviewed-by: Kyotaro Horiguchi
Discussion: https://postgr.es/m/ZBeeH5UoNkTPrwHO@paquier.xyz
Backpatch-through: 11
M doc/src/sgml/monitoring.sgml
Ignore dropped columns during apply of update/delete.
commit : 751d6676daf3413f7c0fbc83860238d02114dbcd
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Mar 2023 09:07:37 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 21 Mar 2023 09:07:37 +0530
We fail to apply updates and deletes when the REPLICA IDENTITY FULL is
used for the table having dropped columns. We didn't use to ignore dropped
columns while doing tuple comparison among the tuples from the publisher
and subscriber during apply of updates and deletes.
Author: Onder Kalaci, Shi yu
Reviewed-by: Amit Kapila
Discussion: https://postgr.es/m/CACawEhVQC9WoofunvXg12aXtbqKnEgWxoRx3+v8q32AWYsdpGg@mail.gmail.com
M src/backend/executor/execReplication.c
M src/test/subscription/t/100_bugs.pl
Fix race in parallel hash join batch cleanup, take II.
commit : 6e94d62e3f04b03c95bd707e43ba32147d35908e
author : Thomas Munro <tmunro@postgresql.org>
date : Tue, 21 Mar 2023 14:29:34 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Tue, 21 Mar 2023 14:29:34 +1300
With unlucky timing and parallel_leader_participation=off (not the
default), PHJ could attempt to access per-batch shared state just as it
was being freed. There was code intended to prevent that by checking
for a cleared pointer, but it was racy. Fix, by introducing an extra
barrier phase. The new phase PHJ_BUILD_RUNNING means that it's safe to
access the per-batch state to find a batch to help with, and
PHJ_BUILD_DONE means that it is too late. The last to detach will free
the array of per-batch state as before, but now it will also atomically
advance the phase, so that late attachers can avoid the hazard. This
mirrors the way per-batch hash tables are freed (see phases
PHJ_BATCH_PROBING and PHJ_BATCH_DONE).
An earlier attempt to fix this (commit 3b8981b6, later reverted) missed
one special case. When the inner side is empty (the "empty inner
optimization), the build barrier would only make it to
PHJ_BUILD_HASHING_INNER phase before workers attempted to detach from
the hashtable. In that case, fast-forward the build barrier to
PHJ_BUILD_RUNNING before proceeding, so that our later assertions hold
and we can still negotiate who is cleaning up.
Revealed by build farm failures, where BarrierAttach() failed a sanity
check assertion, because the memory had been clobbered by dsa_free().
In non-assert builds, the result could be a segmentation fault.
Back-patch to all supported releases.
Author: Thomas Munro <thomas.munro@gmail.com>
Author: Melanie Plageman <melanieplageman@gmail.com>
Reported-by: Michael Paquier <michael@paquier.xyz>
Reported-by: David Geier <geidav.pg@gmail.com>
Tested-by: David Geier <geidav.pg@gmail.com>
Discussion: https://postgr.es/m/20200929061142.GA29096%40paquier.xyz
M src/backend/executor/nodeHash.c
M src/backend/executor/nodeHashjoin.c
M src/include/executor/hashjoin.h
Doc: fix documentation example for bytea hex output format.
commit : d28f441d3232ee5b5c3d0c8505618c8696f5db72
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 Mar 2023 16:11:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 Mar 2023 16:11:22 -0400
Per report from rsindlin
Discussion: https://postgr.es/m/167907221210.1803488.5939223864945604536@wrigleys.postgresql.org
M doc/src/sgml/datatype.sgml
Fix pg_dump for hash partitioning on enum columns.
commit : 7e7c5b683985c85fb990c4d49ab960cbc83434b4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Mar 2023 13:31:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Mar 2023 13:31:40 -0400
Hash partitioning on an enum is problematic because the hash codes are
derived from the OIDs assigned to the enum values, which will almost
certainly be different after a dump-and-reload than they were before.
This means that some rows probably end up in different partitions than
before, causing restore to fail because of partition constraint
violations. (pg_upgrade dodges this problem by using hacks to force
the enum values to keep the same OIDs, but that's not possible nor
desirable for pg_dump.)
Users can work around that by specifying --load-via-partition-root,
but since that's a dump-time not restore-time decision, one might
find out the need for it far too late. Instead, teach pg_dump to
apply that option automatically when dealing with a partitioned
table that has hash-on-enum partitioning.
Also deal with a pre-existing issue for --load-via-partition-root
mode: in a parallel restore, we try to TRUNCATE target tables just
before loading them, in order to enable some backend optimizations.
This is bad when using --load-via-partition-root because (a) we're
likely to suffer deadlocks from restore jobs trying to restore rows
into other partitions than they came from, and (b) if we miss getting
a deadlock we might still lose data due to a TRUNCATE removing rows
from some already-completed restore job.
The fix for this is conceptually simple: just don't TRUNCATE if we're
dealing with a --load-via-partition-root case. The tricky bit is for
pg_restore to identify those cases. In dumps using COPY commands we
can inspect each COPY command to see if it targets the nominal target
table or some ancestor. However, in dumps using INSERT commands it's
pretty impractical to examine the INSERTs in advance. To provide a
solution for that going forward, modify pg_dump to mark TABLE DATA
items that are using --load-via-partition-root with a comment.
(This change also responds to a complaint from Robert Haas that
the dump output for --load-via-partition-root is pretty confusing.)
pg_restore checks for the special comment as well as checking the
COPY command if present. This will fail to identify the combination
of --load-via-partition-root and --inserts in pre-existing dump files,
but that should be a pretty rare case in the field. If it does
happen you will probably get a deadlock failure that you can work
around by not using parallel restore, which is the same as before
this bug fix.
Having done this, there seems no remaining reason for the alarmism
in the pg_dump man page about combining --load-via-partition-root
with parallel restore, so remove that warning.
Patch by me; thanks to Julien Rouhaud for review. Back-patch to
v11 where hash partitioning was introduced.
Discussion: https://postgr.es/m/1376149.1675268279@sss.pgh.pa.us
M doc/src/sgml/ref/pg_dump.sgml
M doc/src/sgml/ref/pg_dumpall.sgml
M src/bin/pg_dump/common.c
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
A src/bin/pg_dump/t/004_pg_dump_parallel.pl
tests: Prevent syslog activity by slapd, take 2
commit : ee880034aac4d315a5aa398c8803715da3d2af97
author : Andres Freund <andres@anarazel.de>
date : Thu, 16 Mar 2023 23:03:31 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 16 Mar 2023 23:03:31 -0700
Unfortunately it turns out that the logfile-only option added in b9f8d1cbad7
is only available in openldap starting in 2.6.
Luckily the option to control the log level (loglevel/-s) have been around for
much longer. As it turns out loglevel/-s only control what goes into syslog,
not what ends up in the file specified with 'logfile' and stderr.
While we currently are specifying 'logfile', nothing ends up in it, as the
option only controls debug messages, and we didn't set a debug level. The
debug level can only be configured on the commandline and also prevents
forking. That'd require larger changes, so this commit doesn't tackle that
issue.
Specify the syslog level when starting slapd using -s, as that allows to
prevent all syslog messages if one uses '0' instead of 'none', while loglevel
doesn't prevent the first message.
Discussion: https://postgr.es/m/20230311233708.3yjdbjkly2q4gq2j@awork3.anarazel.de
Backpatch: 11-
M src/test/ldap/t/001_auth.pl
tests: Minimize syslog activity by slapd
commit : f6f5acc6bc1e162d67b3944f18750f0ae13d2e8e
author : Andres Freund <andres@anarazel.de>
date : Thu, 16 Mar 2023 17:48:47 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 16 Mar 2023 17:48:47 -0700
Until now the tests using slapd spammed syslog for every connection /
query. Use logfile-only to prevent syslog activity. Unfortunately that only
takes effect after logging the first message, but that's still much better
than the prior situation.
Discussion: https://postgr.es/m/20230311233708.3yjdbjkly2q4gq2j@awork3.anarazel.de
Backpatch: 11-
M src/test/ldap/t/001_auth.pl
Small tidyup for commit d41a178b, part II.
commit : 77a8133c959b9b1facee5fb86755444fe84cd9ce
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 17 Mar 2023 14:44:12 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 17 Mar 2023 14:44:12 +1300
Further to commit 6a9229da, checking for NULL is now redundant. An "out
of memory" error would have been thrown already by palloc() and treated
as FATAL, so we can delete a few more lines.
Back-patch to all releases, like those other commits.
Reported-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/4040668.1679013388%40sss.pgh.pa.us
M src/backend/postmaster/postmaster.c
Work around spurious compiler warning in inet operators
commit : 51cb789aa42055ced51d6ba3312ec621133cdc86
author : Andres Freund <andres@anarazel.de>
date : Thu, 16 Mar 2023 14:08:44 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 16 Mar 2023 14:08:44 -0700
gcc 12+ has complaints like the following:
../../../../../pgsql/src/backend/utils/adt/network.c: In function 'inetnot':
../../../../../pgsql/src/backend/utils/adt/network.c:1893:34: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
1893 | pdst[nb] = ~pip[nb];
| ~~~~~~~~~^~~~~~~~~~
../../../../../pgsql/src/include/utils/inet.h:27:23: note: at offset -1 into destination object 'ipaddr' of size 16
27 | unsigned char ipaddr[16]; /* up to 128 bits of address */
| ^~~~~~
../../../../../pgsql/src/include/utils/inet.h:27:23: note: at offset -1 into destination object 'ipaddr' of size 16
This is due to a compiler bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
It has been a year since the bug has been reported without getting fixed. As
the warnings are verbose and use of gcc 12 is becoming more common, it seems
worth working around the bug. Particularly because a simple reformulation of
the loop condition fixes the issue and isn't any less readable.
Author: Tom Lane <tgl@sss.pgh.pa.us>
Author: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/144536.1648326206@sss.pgh.pa.us
Backpatch: 11-
M src/backend/utils/adt/network.c
Small tidyup for commit d41a178b.
commit : 798dae9f65e379c0f4f22d7a6096287ea50ffb41
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 17 Mar 2023 09:44:42 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 17 Mar 2023 09:44:42 +1300
A comment was left behind claiming that we needed to use malloc() rather
than palloc() because the corresponding free would run in another
thread, but that's not true anymore. Remove that comment. And, with
the reason being gone, we might as well actually use palloc().
Back-patch to supported releases, like d41a178b.
Discussion: https://postgr.es/m/CA%2BhUKG%2BpdM9v3Jv4tc2BFx2jh_daY3uzUyAGBhtDkotEQDNPYw%40mail.gmail.com
M src/backend/postmaster/postmaster.c
Fix waitpid() emulation on Windows.
commit : 9f1c64018549e28a6f6aa5ad0d5917085520efdd
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 15 Mar 2023 13:17:18 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 15 Mar 2023 13:17:18 +1300
Our waitpid() emulation didn't prevent a PID from being recycled by the
OS before the call to waitpid(). The postmaster could finish up
tracking more than one child process with the same PID, and confuse
them.
Fix, by moving the guts of pgwin32_deadchild_callback() into waitpid(),
so that resources are released synchronously. The process and PID
continue to exist until we close the process handle, which only happens
once we're ready to adjust our book-keeping of running children.
This seems to explain a couple of failures on CI. It had never been
reported before, despite the code being as old as the Windows port.
Perhaps Windows started recycling PIDs more rapidly, or perhaps timing
changes due to commit 7389aad6 made it more likely to break.
Thanks to Alexander Lakhin for analysis and Andres Freund for tracking
down the root cause.
Back-patch to all supported branches.
Reported-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/20230208012852.bvkn2am4h4iqjogq%40awork3.anarazel.de
M src/backend/postmaster/postmaster.c
Fix corner case bug in numeric to_char() some more.
commit : 386a26023afb624726fb756ffdbef5b5832caa96
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Mar 2023 19:17:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 Mar 2023 19:17:31 -0400
The band-aid applied in commit f0bedf3e4 turns out to still need
some work: it made sure we didn't set Np->last_relevant too small
(to the left of the decimal point), but it didn't prevent setting
it too large (off the end of the partially-converted string).
This could result in fetching data beyond the end of the allocated
space, which with very bad luck could cause a SIGSEGV, though
I don't see any hazard of interesting memory disclosure.
Per bug #17839 from Thiago Nunes. The bug's pretty ancient,
so back-patch to all supported versions.
Discussion: https://postgr.es/m/17839-aada50db24d7b0da@postgresql.org
M src/backend/utils/adt/formatting.c
M src/test/regress/expected/numeric.out
M src/test/regress/sql/numeric.sql
Fix JSON error reporting for many cases of erroneous string values.
commit : 52e9a781656edefb10e8371d46a1a6d62c1bbb11
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Mar 2023 15:19:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Mar 2023 15:19:00 -0400
The majority of error exit cases in json_lex_string() failed to
set lex->token_terminator, causing problems for the error context
reporting code: it would see token_terminator less than token_start
and do something more or less nuts. In v14 and up the end result
could be as bad as a crash in report_json_context(). Older
versions accidentally avoided that fate; but all versions produce
error context lines that are far less useful than intended,
because they'd stop at the end of the prior token instead of
continuing to where the actually-bad input is.
To fix, invent some macros that make it less notationally painful
to do the right thing. Also add documentation about what the
function is actually required to do; and in >= v14, add an assertion
in report_json_context about token_terminator being sufficiently
far advanced.
Per report from Nikolay Shaplov. Back-patch to all supported
versions.
Discussion: https://postgr.es/m/7332649.x5DLKWyVIX@thinkpad-pgpro
M src/common/jsonapi.c
M src/test/regress/expected/json_encoding.out
M src/test/regress/expected/json_encoding_1.out
Fix failure to detect some cases of improperly-nested aggregates.
commit : bc0bcce2e74bf777b458e3fd815bb125dbda2ce6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Mar 2023 12:40:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 Mar 2023 12:40:28 -0400
check_agg_arguments_walker() supposed that it needn't descend into
the arguments of a lower-level aggregate function, but this is
just wrong in the presence of multiple levels of sub-select. The
oversight would lead to executor failures on queries that should
be rejected. (Prior to v11, they actually were rejected, thanks
to a "redundant" execution-time check.)
Per bug #17835 from Anban Company. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/17835-4f29f3098b2d0ba4@postgresql.org
M src/backend/parser/parse_agg.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql
Fix inconsistent error handling for GSS encryption in PQconnectPoll()
commit : 96bef4374e450b2bd387cbfaad9371db3ac0669a
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 13 Mar 2023 16:36:33 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 13 Mar 2023 16:36:33 +0900
The error cases for TLS and GSS encryption were inconsistent. After TLS
fails, the connection is marked as dead and follow-up calls of
PQconnectPoll() would return immediately, but GSS encryption was not
doing that, so the connection would still have been allowed to enter the
GSS handling code. This was handled incorrectly when gssencmode was set
to "require". "prefer" was working correctly, and this could not happen
under "disable" as GSS encryption would not be attempted.
This commit makes the error handling of GSS encryption on par with TLS
portion, fixing the case of gssencmode=require.
Reported-by: Jacob Champion
Author: Michael Paquier
Reviewed-by: Jacob Champion, Stephen Frost
Discussion: https://postgr.es/m/23787477-5fe1-a161-6d2a-e459f74c4713@timescale.com
Backpatch-through: 12
M src/interfaces/libpq/fe-connect.c
Mark unsafe_tests module as not runnable with installcheck
commit : baf7f450dbecaf5333e372502a6d7d20c9482af1
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 12 Mar 2023 09:00:32 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 12 Mar 2023 09:00:32 -0400
This was an omission in the original creation of the module.
Also slightly adjust some wording to avoid a double "is".
Backpatch the non-meson piece of this to release 12, where the module
was introduced.
Discussion: https://postgr.es/m/be869e1c-8e3f-4cde-8609-212c899cccf9@dunslane.net
M src/test/modules/unsafe_tests/Makefile
M src/test/modules/unsafe_tests/README
Fix misbehavior in contrib/pg_trgm with an unsatisfiable regex.
commit : bc436e4a917a7185847e05797249ea889214bffe
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 11 Mar 2023 12:15:41 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 11 Mar 2023 12:15:41 -0500
If the regex compiler can see that a regex is unsatisfiable
(for example, '$foo') then it may emit an NFA having no arcs.
pg_trgm's packGraph function did the wrong thing in this case;
it would access off the end of a work array, and with bad luck
could produce a corrupted output data structure causing more
problems later. This could end with wrong answers or crashes
in queries using a pg_trgm GIN or GiST index with such a regex.
Fix by not trying to de-duplicate if there aren't at least 2 arcs.
Per bug #17830 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/17830-57ff5f89bdb02b09@postgresql.org
M contrib/pg_trgm/expected/pg_word_trgm.out
M contrib/pg_trgm/sql/pg_word_trgm.sql
M contrib/pg_trgm/trgm_regexp.c
Ensure COPY TO on an RLS-enabled table copies no more than it should.
commit : 866fd004d9f94b87d453642c0c854d38884d3d3d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Mar 2023 13:52:28 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 Mar 2023 13:52:28 -0500
The COPY documentation is quite clear that "COPY relation TO" copies
rows from only the named table, not any inheritance children it may
have. However, if you enabled row-level security on the table then
this stopped being true, because the code forgot to apply the ONLY
modifier in the "SELECT ... FROM relation" query that it constructs
in order to allow RLS predicates to be attached. Fix that.
Report and patch by Antonin Houska (comment adjustments and test case
by me). Back-patch to all supported branches.
Discussion: https://postgr.es/m/3472.1675251957@antos
M src/backend/commands/copy.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Fix race in SERIALIZABLE READ ONLY.
commit : ae632f7a31470ca2298bfef79a957dd19678726a
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 9 Mar 2023 16:33:24 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 9 Mar 2023 16:33:24 +1300
Commit bdaabb9b started skipping doomed transactions when building the
list of possible conflicts for SERIALIZABLE READ ONLY. That makes
sense, because doomed transactions won't commit, but a couple of subtle
things broke:
1. If all uncommitted r/w transactions are doomed, a READ ONLY
transaction would arbitrarily not benefit from the safe snapshot
optimization. It would not be taken immediately, and yet no other
transaction would set SXACT_FLAG_RO_SAFE later.
2. In the same circumstances but with DEFERRABLE, GetSafeSnapshot()
would correctly exit its wait loop without sleeping and then take the
optimization in non-assert builds, but assert builds would fail a sanity
check that SXACT_FLAG_RO_SAFE had been set by another transaction.
This is similar to the case for PredXact->WritableSxactCount == 0. We
should opt out immediately if our possibleUnsafeConflicts list is empty
after filtering.
The code to maintain the serializable global xmin is moved down below
the new opt out site, because otherwise we'd have to reverse its effects
before returning.
Back-patch to all supported releases. Bug #17368.
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/17116-d6ca217acc180e30%40postgresql.org
Discussion: https://postgr.es/m/20110707212159.GF76634%40csail.mit.edu
M src/backend/storage/lmgr/predicate.c
Fix corruption due to vacuum_defer_cleanup_age underflowing 64bit xids
commit : e6d77f22c7a8bed88ceef3a3267931f4ce988664
author : Andres Freund <andres@anarazel.de>
date : Tue, 7 Mar 2023 21:36:51 -0800
committer: Andres Freund <andres@anarazel.de>
date : Tue, 7 Mar 2023 21:36:51 -0800
When vacuum_defer_cleanup_age is bigger than the current xid, including the
epoch, the subtraction of vacuum_defer_cleanup_age would lead to a wrapped
around xid. While that normally is not a problem, the subsequent conversion to
a 64bit xid results in a 64bit-xid very far into the future. As that xid is
used as a horizon to detect whether rows versions are old enough to be
removed, that allows removal of rows that are still visible (i.e. corruption).
If vacuum_defer_cleanup_age was never changed from the default, there is no
chance of this bug occurring.
This bug was introduced in dc7420c2c92. A lesser version of it exists in
12-13, introduced by fb5344c969a, affecting only GiST.
The 12-13 version of the issue can, in rare cases, lead to pages in a gist
index getting recycled too early, potentially causing index entries to be
found multiple times.
The fix is fairly simple - don't allow vacuum_defer_cleanup_age to retreat
further than FirstNormalTransactionId.
Patches to make similar bugs easier to find, by adding asserts to the 64bit
xid infrastructure, have been proposed, but are not suitable for backpatching.
Currently there are no tests for vacuum_defer_cleanup_age. A patch introducing
infrastructure to make writing a test easier has been posted to the list.
Reported-by: Michail Nikolaev <michail.nikolaev@gmail.com>
Reviewed-by: Matthias van de Meent <boekewurm+postgres@gmail.com>
Author: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/20230108002923.cyoser3ttmt63bfn@awork3.anarazel.de
Backpatch: 12-, but impact/fix is smaller for 12-13
M src/backend/utils/time/snapmgr.c
Fix more bugs caused by adding columns to the end of a view.
commit : 695b34ab359d84cf8ea94f15852f12bbf04bb038
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Mar 2023 18:21:37 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Mar 2023 18:21:37 -0500
If a view is defined atop another view, and then CREATE OR REPLACE
VIEW is used to add columns to the lower view, then when the upper
view's referencing RTE is expanded by ApplyRetrieveRule we will have
a subquery RTE with fewer eref->colnames than output columns. This
confuses various code that assumes those lists are always in sync,
as they are in plain parser output.
We have seen such problems before (cf commit d5b760ecb), and now
I think the time has come to do what was speculated about in that
commit: let's make ApplyRetrieveRule synthesize some column names to
preserve the invariant that holds in parser output. Otherwise we'll
be chasing this class of bugs indefinitely. Moreover, it appears from
testing that this actually gives us better results in the test case
d5b760ecb added, and likely in other corner cases that we lack
coverage for.
In HEAD, I replaced d5b760ecb's hack to make expandRTE exit early with
an elog(ERROR) call, since the case is now presumably unreachable.
But it seems like changing that in back branches would bring more risk
than benefit, so there I just updated the comment.
Per bug #17811 from Alexander Lakhin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/17811-d31686b78f0dffc9@postgresql.org
M src/backend/parser/parse_relation.c
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Fix some more cases of missed GENERATED-column updates.
commit : 4a94cbd02b2cc637c4a7636a1e7fefee43bff8f6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Mar 2023 18:31:16 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Mar 2023 18:31:16 -0500
If UPDATE is forced to retry after an EvalPlanQual check, it neglected
to repeat GENERATED-column computations, even though those might well
have changed since we're dealing with a different tuple than before.
Fixing this is mostly a matter of looping back a bit further when
we retry. In v15 and HEAD that's most easily done by altering the API
of ExecUpdateAct so that it includes computing GENERATED expressions.
Also, if an UPDATE in a partitioned table turns into a cross-partition
INSERT operation, we failed to recompute GENERATED columns. That's a
bug since 8bf6ec3ba allowed partitions to have different generation
expressions; although it seems to have no ill effects before that.
Fixing this is messier because we can now have situations where the same
query needs both the UPDATE-aligned set of GENERATED columns and the
INSERT-aligned set, and it's unclear which set will be generated first
(else we could hack things by forcing the INSERT-aligned set to be
generated, which is indeed how fe9e658f4 made it work for MERGE).
The best fix seems to be to build and store separate sets of expressions
for the INSERT and UPDATE cases. That would create ABI issues in the
back branches, but so far it seems we can leave this alone in the back
branches.
Per bug #17823 from Hisahiro Kauchi. The first part of this affects all
branches back to v12 where GENERATED columns were added.
Discussion: https://postgr.es/m/17823-b64909cf7d63de84@postgresql.org
M src/backend/executor/execUtils.c
M src/backend/executor/nodeModifyTable.c
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec
M src/test/regress/expected/generated.out
M src/test/regress/sql/generated.sql
Fix assert failures in parallel SERIALIZABLE READ ONLY.
commit : a0f55fc86ab7adde027351f5c9596a3814ddea83
author : Thomas Munro <tmunro@postgresql.org>
date : Mon, 6 Mar 2023 15:07:15 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Mon, 6 Mar 2023 15:07:15 +1300
1. Make sure that we don't decrement SxactGlobalXminCount twice when
the SXACT_FLAG_RO_SAFE optimization is reached in a parallel query.
This could trigger a sanity check failure in assert builds. Non-assert
builds recompute the count in SetNewSxactGlobalXmin(), so the problem
was hidden, explaining the lack of field reports. Add a new isolation
test to exercise that case.
2. Remove an assertion that the DOOMED flag can't be set on a partially
released SERIALIZABLEXACT. Instead, ignore the flag (our transaction
was already determined to be read-only safe, and DOOMED is in fact set
during partial release, and there was already an assertion that it
wasn't set sooner). Improve an existing isolation test so that it
reaches that case (previously it wasn't quite testing what it was
supposed to be testing; see discussion).
Back-patch to 12. Bug #17116. Defects in commit 47a338cf.
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/17116-d6ca217acc180e30%40postgresql.org
M src/backend/storage/lmgr/predicate.c
M src/test/isolation/expected/serializable-parallel-2.out
A src/test/isolation/expected/serializable-parallel-3.out
M src/test/isolation/isolation_schedule
M src/test/isolation/specs/serializable-parallel-2.spec
A src/test/isolation/specs/serializable-parallel-3.spec
Avoid fetching one past the end of translate()'s "to" parameter.
commit : 3b37e844220d4e7cedbb8def7fbcd2b36703d65d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Mar 2023 11:30:17 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 1 Mar 2023 11:30:17 -0500
This is usually harmless, but if you were very unlucky it could
provoke a segfault due to the "to" string being right up against
the end of memory. Found via valgrind testing (so we might've
found it earlier, except that our regression tests lacked any
exercise of translate()'s deletion feature).
Fix by switching the order of the test-for-end-of-string and
advance-pointer steps. While here, compute "to_ptr + tolen"
just once. (Smarter compilers might figure that out for
themselves, but let's just make sure.)
Report and fix by Daniil Anisimov, in bug #17816.
Discussion: https://postgr.es/m/17816-70f3d2764e88a108@postgresql.org
M src/backend/utils/adt/oracle_compat.c
M src/test/regress/expected/strings.out
M src/test/regress/sql/strings.sql
Don't force SQL_ASCII/no-locale for installcheck in vcregress.pl
commit : ab5b76c07a0e920f106228a5e54043cb5cd298b7
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 26 Feb 2023 06:48:41 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 26 Feb 2023 06:48:41 -0500
It's been this way for a very long time, but it appears to have been
masking an issue that only manifests with different settings. Therefore,
run the tests in the installation's default encoding/locale.
Backpatch to all live branches.
M src/tools/msvc/vcregress.pl
Fix MULTIEXPR_SUBLINK with partitioned target tables, yet again.
commit : 1e199c25994791842fe2f80c0809c2e69a3a7d2e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Feb 2023 14:44:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Feb 2023 14:44:14 -0500
We already tried to fix this in commits 3f7323cbb et al (and follow-on
fixes), but now it emerges that there are still unfixed cases;
moreover, these cases affect all branches not only pre-v14. I thought
we had eliminated all cases of making multiple clones of an UPDATE's
target list when we nuked inheritance_planner. But it turns out we
still do that in some partitioned-UPDATE cases, notably including
INSERT ... ON CONFLICT UPDATE, because ExecInitPartitionInfo thinks
it's okay to clone and modify the parent's targetlist.
This fix is based on a suggestion from Andres Freund: let's stop
abusing the ParamExecData.execPlan mechanism, which was only ever
meant to handle initplans, and instead solve the execution timing
problem by having the expression compiler move MULTIEXPR_SUBLINK steps
to the front of their expression step lists. This is feasible because
(a) all branches still in support compile the entire targetlist of
an UPDATE into a single ExprState, and (b) we know that all
MULTIEXPR_SUBLINKs do need to be evaluated --- none could be buried
inside a CASE, for example. There is a minor semantics change
concerning the order of execution of the MULTIEXPR's subquery versus
other parts of the parent targetlist, but that seems like something
we can get away with. By doing that, we no longer need to worry
about whether different clones of a MULTIEXPR_SUBLINK share output
Params; their usage of that data structure won't overlap.
Per bug #17800 from Alexander Lakhin. Back-patch to all supported
branches. In v13 and earlier, we can revert 3f7323cbb and follow-on
fixes; however, I chose to keep the SubPlan.subLinkId field added
in ccbb54c72. We don't need that anymore in the core code, but it's
cheap enough to fill, and removing a plan node field in a minor
release seems like it'd be asking for trouble.
Andres Freund and Tom Lane
Discussion: https://postgr.es/m/17800-ff90866b3906c964@postgresql.org
M src/backend/executor/execExpr.c
M src/backend/executor/nodeSubplan.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/plan/subselect.c
M src/include/nodes/primnodes.h
M src/include/optimizer/subselect.h
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
Fix mishandling of OLD/NEW references in subqueries in rule actions.
commit : 39ad791e851022bc88feca4637118e7b589f5f3a
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 25 Feb 2023 14:45:44 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 25 Feb 2023 14:45:44 +0000
If a rule action contains a subquery that refers to columns from OLD
or NEW, then those are really lateral references, and the planner will
complain if it sees such things in a subquery that isn't marked as
lateral. However, at rule-definition time, the user isn't required to
mark the subquery with LATERAL, and so it can fail when the rule is
used.
Fix this by marking such subqueries as lateral in the rewriter, at the
point where they're used.
Dean Rasheed and Tom Lane, per report from Alexander Lakhin.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/5e09da43-aaba-7ea7-0a51-a2eb981b058b%40gmail.com
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/rules.out
M src/test/regress/sql/rules.sql
Don't repeatedly register cache callbacks in pgoutput plugin.
commit : 861e9e48601b41ab3827ba5d22990c17ed6dcf8c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 23 Feb 2023 15:40:28 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 23 Feb 2023 15:40:28 -0500
Multiple cycles of starting up and shutting down the plugin within a
single session would eventually lead to "out of relcache_callback_list
slots", because pgoutput_startup blindly re-registered its cache
callbacks each time. Fix it to register them only once, as all other
users of cache callbacks already take care to do.
This has been broken all along, so back-patch to all supported branches.
Shi Yu
Discussion: https://postgr.es/m/OSZPR01MB631004A78D743D68921FFAD3FDA79@OSZPR01MB6310.jpnprd01.prod.outlook.com
M src/backend/replication/pgoutput/pgoutput.c
Fix multi-row DEFAULT handling for INSERT ... SELECT rules.
commit : 226da3d4767083b58b9d1acf67b1402865d359bf
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 23 Feb 2023 10:56:41 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Thu, 23 Feb 2023 10:56:41 +0000
Given an updatable view with a DO ALSO INSERT ... SELECT rule, a
multi-row INSERT ... VALUES query on the view fails if the VALUES list
contains any DEFAULTs that are not replaced by view defaults. This
manifests as an "unrecognized node type" error, or an Assert failure,
in an assert-enabled build.
The reason is that when RewriteQuery() attempts to replace the
remaining DEFAULT items with NULLs in any product queries, using
rewriteValuesRTEToNulls(), it assumes that the VALUES RTE is located
at the same rangetable index in each product query. However, if the
product query is an INSERT ... SELECT, then the VALUES RTE is actually
in the SELECT part of that query (at the same index), rather than the
top-level product query itself.
Fix, by descending to the SELECT in such cases. Note that we can't
simply use getInsertSelectQuery() for this, since that expects to be
given a raw rule action with OLD and NEW placeholder entries, so we
duplicate its logic instead.
While at it, beef up the checks in getInsertSelectQuery() by checking
that the jointree->fromlist node is indeed a RangeTblRef, and that the
RTE it points to has rtekind == RTE_SUBQUERY.
Per bug #17803, from Alexander Lakhin. Back-patch to all supported
branches.
Dean Rasheed, reviewed by Tom Lane.
Discussion: https://postgr.es/m/17803-53c63ed4ecb4eac6%40postgresql.org
M src/backend/rewrite/rewriteHandler.c
M src/backend/rewrite/rewriteManip.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql
Fix snapshot handling in logicalmsg_decode
commit : 4df581fa0f4b663141901d87817f77ec695c6d22
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 22 Feb 2023 15:24:09 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 22 Feb 2023 15:24:09 +0100
Whe decoding a transactional logical message, logicalmsg_decode called
SnapBuildGetOrBuildSnapshot. But we may not have a consistent snapshot
yet at that point. We don't actually need the snapshot in this case
(during replay we'll have the snapshot from the transaction), so in
practice this is harmless. But in assert-enabled build this crashes.
Fixed by requesting the snapshot only in non-transactional case, where
we are guaranteed to have SNAPBUILD_CONSISTENT.
Backpatch to 11. The issue exists since 9.6.
Backpatch-through: 11
Reviewed-by: Andres Freund
Discussion: https://postgr.es/m/84d60912-6eab-9b84-5de3-41765a5449e8@enterprisedb.com
M src/backend/replication/logical/decode.c
M src/backend/replication/logical/reorderbuffer.c
Add missing support for the latest SPI status codes.
commit : 906356cf6128ac6e35bcb07f7fd5361eb76c4999
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 22 Feb 2023 13:27:29 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 22 Feb 2023 13:27:29 +0000
SPI_result_code_string() was missing support for SPI_OK_TD_REGISTER,
and in v15 and later, it was missing support for SPI_OK_MERGE, as was
pltcl_process_SPI_result().
The last of those would trigger an error if a MERGE was executed from
PL/Tcl. The others seem fairly innocuous, but worth fixing.
Back-patch to all supported branches. Before v15, this is just adding
SPI_OK_TD_REGISTER to SPI_result_code_string(), which is unlikely to
be seen by anyone, but seems worth doing for completeness.
Reviewed by Tom Lane.
Discussion:
https://postgr.es/m/CAEZATCUg8V%2BK%2BGcafOPqymxk84Y_prXgfe64PDoopjLFH6Z0Aw%40mail.gmail.com
https://postgr.es/m/CAEZATCUMe%2B_KedPMM9AxKqm%3DSZogSxjUcrMe%2BsakusZh3BFcQw%40mail.gmail.com
M src/backend/executor/spi.c
Fix erroneous Valgrind markings in AllocSetRealloc.
commit : 99e74cd235a5cb7d58eadfc627e4e1b1ebac1231
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 Feb 2023 18:47:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 Feb 2023 18:47:47 -0500
If asked to decrease the size of a large (>8K) palloc chunk,
AllocSetRealloc could improperly change the Valgrind state of memory
beyond the new end of the chunk: it would mark data UNDEFINED as far
as the old end of the chunk after having done the realloc(3) call,
thus tromping on the state of memory that no longer belongs to it.
One would normally expect that memory to now be marked NOACCESS,
so that this mislabeling might prevent detection of later errors.
If realloc() had chosen to move the chunk someplace else (unlikely,
but well within its rights) we could also mismark perfectly-valid
DEFINED data as UNDEFINED, causing false-positive valgrind reports
later. Also, any malloc bookkeeping data placed within this area
might now be wrongly marked, causing additional problems.
Fix by replacing relevant uses of "oldsize" with "Min(size, oldsize)".
It's sufficient to mark as far as "size" when that's smaller, because
whatever remains in the new chunk size will be marked NOACCESS below,
and we expect realloc() to have taken care of marking the memory
beyond the new official end of the chunk.
While we're here, also rename the function's "oldsize" variable
to "oldchksize" to more clearly explain what it actually holds,
namely the distance to the end of the chunk (that is, requested size
plus trailing padding). This is more consistent with the use of
"size" and "chksize" to hold the new requested size and chunk size.
Add a new variable "oldsize" in the one stanza where we're actually
talking about the old requested size.
Oversight in commit c477f3e44. Back-patch to all supported branches,
as that was, just in case anybody wants to do valgrind testing on back
branches.
Karina Litskevich
Discussion: https://postgr.es/m/CACiT8iaAET-fmzjjZLjaJC4zwSJmrFyL7LAdHwaYyjjQOQ4hcg@mail.gmail.com
M src/backend/utils/mmgr/aset.c
Print the correct aliases for DML target tables in ruleutils.
commit : 4efb4f0d48787fbdf42c0b760f19c997664f0d56
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Feb 2023 16:40:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Feb 2023 16:40:34 -0500
ruleutils.c blindly printed the user-given alias (or nothing if there
hadn't been one) for the target table of INSERT/UPDATE/DELETE queries.
That works a large percentage of the time, but not always: for queries
appearing in WITH, it's possible that we chose a different alias to
avoid conflict with outer-scope names. Since the chosen alias would
be used in any Var references to the target table, this'd lead to an
inconsistent printout with consequences such as dump/restore failures.
The correct logic for printing (or not) a relation alias was embedded
in get_from_clause_item. Factor it out to a separate function so that
we don't need a jointree node to use it. (Only a limited part of that
function can be reached from these new call sites, but this seems like
the cleanest non-duplicative factorization.)
In passing, I got rid of a redundant "\d+ rules_src" step in rules.sql.
Initial report from Jonathan Katz; thanks to Vignesh C for analysis.
This has been broken for a long time, so back-patch to all supported
branches.
Discussion: https://postgr.es/m/e947fa21-24b2-f922-375a-d4f763ef3e4b@postgresql.org
Discussion: https://postgr.es/m/CALDaNm1MMntjmT_NJGp-Z=xbF02qHGAyuSHfYHias3TqQbPF2w@mail.gmail.com
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/rules.out
M src/test/regress/sql/rules.sql
Fix handling of SCRAM-SHA-256's channel binding with RSA-PSS certificates
commit : 2eb8e54cc373e4e4f9ecf7360563912f9c40ad76
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 15 Feb 2023 10:12:36 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 15 Feb 2023 10:12:36 +0900
OpenSSL 1.1.1 and newer versions have added support for RSA-PSS
certificates, which requires the use of a specific routine in OpenSSL to
determine which hash function to use when compiling it when using
channel binding in SCRAM-SHA-256. X509_get_signature_nid(), that is the
original routine the channel binding code has relied on, is not able to
determine which hash algorithm to use for such certificates. However,
X509_get_signature_info(), new to OpenSSL 1.1.1, is able to do it. This
commit switches the channel binding logic to rely on
X509_get_signature_info() over X509_get_signature_nid(), which would be
the choice when building with 1.1.1 or newer.
The error could have been triggered on the client or the server, hence
libpq and the backend need to have their related code paths patched.
Note that attempting to load an RSA-PSS certificate with OpenSSL 1.1.0
or older leads to a failure due to an unsupported algorithm.
The discovery of relying on X509_get_signature_info() comes from Jacob,
the tests have been written by Heikki (with few tweaks from me), while I
have bundled the whole together while adding the bits needed for MSVC
and meson.
This issue exists since channel binding exists, so backpatch all the way
down. Some tests are added in 15~, triggered if compiling with OpenSSL
1.1.1 or newer, where the certificate and key files can easily be
generated for RSA-PSS.
Reported-by: Gunnar "Nick" Bluth
Author: Jacob Champion, Heikki Linnakangas
Discussion: https://postgr.es/m/17760-b6c61e752ec07060@postgresql.org
Backpatch-through: 11
M configure
M configure.in
M src/backend/libpq/be-secure-openssl.c
M src/include/libpq/libpq-be.h
M src/include/pg_config.h.in
M src/interfaces/libpq/fe-secure-openssl.c
M src/interfaces/libpq/libpq-int.h
M src/tools/msvc/Solution.pm
Disable WindowAgg inverse transitions when subplans are present
commit : 301eb3ee4ecd366c92bc8ecda9c42c3760e018c1
author : David Rowley <drowley@postgresql.org>
date : Mon, 13 Feb 2023 17:09:26 +1300
committer: David Rowley <drowley@postgresql.org>
date : Mon, 13 Feb 2023 17:09:26 +1300
When an aggregate function is used as a WindowFunc and a tuple transitions
out of the window frame, we ordinarily try to make use of the aggregate
function's inverse transition function to "unaggregate" the exiting tuple.
This optimization is disabled for various cases, including when the
aggregate contains a volatile function. In such a case we'd be unable to
ensure that the transition value was calculated to the same value during
transitions and inverse transitions. Unfortunately, we did this check by
calling contain_volatile_functions() which does not recursively search
SubPlans for volatile functions. If the aggregate function's arguments or
its FILTER clause contained a subplan with volatile functions then we'd
fail to notice this.
Here we fix this by just disabling the optimization when the WindowFunc
contains any subplans. Volatile functions are not the only reason that a
subplan may have nonrepeatable results.
Bug: #17777
Reported-by: Anban Company
Discussion: https://postgr.es/m/17777-860b739b6efde977%40postgresql.org
Reviewed-by: Tom Lane
Backpatch-through: 11
M src/backend/executor/nodeWindowAgg.c
Stop recommending auto-download of DTD files, and indeed disable it.
commit : c7b608600547426b1a3181f9b6d4d2e117624e1e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Feb 2023 17:15:23 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Feb 2023 17:15:23 -0500
It appears no longer possible to build the SGML docs without a local
installation of the DocBook DTD, because sourceforge.net now only
permits HTTPS access, and no common version of xsltproc supports that.
Hence, remove the bits of our documentation suggesting that that's
possible or useful.
In fact, we might as well add the --nonet option to the build recipes
automatically, for a bit of extra security.
Also fix our documentation-tool-installation recipes for macOS to
ensure that xmllint and xsltproc are pulled in from MacPorts or
Homebrew. The previous recipes assumed you could use the
Apple-supplied versions of these tools; which still works, except that
you'd need to set an environment variable to ensure that they would
find DTD files provided by those package managers. Simpler and easier
to just recommend pulling in the additional packages.
In HEAD, also document how to build docs using Meson, and adjust
"ninja docs" to just build the HTML docs, for consistency with the
default behavior of doc/src/sgml/Makefile.
In a fit of neatnik-ism, I also made the ordering of the package
lists match the order in which the tools are described at the head
of the appendix.
Aleksander Alekseev, Peter Eisentraut, Tom Lane
Discussion: https://postgr.es/m/CAJ7c6TO8Aro2nxg=EQsVGiSDe-TstP4EsSvDHd7DSRsP40PgGA@mail.gmail.com
M doc/src/sgml/Makefile
M doc/src/sgml/docguide.sgml
M doc/src/sgml/images/Makefile
Make EXEC_BACKEND more convenient on Linux and FreeBSD.
commit : 1e4fda6da918f734dd6dab67b3ddcaba4c2fecb2
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 8 Feb 2023 13:09:49 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 8 Feb 2023 13:09:49 +0900
Try to disable ASLR when building in EXEC_BACKEND mode, to avoid random
memory mapping failures while testing. For developer use only, no
effect on regular builds.
This has been originally applied as of f3e7806 for v15~, but
recently-added buildfarm member gokiburi tests this configuration on
older branches as well, causing it to fail randomly as ASLR would be
enabled.
Suggested-by: Andres Freund <andres@anarazel.de>
Tested-by: Bossart, Nathan <bossartn@amazon.com>
Discussion: https://postgr.es/m/20210806032944.m4tz7j2w47mant26%40alap3.anarazel.de
Backpatch-through: 12
M configure
M configure.in
M src/bin/pg_ctl/pg_ctl.c
M src/common/exec.c
M src/include/pg_config.h.in
M src/include/port.h
M src/test/regress/pg_regress.c
M src/tools/msvc/Solution.pm