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