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?
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?
> 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?
regards, tom lane
