Re: We shouldn't signal process groups with SIGQUIT

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: We shouldn't signal process groups with SIGQUIT
Дата
Msg-id Y/2G9en1O2jw3Usf@paquier.xyz
обсуждение исходный текст
Ответ на Re: We shouldn't signal process groups with SIGQUIT  (Andres Freund <andres@anarazel.de>)
Ответы Re: We shouldn't signal process groups with SIGQUIT  (Thomas Munro <thomas.munro@gmail.com>)
Re: We shouldn't signal process groups with SIGQUIT  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Tue, Feb 14, 2023 at 12:47:12PM -0800, Andres Freund wrote:
> Just naively hacking this behaviour change into the current code, would yield
> sending SIGQUIT to postgres, and then SIGTERM to the whole process
> group. Which seems like a reasonable order?  quickdie() should _exit()
> immediately in the signal handler, so we shouldn't get to processing the
> SIGTERM.  Even if both signals are "reacted to" at the same time, possibly
> with SIGTERM being processed first, the SIGQUIT handler should be executed
> long before the next CFI().

I have been poking a bit at that, and did a change as simple as this
one in signal_child():
 #ifdef HAVE_SETSID
+   if (signal == SIGQUIT)
+       signal = SIGTERM;

From what I can see, SIGTERM is actually received by the backends
before SIGQUIT, and I can also see that the backends have enough room
to process CFIs in some cases, especially short queries, even before
reaching quickdie() and its exit().  So the window between SIGTERM and
SIGQUIT is not as long as one would think.
--
Michael

Вложения

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

Предыдущее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: Support logical replication of DDLs
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: pg_upgrade and logical replication