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

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

The following reply was made to PR lib/56979; it has been noted by GNATS.

From: Tom Lane <tgl%sss.pgh.pa.us@localhost>
To: gnats-bugs%netbsd.org@localhost, David Holland <dholland-bugs%netbsd.org@localhost>
Cc: lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/56979: fork(2) fails to be signal safe
Date: Mon, 29 Aug 2022 14:41:35 -0400

 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 resol=
 ution
 >>>> of that PLT entry, or even all of the program's PLT entries, before w=
 e
 >>>> enable signals.  If there are multiple select(2) calls in the same so=
 urce
 >>>> file, will they share a PLT entry?  If so, I could arrange to run a d=
 ummy
 >>>> 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