Hi,
On 2020-03-27 14:34:56 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I've locally fixed the issue by computing the stack base address anew
> > for postmaster children. Currently in InitPostmasterChild().
>
> > I'd like to get that change upstream. The rr hackers have fixed a number
> > of other issues that could be hit with postgres, but they couldn't see a
> > good way to address the potential for a different signal stack in this
> > edge case. And it doesn't seem crazy to me to compute the stack base
> > again in postmaster children: It's cheap enough and it's extremely
> > unlikely that postmaster uses up a crazy amount of stack.
>
> Seems reasonable. I think we'd probably also need this in the
> EXEC_BACKEND case, in case ASLR puts the child process's stack
> somewhere else. Can you merge your concern with that one?
We currently already do that there, in SubPostmasterMain(). If we add a
set_stack_base() to InitPostmasterChild() we can remove it from there,
though.
> On the other hand, it might be better to not launch children from the
> signal handler, because I don't think we should assume the alternate
> stack can grow as large as the main one. Does POSIX talk about this?
I strongly agree that it'd be better - independent of what we conclude
re a localized fix for rr. I think I looked for what specs around this a
while ago and couldn't find much. fork() is listed as signal safe (but
there was discussion about removing it - going nowhere I think).
> > Tom, while imo not a fix of the right magnitude here: Are you planning /
> > hoping to work again on your postmaster latch patch?
>
> Um ... -ESWAPPEDOUT. What are you thinking of?
https://postgr.es/m/18193.1492793404%40sss.pgh.pa.us
That doesn't convert all that much of postmaster to latches, but once
the basic infrastructure is in place, it doesn't seem too hard to
convert more. In particular sigusr1_handler, which is the relevant one
here, looks fairly easy. SIGHUP_handler(), reaper() shouldn't be hard
either. Whether it could make sense to convert pmdie for SIGQUIT is less
clear to me, but also seems less clearly necessary: We don't fork, and
shutting down anyway.
Greetings,
Andres Freund