Re: [GENERAL] fork() bad

Поиск
Список
Период
Сортировка
От Gerard Saraber
Тема Re: [GENERAL] fork() bad
Дата
Msg-id 36F685F7.CEF52B06@glasscity.net
обсуждение исходный текст
Ответ на Re: [GENERAL] fork() bad  (Richi Plana <richip@mozcom.com>)
Список pgsql-general
Hello,

Richi Plana wrote:
>
> Hi,
>
[ previous discussion snipped ]

>
> Looks like the general consensus is fork()ing is a bad thing where
> PostgreSQL is concerned. So what I did was refrained from opening a
> connection to the backend until AFTER the process fork()ed.
>
> As some of you may know, I'm hacking Ascend RADIUS 2.01 to look up a
> PostgreSQL database for authentication and log to PG for accounting.
> Normally, RADIUS fork()s once for Accounting and fork()s for each
> Authentication request. That's a lot of fork()ing and establishing
> connections to the backend. It's slow, but it's better than junking
> whatever code I've written so far.
>
> If anyone can give a better suggestion, I'm all ears. Also, if anyone
> wants the code when it's done, try asking. ;^)
>

Would it be possible to create a "connection pool" sort of have an array
of connections go pgsql, and mark one of them as "in use" right before
you fork?
You may have to stick the "in use" marks in shared memory, so that after
the fork-ed process is done with the pgsql connection it marks it as
"free" again, so it can be re-used for a next process.
I hope I'm making some sense :)

Regards,
Gerard Saraber
gsaraber@glasscity.net

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

Предыдущее
От: Herouth Maoz
Дата:
Сообщение: Re: [GENERAL] fork() bad
Следующее
От: Richi Plana
Дата:
Сообщение: Re: [GENERAL] fork() bad