Re: RFC: replace pg_stat_activity.waiting with something more descriptive

On Tue, Jul 7, 2015 at 6:28 AM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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(dot)fujii(at)gmail(dot)com> wrote in <CAHGQGwEJwov8YwvmbbWps3Rba6kF1yf7qL3S==Oy4D=gq9YNsQ(at)mail(dot)gmail(dot)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