Re: Expose lock group leader pid in pg_stat_activity

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Expose lock group leader pid in pg_stat_activity
Дата
Msg-id CAOBaU_YpsBA2puV8NtjV_Oit2jbt=wnNSA_2E41kGUi_BhA8rA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Expose lock group leader pid in pg_stat_activity  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: Expose lock group leader pid in pg_stat_activity
Список pgsql-hackers
On Tue, Jan 28, 2020 at 2:09 PM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
>
> I agree a separate "leader_id" column is easier to work with, as it does
> not require unnesting and so on.
>
> As for the consistency, I agree we probably can't make this perfect, as
> we're fetching and processing the PGPROC records one by one. Fixing that
> would require acquiring a much stronger lock on PGPROC, and perhaps some
> other locks. That's pre-existing behavior, of course, it's just not very
> obvious as we don't have any dependencies between the rows, I think.
> Adding the leader_id will change, that, of course. But I think it's
> still mostly OK, even with the possible inconsistency.

There were already some dependencies between the rows since parallel
queries were added, as you could see eg. a parallel worker while no
query is currently active.  This patch will make those corner cases
more obvious.  Should I document the possible inconsistencies?



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Expose lock group leader pid in pg_stat_activity
Следующее
От: Justin Pryzby
Дата:
Сообщение: tableam options for pg_dump/ALTER/LIKE