'latest_page_number' is set to the correct value, according to
nextOffset, early at system startup. Contrary to the comment, it hence
should be set up correctly by the time we get to WAL replay.
This was committed to back-branches earlier already (commit
817f74600d), to fix a bug in a backwards-compatibility codepath. We
don't have that bug on 'master', but the change nevertheless makes
sense on 'master' too.
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
Reviewed-by: Kirill Reshke <reshkekirill@gmail.com>
Discussion: https://www.postgresql.org/message-id/
20260214090150.GC2297@p46.dedyn.io;lightning.p46.dedyn.io
Discussion: https://www.postgresql.org/message-id/
e1787b17-dc93-4621-a5a1-
c713d1ac6a1b@iki.fi
else if (info == XLOG_MULTIXACT_TRUNCATE_ID)
{
xl_multixact_truncate xlrec;
- int64 pageno;
memcpy(&xlrec, XLogRecGetData(record),
SizeOfMultiXactTruncate);
SetMultiXactIdLimit(xlrec.oldestMulti, xlrec.oldestMultiDB);
PerformMembersTruncation(xlrec.oldestOffset);
-
- /*
- * During XLOG replay, latest_page_number isn't necessarily set up
- * yet; insert a suitable value to bypass the sanity test in
- * SimpleLruTruncate.
- */
- pageno = MultiXactIdToOffsetPage(xlrec.oldestMulti);
- pg_atomic_write_u64(&MultiXactOffsetCtl->shared->latest_page_number,
- pageno);
PerformOffsetsTruncation(xlrec.oldestMulti);
LWLockRelease(MultiXactTruncationLock);