Re: Detecting libpq connections improperly shared via fork()

On Thursday, October 04, 2012 03:23:54 AM Tom Lane wrote:
> 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.
I guess its going to be os/libc dependant. In glibc systems getpid() should be
basically just be a function call (no syscall).

> 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.
True. But people seem to be more wary of problems in the case of threads... We
could play similar things with pthread_self() or gettid() but I am not sure how
portable even the former is...

Greetings,

Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services