Re: Fix bug in multixact Oldest*MXactId initialization and access
| От | Chao Li |
|---|---|
| Тема | Re: Fix bug in multixact Oldest*MXactId initialization and access |
| Дата | |
| Msg-id | C991344D-F38A-4EEC-903A-72B52FF887FA@gmail.com обсуждение исходный текст |
| Ответ на | Re: Fix bug in multixact Oldest*MXactId initialization and access (Yura Sokolov <y.sokolov@postgrespro.ru>) |
| Ответы |
Re: Fix bug in multixact Oldest*MXactId initialization and access
|
| Список | 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 по дате отправления: