On Wed, Oct 3, 2012 at 01:53:28PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > Yes, but those framework libraries are typically supposed to prevent > > such problems from being seen by applications calling them. > > How exactly would a library prevent such problems? In particular, > let's see a proposal for how libpq might make it look like a fork > was transparent for an open connection.
I guess that is impossible. > > This is > > certainly sloppy practice on Apple's part, and it leave us wondering if > > we are using anything that might be a problem. The bottom line is that > > we don't know. > > > Libraries are supposed to document these limitations, as we do with > > libpq. I wonder if they just documented fork() and now don't feel they > > need to document these limitations per-library. > > Do we know that they *didn't* document such issues per-library? > Mentioning the risk under fork() too doesn't seem unreasonable. > > Not trying to sound like an Apple apologist, but I see a whole lot of > bashing going on here on the basis of darn little evidence. Well, ideally if Apple is going to brand a Unix function as unsafe, it would be good to mention which libraries are unsafe. I have no idea if they are documenting the problems in the libraries themselves. I guess my point is that the fork() warning was too vague. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
