Re: Detecting libpq connections improperly shared via fork() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Detecting libpq connections improperly shared via fork()
Date
Msg-id 12193.1349314550@sss.pgh.pa.us
Whole thread Raw
In response to Re: Detecting libpq connections improperly shared via fork()  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On Thursday, October 04, 2012 12:16:14 AM Daniel Farina wrote:
>> I suppose this might needlessly eliminate someone who forks and hands
>> off the PGconn struct to exactly one child, but it's hard to argue
>> with its simplicity and portability of mechanism.

> Even that scenario isn't easy to get right... You need to get the socket from
> libpq in the parent after the fork() and close it. Only after that you can 
> PQfinish it. Which you probably need to do before establishing other 
> connections.

No, it's much easier than that: the parent can simply forget that it has
a PGconn.  It will leak the memory occupied by the PGconn object, and it
will leak an open socket (which will only be half-open after the child
does PQfinish).  This would be noticeable if the parent is long-lived
and creates many such connections over its lifespan, but otherwise
people could be doing it just fine.  In fact, I had to look closely to
convince myself that pgbench didn't do it already.

I suspect that if we provide a mechanism like this, we'll have to
provide a way to turn it off, or somebody is going to complain that
we broke their code.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Detecting libpq connections improperly shared via fork()
Next
From: Merlin Moncure
Date:
Subject: Re: FDW for PostgreSQL