Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Sep 3, 2020 at 5:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Concretely, something about like this (I just did the bgwriter, but
>> we'd want the same in all the background processes). I tried to
>> respond to Robert's complaint about the inaccurate comment just above
>> sigsetjmp, too.
>> This passes check-world, for what little that's worth.
> Seems totally reasonable from here.
OK, I did the same in other relevant places and pushed it.
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?
regards, tom lane
