Hi, On 2020-03-27 14:34:56 -0400, Tom Lane wrote: > Andres Freund <and...@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