Re: Fix bug in multixact Oldest*MXactId initialization and access - Mailing list pgsql-hackers

From Chao Li
Subject Re: Fix bug in multixact Oldest*MXactId initialization and access
Date
Msg-id C991344D-F38A-4EEC-903A-72B52FF887FA@gmail.com
Whole thread Raw
In response to Re: Fix bug in multixact Oldest*MXactId initialization and access  (Yura Sokolov <y.sokolov@postgrespro.ru>)
Responses Re: Fix bug in multixact Oldest*MXactId initialization and access
List pgsql-hackers

> On Feb 25, 2026, at 23:16, Yura Sokolov <y.sokolov@postgrespro.ru> wrote:
>
> Good day.
>
> Chao Li and Sami Imseih, thank you for looking at.
>
> After thinking a bit, I've decided to make sizes of arrays precise:
> - OldestMemberMXactId's size remains MaxBackends + max_prepared_xacts.
>  Instead of changing its size, procno is now adjusted to not include
> auxiliary procs.
> - OldestVisibleMXactId contains only MaxBackends elemenents now.
>  It is used only for real backends and not prepared transactions.
>
> All accesses are validated with asserts certainly.
>
> I believe, index transformation in access of OldestMemberMXactId will not
> cost much since all this operations are quite rare.
> In the loops arrays are accessed directly since limiting loop index is enough.
>
> --
> regards
> Yura Sokolov aka funny-falcon<v3-0001-Fix-multixacts-OldestMemberMXactId-and-OldestVisi.patch>

Actually, while I reviewing v1, I was thinking over the same way as v3, as the NUM_AUXILIARY_PROCS portions in
OldestMemberMXactIdand OldestVisibleMXactId arrays are not used at all. I didn’t raise the idea because that given
thesecode are in hot paths, I wasn't sure if the complexity was worth the shared memory optimization. It’s a classic
trade-off,and I’m curious to see which direction the senior committers prefer. 

However, I agree that the new helper function names in v3 are a significant improvement over v1.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/







pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: postgres_fdw: Use COPY to speed up batch inserts
Next
From: Amit Kapila
Date:
Subject: Re: Skipping schema changes in publication