Re: Expose lock group leader pid in pg_stat_activity
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: Expose lock group leader pid in pg_stat_activity |
| Дата | |
| Msg-id | 20200316060231.GD2331@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Expose lock group leader pid in pg_stat_activity (Justin Pryzby <pryzby@telsasoft.com>) |
| Список | pgsql-hackers |
On Mon, Mar 16, 2020 at 12:43:41AM -0500, Justin Pryzby wrote: > I think I see. Julien's v3 patch did this: > https://www.postgresql.org/message-id/attachment/106429/pgsa_leader_pid-v3.diff > + if (proc->lockGroupLeader) > + values[29] = Int32GetDatum(proc->lockGroupLeader->pid); > > ..which is racy because a proc with a leader might die and be replaced by > another proc without a leader between 1 and 2. > > But the code since v4 does: > > + leader = proc->lockGroupLeader; > + if (leader) > + values[29] = Int32GetDatum(leader->pid); > > ..which is safe because PROCs are allocated in shared memory, so leader is for > sure a non-NULL pointer to a PROC. leader->pid may be read inconsistently, > which is what the comment says: "no extra lock is being held". Yes, you have the correct answer here. As shaped, the code relies on the state of a PGPROC entry in shared memory. -- Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера