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
