Re: Detecting libpq connections improperly shared via fork()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Daniel Farina <daniel(at)heroku(dot)com>
Subject: Re: Detecting libpq connections improperly shared via fork()
Date: 2012-10-04 01:35:50
Message-ID: 12193.1349314550@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2012-10-04 01:44:00 Re: FDW for PostgreSQL
Previous Message Tom Lane 2012-10-04 01:23:54 Re: Detecting libpq connections improperly shared via fork()