Re: 17.8 standby crashes during WAL replay from 17.5 primary: "could not access status of transaction"
Michael Banck <mbanck@gmx.net>
From: Michael Banck <mbanck@gmx.net>
To: Sebastian Webber <sebastian@swebber.me>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2026-02-14T09:05:02Z
Lists: pgsql-bugs
Hi, On Fri, Feb 13, 2026 at 05:31:18PM -0300, Sebastian Webber wrote: > 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. Ouch. For the record, somebody else (Jacob Bunk Nielsen) reported the same(?) issue independently on Slack: |We are running a PostgreSQL 17.7 primary with a number of physical replicas. We upgraded some of the replicas from 17.5 to 17.8 earlier today, and now 4 of them consistently die after a short time with errors like: | |Feb 13 13:36:01 srv2 postgres[13068]: [12-1] 2026-02-13 13:36:01 UTC::@:[13068]: FATAL: could not access status of transaction 155428864 |Feb 13 13:36:01 srv2 postgres[13068]: [12-2] 2026-02-13 13:36:01 UTC::@:[13068]: DETAIL: Could not read from file "pg_multixact/offsets/0943" at offset 172032: read too few bytes. |Feb 13 13:36:01 srv2 postgres[13068]: [12-3] 2026-02-13 13:36:01 UTC::@:[13068]: CONTEXT: WAL redo at 9F79/27144740 for MultiXact/CREATE_ID: 155428863 offset 1359592572 nmembers 2: 448728610 (keysh) 448728612 (keysh) | |Did we hit a bug in the newly released 17.8? Sebastian, as it looks like you are able to reproduce it - are you maybe in a position to bisect from 17.5 to 17.8 to see which commit is responsible for this? Michael
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Don't reset 'latest_page_number' when replaying multixid truncation
- 516310ed4dba 19 (unreleased) landed
- 547a8aaa7d4f 14.22 landed
- 899de38d8f3b 15.17 landed
- 23064542f8bd 16.13 landed
- 4a36c89f1657 17.9 landed
- 817f74600d0d 18.3 landed
-
Set next multixid's offset when creating a new multixid
- 8ba61bc06386 17.8 cited
-
Rework the way multixact truncations work.
- 4f627f897367 9.6.0 cited