Re: Detecting libpq connections improperly shared via fork()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Detecting libpq connections improperly shared via fork()
Дата
Msg-id 11996.1349313834@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Detecting libpq connections improperly shared via fork()  (Daniel Farina <daniel@heroku.com>)
Ответы Re: Detecting libpq connections improperly shared via fork()
Re: Detecting libpq connections improperly shared via fork()
Список pgsql-hackers
Daniel Farina <daniel@heroku.com> writes:
> On Wed, Oct 3, 2012 at 3:14 PM, Andres Freund <andres@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.

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.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Support for REINDEX CONCURRENTLY
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Detecting libpq connections improperly shared via fork()