On Fri, Sep 11, 2020 at 4:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It's not clear to me whether we want to institute the "accepting SIGQUIT
> is always okay" rule in processes that didn't already have code to change
> BlockSig. The relevant processes are pgarch.c, startup.c, bgworker.c,
> autovacuum.c (launcher and workers both), and walsender.c. In the first
> two of these I doubt it matters, because I don't think they'll ever block
> signals again anyway -- they certainly don't have outer sigsetjmp blocks.
> And I'm a bit hesitant to mess with bgworker given that we seem to expect
> that to be heavily used by extension code, and we're exposing code to
> allow extensions to mess with the signal blocking state. On the other
> hand, as long as SIGQUIT is pointing at SignalHandlerForCrashExit, it's
> hard to see a reason why holding it off could be necessary. So maybe
> having a uniform rule would be good.
>
> Any thoughts about that?
I think a backend process that isn't timely handling SIGQUIT is by
that very fact buggy. "pg_ctl stop -mi" isn't a friendly suggestion.
So I favor trying to make it uniform.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
