Andres Freund <andres@anarazel.de> writes:
> On 2018-05-08 18:04:07 -0400, Tom Lane wrote:
>> Yeah. Though now that we have the postmaster mechanism to wait-five-
>> seconds-then-SIGKILL, maybe we could rethink that requirement? If we
>> reimplemented SIGQUIT to work more like SIGTERM, it would surely be
>> a lot safer. There would be cases where a stuck backend wouldn't
>> respond and it'd eventually get SIGKILL'd, but in return we'd get rid
>> of problems like this one.
> Right now we intentionally do not accept interrupts in a couple places
> where we want to die quickly because we're making persistent changes. I
> don't think it'd be good to continue e.g. committing any longer than
> possible after one process segfaulted.
Well, that's an implementation question. I was sort of envisioning that
we could allow CHECK_FOR_INTERRUPTS to respond to a SIGQUIT interrupt
even when regular interrupts are disabled, reasoning that if we're at
a CHECK_FOR_INTERRUPTS at all, then we should be someplace where it's
more or less safe to trigger the exit. If we had it like that, then
for example the commit sequence could put a CHECK_FOR_INTERRUPTS at
the last possible moment before committing, knowing that regular
interrupts are held off --- but if there's a SIGQUIT pending we'd
take it.
regards, tom lane
