From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | core dumps generated in archive / restore commands etc |
Date: | 2022-12-06 21:58:06 |
Message-ID: | 20221206215806.ka2sq3x7ukipgryy@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Occasionally I see core dumps for sh, cp etc when running the tests. I think
this is mainly due to immediate shutdowns / crashes signalling the entire
process group with SIGQUIT. If a sh/cp/... is running as part of an
archive/restore command when the signal arrives, we'll trigger a coredump,
because those tools won't have a SIGQUIT handler.
ISTM that postmaster's signal_child() shouldn't send SIGQUIT to the process
group in the #ifdef HAVE_SETSID section. We've already signalled the backend
with SIGQUIT, so we could change the signal we send to the whole process group
to one that doesn't trigger core dumps by default. SIGTERM seems like it would
be the right choice.
The one non-trivial aspect of this is that that signal will also be delivered
to the group leader. It's possible that that could lead to some minor test
behaviour issues, because the output could change if e.g. SIGTERM is received
/ processed first.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Borisov | 2022-12-06 22:26:55 | Re: Allow placeholders in ALTER ROLE w/o superuser |
Previous Message | Peter Geoghegan | 2022-12-06 21:45:09 | Re: New strategies for freezing, advancing relfrozenxid early |