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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Vladimir Borodin <root(at)simply(dot)name>, Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date: 2016-03-11 12:32:48
Message-ID: CA+TgmoY-8MzHp4uHe9uLVZNbcAaZmT0gtxonKAVev9WXgBxMAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 11, 2016 at 1:19 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Fri, Mar 11, 2016 at 12:28 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Committed with some further editing. In particular, the way you
>> determined whether we could safely access the tranche information for
>> any given ID was wrong; please check over what I did and make sure
>> that isn't also wrong.
>>
> There are few typos which I have tried to fix with the attached patch. Can
> you tell me what was wrong with the way it was done in patch?

LWLocks can be taken during transaction abort and you might have to
wait, so keeping the wait state around from before you started to
abort the transaction doesn't make any sense. You aren't waiting at
that point, and if you get stuck in some part of the code that isn't
instrumented to expose wait instrumentation, you certainly don't want
pg_stat_activity to still reflect the way things were when you
previously waiting on something else. It's essential that we clear
the wait state as early as possible - right after LWLockReleaseAll -
because at that point we are no longer waiting. Then you no longer
need to do it later on.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2016-03-11 12:33:16 Re: The plan for FDW-based sharding
Previous Message Kevin Grittner 2016-03-11 12:25:57 Re: WIP: Detecting SSI conflicts before reporting constraint violations