On Thursday, October 04, 2012 03:23:54 AM Tom Lane wrote: > Daniel Farina <dan...@heroku.com> writes: > > On Wed, Oct 3, 2012 at 3:14 PM, Andres Freund <and...@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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers