Re: Cleaning up historical portability baggage

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Cleaning up historical portability baggage
Дата
Msg-id 146576.1659825723@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Cleaning up historical portability baggage  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Cleaning up historical portability baggage  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> Did I understand correctly that the places that do kill(-pid) followed
> by kill(pid) really only need the kill(-pid)?

Uh ... did you read the comment right above signal_child?

 * There is a race condition for recently-forked children: they might not
 * have executed setsid() yet.  So we signal the child directly as well as
 * the group.  We assume such a child will handle the signal before trying
 * to spawn any grandchild processes.  We also assume that signaling the
 * child twice will not cause any problems.

It might be that this is wrong and signaling -pid will work even if
the child hasn't yet done setsid(), but I doubt it: the kill(2) man
page is pretty clear that it'll fail if "the process group doesn't
exist".

Perhaps we could finesse that by signaling -pid first, and then
signaling pid if that fails, but offhand it seems like that has
the described race condition w.r.t. grandchild processes.

            regards, tom lane



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Making autovacuum logs indicate if insert-based threshold was the triggering condition
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Making autovacuum logs indicate if insert-based threshold was the triggering condition