Horton
Menu

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

Andrey Borodin <x4mmm@yandex-team.ru>

View thread
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-14T17:41:43Z
Lists: pgsql-bugs 

> On 14 Feb 2026, at 21:18, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> 
> Perhaps, we also can bump latest_page_number forward?
This is not a good idea, we don't want "most accurate latest_page_number", we need precise number at any point after StartupMultiXact().

Wiping write by XLOG_MULTIXACT_TRUNCATE_ID seems correct to me everywhere 14-18.

I'd also suggest updating comment:

* this is not critical data, since we use it only to avoid swapping out
* the latest page.

It's absolutely critical now.


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.