From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Using connection after fork |
Date: | 2004-08-10 14:17:28 |
Message-ID: | 28050.1092147448@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I'm looking at a database-using program (PostgreSQL/libpq and MySQL) which
> does the following: A daemon process opens a database connection, forks
> children on request, and those children access the database using that
> inherited connection. After one request, the child dies. It seems to me
> that this connection sharing cannot work because the processes would get
> mixed up,
I agree, unless there is some interlock that prevents a new child from
being spawned before the last previous one died. It would seem to work
under light load where that happened anyway.
> but the author claims that he has tested this successfully. I've
> been trying to figure out the semantics from the libc documentation, but I
> can't find a definitive answer. Does anyone know what will happen in this
> situation, and why it actually appears to work?
I'll bet lunch that he simply has not stress-tested it hard enough to
have multiple children actually using the connection at the same time.
I can positively guarantee that it won't work if you do.
It would also not work with SSL, since the encryption state would get
out of sync. And some secondary features like tracking the current
transaction state could get out of sync too. But the basic
query-issuing cycle would probably appear to work as long as only one
child actually had a query in progress at any instant.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-08-10 14:26:20 | Re: nested transaction |
Previous Message | Raphael Bauduin | 2004-08-10 14:15:50 | Re: history tables with only one function? |