Re: SIGQUIT on archiver child processes maybe not such a hot idea?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SIGQUIT on archiver child processes maybe not such a hot idea?
Дата
Msg-id 23037.1567526660@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SIGQUIT on archiver child processes maybe not such a hot idea?  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: SIGQUIT on archiver child processes maybe not such a hot idea?  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> But now we know that sending it to grand-children is wrong in a
> sense that that leads to left-alone unwanted core files. But the
> behavior is already knwon at the time.

> So, Now I know that we need to revert that in certain extent if
> we want to stop the core-dumping behavior...

Yeah.  After thinking about this more, I'm inclined to propose that
we just change what the postmaster does, as per attached patch.

A couple of questions arise:

* Would it be better to substitute SIGTERM instead of SIGINT?
The POSIX default handling is the same for both, but some programs
might interpret them differently.

* With this patch, our own processes would see SIGQUIT then
SIGINT (or SIGTERM).  Would any of them misbehave?  I think not
(and this patch does pass check-world) but it might be a good
idea to double-check.

            regards, tom lane

diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index 62dc93d..e4736a1 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -3956,6 +3956,10 @@ PostmasterStateMachine(void)
  * archive_recovery script, or SIGINT a script being run by a backend via
  * system().
  *
+ * SIGQUIT is a special case, in that the POSIX-spec default handling for
+ * it includes dumping core, which we don't really want for non-Postgres
+ * processes.  Hence, we send SIGINT not SIGQUIT to the process group.
+ *
  * 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
@@ -3972,12 +3976,15 @@ signal_child(pid_t pid, int signal)
     {
         case SIGINT:
         case SIGTERM:
-        case SIGQUIT:
         case SIGSTOP:
         case SIGKILL:
             if (kill(-pid, signal) < 0)
                 elog(DEBUG3, "kill(%ld,%d) failed: %m", (long) (-pid), signal);
             break;
+        case SIGQUIT:
+            if (kill(-pid, SIGINT) < 0)
+                elog(DEBUG3, "kill(%ld,%d) failed: %m", (long) (-pid), SIGINT);
+            break;
         default:
             break;
     }

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: standby recovery fails (tablespace related) (tentative patch anddiscussion)
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Rearranging ALTER TABLE to avoid multi-operations bugs