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

Re: Detecting libpq connections improperly shared via fork()

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Detecting libpq connections improperly shared via fork()
Date: 2012-10-03 22:40:37
Message-ID: CAAZKuFbXW1hpagbZvTO7W6E5C=SdCFTqccz-+ALWcERkbbqzJg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Oct 3, 2012 at 3:34 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On Thursday, October 04, 2012 12:16:14 AM Daniel Farina wrote:
>> On Wed, Oct 3, 2012 at 3:14 PM, Andres Freund <andres(at)2ndquadrant(dot)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.

Well, as a general rule, people care a lot less about "that strange
error that happens when I'm done" as opposed to "that thing that
happens randomly while I'm mid-workload," so odds are very slim that
I'd see that defect reported -- I think chances are also poor that
that bug would go fixed in applications that have it, because the
impact would appear minor, so as per the natural of order of things
it'll be deprioritized indefinitely.  But I see your point: the number
of intentional abusers might be even smaller than I thought.

-- 
fdr


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-10-03 22:57:09
Subject: Re: do we EXEC_BACKEND on Mac OS X?
Previous:From: Andres FreundDate: 2012-10-03 22:34:36
Subject: Re: Detecting libpq connections improperly shared via fork()

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