MIME-Version: 1.0
From: Sebastian Webber <sebastian@swebber.me>
Date: Fri, 13 Feb 2026 17:31:18 -0300
Message-ID: <CACV2tSw3VYS7d27ftO_cs+aF3M54+JwWBbqSGLcKoG9cvyb6EA@mail.gmail.com>
Subject: 17.8 standby crashes during WAL replay from 17.5 primary: "could not
 access status of transaction"
To: pgsql-bugs@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000008a44f7064aba7df1"
Archived-At: <https://www.postgresql.org/message-id/CACV2tSw3VYS7d27ftO_cs%2BaF3M54%2BJwWBbqSGLcKoG9cvyb6EA%40mail.gmail.com>
Precedence: bulk

--0000000000008a44f7064aba7df1
Content-Type: text/plain; charset="UTF-8"

PostgreSQL version: 17.8 (standby), 17.5 (primary)

Primary: PostgreSQL 17.5 (Debian 17.5-1.pgdg130+1) on
aarch64-unknown-linux-gnu
Standby: PostgreSQL 17.8 (Debian 17.8-1.pgdg13+1) on
aarch64-unknown-linux-gnu

Platform: Docker containers on macOS (Apple Silicon / aarch64), Docker
Desktop


Description
-----------

A PostgreSQL 17.8 standby crashes during WAL replay when streaming
from a 17.5 primary. The crash occurs after replaying a
MultiXact/TRUNCATE_ID record followed by a MultiXact/CREATE_ID
record.


Steps to reproduce
------------------

1. Start a 17.5 primary configured for streaming replication
2. Seed a database with ~2GB of data (tables with foreign key
   constraints)
3. Start a 17.5 standby via pg_basebackup, confirm streaming
   replication
4. Generate ~500K MultiXact IDs using concurrent SELECT ... FOR SHARE
   / FOR KEY SHARE on the same rows
5. Run VACUUM on the multixact-heavy tables (generates TRUNCATE_ID
   WAL records)
6. Stop the 17.5 standby
7. Continue generating ~2M additional MultiXact IDs on the primary
   (builds WAL backlog)
8. Start a 17.8 standby on the same data volume -- it begins
   replaying the WAL backlog
9. Standby crashes during replay

An automated reproducer (Go program + shell scripts) is available at:
https://gist.github.com/sebastianwebber/2cd25d298bfe85cabcd8d41f83591acb

It requires Go 1.22+ and Docker. Typical runtime is ~10 minutes.

  go run main.go --cleanup


Actual output (standby log)
----------------------------

The standby successfully replays multiple SLRU page boundaries with
this pattern:

  DEBUG:  next offsets page is not initialized, initializing it now
  CONTEXT:  WAL redo at 3/28C148D8 for MultiXact/CREATE_ID: 856063 offset
6680130 nmembers 9: ...
  DEBUG:  skipping initialization of offsets page 418 because it was
already initialized on multixid creation
  CONTEXT:  WAL redo at 3/28C149B8 for MultiXact/ZERO_OFF_PAGE: 418

This repeats for pages 408 through 418. Then a truncation occurs:

  DEBUG:  replaying multixact truncation: offsets [1, 490986), offsets
segments [0, 7), members [1, 3864017), members segments [0, 49)
  CONTEXT:  WAL redo at 3/29D6D548 for MultiXact/TRUNCATE_ID: offsets [1,
490986), members [1, 3864017)

The very next CREATE_ID crashes:

  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)

  LOG:  startup process (PID 29) exited with exit code 1
  LOG:  shutting down due to startup process failure


Expected output
---------------

The standby should successfully replay all WAL records and reach a
consistent streaming state.


Configuration (non-default on primary)
--------------------------------------

  wal_level = replica
  max_wal_senders = 10
  max_connections = 1200
  shared_buffers = 256MB
  wal_keep_size = 16GB
  autovacuum_multixact_freeze_max_age = 100000
  vacuum_multixact_freeze_min_age = 1000
  vacuum_multixact_freeze_table_age = 50000

Standby configured with log_min_messages = debug1.

-- 
Sebastian Webber

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

<div dir=3D"ltr"><div>PostgreSQL version: 17.8 (standby), 17.5 (primary)<br=
><br>Primary: PostgreSQL 17.5 (Debian 17.5-1.pgdg130+1) on aarch64-unknown-=
linux-gnu<br>Standby: PostgreSQL 17.8 (Debian 17.8-1.pgdg13+1) on aarch64-u=
nknown-linux-gnu<br><br>Platform: Docker containers on macOS (Apple Silicon=
 / aarch64), Docker Desktop<br><br><br>Description<br>-----------<br><br>A =
