Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
От | Alvaro Herrera |
---|---|
Тема | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
Дата | |
Msg-id | 202311171358.7becb6achg2e@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
|
Список | pgsql-hackers |
On 2023-Nov-17, Dilip Kumar wrote: > On Thu, Nov 16, 2023 at 3:11 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > > > I just noticed that 0003 does some changes to > > TransactionGroupUpdateXidStatus() that haven't been adequately > > explained AFAICS. How do you know that these changes are safe? > > IMHO this is safe as well as logical to do w.r.t. performance. It's > safe because whenever we are updating any page in a group we are > acquiring the respective bank lock in exclusive mode and in extreme > cases if there are pages from different banks then we do switch the > lock as well before updating the pages from different groups. Looking at the coverage for this code, https://coverage.postgresql.org/src/backend/access/transam/clog.c.gcov.html#413 it seems in our test suites we never hit the case where there is anything in the "nextidx" field for commit groups. To be honest, I don't understand this group stuff, and so I'm doubly hesitant to go without any testing here. Maybe it'd be possible to use Michael Paquier's injection points somehow? I think in the code comments where you use "w.r.t.", that acronym can be replaced with "for", which improves readability. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "All rings of power are equal, But some rings of power are more equal than others." (George Orwell's The Lord of the Rings)
В списке pgsql-hackers по дате отправления: