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 по дате отправления: