pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Don't reset 'latest_page_number' when replaying multixid truncat
6+ messages / 1 participants
[nested] [flat]
* pgsql: Don't reset 'latest_page_number' when replaying multixid truncat
@ 2026-02-16 16:01 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-02-16 16:01 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Don't reset 'latest_page_number' when replaying multixid truncation
'latest_page_number' is set to the correct value, according to
nextOffset, early at system startup. Contrary to the comment, it hence
should be set up correctly by the time we get to WAL replay.
This fixes a failure to replay WAL generated on older minor versions,
before commit 789d65364c (18.2, 17.8, 16.12, 15.16, 14.21). The
failure occurs after a truncation record has been replayed and looks
like this:
FATAL: could not access status of transaction 858112
DETAIL: Could not read from file "pg_multixact/offsets/000D" at offset 24576: read too few bytes.
CONTEXT: WAL redo at 3/2A3AB408 for MultiXact/CREATE_ID: 858111 offset 6695072 nmembers 5: 1048228 (sh) 1048271 (keysh) 1048316 (sh) 1048344 (keysh) 1048370 (sh)
Reported-by: Sebastian Webber <sebastian@swebber.me>
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>
Discussion: https://www.postgresql.org/message-id/20260214090150.GC2297@p46.dedyn.io;lightning.p46.dedyn.io
Backpatch-through: 14-18
Branch
------
REL_18_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/817f74600d0d015309596762c9e4a07e0ac8fdbf
Modified Files
--------------
src/backend/access/transam/multixact.c | 10 ----------
src/include/access/slru.h | 4 +++-
2 files changed, 3 insertions(+), 11 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't reset 'latest_page_number' when replaying multixid truncat
@ 2026-02-16 16:01 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-02-16 16:01 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Don't reset 'latest_page_number' when replaying multixid truncation
'latest_page_number' is set to the correct value, according to
nextOffset, early at system startup. Contrary to the comment, it hence
should be set up correctly by the time we get to WAL replay.
This fixes a failure to replay WAL generated on older minor versions,
before commit 789d65364c (18.2, 17.8, 16.12, 15.16, 14.21). The
failure occurs after a truncation record has been replayed and looks
like this:
FATAL: could not access status of transaction 858112
DETAIL: Could not read from file "pg_multixact/offsets/000D" at offset 24576: read too few bytes.
CONTEXT: WAL redo at 3/2A3AB408 for MultiXact/CREATE_ID: 858111 offset 6695072 nmembers 5: 1048228 (sh) 1048271 (keysh) 1048316 (sh) 1048344 (keysh) 1048370 (sh)
Reported-by: Sebastian Webber <sebastian@swebber.me>
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>
Discussion: https://www.postgresql.org/message-id/20260214090150.GC2297@p46.dedyn.io;lightning.p46.dedyn.io
Backpatch-through: 14-18
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/4a36c89f1657e0c159a1dcef18f5da4f2cc9348f
Modified Files
--------------
src/backend/access/transam/multixact.c | 10 ----------
src/include/access/slru.h | 4 +++-
2 files changed, 3 insertions(+), 11 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't reset 'latest_page_number' when replaying multixid truncat
@ 2026-02-16 16:01 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-02-16 16:01 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Don't reset 'latest_page_number' when replaying multixid truncation
'latest_page_number' is set to the correct value, according to
nextOffset, early at system startup. Contrary to the comment, it hence
should be set up correctly by the time we get to WAL replay.
This fixes a failure to replay WAL generated on older minor versions,
before commit 789d65364c (18.2, 17.8, 16.12, 15.16, 14.21). The
failure occurs after a truncation record has been replayed and looks
like this:
FATAL: could not access status of transaction 858112
DETAIL: Could not read from file "pg_multixact/offsets/000D" at offset 24576: read too few bytes.
CONTEXT: WAL redo at 3/2A3AB408 for MultiXact/CREATE_ID: 858111 offset 6695072 nmembers 5: 1048228 (sh) 1048271 (keysh) 1048316 (sh) 1048344 (keysh) 1048370 (sh)
Reported-by: Sebastian Webber <sebastian@swebber.me>
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>
Discussion: https://www.postgresql.org/message-id/20260214090150.GC2297@p46.dedyn.io;lightning.p46.dedyn.io
Backpatch-through: 14-18
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/23064542f8bdcbc4b6a513cac8ceed67c0d2336e
Modified Files
--------------
src/backend/access/transam/multixact.c | 9 ---------
src/include/access/slru.h | 4 +++-
2 files changed, 3 insertions(+), 10 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't reset 'latest_page_number' when replaying multixid truncat
@ 2026-02-16 16:01 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-02-16 16:01 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Don't reset 'latest_page_number' when replaying multixid truncation
'latest_page_number' is set to the correct value, according to
nextOffset, early at system startup. Contrary to the comment, it hence
should be set up correctly by the time we get to WAL replay.
This fixes a failure to replay WAL generated on older minor versions,
before commit 789d65364c (18.2, 17.8, 16.12, 15.16, 14.21). The
failure occurs after a truncation record has been replayed and looks
like this:
FATAL: could not access status of transaction 858112
DETAIL: Could not read from file "pg_multixact/offsets/000D" at offset 24576: read too few bytes.
CONTEXT: WAL redo at 3/2A3AB408 for MultiXact/CREATE_ID: 858111 offset 6695072 nmembers 5: 1048228 (sh) 1048271 (keysh) 1048316 (sh) 1048344 (keysh) 1048370 (sh)
Reported-by: Sebastian Webber <sebastian@swebber.me>
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>
Discussion: https://www.postgresql.org/message-id/20260214090150.GC2297@p46.dedyn.io;lightning.p46.dedyn.io
Backpatch-through: 14-18
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/899de38d8f3b519e7fd5b2acf580d1c9282ee6f1
Modified Files
--------------
src/backend/access/transam/multixact.c | 9 ---------
src/include/access/slru.h | 4 +++-
2 files changed, 3 insertions(+), 10 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't reset 'latest_page_number' when replaying multixid truncat
@ 2026-02-16 16:01 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-02-16 16:01 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Don't reset 'latest_page_number' when replaying multixid truncation
'latest_page_number' is set to the correct value, according to
nextOffset, early at system startup. Contrary to the comment, it hence
should be set up correctly by the time we get to WAL replay.
This fixes a failure to replay WAL generated on older minor versions,
before commit 789d65364c (18.2, 17.8, 16.12, 15.16, 14.21). The
failure occurs after a truncation record has been replayed and looks
like this:
FATAL: could not access status of transaction 858112
DETAIL: Could not read from file "pg_multixact/offsets/000D" at offset 24576: read too few bytes.
CONTEXT: WAL redo at 3/2A3AB408 for MultiXact/CREATE_ID: 858111 offset 6695072 nmembers 5: 1048228 (sh) 1048271 (keysh) 1048316 (sh) 1048344 (keysh) 1048370 (sh)
Reported-by: Sebastian Webber <sebastian@swebber.me>
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>
Discussion: https://www.postgresql.org/message-id/20260214090150.GC2297@p46.dedyn.io;lightning.p46.dedyn.io
Backpatch-through: 14-18
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/547a8aaa7d4fffd686c75b1e00b1c11c0980aabc
Modified Files
--------------
src/backend/access/transam/multixact.c | 9 ---------
src/include/access/slru.h | 4 +++-
2 files changed, 3 insertions(+), 10 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Don't reset 'latest_page_number' when replaying multixid truncat
@ 2026-03-22 12:29 Heikki Linnakangas <heikki.linnakangas@iki.fi>
0 siblings, 0 replies; 6+ messages in thread
From: Heikki Linnakangas @ 2026-03-22 12:29 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Don't reset 'latest_page_number' when replaying multixid truncation
'latest_page_number' is set to the correct value, according to
nextOffset, early at system startup. Contrary to the comment, it hence
should be set up correctly by the time we get to WAL replay.
This was committed to back-branches earlier already (commit
817f74600d), to fix a bug in a backwards-compatibility codepath. We
don't have that bug on 'master', but the change nevertheless makes
sense on 'master' too.
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>
Discussion: https://www.postgresql.org/message-id/20260214090150.GC2297@p46.dedyn.io;lightning.p46.dedyn.io
Discussion: https://www.postgresql.org/message-id/e1787b17-dc93-4621-a5a1-c713d1ac6a1b@iki.fi
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/516310ed4dba89bd300242df0d56b4782f33ed4d
Modified Files
--------------
src/backend/access/transam/multixact.c | 10 ----------
1 file changed, 10 deletions(-)
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-03-22 12:29 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-02-16 16:01 pgsql: Don't reset 'latest_page_number' when replaying multixid truncat Heikki Linnakangas <heikki.linnakangas@iki.fi>
2026-02-16 16:01 pgsql: Don't reset 'latest_page_number' when replaying multixid truncat Heikki Linnakangas <heikki.linnakangas@iki.fi>
2026-02-16 16:01 pgsql: Don't reset 'latest_page_number' when replaying multixid truncat Heikki Linnakangas <heikki.linnakangas@iki.fi>
2026-02-16 16:01 pgsql: Don't reset 'latest_page_number' when replaying multixid truncat Heikki Linnakangas <heikki.linnakangas@iki.fi>
2026-02-16 16:01 pgsql: Don't reset 'latest_page_number' when replaying multixid truncat Heikki Linnakangas <heikki.linnakangas@iki.fi>
2026-03-22 12:29 pgsql: Don't reset 'latest_page_number' when replaying multixid truncat Heikki Linnakangas <heikki.linnakangas@iki.fi>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox