Re: SIGQUIT on archiver child processes maybe not such a hot idea? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SIGQUIT on archiver child processes maybe not such a hot idea?
Date
Msg-id 13844.1568145692@sss.pgh.pa.us
Whole thread Raw
In response to Re: SIGQUIT on archiver child processes maybe not such a hot idea?  (Stephen Frost <sfrost@snowman.net>)
Responses RE: SIGQUIT on archiver child processes maybe not such a hot idea?
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * David Steele (david@pgmasters.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Move user options to the end of the command in pg_upgrade
Next
From: Alvaro Herrera from 2ndQuadrant
Date:
Subject: Re: Duplicated LSN in ReorderBuffer