> 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
toofew 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.
