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+TgmoY-8MzHp4uHe9uLVZNbcAaZmT0gtxonKAVev9WXgBxMAQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Fri, Mar 11, 2016 at 1:19 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Fri, Mar 11, 2016 at 12:28 AM, Robert Haas <robertmhaas@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: WIP: Detecting SSI conflicts before reporting constraint violations
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: The plan for FDW-based sharding