17.8 standby crashes during WAL replay from 17.5 primary: "could not access status of transaction"

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