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 11996.1349313834@sss.pgh.pa.us
Whole thread Raw
In response to Re: Detecting libpq connections improperly shared via fork()  (Daniel Farina <daniel@heroku.com>)
Responses Re: Detecting libpq connections improperly shared via fork()  (Andrew Dunstan <andrew@dunslane.net>)
Re: Detecting libpq connections improperly shared via fork()  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Daniel Farina <daniel@heroku.com> writes:
> On Wed, Oct 3, 2012 at 3:14 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> Hm. An easier version of this could just be storing the pid of the process
>> that did the PQconnectdb* in the PGconn struct. You can then check that
>> PGconn->pid == getpid() at relatively few places and error out on a mismatch.
>> That should be doable with only minor overhead.

> 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.

Yeah, the same thing had occurred to me, but I'm not sure that getpid()
is really cheap enough to claim that the overhead is negligible.

A bigger problem with this is that it only fixes the issue for cases in
which somebody makes new threads of control with fork().  I believe that
issues involving multiple threads trying to use the same PGconn are at
least as widespread.  I'm not terribly excited about removing
functionality and adding overhead to protect against just one variant of
the problem.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Support for REINDEX CONCURRENTLY
Next
From: Tom Lane
Date:
Subject: Re: Detecting libpq connections improperly shared via fork()