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-14T16:18:39Z
Lists: pgsql-bugs 
Ouch...

I remember this place. For some reason I thought endTruncOff is the end of offsets. That would make sense here... Now I see it's just a new oldest offset.

> On 14 Feb 2026, at 16:42, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> 
> If we want to play it even more safe -- and I guess that's the right thing to do for backpatching -- we could set latest_page_number *temporarily* while we do the the truncation, and restore the old value afterwards.

As far as I can see, the only relevant usage of last_page_number is:
/*
 * While we are holding the lock, make an important safety check: the
 * current endpoint page must not be eligible for removal.
 */
if (ctl->PagePrecedes(shared->latest_page_number, cutoffPage))
{
	LWLockRelease(shared->ControlLock);
	ereport(LOG,
		(errmsg("could not truncate directory \"%s\": apparent wraparound",
		ctl->Dir)));
	return;
}


Perhaps, we also can bump latest_page_number forward?


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.