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

> On 16 Feb 2026, at 21:01, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> 
> Andrey if you can verify with your TAP test, too, that'd be great.

Here's a hand-wavy test on top of REL_17_STABLE. It modifies binaries to simulate old WAL write behavior.
I tried to hack it with -DDEMO_SIMULATE_OLD_MULTIXACT_BEHAVIOR, but gave up and just hardcoded.
We are not going to commit it, aren't we?

If we comment out this line (patch does it)

        pg_atomic_write_u64(&MultiXactOffsetCtl->shared->latest_page_number,
pageno);

the test will pass.

Either way it will hang indefinitely because

2026-02-18 13:44:12.238 +05 [52360] LOG: started streaming WAL from primary at 0/3000000 on timeline 1
2026-02-18 13:44:12.250 +05 [52359] FATAL: could not access status of transaction 4096
2026-02-18 13:44:12.250 +05 [52359] DETAIL: Could not read from file "pg_multixact/offsets/0000" at offset 16384: read too few bytes.
2026-02-18 13:44:12.250 +05 [52359] CONTEXT: WAL redo at 0/30245E0 for MultiXact/CREATE_ID: 4095 offset 8189 nmembers 2: 4835 (sh) 4835 (upd)

Most hand-wavy part is test_multixact_write_truncate_wal(): truncation is synthetic.

FWIW, a lot of calculations and commenting done by LLM. Let me know if such a verbosity is not good for readability.


Best regards, Andrey Borodin.