MIME-Version: 1.0
From: =?UTF-8?Q?Torsten_F=C3=B6rtsch?= <tfoertsch123@gmail.com>
Date: Wed, 18 Feb 2026 08:40:22 +0000
Message-ID: <CAKkG4_kU9=VHM7BT0wAV+L9nKRB2UWQLYLkQdatJZK9GKwc4Pg@mail.gmail.com>
Subject: Bug: PG 14 recovery failure
To: PostgreSQL mailing lists <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="00000000000031a6ef064b15246d"
Archived-At: <https://www.postgresql.org/message-id/CAKkG4_kU9%3DVHM7BT0wAV%2BL9nKRB2UWQLYLkQdatJZK9GKwc4Pg%40mail.gmail.com>
Precedence: bulk

--00000000000031a6ef064b15246d
Content-Type: text/plain; charset="UTF-8"

Hi,

for many years I have been running a backup check system for my databases
that constantly
- upgrade to the latest available PG minor version (Debian PGDG)
- restore a DB from a basebackup on S3
- replay all available WAL
- perform a ton consistency checks
- repeat the same with the next DB
- when all DBs are done start from the beginning

All the DBs are PG14. After 14.21 was released last week I saw some of our
bigger DBs failing after replaying a few 1000 WAL files.

The error message reads like so:

2026-02-14 01:53:59.595 UTC [2441074] LOG: restored log file
"0000000500017F8D0000004E" from archive 2026-02-14 01:53:59.605 UTC
[2441074] FATAL: could not access status of transaction 2030956544
2026-02-14 01:53:59.605 UTC [2441074] DETAIL: Could not read from file
"pg_multixact/offsets/790D" at offset 245760: read too few bytes.
2026-02-14 01:53:59.605 UTC [2441074] CONTEXT: WAL redo at 17F8D/4E1E03E8
for MultiXact/CREATE_ID: 2030956543 offset 1335629905 nmembers 2: 691151655
(keysh) 691151658 (keysh)
It does not happen every time. A freshly taken backup succeeded in
restoring ~3000 WAL files. In the next round it failed at ~5000 WAL files.
If it fails, it is reproducible. It will fail at the same multixact offset
again.

The multixact offset file where it fails does not exist in the base backup.
It is built during replay. In all cases I saw, the offset mentioned in the
error message is the length of the file. So, PG apparently wants to read
beyond the end of the file.

After rolling back to PG 14.20, everything started working again.

The release notes mention a few multixact changes from 14.20 to 14.21. I
can't claim to understand the change fully. But
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=81416e101
looks like the best culprit candidate to me.

All the best,
Torsten

--00000000000031a6ef064b15246d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>for many years I have been running =
a backup check system for my databases that constantly</div><div>- upgrade =
to the latest available PG minor version (Debian PGDG)</div><div>- restore =
a DB from a basebackup on S3</div><div>- replay all available WAL</div><div=
>- perform a ton consistency checks</div><div>- repeat the same with the ne=
xt DB</div><div>- when all DBs are done start from the beginning</div><div>=
<br></div><div>All the DBs are PG14. After 14.21 was released last week I s=
aw some of our bigger DBs failing after replaying a few 1000 WAL files.</di=
v><div><br></div><div>The error message reads like so:</div><div><br></div>=
<div><span style=3D"color:rgb(29,28,29);font-family:Monaco,Menlo,Consolas,&=
quot;Courier New&quot;,monospace;font-size:12px;white-space:pre;background-=
color:rgb(248,248,248)">2026-02-14 01:53:59.595 UTC [2441074] LOG:  restore=
d log file &quot;0000000500017F8D0000004E&quot; from archive
2026-02-14 01:53:59.605 UTC [2441074] FATAL:  could not access status of tr=
ansaction 2030956544
2026-02-14 01:53:59.605 UTC [2441074] DETAIL:  Could not read from file &qu=
ot;pg_multixact/offsets/790D&quot; at offset 245760: read too few bytes.
2026-02-14 01:53:59.605 UTC [2441074] CONTEXT:  WAL redo at 17F8D/4E1E03E8 =
for MultiXact/CREATE_ID: 2030956543 offset 1335629905 nmembers 2: 691151655=
 (keysh) 691151658 (keysh)
</span><br class=3D"gmail-Apple-interchange-newline"></div><div>It does not=
 happen every time. A freshly taken backup succeeded in restoring ~3000 WAL=
 files. In the next round it failed at ~5000 WAL files. If it fails, it is =
reproducible. It will fail at the same multixact offset again.</div><div><b=
r></div><div>The multixact offset file where it fails does not exist in the=
 base backup. It is built during replay. In all cases I saw, the offset men=
tioned in the error message is the length of the file. So, PG apparently wa=
nts to read beyond the end of the file.</div><div><br></div><div>After roll=
ing back to PG 14.20, everything started working again.</div><div><br></div=
><div>The release notes mention a few multixact changes from 14.20 to 14.21=
. I can&#39;t claim to understand the change fully. But=C2=A0<a href=3D"htt=
ps://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dcommitdiff;h=3D81416=
e101">https://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dcommitdiff;=
h=3D81416e101</a> looks like the best culprit candidate to me.</div><div><b=
r></div><div>All the best,</div><div>Torsten</div></div>

--00000000000031a6ef064b15246d--