Hi,
On Mon, 22 Mar 1999, M Simms wrote:
|o| > My process establishes a connection with a PostgreSQL backen and then
|o| > fork()s (twice, actually). To make things even more complicated (though I
|o| > don't know if it affects things), my connection handle is a global
|o| > variable in a dynamically-loaded shared object.
|o| >
|o| > I tried PQreset()ing the connections after forking and then I'd try a
|o| > begin but I'd get the ff.:
|o| If you fork, you will have two processes pumping data down the
|o| same connection to the database, cos the fork() will simply
|o| duplicate the file descriptor reference, not make you a new
|o| connection. If two forked() processes try and send data or
|o| retrieve data at the same time, everything will break, as the
|o| database obviously will not know what the hell is going on and
|o| will get a mangled transmission
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. ;^)
L L Richi Plana 8^) ,-,-. ,-,-. ,-,-. ,-,-. ,-
LL LL Systems Administrator / / \ \ / / \ \ / / \ \ / / \ \ / /
LLLLL Mosaic Communications, Inc. \ \ / / \ \ / / \ \ / / \ \ / /
LLLLL mailto:richip@mozcom.com `-'-' `-'-' `-'-' `-'-'
------------------------------------------------------------------------
P G P Key available at http://www2.mozcom.com/~richip/richip.asc
Tired of Spam? Join this CAUCE! http://www.cauce.org/