Re: Bug in MultiXact replay compat logic for older minor version after crash-recovery - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Bug in MultiXact replay compat logic for older minor version after crash-recovery
Date
Msg-id F513DFBB-DCFE-4B99-B01E-DDB04414857C@yandex-team.ru
Whole thread Raw
In response to Re: Bug in MultiXact replay compat logic for older minor version after crash-recovery  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Bug in MultiXact replay compat logic for older minor version after crash-recovery
List pgsql-hackers

> On 19 Mar 2026, at 23:11, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
> :-(. This is a gift that keeps giving.

Well, maybe, we could leaving that deadlock in place for some time...

> Idea 3:
>
> I think a better fix is to accept that our tracking is a little imprecise and use SimpleLruDoesPhysicalPageExist() to
checkif the page exists. I suspect that's too expensive to do on every RecordNewMultiXact() call that crosses a page,
butperhaps we could do it once at StartupMultiXact(). 
>
> Or perhaps track last-zeroed page separately from latest_page_number, and if we haven't seen any
XLOG_MULTIXACT_ZERO_OFF_PAGErecords yet after startup, call SimpleLruDoesPhysicalPageExist() to determine if
initializationis needed. Attached patch does that. 

SimpleLruDoesPhysicalPageExist() does not detect recently zeroed pages via buffers, because it goes directly to FS.
I tried this approach when implementing deadlock fix, it did not work for me.


Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: Marco Nenciarini
Date:
Subject: Re: BUG: Cascading standby fails to reconnect after falling back to archive recovery
Next
From: Amit Kapila
Date:
Subject: Re: Skipping schema changes in publication