Re: [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Here is a set of patches to address this issue.
> The first one is a small refactoring of the signal setting portability
> business.

OK

> The second one fixes the SIGQUIT handler inadvertently unblocking
> SIGQUIT within itself.

OK

> The third one installs an alarm so that if the ereport() call in
> quickdie() doesn't finish after 60 seconds, it skips it and finishes up.
> The precise logic of this could be debated, but it more or less appears
> to get the job done.

I'm not too happy with depending on alarm(), which according to the
pgbench sources is not portable to Windows. The postmaster does
something equivalent using enable_sig_alarm(); can we use that?

A different line of thought is that this still doesn't fix the problem
because you're depending on a fair amount of libc infrastructure that
might not be too reentrant (and the same objection could probably be
mounted against enable_sig_alarm). It would be better for the
postmaster to be in charge of enforcing the timeout, and have it issue
SIGKILL against children that don't die fast enough to suit it.

regards, tom lane