From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, 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 22:57:09 |
Message-ID: | 4788.1349305029@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Wed, Oct 03, 2012 at 01:57:47PM -0400, Bruce Momjian wrote:
>> On Wed, Oct 3, 2012 at 01:53:28PM -0400, Tom Lane wrote:
>>> 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.
> Well, not quite impossible. A simple solution would be to use
> pthread_atfork() to register a handler that puts the socket into an
> invalid state in either the parent or the child.
That doesn't make it "transparent" --- that merely ensures that we break
one of the two currently-working use cases (namely, that either the
parent or the child can continue to use the connection as long as the
other doesn't touch it).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ralf Rantzau | 2012-10-03 23:13:49 | Question on "box @> point" using GiST index on boxes |
Previous Message | Daniel Farina | 2012-10-03 22:40:37 | Re: Detecting libpq connections improperly shared via fork() |