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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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