On Tue, Jul 7, 2015 at 6:28 AM, Kyotaro HORIGUCHI <horiguchi.kyot...@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.fu...@gmail.com> wrote > in <CAHGQGwEJwov8YwvmbbWps3Rba6kF1yf7qL3S==Oy4D=gq9y...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
