core dumps generated in archive / restore commands etc

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

Browse pgsql-hackers by date

  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