Skip site navigation (1) Skip section navigation (2)

Re: Detecting libpq connections improperly shared via fork()

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Daniel Farina <daniel(at)heroku(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Detecting libpq connections improperly shared via fork()
Date: 2012-10-09 09:51:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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> 
> >> 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...


 Andres Freund	         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Daniel FarinaDate: 2012-10-09 10:05:34
Subject: Re: Detecting libpq connections improperly shared via fork()
Previous:From: Vik ReykjaDate: 2012-10-09 09:51:15
Subject: Re: Truncate if exists

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group