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

Andrey Borodin <x4mmm@yandex-team.ru>

From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Sebastian Webber <sebastian@swebber.me>, pgsql-bugs@lists.postgresql.org, Andrey Borodin <amborodin@acm.org>, Álvaro Herrera <alvherre@kurilemu.de>, Dmitry Yurichev <dsy.075@yandex.ru>, Chao Li <li.evan.chao@gmail.com>, Ivan Bykov <i.bykov@modernsys.ru>, Kirill Reshke <reshkekirill@gmail.com>
Date: 2026-02-15T18:11:32Z
Lists: pgsql-bugs

Attachments


> On 14 Feb 2026, at 22:41, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> 
> Wiping write by XLOG_MULTIXACT_TRUNCATE_ID seems correct to me everywhere 14-18.

FWIW I've tried to create a TAP-reproducer, but it's tricky in controlled environment.
But I've created a TAP that triggers near-wraparound truncation:

2026-02-15 23:05:57.716 +05 [73950] DEBUG: replaying multixact truncation: offsets [1, 2147483648), offsets segments [0, 8000), members [1, 3), members segments [0, 0)
2026-02-15 23:05:57.716 +05 [73950] CONTEXT: WAL redo at 0/309CD70 for MultiXact/TRUNCATE_ID: offsets [1, 2147483648), members [1, 3)
2026-02-15 23:05:57.716 +05 [73950] DEBUG: MultiXactId wrap limit is 4294967295, limited by database with OID 1
2026-02-15 23:05:57.716 +05 [73950] CONTEXT: WAL redo at 0/309CD70 for MultiXact/TRUNCATE_ID: offsets [1, 2147483648), members [1, 3)
2026-02-15 23:05:57.716 +05 [73950] LOG: file "pg_multixact/offsets/8000" doesn't exist, reading as zeroes


And I observe no problems with applied "0001-Don-t-reset-latest_page_number-when-replaying-multix.patch"


Best regards, Andrey Borodin.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Don't reset 'latest_page_number' when replaying multixid truncation

  2. Set next multixid's offset when creating a new multixid

  3. Rework the way multixact truncations work.