Re: SIGQUIT on archiver child processes maybe not such a hot idea?

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * David Steele (david(at)pgmasters(dot)net) wrote:
>> On 9/3/19 12:04 PM, Tom Lane wrote:
>>> * 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.

>> I prefer SIGTERM, but FWIW pgBackRest handles them both the same way.

> Yeah, I wondered about that too, perhaps SIGTERM is better. I'm not
> really particular either way.

Yeah, after thinking about it, SIGTERM is probably what to use.
It's less likely that some random program would think it should
maybe not terminate in response. Catching SIGINT is pretty common
among "interactive" programs, and while there doesn't seem an
obvious reason to be using something like that below a PG process,
you never know.

I looked around for potential problems arising from my other
point about our own processes seeing SIGQUIT then SIGTERM.
For the most part this shouldn't be an issue because the
SIGQUIT handlers will just do _exit(2) anyway. However,
pgarch.c is a bit out of step. For one thing, its SIGTERM
handler has a comment saying the postmaster will never send
SIGTERM, which needs to be adjusted. For another, its
SIGQUIT handler does exit(1) not _exit(2), which seems rather
dubious ... should we make it more like the rest? I think
the reasoning there might've been that if some DBA decides to
SIGQUIT the archiver, we don't need to force a database-wide
reset; but why exactly should we tolerate that?

regards, tom lane