Stamp 13.10.
commit : 20aba55fae83cd0b6f7511365d172da8cd7e0135
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2023 16:42:56 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2023 16:42:56 -0500
M configure
M configure.in
Last-minute updates for release notes.
commit : 6926350d6b90181193e776d3313c49226cbca2ea
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2023 11:43:10 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2023 11:43:10 -0500
Security: CVE-2022-41862
M doc/src/sgml/release-13.sgml
Translation updates
commit : 07113f15cd123aa2279cb37e0e848766e050225b
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 6 Feb 2023 12:18:46 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 6 Feb 2023 12:18:46 +0100
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: a7bebd06a02093ea07899fc0804adeb372126620
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/ja.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/bin/initdb/po/ru.po
M src/bin/pg_archivecleanup/po/ru.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetwal/po/ru.po
M src/bin/pg_rewind/po/ru.po
M src/bin/pg_test_fsync/po/ru.po
M src/bin/pg_test_timing/po/ru.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_verifybackup/po/ru.po
M src/bin/pg_waldump/po/ru.po
M src/bin/psql/po/de.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/sv.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/ru.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/po/ru.po
Properly NULL-terminate GSS receive buffer on error packet reception
commit : 45a945ee97b8b55a45d2ff5d4f4944b1e2dcacb8
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 6 Feb 2023 11:20:27 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 6 Feb 2023 11:20:27 +0900
pqsecure_open_gss() includes a code path handling error messages with
v2-style protocol messages coming from the server. The client-side
buffer holding the error message does not force a NULL-termination, with
the data of the server getting copied to the errorMessage of the
connection. Hence, it would be possible for a server to send an
unterminated string and copy arbitrary bytes in the buffer receiving the
error message in the client, opening the door to a crash or even data
exposure.
As at this stage of the authentication process the exchange has not been
completed yet, this could be abused by an attacker without Kerberos
credentials. Clients that have a valid kerberos cache are vulnerable as
libpq opportunistically requests for it except if gssencmode is
disabled.
Author: Jacob Champion
Backpatch-through: 12
Security: CVE-2022-41862
M src/interfaces/libpq/fe-secure-gssapi.c
Release notes for 15.2, 14.7, 13.10, 12.14, 11.19.
commit : 70192be7bd9ecc5e1e18989ab7a90ac00ce90e9b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Feb 2023 16:22:32 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 Feb 2023 16:22:32 -0500
M doc/src/sgml/release-13.sgml
doc: Fix XML formatting that psql cannot handle
commit : c7b31ecc27f4056a40e17432dc17c1aeffe5d117
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 3 Feb 2023 09:04:35 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 3 Feb 2023 09:04:35 +0100
Breaking <phrase> over two lines is not handled by psql's
create_help.pl. (It creates faulty \help output.)
Undo the formatting change introduced by
9bdad1b5153e5d6b77a8f9c6e32286d6bafcd76d to fix this for now.
M doc/src/sgml/ref/fetch.sgml
M doc/src/sgml/ref/move.sgml
Update time zone data files to tzdata release 2022g.
commit : 20d9da10727d6562ca11e18b1e65cf6174d3902e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 Jan 2023 17:36:55 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 Jan 2023 17:36:55 -0500
DST law changes in Greenland and Mexico. Notably, a new timezone
America/Ciudad_Juarez has been split off from America/Ojinaga.
Historical corrections for northern Canada, Colombia, and Singapore.
M src/timezone/data/tzdata.zi
Doc: clarify use of NULL to drop comments and security labels.
commit : 5fb1809eb966ec04ce2ec8fa4f0c382092659f03
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 Jan 2023 14:32:24 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 31 Jan 2023 14:32:24 -0500
This was only mentioned in the description of the text/label, which
are marked as being in quotes in the synopsis, which can cause
confusion (as witnessed on IRC).
Also separate the literal and NULL cases in the parameter list, per
suggestion from Tom Lane.
Also add an example of dropping a security label.
Dagfinn Ilmari Mannsåker, with some tweaks by me
Discussion: https://postgr.es/m/87sffqk4zp.fsf@wibble.ilmari.org
M doc/src/sgml/ref/comment.sgml
M doc/src/sgml/ref/security_label.sgml
Remove recovery test 011_crash_recovery.pl
commit : ee11824ac4c228b354c71991d7ef14c4496bcfe5
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 31 Jan 2023 12:47:15 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 31 Jan 2023 12:47:15 +0900
This test has been added as of 857ee8e that has introduced the SQL
function txid_status(), with the purpose of checking that a transaction
ID still in-progress during a crash is correctly marked as aborted after
recovery finishes.
This test is unstable, and some configuration scenarios may that easier
to reproduce (wal_level=minimal, wal_compression=on) because the WAL
holding the information about the in-progress transaction ID may not
have made it to disk yet, hence a post-crash recovery may cause the same
XID to be reused, triggering a test failure.
We have discussed a few approaches, like making this function force a
WAL flush to make it reliable across crashes, but we don't want to pay a
performance penalty in some scenarios, as well. The test could have
been tweaked to enforce a checkpoint but that actually breaks the
promise of the test to rely on a stable result of txid_status() after
a crash.
This issue has been reported a few times across the past years, with an
original report from Kyotaro Horiguchi. The buildfarm machines tanager,
hachi and gokiburi enable wal_compression, and fail on this test
periodically.
Discussion: https://postgr.es/m/3163112.1674762209@sss.pgh.pa.us
Discussion: https://postgr.es/m/20210305.115011.558061052471425531.horikyota.ntt@gmail.com
Backpatch-through: 11
D src/test/recovery/t/011_crash_recovery.pl
Fix rare sharedtuplestore.c corruption.
commit : 1a5afe007779b677c4f2e411f8d9af23f7a2d085
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 26 Jan 2023 14:50:07 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 26 Jan 2023 14:50:07 +1300
If the final chunk of an oversized tuple being written out to disk was
exactly 32760 bytes, it would be corrupted due to a fencepost bug.
Bug #17619. Back-patch to 11 where the code arrived.
While testing that (see test module in archives), I (tmunro) noticed
that the per-participant page counter was not initialized to zero as it
should have been; that wasn't a live bug when it was written since DSM
memory was originally always zeroed, but since 14
min_dynamic_shared_memory might be configured and it supplies non-zeroed
memory, so that is also fixed here.
Author: Dmitry Astapov <dastapov@gmail.com>
Discussion: https://postgr.es/m/17619-0de62ceda812b8b5%40postgresql.org
M src/backend/utils/sort/sharedtuplestore.c
Fix error handling in libpqrcv_connect()
commit : c5864805ba99f79b49b12dc14499da58b0e15eb8
author : Andres Freund <andres@anarazel.de>
date : Mon, 23 Jan 2023 18:04:02 -0800
committer: Andres Freund <andres@anarazel.de>
date : Mon, 23 Jan 2023 18:04:02 -0800
When libpqrcv_connect (also known as walrcv_connect()) failed, it leaked the
libpq connection. In most paths that's fairly harmless, as the calling process
will exit soon after. But e.g. CREATE SUBSCRIPTION could lead to a somewhat
longer lived leak.
Fix by releasing resources, including the libpq connection, on error.
Add a test exercising the error code path. To make it reliable and safe, the
test tries to connect to port=-1, which happens to fail during connection
establishment, rather than during connection string parsing.
Reviewed-by: Noah Misch <noah@leadboat.com>
Discussion: https://postgr.es/m/20230121011237.q52apbvlarfv6jm6@awork3.anarazel.de
Backpatch: 11-
M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
M src/test/regress/expected/subscription.out
M src/test/regress/sql/subscription.sql
Allow REPLICA IDENTITY to be set on an index that's not (yet) valid.
commit : 72d611109e65e279aa5719aba9831761f6f6c368
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Jan 2023 13:10:29 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Jan 2023 13:10:29 -0500
The motivation for this change is that when pg_dump dumps a
partitioned index that's marked REPLICA IDENTITY, it generates a
command sequence that applies REPLICA IDENTITY before the partitioned
index has been marked valid, causing restore to fail. We could
perhaps change pg_dump to not do it like that, but that would be
difficult and would not fix existing dump files with the problem.
There seems to be very little reason for the backend to disallow
this anyway --- the code ignores indisreplident when the index
isn't valid --- so instead let's fix it by allowing the case.
Commit 9511fb37a previously expressed a concern that allowing
indisreplident to be set on invalid indexes might allow us to
wind up in a situation where a table could have indisreplident
set on multiple indexes. I'm not sure I follow that concern
exactly, but in any case the only way that could happen is because
relation_mark_replica_identity is too trusting about the existing set
of markings being valid. Let's just rip out its early-exit code path
(which sure looks like premature optimization anyway; what are we
doing expending code to make redundant ALTER TABLE ... REPLICA
IDENTITY commands marginally faster and not-redundant ones marginally
slower?) and fix it to positively guarantee that no more than one
index is marked indisreplident.
The pg_dump failure can be demonstrated in all supported branches,
so back-patch all the way. I chose to back-patch 9511fb37a as well,
just to keep indisreplident handling the same in all branches.
Per bug #17756 from Sergey Belyashov.
Discussion: https://postgr.es/m/17756-dd50e8e0c8dd4a40@postgresql.org
M src/backend/catalog/index.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/replica_identity.out
M src/test/regress/sql/replica_identity.sql
Reject CancelRequestPacket having unexpected length.
commit : a9bccffe5a39dab64ca597476563f8d965b46428
author : Noah Misch <noah@leadboat.com>
date : Sat, 21 Jan 2023 06:08:00 -0800
committer: Noah Misch <noah@leadboat.com>
date : Sat, 21 Jan 2023 06:08:00 -0800
When the length was too short, the server read outside the allocation.
That yielded the same log noise as sending the correct length with
(backendPID,cancelAuthCode) matching nothing. Change to a message about
the unexpected length. Given the attacker's lack of control over the
memory layout and the general lack of diversity in memory layouts at the
code in question, we doubt a would-be attacker could cause a segfault.
Hence, while the report arrived via security@postgresql.org, this is not
a vulnerability. Back-patch to v11 (all supported versions).
Andrey Borodin, reviewed by Tom Lane. Reported by Andrey Borodin.
M src/backend/postmaster/postmaster.c
Make our back branches build under -fkeep-inline-functions.
commit : c78f109b87d8a64b0f785bf6fa30d4bd29742638
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Jan 2023 11:58:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Jan 2023 11:58:12 -0500
Add "#ifndef FRONTEND" where necessary to make pg_waldump build
on compilers that don't elide unused static-inline functions.
This back-patches relevant parts of commit 3e9ca5260, fixing build
breakage from dc7420c2c and back-patching of f10f0ae42.
Per recently-resurrected buildfarm member castoroides. We aren't
expecting castoroides to build anything newer than v11, but we
might as well clean up the intermediate branches while at it.
M src/include/utils/rel.h
Log the correct ending timestamp in recovery_target_xid mode.
commit : 1b9a0b96a8701ddcd147836241f89d616772d332
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Jan 2023 12:23:20 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Jan 2023 12:23:20 -0500
When ending recovery based on recovery_target_xid matching with
recovery_target_inclusive = off, we printed an incorrect timestamp
(always 2000-01-01) in the "recovery stopping before ... transaction"
log message. This is a consequence of sloppy refactoring in
c945af80c: the code to fetch recordXtime out of the commit/abort
record used to be executed unconditionally, but it was changed
to get called only in the RECOVERY_TARGET_TIME case. We need only
flip the order of operations to restore the intended behavior.
Per report from Torsten Förtsch. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/CAKkG4_kUevPqbmyOfLajx7opAQk6Cvwkvx0HRcFjSPfRPTXanA@mail.gmail.com
M src/backend/access/transam/xlog.c
Add missing assign hook for GUC checkpoint_completion_target
commit : fed4e92f3bfd4dfbbee472fb4b0b86d9b9100a3c
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Jan 2023 13:13:30 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Jan 2023 13:13:30 +0900
This is wrong since 88e9823, that has switched the WAL sizing
configuration from checkpoint_segments to min_wal_size and
max_wal_size. This missed the recalculation of the internal value of
the internal "CheckPointSegments", that works as a mapping of the old
GUC checkpoint_segments, on reload, for example, and it controls the
timing of checkpoints depending on the volume of WAL generated.
Most users tend to leave checkpoint_completion_target at 0.9 to smooth
the I/O workload, which is why I guess this has gone unnoticed for so
long, still it can be useful to tweak and reload the value dynamically
in some cases to control the timing of checkpoints.
Author: Bharath Rupireddy
Discussion: https://postgr.es/m/CALj2ACXgPPAm28mruojSBno+F_=9cTOOxHAywu_dfZPeBdybQw@mail.gmail.com
Backpatch-through: 11
M src/backend/utils/misc/guc.c
Fix failure with perlcritic in psql's create_help.pl
commit : dfe96d6130694e43bf078de0c9e39b55bc222b7a
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Jan 2023 10:02:12 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Jan 2023 10:02:12 +0900
No buildfarm members have reported that yet, but a recently-refreshed
Debian host did.
Reviewed-by: Andrew Dunstan
Discussion: https://postgr.es/m/Y8ey5z4Nav62g4/K@paquier.xyz
Backpatch-through: 11
M src/bin/psql/create_help.pl
AdjustUpgrade.pm should zap test_ext_cine, too.
commit : 1136d81bfa7f902a14fd426a97ecd99381d72953
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Jan 2023 16:00:39 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Jan 2023 16:00:39 -0500
test_extensions' test_ext_cine extension has the same upgrade hazard
as test_ext7: the regression test leaves it in an updated state
from which no downgrade path to default is provided. This causes
the update_extensions.sql script helpfully provided by pg_upgrade
to fail. So drop it in cross-version-upgrade testing.
Not entirely sure how come I didn't hit this in testing yesterday;
possibly I'd built the upgrade reference databases with
testmodules-install-check disabled.
Backpatch to v10 where this module was introduced.
M src/test/perl/PostgreSQL/Test/AdjustUpgrade.pm
Create common infrastructure for cross-version upgrade testing.
commit : 3f0b9df88bb33ec52b0af8b11295d256d2011e29
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 16 Jan 2023 20:35:53 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 16 Jan 2023 20:35:53 -0500
To test pg_upgrade across major PG versions, we have to be able to
modify or drop any old objects with no-longer-supported properties,
and we have to be able to deal with cosmetic changes in pg_dump output.
Up to now, the buildfarm and pg_upgrade's own test infrastructure had
separate implementations of the former, and we had nothing but very
ad-hoc rules for the latter (including an arbitrary threshold on how
many lines of unchecked diff were okay!). This patch creates a Perl
module that can be shared by both those use-cases, and adds logic
that deals with pg_dump output diffs in a much more tightly defined
fashion.
This largely supersedes previous efforts in commits 0df9641d3,
9814ff550, and 62be9e4cd, which developed a SQL-script-based solution
for the task of dropping old objects. There was nothing fundamentally
wrong with that work in itself, but it had no basis for solving the
output-formatting problem. The most plausible way to deal with
formatting is to build a Perl module that can perform editing on the
dump files; and once we commit to that, it makes more sense for the
same module to also embed the knowledge of what has to be done for
dropping old objects.
Back-patch versions of the helper module as far as 9.2, to
support buildfarm animals that still test that far back.
It's also necessary to back-patch PostgreSQL/Version.pm,
because the new code depends on that. I fixed up pg_upgrade's
002_pg_upgrade.pl in v15, but did not look into back-patching
it further than that.
Tom Lane and Andrew Dunstan
Discussion: https://postgr.es/m/891521.1673657296@sss.pgh.pa.us
D src/bin/pg_upgrade/upgrade_adapt.sql
A src/test/perl/PostgreSQL/Test/AdjustUpgrade.pm
A src/test/perl/PostgreSQL/Version.pm
Fix some BufFileRead() error reporting
commit : cf74b6eadb9d8fcfd51a99e9cc6b04d019e36b12
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 16 Jan 2023 09:20:44 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 16 Jan 2023 09:20:44 +0100
Remove "%m" from error messages where errno would be bogus. Add short
read byte counts where appropriate.
This is equivalent to what was done in
7897e3bb902c557412645b82120f4d95f7474906, but some code was apparently
developed concurrently to that and not updated accordingly.
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/f3501945-c591-8cc3-5ef0-b72a2e0eaa9c@enterprisedb.com
M src/backend/replication/backup_manifest.c
Make new GENERATED-expressions code more bulletproof.
commit : 787db4be947c2be419c4e97ba9d611708f2523c5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Jan 2023 14:06:46 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Jan 2023 14:06:46 -0500
In commit 8bf6ec3ba I assumed that no code path could reach
ExecGetExtraUpdatedCols without having gone through
ExecInitStoredGenerated. That turns out not to be the case in
logical replication: if there's an ON UPDATE trigger on the target
table, trigger.c will call this code before anybody has set up its
generated columns. Having seen that, I don't have a lot of faith in
there not being other such paths. ExecGetExtraUpdatedCols can call
ExecInitStoredGenerated for itself, as long as we are willing to
assume that it is only called in CMD_UPDATE operations, which on
the whole seems like a safer leap of faith.
Per report from Vitaly Davydov.
Discussion: https://postgr.es/m/d259d69652b8c2ff50e14cda3c236c7f@postgrespro.ru
M src/backend/executor/execUtils.c
M src/backend/executor/nodeModifyTable.c
M src/include/executor/nodeModifyTable.h
M src/test/subscription/t/011_generated.pl
Fix WaitEventSetWait() buffer overrun.
commit : c159b0383fa6412686abfb4e6de9face87d2b0cc
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 13 Jan 2023 10:40:52 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 13 Jan 2023 10:40:52 +1300
The WAIT_USE_EPOLL and WAIT_USE_KQUEUE implementations of
WaitEventSetWaitBlock() confused the size of their internal buffer with
the size of the caller's output buffer, and could ask the kernel for too
many events. In fact the set of events retrieved from the kernel needs
to be able to fit in both buffers, so take the smaller of the two.
The WAIT_USE_POLL and WAIT_USE WIN32 implementations didn't have this
confusion.
This probably didn't come up before because we always used the same
number in both places, but commit 7389aad6 calculates a dynamic size at
construction time, while using MAXLISTEN for its output event buffer on
the stack. That seems like a reasonable thing to want to do, so
consider this to be a pre-existing bug worth fixing.
As discovered by valgrind on skink.
Back-patch to all supported releases for epoll, and to release 13 for
the kqueue part, which copied the incorrect epoll code.
Reviewed-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/901504.1673504836%40sss.pgh.pa.us
M src/backend/storage/ipc/latch.c
Fix jsonpath existense checking of missing variables
commit : 2ff3ac3b5f52a54b829cc7275141839581b568de
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Thu, 12 Jan 2023 18:16:34 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Thu, 12 Jan 2023 18:16:34 +0300
The current jsonpath code assumes that the referenced variable always exists.
It could only throw an error at the value valuation time. At the same time
existence checking assumes variable is present without valuation, and error
suppression doesn't work for missing variables.
This commit makes existense checking trigger an error for missing variables.
This makes the overall behavior consistent.
Backpatch to 12 where jsonpath was introduced.
Reported-by: David G. Johnston
Discussion: https://postgr.es/m/CAKFQuwbeytffJkVnEqDyLZ%3DrQsznoTh1OgDoOF3VmOMkxcTMjA%40mail.gmail.com
Author: Alexander Korotkov, David G. Johnston
Backpatch-through: 12
M src/backend/utils/adt/jsonpath_exec.c
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/sql/jsonb_jsonpath.sql
Avoid using tuple from syscache for update of pg_database.datfrozenxid
commit : 72b6098be47e19eff50a052676908e0fde25e7ee
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 11 Jan 2023 09:56:14 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 11 Jan 2023 09:56:14 +0900
pg_database.datfrozenxid gets updated using an in-place update at the
end of vacuum or autovacuum. Since 96cdeae, as pg_database has a toast
relation, it is possible for a pg_database tuple to have toast values
if there is a large set of ACLs in place. In such a case, the in-place
update would fail because of the flattening of the toast values done for
the catcache entry fetched. Instead of using a copy from the catcache,
this changes the logic to fetch the copy of the tuple by directly
scanning pg_database.
Note that before 96cdeae, attempting to insert such a tuple to
pg_database would cause a "row is too big" error, so the end-of-vacuum
problem was not reachable.
This issue has been originally fixed in 947789f on v14~, and there have
been reports about this problem on v12 and v13, causing failures at the
end of VACUUM. This completes the fix on all the stable branches where
pg_database can use a toast table, down to 12.
Author: Ashwin Agrawal, Junfeng Yang
Discussion: https://postgr.es/m/DM5PR0501MB38800D9E4605BCA72DD35557CCE10@DM5PR0501MB3880.namprd05.prod.outlook.com
Discussion: https://postgr.es/m/Y70XNVbUWQsR2Car@paquier.xyz
Backpatch-through: 12
M src/backend/access/heap/heapam.c
M src/backend/commands/vacuum.c
Fix tab completion of ALTER FUNCTION/PROCEDURE/ROUTINE ... SET SCHEMA.
commit : 2ad4abedfeec23098c8066cf177216238224a60a
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Fri, 6 Jan 2023 11:13:34 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Fri, 6 Jan 2023 11:13:34 +0000
The ALTER DATABASE|FUNCTION|PROCEDURE|ROLE|ROUTINE|USER ... SET <name>
case in psql tab completion failed to exclude <name> = "SCHEMA", which
caused ALTER FUNCTION|PROCEDURE|ROUTINE ... SET SCHEMA to complete
with "FROM CURRENT" and "TO", which won't work.
Fix that, so that those cases now complete with the list of schemas,
like other ALTER ... SET SCHEMA commands.
Noticed while testing the recent patch to improve tab completion for
ALTER FUNCTION/PROCEDURE/ROUTINE, but this is not directly related to
that patch. Rather, this is a long-standing bug, so back-patch to all
supported branches.
Discussion: https://postgr.es/m/CALDaNm0s7GQmkLP_mx5Cvk=UzYMnjhPmXBxU8DsHEunFbC5sTg@mail.gmail.com
M src/bin/psql/tab-complete.c
Fix calculation of which GENERATED columns need to be updated.
commit : ad38e2f89116435cffd56507380d94e4eb588789
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 Jan 2023 14:12:17 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 Jan 2023 14:12:17 -0500
We were identifying the updatable generated columns of inheritance
children by transposing the calculation made for their parent.
However, there's nothing that says a traditional-inheritance child
can't have generated columns that aren't there in its parent, or that
have different dependencies than are in the parent's expression.
(At present it seems that we don't enforce that for partitioning
either, which is likely wrong to some degree or other; but the case
clearly needs to be handled with traditional inheritance.)
Hence, drop the very-klugy-anyway "extraUpdatedCols" RTE field
in favor of identifying which generated columns depend on updated
columns during executor startup. In HEAD we can remove
extraUpdatedCols altogether; in back branches, it's still there but
always empty. Another difference between the HEAD and back-branch
versions of this patch is that in HEAD we can add the new bitmap field
to ResultRelInfo, but that would cause an ABI break in back branches.
Like 4b3e37993, add a List field at the end of struct EState instead.
Back-patch to v13. The bogus calculation is also being made in v12,
but it doesn't have the same visible effect because we don't use it
to decide which generated columns to recalculate; as a consequence of
which the patch doesn't apply easily. I think that there might still
be a demonstrable bug associated with trigger firing conditions, but
that's such a weird corner-case usage that I'm content to leave it
unfixed in v12.
Amit Langote and Tom Lane
Discussion: https://postgr.es/m/CA+HiwqFshLKNvQUd1DgwJ-7tsTp=dwv7KZqXC4j2wYBV1aCDUA@mail.gmail.com
Discussion: https://postgr.es/m/2793383.1672944799@sss.pgh.pa.us
M contrib/postgres_fdw/postgres_fdw.c
M src/backend/executor/execUtils.c
M src/backend/executor/nodeModifyTable.c
M src/backend/optimizer/util/inherit.c
M src/backend/optimizer/util/plancat.c
M src/backend/replication/logical/worker.c
M src/backend/rewrite/rewriteHandler.c
M src/include/nodes/execnodes.h
M src/include/nodes/parsenodes.h
M src/include/optimizer/inherit.h
M src/include/optimizer/plancat.h
M src/include/rewrite/rewriteHandler.h
M src/test/regress/expected/generated.out
M src/test/regress/sql/generated.sql
Improve documentation of the CREATEROLE attibute.
commit : 5dac191edf1816860993e5f43b817eafcece1166
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 3 Jan 2023 14:50:40 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 3 Jan 2023 14:50:40 -0500
In user-manag.sgml, document precisely what privileges are conveyed
by CREATEROLE. Make particular note of the fact that it allows
changing passwords and granting access to high-privilege roles.
Also remove the suggestion of using a user with CREATEROLE and
CREATEDB instead of a superuser, as there is no real security
advantage to this approach.
Elsewhere in the documentation, adjust text that suggests that
<literal>CREATEROLE</literal> only allows for role creation, and
refer to the documentation in user-manag.sgml as appropriate.
Patch by me, reviewed by Álvaro Herrera
Discussion: http://postgr.es/m/CA+TgmoZBsPL8nPhvYecx7iGo5qpDRqa9k_AcaW1SbOjugAY1Ag@mail.gmail.com
M doc/src/sgml/ref/alter_role.sgml
M doc/src/sgml/ref/create_role.sgml
M doc/src/sgml/ref/createuser.sgml
M doc/src/sgml/user-manag.sgml
Fix typos in comments, code and documentation
commit : 1c89549ca48d04195bfc774534a54cf84b797e8b
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 3 Jan 2023 16:26:34 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 3 Jan 2023 16:26:34 +0900
While on it, newlines are removed from the end of two elog() strings.
The others are simple grammar mistakes. One comment in pg_upgrade
referred incorrectly to sequences since a7e5457.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20221230231257.GI1153@telsasoft.com
Backpatch-through: 11
M doc/src/sgml/parallel.sgml
M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/sources.sgml
M src/backend/access/common/bufmask.c
M src/backend/access/spgist/spgutils.c
M src/backend/jit/llvm/llvmjit.c
M src/backend/optimizer/util/tlist.c
M src/backend/utils/adt/ruleutils.c
M src/bin/pg_upgrade/info.c
M src/test/regress/expected/expressions.out
M src/test/regress/sql/expressions.sql
perl: Hide warnings inside perl.h when using gcc compatible compiler
commit : ce073d01445c09733ba71010276f1ef255b89efd
author : Andres Freund <andres@anarazel.de>
date : Thu, 29 Dec 2022 12:47:29 -0800
committer: Andres Freund <andres@anarazel.de>
date : Thu, 29 Dec 2022 12:47:29 -0800
New versions of perl trigger warnings within perl.h with our compiler
flags. At least -Wdeclaration-after-statement, -Wshadow=compatible-local are
known to be problematic.
To avoid these warnings, conditionally use #pragma GCC system_header before
including plperl.h.
Alternatively, we could add the include paths for problematic headers with
-isystem, but that is a larger hammer and is harder to search for.
A more granular alternative would be to use #pragma GCC diagnostic
push/ignored/pop, but gcc warns about unknown warnings being ignored, so every
to-be-ignored-temporarily compiler warning would require its own pg_config.h
symbol and #ifdef.
As the warnings are voluminous, it makes sense to backpatch this change. But
don't do so yet, we first want gather buildfarm coverage - it's e.g. possible
that some compiler claiming to be gcc compatible has issues with the pragma.
Author: Andres Freund <andres@anarazel.de>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: Discussion: https://postgr.es/m/20221228182455.hfdwd22zztvkojy2@awork3.anarazel.de
M src/include/c.h
M src/pl/plperl/plperl.h
Avoid reference to nonexistent array element in ExecInitAgg().
commit : 19adcaf00f7d8480f231bcfbb6b7a4401a531ce5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Jan 2023 16:17:00 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Jan 2023 16:17:00 -0500
When considering an empty grouping set, we fetched
phasedata->eqfunctions[-1]. Because the eqfunctions array is
palloc'd, that would always be an aset pointer in released versions,
and thus the code accidentally failed to malfunction (since it would
do nothing unless it found a null pointer). Nonetheless this seems
like trouble waiting to happen, so add a check for length == 0.
It's depressing that our valgrind testing did not catch this.
Maybe we should reconsider the choice to not mark that word NOACCESS?
Richard Guo
Discussion: https://postgr.es/m/CAMbWs4-vZuuPOZsKOYnSAaPYGKhmacxhki+vpOKk0O7rymccXQ@mail.gmail.com
M src/backend/executor/nodeAgg.c
Update copyright for 2023
commit : 58dcac07ed347774d0fa5cc8e47dcd8462bdf136
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Jan 2023 15:00:36 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 2 Jan 2023 15:00:36 -0500
Backpatch-through: 11
M COPYRIGHT
M doc/src/sgml/legal.sgml
Fix event trigger example
commit : 843072e1b2c3e329d2040bb266dc4b9222d3db5f
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 23 Dec 2022 13:21:41 +0100
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 23 Dec 2022 13:21:41 +0100
Commit 2f9661311b changed command tags from strings to numbers, but
forgot to adjust the code in the event trigger example, which
consequently failed to compile.
While fixing that, improve the indentation to adhere to pgindent style.
Backpatch to v13, where the change was introduced.
Author: Laurenz Albe
Discussion: https://postgr.es/m/81e36ac17dc80489e74dc5b6914afa6ccdb1a99d.camel@cybertec.at
M doc/src/sgml/event-trigger.sgml
Fix some incorrectness in upgrade_adapt.sql on query for WITH OIDS
commit : d4fea2e89d44a0132e86a1659cf79e8c3057bb57
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Dec 2022 11:27:17 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Dec 2022 11:27:17 +0900
The query used to disable WITH OIDS in all the relations making use of
it was checking for materialized views, but this is not a supported
operation. On the contrary, this needs to be done on foreign tables.
While on it, use quote_ident() in the ALTER TABLE strings built on the
relation name.
Author: Anton A. Melnikov, Michael Paquier
Discussion: https://postgr.es/m/49f389ba-95ce-8a9b-09ae-f60650c0e7c7@inbox.ru
Backpatch-through: 12
M src/bin/pg_upgrade/upgrade_adapt.sql
Fix come incorrect elog() messages in aclchk.c
commit : 4dbe72d61ac6dc1ed4a230db2adec1dc01041f7f
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Dec 2022 10:04:34 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Dec 2022 10:04:34 +0900
Three error strings used with cache lookup failures were referring to
incorrect object types for ACL checks:
- Schemas
- Types
- Foreign Servers
There errors should never be triggered, but if they do incorrect
information would be reported.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20221222153041.GN1153@telsasoft.com
Backpatch-through: 11
M src/backend/catalog/aclchk.c
Add some recursion and looping defenses in prepjointree.c.
commit : 4fceb454f2df57f63d05ccb4a26a9f49c377f28c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Dec 2022 10:35:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Dec 2022 10:35:03 -0500
Andrey Lepikhov demonstrated a case where we spend an unreasonable
amount of time in pull_up_subqueries(). Not only is that recursing
with no explicit check for stack overrun, but the code seems not
interruptable by control-C. Let's stick a CHECK_FOR_INTERRUPTS
there, along with sprinkling some stack depth checks.
An actual fix for the excessive time consumption seems a bit
risky to back-patch; but this isn't, so let's do so.
Discussion: https://postgr.es/m/703c09a2-08f3-d2ec-b33d-dbecd62428b8@postgrespro.ru
M src/backend/optimizer/prep/prepjointree.c
Fix contrib/seg to be more wary of long input numbers.
commit : d35f1d485c392ce058382794742ce246e47643ec
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Dec 2022 17:51:50 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Dec 2022 17:51:50 -0500
seg stores the number of significant digits in an input number
in a "char" field. If char is signed, and the input is more than
127 digits long, the count can read out as negative causing
seg_out() to print garbage (or, if you're really unlucky,
even crash).
To fix, clamp the digit count to be not more than FLT_DIG.
(In theory this loses some information about what the original
input was, but it doesn't seem like useful information; it would
not survive dump/restore in any case.)
Also, in case there are stored values of the seg type containing
bad data, add a clamp in seg_out's restore() subroutine.
Per bug #17725 from Robins Tharakan. It's been like this
forever, so back-patch to all supported branches.
Discussion: https://postgr.es/m/17725-0a09313b67fbe86e@postgresql.org
M contrib/seg/expected/seg.out
M contrib/seg/seg.c
M contrib/seg/segparse.y
M contrib/seg/sql/seg.sql
Re-adjust drop-index-concurrently-1 isolation test
commit : e39856d1f027a91f20e7c8cac7a5c844b74c4962
author : David Rowley <drowley@postgresql.org>
date : Fri, 16 Dec 2022 11:41:28 +1300
committer: David Rowley <drowley@postgresql.org>
date : Fri, 16 Dec 2022 11:41:28 +1300
It seems that drop-index-concurrently-1 has started to forget what it was
originally meant to be testing. d2d8a229b, which added incremental sorts
changed the expected plan to be an Index Scan plan instead of a Seq Scan
plan. This occurred as the primary key index of the table in question
provided presorted input and, because that index happened to be the
cheapest input path due to enable_seqscan being disabled, the incremental
sort changes just added a Sort on top of that. It seems based on the name
of the PREPAREd statement that the intention here is that the query
produces a seqscan plan.
The reason this test has become broken seems to be due to how the test was
originally coded. The test was trying to force a seqscan plan by
performing some casting to make it so the test_dc index couldn't be used
to perform the required filtering. Trying to coax the planner into using
a plan which has costed in a disable_cost seems like it's always going to
be flakey as small changes in costs are drowned out by the large
disable_cost combined with add_path's STD_FUZZ_FACTOR. Here we get rid of
the casts that we're using to try to trick the planner into a seqscan and
instead toggle enable_seqscan as and when required to get the desired
plan.
Additionally, rename a few things in the test and add some additional
wording to the comments to try and make it more clear in the future what
we expect this test to be doing.
Discussion: https://postgr.es/m/CAApHDvrbDhObhLV+=U_K_-t+2Av2av1aL9d+2j_3AO-XndaviA@mail.gmail.com
Backpatch-through: 13, where d2d8a229b changed the expected test output
M src/test/isolation/expected/drop-index-concurrently-1.out
M src/test/isolation/expected/drop-index-concurrently-1_2.out
M src/test/isolation/specs/drop-index-concurrently-1.spec
Rethink handling of [Prevent|Is]InTransactionBlock in pipeline mode.
commit : 942cc240f95998793e10156952c14961b5559b2a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Dec 2022 14:23:59 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Dec 2022 14:23:59 -0500
Commits f92944137 et al. made IsInTransactionBlock() set the
XACT_FLAGS_NEEDIMMEDIATECOMMIT flag before returning "false",
on the grounds that that kept its API promises equivalent to those of
PreventInTransactionBlock(). This turns out to be a bad idea though,
because it allows an ANALYZE in a pipelined series of commands to
cause an immediate commit, which is unexpected.
Furthermore, if we return "false" then we have another issue,
which is that ANALYZE will decide it's allowed to do internal
commit-and-start-transaction sequences, thus possibly unexpectedly
committing the effects of previous commands in the pipeline.
To fix the latter situation, invent another transaction state flag
XACT_FLAGS_PIPELINING, which explicitly records the fact that we
have executed some extended-protocol command and not yet seen a
commit for it. Then, require that flag to not be set before allowing
InTransactionBlock() to return "false".
Having done that, we can remove its setting of NEEDIMMEDIATECOMMIT
without fear of causing problems. This means that the API guarantees
of IsInTransactionBlock now diverge from PreventInTransactionBlock,
which is mildly annoying, but it seems OK given the very limited usage
of IsInTransactionBlock. (In any case, a caller preferring the old
behavior could always set NEEDIMMEDIATECOMMIT for itself.)
For consistency also require XACT_FLAGS_PIPELINING to not be set
in PreventInTransactionBlock. This too is meant to prevent commands
such as CREATE DATABASE from silently committing previous commands
in a pipeline.
Per report from Peter Eisentraut. As before, back-patch to all
supported branches (which sadly no longer includes v10).
Discussion: https://postgr.es/m/65a899dd-aebc-f667-1d0a-abb89ff3abf8@enterprisedb.com
M doc/src/sgml/protocol.sgml
M src/backend/access/transam/xact.c
M src/backend/tcop/postgres.c
M src/include/access/xact.h
doc: Add missing <varlistentry> markups for developer GUCs
commit : 84e6188d68f421523f4a25e9132e8e4fa9700648
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 5 Dec 2022 11:23:33 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 5 Dec 2022 11:23:33 +0900
Missing such markups makes it impossible to create links back to these
GUCs, and all the other parameters have one already.
Author: Ian Lawrence Barwick
Discussion: https://postgr.es/m/CAB8KJ=jx=6dFB_EN3j0UkuvG3cPu5OmQiM-ZKRAz+fKvS+u8Ng@mail.gmail.com
Backpatch-through: 11
M doc/src/sgml/config.sgml
Fix generate_partitionwise_join_paths() to tolerate failure.
commit : 4ebca555cf238628b933f79fd90fdd41bed4d39d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Dec 2022 13:17:18 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Dec 2022 13:17:18 -0500
We might fail to generate a partitionwise join, because
reparameterize_path_by_child() does not support all path types.
This should not be a hard failure condition: we should just fall back
to a non-partitioned join. However, generate_partitionwise_join_paths
did not consider this possibility and would emit the (misleading)
error "could not devise a query plan for the given query" if we'd
failed to make any paths for a child join. Fix it to give up on
partitionwise joining if so. (The accepted technique for giving up
appears to be to set rel->nparts = 0, which I find pretty bizarre,
but there you have it.)
I have not added a test case because there'd be little point:
any omissions of this sort that we identify would soon get fixed
by extending reparameterize_path_by_child(), so the test would stop
proving anything. However, right now there is a known test case based
on failure to cover MaterialPath, and with that I've found that this
is broken in all supported versions. Hence, patch all the way back.
Original report and patch by me; thanks to Richard Guo for
identifying a test case that works against committed versions.
Discussion: https://postgr.es/m/1854233.1669949723@sss.pgh.pa.us
M src/backend/optimizer/path/allpaths.c
Fix DEFAULT handling for multi-row INSERT rules.
commit : 3bed881237b1b5694d525da7c8974e09198d445f
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 3 Dec 2022 12:17:47 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sat, 3 Dec 2022 12:17:47 +0000
When updating a relation with a rule whose action performed an INSERT
from a multi-row VALUES list, the rewriter might skip processing the
VALUES list, and therefore fail to replace any DEFAULTs in it. This
would lead to an "unrecognized node type" error.
The reason was that RewriteQuery() assumed that a query doing an
INSERT from a multi-row VALUES list would necessarily only have one
item in its fromlist, pointing to the VALUES RTE to read from. That
assumption is correct for the original query, but not for product
queries produced for rule actions. In such cases, there may be
multiple items in the fromlist, possibly including multiple VALUES
RTEs.
What is required instead is for RewriteQuery() to skip any RTEs from
the product query's originating query, which might include one or more
already-processed VALUES RTEs. What's left should then include at most
one VALUES RTE (from the rule action) to be processed.
Patch by me. Thanks to Tom Lane for reviewing.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAEZATCV39OOW7LAR_Xq4i%2BLc1Byux%3DeK3Q%3DHD_pF1o9LBt%3DphA%40mail.gmail.com
M src/backend/rewrite/rewriteHandler.c
M src/test/regress/expected/rules.out
M src/test/regress/sql/rules.sql
Prevent pgstats from getting confused when relkind of a relation changes
commit : 7944d2d8c78b190908e99b4dc1719d7dca83091b
author : Andres Freund <andres@anarazel.de>
date : Fri, 2 Dec 2022 17:50:26 -0800
committer: Andres Freund <andres@anarazel.de>
date : Fri, 2 Dec 2022 17:50:26 -0800
When the relkind of a relache entry changes, because a table is converted into
a view, pgstats can get confused in 15+, leading to crashes or assertion
failures.
For HEAD, Tom fixed this in b23cd185fd5, by removing support for converting a
table to a view, removing the source of the inconsistency. This commit just
adds an assertion that a relcache entry's relkind does not change, just in
case we end up with another case of that in the future. As there's no cases of
changing relkind anymore, we can't add a test that that's handled correctly.
For 15, fix the problem by not maintaining the association with the old pgstat
entry when the relkind changes during a relcache invalidation processing. In
that case the pgstat entry needs to be unlinked first, to avoid
PgStat_TableStatus->relation getting out of sync. Also add a test reproducing
the issues.
No known problem exists in 11-14, so just add the test there.
Reported-by: vignesh C <vignesh21@gmail.com>
Author: Andres Freund <andres@anarazel.de>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CALDaNm2yXz+zOtv7y5zBd5WKT8O0Ld3YxikuU3dcyCvxF7gypA@mail.gmail.com
Discussion: https://postgr.es/m/CALDaNm3oZA-8Wbps2Jd1g5_Gjrr-x3YWrJPek-mF5Asrrvz2Dg@mail.gmail.com
Backpatch: 15-
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
Fix memory leak for hashing with nondeterministic collations.
commit : a844052b5d97c351ba800e51e37b833f93863c29
author : Jeff Davis <jdavis@postgresql.org>
date : Thu, 1 Dec 2022 11:26:32 -0800
committer: Jeff Davis <jdavis@postgresql.org>
date : Thu, 1 Dec 2022 11:26:32 -0800
Backpatch through 12, where nondeterministic collations were
introduced (5e1963fb76).
Backpatch-through: 12
M src/backend/access/hash/hashfunc.c
M src/backend/utils/adt/varchar.c
Doc: add example of round(v, s) with negative s.
commit : a475157e6bf0c0f509cc9fb6ccff2b3876eb5f4b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Dec 2022 12:26:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 1 Dec 2022 12:26:12 -0500
This has always worked, but you'd be unlikely to guess it
from the documentation. Add an example showing it.
Lack of docs noted by David Johnston. Back-patch to v13;
the documentation layout we used before that was not very
amenable to squeezing in multiple examples.
Discussion: https://postgr.es/m/CAKFQuwZ4Vy1Xty0G5Ok+ot=NDrU3C6hzF1JwUk-FEkwe3V9_RA@mail.gmail.com
M doc/src/sgml/func.sgml
revert: add transaction processing chapter with internals info
commit : 312061cbc76e1a1f3244f89697c4078bc3e8523c
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 1 Dec 2022 10:45:08 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 1 Dec 2022 10:45:08 -0500
This doc patch (master hash 66bc9d2d3e) was decided to be too
significant for backpatching, so reverted in all but master. Also fix
SGML file header comment in master.
Reported-by: Peter Eisentraut
Discussion: https://postgr.es/m/c6304b19-6ff7-f3af-0148-cf7aa7e2fbfd@enterprisedb.com
Backpatch-through: 11
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/datatype.sgml
M doc/src/sgml/filelist.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/glossary.sgml
M doc/src/sgml/monitoring.sgml
M doc/src/sgml/pgrowlocks.sgml
M doc/src/sgml/postgres.sgml
M doc/src/sgml/ref/release_savepoint.sgml
M doc/src/sgml/ref/rollback.sgml
M doc/src/sgml/ref/rollback_to.sgml
M doc/src/sgml/wal.sgml
D doc/src/sgml/xact.sgml
Reject missing database name in pg_regress and cohorts.
commit : ae9939020dda40af579678489b11ef20fe3cca05
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Nov 2022 13:01:41 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Nov 2022 13:01:41 -0500
Writing "pg_regress --dbname= ..." led to a crash, because
we weren't expecting there to be no database name supplied.
It doesn't seem like a great idea to run regression tests
in whatever is the user's default database; so rather than
supporting this case let's explicitly reject it.
Per report from Xing Guo. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/CACpMh+A8cRvtvtOWVAZsCM1DU81GK4DL26R83y6ugZ1osV=ifA@mail.gmail.com
M src/test/regress/pg_regress.c
doc: add transaction processing chapter with internals info
commit : 4df5462f345b5e50cedf42300cad8616c7df3f6d
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 29 Nov 2022 20:49:52 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 29 Nov 2022 20:49:52 -0500
This also adds references to this new chapter at relevant sections of
our documentation. Previously much of these internal details were
exposed to users, but not explained. This also updates RELEASE
SAVEPOINT.
Discussion: https://postgr.es/m/CANbhV-E_iy9fmrErxrCh8TZTyenpfo72Hf_XD2HLDppva4dUNA@mail.gmail.com
Author: Simon Riggs, Laurenz Albe
Reviewed-by: Bruce Momjian
Backpatch-through: 11
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/datatype.sgml
M doc/src/sgml/filelist.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/glossary.sgml
M doc/src/sgml/monitoring.sgml
M doc/src/sgml/pgrowlocks.sgml
M doc/src/sgml/postgres.sgml
M doc/src/sgml/ref/release_savepoint.sgml
M doc/src/sgml/ref/rollback.sgml
M doc/src/sgml/ref/rollback_to.sgml
M doc/src/sgml/wal.sgml
A doc/src/sgml/xact.sgml
Fix comment in fe-auth-scram.c
commit : 4c7bb4dccb49379d891853ebd99ade7002843f96
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 30 Nov 2022 08:38:33 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 30 Nov 2022 08:38:33 +0900
The frontend-side routine in charge of building a SCRAM verifier
mentioned that the restrictions applying to SASLprep on the password
with the encoding are described at the top of fe-auth-scram.c, but this
information is in auth-scram.c.
This is wrong since 8f8b9be, so backpatch all the way down as this is an
important documentation bit.
Spotted while reviewing a different patch.
Backpatch-through: 11
M src/interfaces/libpq/fe-auth-scram.c
Improve heuristics for compressing the KnownAssignedXids array.
commit : 6e8ad11521cccda7dad29f3e6750eb0b9be46527
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2022 15:43:17 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2022 15:43:17 -0500
Previously, we'd compress only when the active range of array entries
reached Max(4 * PROCARRAY_MAXPROCS, 2 * pArray->numKnownAssignedXids).
If max_connections is large, the first term could result in not
compressing for a long time, resulting in much wastage of cycles in
hot-standby backends scanning the array to take snapshots. Get rid
of that term, and just bound it to 2 * pArray->numKnownAssignedXids.
That however creates the opposite risk, that we might spend too much
effort compressing. Hence, consider compressing only once every 128
commit records. (This frequency was chosen by benchmarking. While
we only tried one benchmark scenario, the results seem stable over
a fairly wide range of frequencies.)
Also, force compression when processing RecoveryInfo WAL records
(which should be infrequent); the old code could perform compression
then, but would do so only after the same array-range check as for
the transaction-commit path.
Also, opportunistically run compression if the startup process is about
to wait for WAL, though not oftener than once a second. This should
prevent cases where we waste lots of time by leaving the array
not-compressed for long intervals due to low WAL traffic.
Lastly, add a simple check to keep us from uselessly compressing
when the array storage is already compact.
Back-patch, as the performance problem is worse in pre-v14 branches
than in HEAD.
Simon Riggs and Michail Nikolaev, with help from Tom Lane and
Andres Freund.
Discussion: https://postgr.es/m/CALdSSPgahNUD_=pB_j=1zSnDBaiOtqVfzo8Ejt5J_k7qZiU1Tw@mail.gmail.com
M src/backend/access/transam/xlog.c
M src/backend/storage/ipc/procarray.c
M src/include/storage/procarray.h
Remove bogus Assert and dead code in remove_useless_results_recurse().
commit : aca695fb6847638538833821ebab8a62d51c4549
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2022 10:52:44 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2022 10:52:44 -0500
The JOIN_SEMI case Assert'ed that there are no PlaceHolderVars that
need to be evaluated at the semijoin's RHS, which is wrong because
there could be some in the semijoin's qual condition. However, there
could not be any references further up than that, and within the qual
there is not any way that such a PHV could have gone to null yet, so
we don't really need the PHV and there is no need to avoid making the
RHS-removal optimization. The upshot is that there's no actual bug
in production code, and we ought to just remove this misguided Assert.
While we're here, also drop the JOIN_RIGHT case, which is dead code
because reduce_outer_joins() already got rid of JOIN_RIGHT.
Per bug #17700 from Xin Wen. Uselessness of the JOIN_RIGHT case
pointed out by Richard Guo. Back-patch to v12 where this code
was added.
Discussion: https://postgr.es/m/17700-2b5c10d917c30687@postgresql.org
M src/backend/optimizer/prep/prepjointree.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Fix binary mismatch for MSVC plperl vs gcc built perl libs
commit : 68d89d80c3db06ad080a0f291e165456fb2f51f7
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 27 Nov 2022 09:03:22 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 27 Nov 2022 09:03:22 -0500
When loading plperl built against Strawberry perl or the msys2 ucrt perl
that have been built with gcc, a binary mismatch has been encountered
which looks like this:
loadable library and perl binaries are mismatched (got handshake key 0000000012800080, needed 0000000012900080)
To cure this we bring the handshake keys into sync by adding
NO_THREAD_SAFE_LOCALE to the defines used to build plperl.
Discussion: https://postgr.es/m/20211005004334.tgjmro4kuachwiuc@alap3.anarazel.de
Discussion: https://postgr.es/m/c2da86a0-2906-744c-923d-16da6047875e@dunslane.net
Backpatch to all live branches.
M src/tools/msvc/Mkvcbuild.pm
Remove temporary portlock directory during make [dist]clean.
commit : a2dcd78dd0837c5b705569f99d86ebf0d5a5725f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Nov 2022 10:30:31 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Nov 2022 10:30:31 -0500
Another oversight in 9b4eafcaf.
M GNUmakefile.in
Add portlock directory to .gitignore
commit : 46d724107b5527b1b94e15358acd1bf030dd70c4
author : Andrew Dunstan <andrew@dunslane.net>
date : Sat, 26 Nov 2022 07:44:23 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sat, 26 Nov 2022 07:44:23 -0500
Commit 9b4eafcaf4 added creattion of a directory to reserve TAP test
ports at the top of the build tree. In a non-vpath build this means at
the top of the source tree, so it needs to be added to .gitignore.
As suggested by Michael Paquier
Backpatch to all live branches.
M .gitignore
Allow building with MSVC and Strawberry perl
commit : 9fe5cff141388316779bcc6662ca2d2cd0e53872
author : Andrew Dunstan <andrew@dunslane.net>
date : Fri, 25 Nov 2022 15:28:38 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Fri, 25 Nov 2022 15:28:38 -0500
Strawberry uses __builtin_expect which Visual C doesn't have. For this
case define it as a noop. Solution taken from vim sources.
Backpatch to all live branches
M src/pl/plperl/plperl.h
Fix uninitialized access to InitialRunningXacts during decoding.
commit : 4ec157c15067be979d271416dacf86a5fce34cbc
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 25 Nov 2022 09:15:31 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 25 Nov 2022 09:15:31 +0530
In commit 272248a0c, we introduced an InitialRunningXacts array to
remember transactions and subtransactions that were running when the
xl_running_xacts record that we decoded was written. This array was
allocated in the snapshot builder memory context after we restore
serialized snapshot but we forgot to reset the array while freeing the
builder memory context. So, the next time when we start decoding in the
same session where we don't restore any serialized snapshot, we ended up
using the uninitialized array and that can lead to unpredictable behavior.
This problem doesn't exist in HEAD as instead of using
InitialRunningXacts, we added the list of transaction IDs and
sub-transaction IDs, that have modified catalogs and are running during
snapshot serialization, to the serialized snapshot (see commit 7f13ac8123).
Reported-by: Maxim Orlov
Author: Masahiko Sawada
Reviewed-by: Amit Kapila, Maxim Orlov
Backpatch-through: 11
Discussion: https://postgr.es/m/CACG=ezZoz_KG+Ryh9MrU_g5e0HiVoHocEvqFF=NRrhrwKmEQJQ@mail.gmail.com
M src/backend/replication/logical/snapbuild.c
Make multixact error message more explicit
commit : 5a185246f9a742371a75ac0e3a95d0ceba9494e5
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 24 Nov 2022 10:45:10 +0100
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 24 Nov 2022 10:45:10 +0100
There are recent reports involving a very old error message that we have
no history of hitting -- perhaps a recently introduced bug. Improve the
error message in an attempt to improve our chances of investigating the
bug.
Per reports from Dimos Stamatakis and Bob Krier.
Backpatch to 11.
Discussion: https://postgr.es/m/CO2PR0801MB2310579F65529380A4E5EDC0E20A9@CO2PR0801MB2310.namprd08.prod.outlook.com
Discussion: https://postgr.es/m/17518-04e368df5ad7f2ee@postgresql.org
M src/backend/access/transam/multixact.c
Fix perl warning from commit 9b4eafcaf4
commit : f4b777e77dbc46b657bd3ea331ba9f14fe4d34c9
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 23 Nov 2022 07:17:26 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 23 Nov 2022 07:17:26 -0500
per gripe from Andres Freund and Tom Lane
Backpatch to all live branches.
M src/test/perl/PostgresNode.pm
YA attempt at taming worst-case behavior of get_actual_variable_range.
commit : 6e639267a5346c169a77b4ec3b14de8da2ddce8c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Nov 2022 14:40:20 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Nov 2022 14:40:20 -0500
We've made multiple attempts at preventing get_actual_variable_range
from taking an unreasonable amount of time (3ca930fc3, fccebe421).
But there's still an issue for the very first planning attempt after
deletion of a large number of extremal-valued tuples. While that
planning attempt will set "killed" bits on the tuples it visits and
thereby reduce effort for next time, there's still a lot of work it
has to do to visit the heap and then set those bits. It's (usually?)
not worth it to do that much work at plan time to have a slightly
better estimate, especially in a context like this where the table
contents are known to be mutating rapidly.
Therefore, let's bound the amount of work to be done by giving up
after we've visited 100 heap pages. Giving up just means we'll
fall back on the extremal value recorded in pg_statistic, so it
shouldn't mean that planner estimates suddenly become worthless.
Note that this means we'll still gradually whittle down the problem
by setting a few more index "killed" bits in each planning attempt;
so eventually we'll reach a good state (barring further deletions),
even in the absence of VACUUM.
Simon Riggs, per a complaint from Jakub Wartak (with cosmetic
adjustments by me). Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAKZiRmznOwi0oaV=4PHOCM4ygcH4MgSvt8=5cu_vNCfc8FSUug@mail.gmail.com
M src/backend/utils/adt/selfuncs.c
Prevent port collisions between concurrent TAP tests
commit : 4b9013d64f231ddbadd2b06cf75499c8e8cd4cc1
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 22 Nov 2022 10:35:04 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 22 Nov 2022 10:35:04 -0500
Currently there is a race condition where if concurrent TAP tests both
test that they can open a port they will assume that it is free and use
it, causing one of them to fail. To prevent this we record a reservation
using an exclusive lock, and any TAP test that discovers a reservation
checks to see if the reserving process is still alive, and looks for
another free port if it is.
Ports are reserved in a directory set by the environment setting
PG_TEST_PORT_DIR, or if that doesn't exist a subdirectory of the top
build directory as set by Makefile.global, or its own
tmp_check directory.
The prove_check recipe in Makefile.global.in is extended to export
top_builddir to the TAP tests. This was already exported by the
prove_installcheck recipes.
Per complaint from Andres Freund
Backpatched from 9b4eafcaf4 to all live branches
Discussion: https://postgr.es/m/20221002164931.d57hlutrcz4d2zi7@awork3.anarazel.de
M src/Makefile.global.in
M src/test/perl/PostgresNode.pm
Ignore invalidated slots while computing oldest catalog Xmin
commit : 36eeb37cd611c0a0bfb5743d9ddbef8f04fc87f3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 22 Nov 2022 10:56:07 +0100
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 22 Nov 2022 10:56:07 +0100
Once a logical slot has acquired a catalog_xmin, it doesn't let go of
it, even when invalidated by exceeding the max_slot_wal_keep_size, which
means that dead catalog tuples are not removed by vacuum anymore since
the point is invalidated, until the slot is dropped. This could be
catastrophic if catalog churn is high.
Change the computation of Xmin to ignore invalidated slots,
to prevent dead rows from accumulating.
Backpatch to 13, where slot invalidation appeared.
Author: Sirisha Chamarthi <sirichamarthi22@gmail.com>
Reviewed-by: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Discussion: https://postgr.es/m/CAKrAKeUEDeqquN9vwzNeG-CN8wuVsfRYbeOUV9qKO_RHok=j+g@mail.gmail.com
M src/backend/replication/slot.c
M src/backend/storage/ipc/procarray.c
Replace link to Hunspell with the current homepage
commit : 0e3215292f48f3e204402a07140322b63a30de36
author : Daniel Gustafsson <dgustafsson@postgresql.org>
date : Mon, 21 Nov 2022 23:25:48 +0100
committer: Daniel Gustafsson <dgustafsson@postgresql.org>
date : Mon, 21 Nov 2022 23:25:48 +0100
The Hunspell project moved from Sourceforge to Github sometime
in 2016, so update our links to match the new URL. Backpatch
the doc changes to all supported versions.
Discussion: https://postgr.es/m/DC9A662A-360D-4125-A453-5A6CB9C6C4B4@yesql.se
Backpatch-through: v11
M doc/src/sgml/textsearch.sgml
Add comments and a missing CHECK_FOR_INTERRUPTS in ts_headline.
commit : 74670688faaec94d9177ac182c5516c5f1a7bb9c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Nov 2022 17:07:07 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Nov 2022 17:07:07 -0500
I just spent an annoying amount of time reverse-engineering the
100%-undocumented API between ts_headline and the text search
parser's prsheadline function. Add some commentary about that
while it's fresh in mind. Also remove some unused macros in
wparser_def.c.
While at it, I noticed that when commit 78e73e875 added a
CHECK_FOR_INTERRUPTS call in TS_execute_recurse, it missed
doing so in the parallel function TS_phrase_execute, which
surely needs one just as much.
Back-patch because of the missing CHECK_FOR_INTERRUPTS.
Might as well back-patch the rest of this too.
M src/backend/tsearch/ts_parse.c
M src/backend/tsearch/wparser_def.c
M src/backend/utils/adt/tsvector_op.c
M src/include/tsearch/ts_public.h
Fix mislabeling of PROC_QUEUE->links as PGPROC, fixing UBSan on 32bit
commit : c13667b518e3ff21fd756b571302acd6f8688e45
author : Andres Freund <andres@anarazel.de>
date : Wed, 16 Nov 2022 20:00:59 -0800
committer: Andres Freund <andres@anarazel.de>
date : Wed, 16 Nov 2022 20:00:59 -0800
ProcSleep() used a PGPROC* variable to point to PROC_QUEUE->links.next,
because that does "the right thing" with SHMQueueInsertBefore(). While that
largely works, it's certainly not correct and unnecessary - we can just use
SHM_QUEUE* to point to the insertion point.
Noticed when testing a 32bit of postgres with undefined behavior
sanitizer. UBSan noticed that sometimes the supposed PGPROC wasn't
sufficiently aligned (required since 46d6e5f5679, ensured indirectly, via
ShmemAllocRaw() guaranteeing cacheline alignment).
For now fix this by using a SHM_QUEUE* for the insertion point. Subsequently
we should replace all the use of PROC_QUEUE and SHM_QUEUE with ilist.h, but
that's a larger change that we don't want to backpatch.
Backpatch to all supported versions - it's useful to be able to run postgres
under UBSan.
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/20221117014230.op5kmgypdv2dtqsf@awork3.anarazel.de
Backpatch: 11-
M src/backend/storage/lmgr/proc.c
Doc: sync src/tutorial/basics.source with SGML documentation.
commit : d3d388831d8819dbf415d2cddadded9f9c4135bd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Nov 2022 13:09:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Nov 2022 13:09:14 -0500
basics.source is supposed to be pretty closely in step with
the examples in chapter 2 of the tutorial, but I forgot to
update it in commit f05a5e000. Fix that, and adjust a couple
of other discrepancies that had crept in over time.
(I notice that advanced.source is nowhere near being in sync
with chapter 3, but I lack the ambition to do something
about that right now.)
M src/tutorial/basics.source
pg_dump: avoid unsafe function calls in getPolicies().
commit : a5b26aaafe4fc4ee96d09103e2692b743850c1a6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Nov 2022 12:00:27 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Nov 2022 12:00:27 -0500
getPolicies() had the same disease I fixed in other places in
commit e3fcbbd62, i.e., it was calling pg_get_expr() for
expressions on tables that we don't necessarily have lock on.
To fix, restrict the query to only collect interesting rows,
rather than doing the filtering on the client side.
Back-patch of commit 3e6e86abc. That's been in v15/HEAD long enough
to have some confidence about it, so now let's fix the problem in
older branches.
Discussion: https://postgr.es/m/2273648.1634764485@sss.pgh.pa.us
Discussion: https://postgr.es/m/7d7eb6128f40401d81b3b7a898b6b4de@W2012-02.nidsa.loc
Discussion: https://postgr.es/m/45c93d57-9973-248e-d2df-e02ca9af48d4@darold.net
M src/bin/pg_dump/pg_dump.c
Postpone calls of unsafe server-side functions in pg_dump.
commit : e46e986baef04b9127a991f8a08d5c057671cb45
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Nov 2022 11:40:30 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Nov 2022 11:40:30 -0500
Avoid calling pg_get_partkeydef(), pg_get_expr(relpartbound),
and regtypeout until we have lock on the relevant tables.
The existing coding is at serious risk of failure if there
are any concurrent DROP TABLE commands going on --- including
drops of other sessions' temp tables.
Back-patch of commit e3fcbbd62. That's been in v15/HEAD long enough
to have some confidence about it, so now let's fix the problem in
older branches.
Original patch by me; thanks to Gilles Darold for back-patching
legwork.
Discussion: https://postgr.es/m/2273648.1634764485@sss.pgh.pa.us
Discussion: https://postgr.es/m/7d7eb6128f40401d81b3b7a898b6b4de@W2012-02.nidsa.loc
Discussion: https://postgr.es/m/45c93d57-9973-248e-d2df-e02ca9af48d4@darold.net
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
Replace RelationOpenSmgr() with RelationGetSmgr().
commit : 9a299cf7c21f30ca5d045faaf725e8216d3cc5f5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Nov 2022 16:54:30 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Nov 2022 16:54:30 -0500
This is a back-patch of the v15-era commit f10f0ae42 into older
supported branches. The idea is to design out bugs in which an
ill-timed relcache flush clears rel->rd_smgr partway through
some code sequence that wasn't expecting that. We had another
report today of a corner case that reliably crashes v14 under
debug_discard_caches (nee CLOBBER_CACHE_ALWAYS), and therefore
would crash once in a blue moon in the field. We're unlikely
to get rid of all such code paths unless we adopt the more
rigorous coding rules instituted by f10f0ae42. Therefore,
even though this is a bit invasive, it's time to back-patch.
Some comfort can be taken in the fact that f10f0ae42 has been
in v15 for 16 months without problems.
I left the RelationOpenSmgr macro present in the back branches,
even though no core code should use it anymore, in order to not break
third-party extensions in minor releases. Such extensions might opt
to start using RelationGetSmgr instead, to reduce their code
differential between v15 and earlier branches. This carries a hazard
of failing to compile against headers from existing minor releases.
However, once compiled the extension should work fine even with such
releases, because RelationGetSmgr is a "static inline" function so
it creates no link-time dependency. So depending on distribution
practices, that might be an OK tradeoff.
Per report from Spyridon Dimitrios Agathos. Original patch
by Amul Sul.
Discussion: https://postgr.es/m/CAFM5RaqdgyusQvmWkyPYaWMwoK5gigdtW-7HcgHgOeAw7mqJ_Q@mail.gmail.com
Discussion: https://postgr.es/m/CANiYTQsU7yMFpQYnv=BrcRVqK_3U3mtAzAsJCaqtzsDHfsUbdQ@mail.gmail.com
M contrib/amcheck/verify_nbtree.c
M contrib/bloom/blinsert.c
M contrib/pg_prewarm/autoprewarm.c
M contrib/pg_prewarm/pg_prewarm.c
M contrib/pg_visibility/pg_visibility.c
M src/backend/access/gist/gistbuild.c
M src/backend/access/hash/hashpage.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/heap/rewriteheap.c
M src/backend/access/heap/visibilitymap.c
M src/backend/access/nbtree/nbtree.c
M src/backend/access/nbtree/nbtsort.c
M src/backend/access/spgist/spginsert.c
M src/backend/access/table/tableam.c
M src/backend/catalog/heap.c
M src/backend/catalog/index.c
M src/backend/catalog/storage.c
M src/backend/commands/tablecmds.c
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/freespace/freespace.c
M src/include/utils/rel.h
Account for IPC::Run::result() Windows behavior change.
commit : d419d391fc215cd682953394bb8e2a48bd7deb7b
author : Noah Misch <noah@leadboat.com>
date : Thu, 17 Nov 2022 07:35:06 -0800
committer: Noah Misch <noah@leadboat.com>
date : Thu, 17 Nov 2022 07:35:06 -0800
This restores compatibility with the not-yet-released successor of
version 20220807.0. Back-patch to 9.4, which introduced this code.
Reviewed by Andrew Dunstan.
Discussion: https://postgr.es/m/20221117061805.GA4020280@rfd.leadboat.com
M src/test/perl/TestLib.pm
Fix cleanup lock acquisition in SPLIT_ALLOCATE_PAGE replay.
commit : 20c22333630111718bc97ce9a19b392f23e3c525
author : Amit Kapila <akapila@postgresql.org>
date : Mon, 14 Nov 2022 10:11:10 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Mon, 14 Nov 2022 10:11:10 +0530
During XLOG_HASH_SPLIT_ALLOCATE_PAGE replay, we were checking for a
cleanup lock on the new bucket page after acquiring an exclusive lock on
it and raising a PANIC error on failure. However, it is quite possible
that checkpointer can acquire the pin on the same page before acquiring a
lock on it, and then the replay will lead to an error. So instead, directly
acquire the cleanup lock on the new bucket page during
XLOG_HASH_SPLIT_ALLOCATE_PAGE replay operation.
Reported-by: Andres Freund
Author: Robert Haas
Reviewed-By: Amit Kapila, Andres Freund, Vignesh C
Backpatch-through: 11
Discussion: https://postgr.es/m/20220810022617.fvjkjiauaykwrbse@awork3.anarazel.de
M src/backend/access/hash/hash_xlog.c
M src/backend/access/hash/hashpage.c
Fix theoretical torn page hazard.
commit : 58a45bb1d82b90e33a45b646717bf6a035256ded
author : Jeff Davis <jdavis@postgresql.org>
date : Thu, 10 Nov 2022 14:46:30 -0800
committer: Jeff Davis <jdavis@postgresql.org>
date : Thu, 10 Nov 2022 14:46:30 -0800
The original report was concerned with a possible inconsistency
between the heap and the visibility map, which I was unable to
confirm. The concern has been retracted.
However, there did seem to be a torn page hazard when using
checksums. By not setting the heap page LSN during redo, the
protections of minRecoveryPoint were bypassed. Fixed, along with a
misleading comment.
It may have been impossible to hit this problem in practice, because
it would require a page tear between the checksum and the flags, so I
am marking this as a theoretical risk. But, as discussed, it did
violate expectations about the page LSN, so it may have other
consequences.
Backpatch to all supported versions.
Reported-by: Konstantin Knizhnik
Reviewed-by: Konstantin Knizhnik
Discussion: https://postgr.es/m/fed17dac-8cb8-4f5b-d462-1bb4908c029e@garret.ru
Backpatch-through: 11
M src/backend/access/heap/heapam.c
Fix alter_table.sql test case to test what it claims to.
commit : 294a2199a331ff719e0d0fe70fd2b6200689eb16
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Nov 2022 17:24:26 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Nov 2022 17:24:26 -0500
The stanza "SET STORAGE may need to add a TOAST table" does not
test what it's supposed to, and hasn't done so since we added
the ability to store constant column default values as metadata.
We need to use a non-constant default to get the expected table
rewrite to actually happen.
Fix that, and add the missing checks that would have exposed the
problem to begin with.
Noted while reviewing a patch that made changes in this test case.
Back-patch to v11 where the problem came in.
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Re-allow building on Microsoft Visual Studio 2013.
commit : 0942acb73efcff1564f8d1b1ae890c8135467eae
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Nov 2022 10:23:49 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Nov 2022 10:23:49 -0500
In commit 450ee7012 I supposed that all platforms we now care about have
snprintf(), since that's required by C99. Turns out that Microsoft did
not get around to adding that until VS2015. We've dropped support for
VS2013 as of HEAD (cf 6203583b7), but not in the back branches, so add
a hack for this in the back branches only.
There's no easy shortcut to an exact emulation of standard snprintf
in VS2013, but fortunately we don't need one: this code was just fine
with using sprintf before 450ee7012, so we can make it do so again
on that platform (and any others where the problem might crop up).
Per bug #17681 from Daisuke Higuchi. Back-patch to v12, like the
previous patch.
Discussion: https://postgr.es/m/17681-485ba2ec13e7f392@postgresql.org
M src/port/snprintf.c
Doc: add comments about PreventInTransactionBlock/IsInTransactionBlock.
commit : 1949135e79e852e19958873203bf32691754faaa
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 9 Nov 2022 11:08:52 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 9 Nov 2022 11:08:52 -0500
Add a little to the header comments for these functions to make it
clearer what guarantees about commit behavior are provided to callers.
(See commit f92944137 for context.)
Although this is only a comment change, it's really documentation
aimed at authors of extensions, so it seems appropriate to back-patch.
Yugo Nagata and Tom Lane, per further discussion of bug #17434.
Discussion: https://postgr.es/m/17434-d9f7a064ce2a88a3@postgresql.org
M src/backend/access/transam/xact.c
Fix compilation warnings with libselinux 3.1 in contrib/sepgsql/
commit : c304c069d14805b1e2e034ec01236077139091cf
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 9 Nov 2022 09:39:53 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 9 Nov 2022 09:39:53 +0900
Upstream SELinux has recently marked security_context_t as officially
deprecated, causing warnings with -Wdeprecated-declarations. This is
considered as legacy code for some time now by upstream as
security_context_t got removed from most of the code tree during the
development of 2.3 back in 2014.
This removes all the references to security_context_t in sepgsql/ to be
consistent with SELinux, fixing the warnings. Note that this does not
impact the minimum version of libselinux supported.
This has been applied first as 1f32136 for 14~, but no other branches
got the call. This is in line with the recent project policy to have no
warnings in branches where builds should still be supported (9.2~ as of
today). Per discussion with Tom Lane and Álvaro Herrera.
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/20200813012735.GC11663@paquier.xyz
Discussion: https://postgr.es/m/20221103181028.raqta27jcuypor4l@alvherre.pgsql
Backpatch-through: 9.2
M contrib/sepgsql/label.c
M contrib/sepgsql/selinux.c
M contrib/sepgsql/uavc.c
Doc: improve tutorial section about grouped aggregates.
commit : 2dca4d38c0b7025bf48db13727360177dd64c570
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Nov 2022 18:25:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 8 Nov 2022 18:25:03 -0500
Commit fede15417 introduced FILTER by jamming it into the existing
example introducing HAVING, which seems pedagogically poor to me;
and it added no information about what the keyword actually does.
Not to mention that the claimed output didn't match the sample
data being used in this running example.
Revert that and instead make an independent example using FILTER.
To help drive home the point that it's a per-aggregate filter,
we need to use two aggregates not just one; for consistency
expand all the examples in this segment to do that.
Also adjust the example using WHERE ... LIKE so that it'd produce
nonempty output with this sample data, and show that output.
Back-patch, as the previous patch was. (Sadly, v10 is now out
of scope.)
Discussion: https://postgr.es/m/166794307526.652.9073408178177444190@wrigleys.postgresql.org
M doc/src/sgml/query.sgml