Re: kern/56979: fork(2) fails to be signal safe

[Tom Lane <tgl%sss.pgh.pa.us@localhost>]

David Holland <dholland-bugs%netbsd.org@localhost> writes:
>  On Sun, Aug 28, 2022 at 05:05:01PM +0000, Tom Lane wrote:
>>>> What I'm wondering about now is whether there is a way to force resolution
>>>> of that PLT entry, or even all of the program's PLT entries, before we
>>>> enable signals.  If there are multiple select(2) calls in the same source
>>>> file, will they share a PLT entry?  If so, I could arrange to run a dummy
>>>> select() call somewhere early in startup.
 
>  There's LD_BIND_NOW, but I'm not sure if there's a good way to request
>  that behavior from inside a program :-(

Local testing seems to confirm the idea that issuing a dummy select()
before unblocking signals eliminates the issue for Postgres.  I can't
be totally sure given the narrowness of the failure window, but my
test ran without failure for considerably longer than it had managed
before.  So I'm thinking of going with that solution.

I now suspect that the reason we'd not seen this before could be
(aside from the timing improbability) that there was previously
another select() call somewhere in postmaster startup, and that
that one went away in seemingly-unrelated refactoring.  This'd be
substantially more plausible if the PLT entry for select() is
shared across the whole main executable and not just one .c file
--- could anyone confirm for me which way it works?

			regards, tom lane