On Fri, Sep 11, 2020 at 4:20 PM Tom Lane <t...@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
