On Thursday, October 04, 2012 12:16:14 AM Daniel Farina wrote:
> On Wed, Oct 3, 2012 at 3:14 PM, Andres Freund <andres@2ndquadrant.com>
wrote:
> > On Thursday, October 04, 2012 12:08:18 AM Daniel Farina wrote:
> >> It would be fantastic for libpq to somehow monitor use of a connection
> >> from multiple PIDs that share a parent and deliver an error indicating
> >> what is wrong. Unfortunately detecting that would require either a
> >> file or some kind of shared memory map, AFAIK, and I don't know how
> >> keen anyone is on accepting that patch. So, may I ask: how keen is
> >> anyone on accepting such a patch, and under what conditions of
> >> mechanism?
> >
> > 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.
Even that scenario isn't easy to get right... You need to get the socket from
libpq in the parent after the fork() and close it. Only after that you can
PQfinish it. Which you probably need to do before establishing other
connections.
The only scenario where I can dream up some use for doing something like that
isn't really convincing and revolves around setreuid() and peer
authentication. But you can do the setreuid after the fork just fine...
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
