Kyotaro Horiguchi <horikyota....@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;
}
