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