PostgreSQL 17.8 standby crashes during WAL replay when streaming<br>from a =
17.5 primary. The crash occurs after replaying a<br>MultiXact/TRUNCATE_ID r=
ecord followed by a MultiXact/CREATE_ID<br>record.<br><br><br>Steps to repr=
oduce<br>------------------<br><br>1. Start a 17.5 primary configured for s=
treaming replication<br>2. Seed a database with ~2GB of data (tables with f=
oreign key<br>=C2=A0 =C2=A0constraints)<br>3. Start a 17.5 standby via pg_b=
asebackup, confirm streaming<br>=C2=A0 =C2=A0replication<br>4. Generate ~50=
0K MultiXact IDs using concurrent SELECT ... FOR SHARE<br>=C2=A0 =C2=A0/ FO=
R KEY SHARE on the same rows<br>5. Run VACUUM on the multixact-heavy tables=
 (generates TRUNCATE_ID<br>=C2=A0 =C2=A0WAL records)<br>6. Stop the 17.5 st=
andby<br>7. Continue generating ~2M additional MultiXact IDs on the primary=
<br>=C2=A0 =C2=A0(builds WAL backlog)<br>8. Start a 17.8 standby on the sam=
e data volume -- it begins<br>=C2=A0 =C2=A0replaying the WAL backlog<br>9. =
Standby crashes during replay<br><br>An automated reproducer (Go program + =
shell scripts) is available at:<br><a href=3D"https://gist.github.com/sebas=
tianwebber/2cd25d298bfe85cabcd8d41f83591acb">https://gist.github.com/sebast=
ianwebber/2cd25d298bfe85cabcd8d41f83591acb</a><br><br>It requires Go 1.22+ =
and Docker. Typical runtime is ~10 minutes.<br><br>=C2=A0 go run main.go --=
cleanup<br><br><br>Actual output (standby log)<br>-------------------------=
---<br><br>The standby successfully replays multiple SLRU page boundaries w=
ith<br>this pattern:<br><br>=C2=A0 DEBUG: =C2=A0next offsets page is not in=
itialized, initializing it now<br>=C2=A0 CONTEXT: =C2=A0WAL redo at 3/28C14=
8D8 for MultiXact/CREATE_ID: 856063 offset 6680130 nmembers 9: ...<br>=C2=
=A0 DEBUG: =C2=A0skipping initialization of offsets page 418 because it was=
 already initialized on multixid creation<br>=C2=A0 CONTEXT: =C2=A0WAL redo=
 at 3/28C149B8 for MultiXact/ZERO_OFF_PAGE: 418<br><br>This repeats for pag=
es 408 through 418. Then a truncation occurs:<br><br>=C2=A0 DEBUG: =C2=A0re=
playing multixact truncation: offsets [1, 490986), offsets segments [0, 7),=
 members [1, 3864017), members segments [0, 49)<br>=C2=A0 CONTEXT: =C2=A0WA=
L redo at 3/29D6D548 for MultiXact/TRUNCATE_ID: offsets [1, 490986), member=
s [1, 3864017)<br><br>The very next CREATE_ID crashes:<br><br>=C2=A0 FATAL:=
 =C2=A0could not access status of transaction 858112<br>=C2=A0 DETAIL: =C2=
=A0Could not read from file &quot;pg_multixact/offsets/000D&quot; at offset=
 24576: read too few bytes.<br>=C2=A0 CONTEXT: =C2=A0WAL redo at 3/2A3AB408=
 for MultiXact/CREATE_ID: 858111 offset 6695072 nmembers 5: 1048228 (sh) 10=
48271 (keysh) 1048316 (sh) 1048344 (keysh) 1048370 (sh)<br><br>=C2=A0 LOG: =
=C2=A0startup process (PID 29) exited with exit code 1<br>=C2=A0 LOG: =C2=
=A0shutting down due to startup process failure<br><br><br>Expected output<=
br>---------------<br><br>The standby should successfully replay all WAL re=
cords and reach a<br>consistent streaming state.<br><br><br>Configuration (=
non-default on primary)<br>--------------------------------------<br><br>=
=C2=A0 wal_level =3D replica<br>=C2=A0 max_wal_senders =3D 10<br>=C2=A0 max=
_connections =3D 1200<br>=C2=A0 shared_buffers =3D 256MB<br>=C2=A0 wal_keep=
_size =3D 16GB<br>=C2=A0 autovacuum_multixact_freeze_max_age =3D 100000<br>=
=C2=A0 vacuum_multixact_freeze_min_age =3D 1000<br>=C2=A0 vacuum_multixact_=
freeze_table_age =3D 50000<br><br>Standby configured with log_min_messages =
=3D debug1.<br></div><div><br></div><span class=3D"gmail_signature_prefix">=
-- </span><br><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"=
gmail_signature"><div dir=3D"ltr"><div dir=3D"ltr">Sebastian Webber<br></di=
v></div></div></div>

--0000000000008a44f7064aba7df1--