On 2023-Nov-18, Dilip Kumar wrote: > On Fri, Nov 17, 2023 at 6:16 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote:
> > I wonder what's the deal with false sharing in the new > > bank_cur_lru_count array. Maybe instead of using LWLockPadded for > > bank_locks, we should have a new struct, with both the LWLock and the > > LRU counter; then pad *that* to the cacheline size. This way, both the > > lwlock and the counter come to the CPU running this code together. > > Actually, the array lengths of both LWLock and the LRU counter are > different so I don't think we can move them to a common structure. > The length of the *buffer_locks array is equal to the number of slots, > the length of the *bank_locks array is Min (number_of_banks, 128), and > the length of the *bank_cur_lru_count array is number_of_banks. Oh. > > 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? > > Sorry, but I am not aware of "Michael Paquier's injection" Is it > something already in the repo? Can you redirect me to some of the > example test cases if we already have them? Then I will try it out. https://postgr.es/zvwufo_ykztjh...@paquier.xyz -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Sallah, I said NO camels! That's FIVE camels; can't you count?" (Indiana Jones)