Re: Expose lock group leader pid in pg_stat_activity

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Expose lock group leader pid in pg_stat_activity
Дата
Msg-id 20200118025102.GB230692@paquier.xyz
обсуждение исходный текст
Ответ на Re: Expose lock group leader pid in pg_stat_activity  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: Expose lock group leader pid in pg_stat_activity
Список pgsql-hackers
On Fri, Jan 17, 2020 at 05:07:55PM +0100, Julien Rouhaud wrote:
> Oh indeed.  But unless we hold some LWLock during the whole function
> execution, we cannot guarantee a consistent view right?

Yep.  That's possible.

> And isn't it already possible to e.g. see a parallel worker in
> pg_stat_activity while all other queries are shown are idle, if
> you're unlucky enough?

Yep.  That's possible.

> Also, LockHashPartitionLockByProc requires the leader PGPROC, and
> there's no guarantee that we'll see the leader before any of the
> workers, so I'm unsure how to implement what you said.  Wouldn't it be
> better to simply fetch the leader PGPROC after acquiring a shared
> ProcArrayLock, and using that copy to display the pid, after checking
> that we retrieved a non-null PGPROC?

Another idea would be to check if the current PGPROC entry is a leader
and print in an int[] the list of PIDs of all the workers while
holding a shared LWLock to avoid anything to be unregistered.  Less
handy, but a bit more consistent.  One problem with doing that is
that you may have in your list of PIDs some worker processes that are
already gone when going through all the other backend entries.  An
advantage is that an empty array could mean "I am the leader, but
nothing has been registered yet to my group lock." (note that the
leader adds itself to lockGroupMembers).
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg13 PGDLLIMPORT list
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Improve errors when setting incorrect bounds for SSL protocols