Re: Bug in MultiXact replay compat logic for older minor version after crash-recovery
x4mmm@yandex-team.ru
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: "段坤仁(刻韧)" <duankunren.dkr@alibaba-inc.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-03-20T13:39:32Z
Lists: pgsql-hackers
> On 20 Mar 2026, at 16:19, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > > Hmm, after startup, before we have zeroed any pages, it still works though. So I think my patch works, but it means that tracking the latest page we have zeroed is not merely an optimization to avoid excessive SimpleLruDoesPhysicalPageExist() calls, it's needed for correctness. Need to adjust the comments for that. If we are sure buffers have no this page we can detect it via FS. Otherwise... nothing bad can happen, actually. We might get false positive and zero the page once more. If we got init_needed==false, maybe cache it for this page and set last_initialized_offsets_page = pageno? Or, perhaps, XLOG_MULTIXACT_ZERO_OFF_PAGE will do it for us anyway, but a bit later. Best regards, Andrey Borodin.
Commits
-
Fix multixact backwards-compatibility with CHECKPOINT race condition
- e35e466f61b3 14.23 landed
- a5f412107f98 15.18 landed
- 77dff5d937b1 16.14 landed
- 1ca38503219a 17.10 landed
- 0852643e1c60 18.4 landed
-
Don't reset 'latest_page_number' when replaying multixid truncation
- 516310ed4dba 19 (unreleased) cited