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

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

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

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Tom Lane <tgl%sss.pgh.pa.us@localhost>
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: kern/56979: fork(2) fails to be signal safe
Date: Fri, 26 Aug 2022 08:38:10 +0000

 > Date: Thu, 25 Aug 2022 22:37:03 -0400
 > From: Tom Lane <tgl%sss.pgh.pa.us@localhost>
 > 
 > I've built the system with that patch added, and will start using it
 > tomorrow.  I do not have a reliable reproducer, and on reflection it's
 > hard to see how to make one -- unless you know of an operation that
 > would hold the rtld lock for a decently long period of time.  However,
 > I'm finding that my macppc Postgres buildfarm instance [1] is hitting
 > this in perhaps one out of five or ten runs, so if it can survive for
 > a week or two then I'll feel pretty confident that this patch fixes
 > it for me.
 
 Cool, thanks!
 
 > FWIW, the second patch certainly looks like it will alleviate the
 > symptom I'm seeing.  I suppose it would not fix cases where the
 > signal interrupts an operation holding the rtld lock exclusively;
 > but I do not think that will be a problem for my use-case.
 
 The rtld exclusive lock blocks signals (except for SIGTRAP, which
 might be a bug...).
 
 > I have no opinion about the first patch -- Postgres doesn't use
 > pthread_atfork.
 
 Perhaps not, but if you did, and if a signal interrupted
 pthread_atfork triggering a signal handler that calls fork, then
 fork's attempts to invoke the atfork handlers might see the data
 structures in the middle of an update.