On Fri, Jul 15, 2022 at 1:02 AM Thomas Munro <thomas.mu...@gmail.com> wrote:
> On Fri, Jul 15, 2022 at 12:15 AM Thomas Munro <thomas.mu...@gmail.com> wrote:
> > Yeah. Done, and pushed. 0002 not back-patched.
>
> Hmm, there were a couple of hard to understand build farm failures.
> My first thought is that the signal mask stuff should only be done if
> IsUnderPostmaster, otherwise it clobbers the postmaster's signal mask
> when reached from dsm_postmaster_startup(). Looking into that.
I pushed that change, and I hope that clears up the problems seen on
eg curculio. It does raise the more general question of why it's safe
to assume the signal mask is UnBlockSig on entry in regular backends.
I expect it to be in released branches, but things get more
complicated as we use DSM in more ways and it's not ideal to bet on
that staying true. I checked that this throw-away assertion doesn't
fail currently:
if (IsUnderPostmaster)
+ {
+ sigset_t old;
+ sigprocmask(SIG_SETMASK, NULL, &old);
+ Assert(memcmp(&old, &UnBlockSig, sizeof(UnBlockSig)) == 0);
PG_SETMASK(&BlockSig);
+ }
... but now I'm wondering if we should be more defensive and possibly
even save/restore the mask. Originally I discounted that because I
thought I had to go through PG_SETMASK for portability reasons, but on
closer inspection, I don't see any reason not to use sigprocmask
directly in Unix-only code.
