Re: Improve LWLock tranche name visibility across backends
От | Sami Imseih |
---|---|
Тема | Re: Improve LWLock tranche name visibility across backends |
Дата | |
Msg-id | CAA5RZ0smYcqdQU1bGmtccTVOkhLT8EE-wJyXLXZZZWE=S29Akg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improve LWLock tranche name visibility across backends (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
Список | pgsql-hackers |
Thanks for testing! > which is what we expect. > > But if I look at LWLockTrancheNames.local (for the process that queried pg_stat_activity): > > (gdb) p LWLockTrancheNames.local[0] > $1 = 0x0 > (gdb) p LWLockTrancheNames.local[1] > $2 = 0x7b759a81b038 "BDT_Lck" > > It looks like there is an indexing issue, as we should start at index 0. > > Issue 2 / question -- > > If I call LWLockNewTrancheId("BDT_play2") multiple times to ensure that > > > Then if, in another backend, I call GetLWTrancheName by querying pg_stat_activity > then I see "BDT_Lck" being reported as wait event name (which is good). > > The thing that worries me a bit is that the local cache is populated only for > "BDT_Lck", but not for all the other "BDT_play2". Issue #1 and issue #2 are related. In both cases you have a registered wait event that only lives in shared memory, but was never required to be accessed by pg_stat_activity, so it was never cached locally. > When we need to populate the local cache, would it be better to populate > it with the whole dsa content instead of just the current missing ID as done > in GetLWTrancheName(): I do agree that we should just sync the local cache totally whenever we can't find the tranche name in the local cache. Will fix in the next rev. -- Sami
В списке pgsql-hackers по дате отправления: