Re: Detecting libpq connections improperly shared via fork()

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

Daniel Farina <daniel(at)heroku(dot)com> writes:
> On Wed, Oct 3, 2012 at 3:14 PM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-10-04 01:35:50 Re: Detecting libpq connections improperly shared via fork()
Previous Message Michael Paquier 2012-10-04 01:19:02 Re: Support for REINDEX CONCURRENTLY