Re: RFC: replace pg_stat_activity.waiting with something more descriptive
От | Robert Haas |
---|---|
Тема | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Дата | |
Msg-id | CA+TgmoYzfAgFeqcJaf1XvKS0YaZ_be4vFg03fWFasf4r+fAYhA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Список | pgsql-hackers |
On Tue, Jul 7, 2015 at 6:28 AM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > Please forgive me to resend this message for some too-sad > misspellings. > > # "Waiting for heavy weight locks" is somewhat confusing to spell.. > > === > Hello, > > At Tue, 7 Jul 2015 16:27:38 +0900, Fujii Masao <masao.fujii@gmail.com> wrote in <CAHGQGwEJwov8YwvmbbWps3Rba6kF1yf7qL3S==Oy4D=gq9YNsQ@mail.gmail.com> >> Each backend reports its event when trying to take a lock. But >> the reported event is never reset until next event is reported. >> Is this OK? This means that the wait_event column keeps showing >> the *last* event while a backend is in idle state, for example. >> So, shouldn't we reset the reported event or report another one >> when releasing the lock? > > It seems so but pg_stat_activity.waiting would indicate whether > the event is lasting. However, .waiting reflects only the status > of heavy-weight locks. It would be quite misleading. > > I think that pg_stat_activity.wait_event sould be linked to > .waiting then .wait_event should be restricted to heavy weight > locks if the meaning of .waiting cannot not be changed. Yeah, that's clearly no good. It only makes sense to have wait_event show the most recent event if waiting tells you whether the wait is still ongoing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: