Skip site navigation (1) Skip section navigation (2)

Re: do we EXEC_BACKEND on Mac OS X?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>,Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: do we EXEC_BACKEND on Mac OS X?
Date: 2012-10-03 17:57:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Oct  3, 2012 at 01:53:28PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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  <bruce(at)momjian(dot)us>

  + It's impossible for everything to be true. +

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2012-10-03 18:04:04
Subject: Re: Hash id in pg_stat_statements
Previous:From: Tom LaneDate: 2012-10-03 17:56:01

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group