> Martijn van Oosterhout <kleptog@xxxxxxxxx> writes:
>> On Tue, Nov 13, 2007 at 12:02:31PM -0500, dan@xxxxxxxxx wrote:
>>> How does Postgres handle sharing database handles across child
>>> processes?
>>> That is, if I have a process that opens a connection to the database
>>> and
>>> then forks a few child processes, what happens?
>>>
>>> Can the child processes safely use the handle?
>
>> No.
>
> For some time now, libpq has set FD_CLOEXEC on the socket connection to
> the backend, which ensures that child processes won't be able to mess up
> the parent's database connection. However it sounded like Dan might be
> doing fork without exec, in which case he's definitely at risk ...
Yep, this is a fork without exec. And the child processes often aren't
even doing any database access -- the database connection's opened and
held, then a child is forked off, and the child 'helpfully' closes the
handle during the child's global destruction phase.
Am I at any risk in the parent process? That is, if the parent's got some
transaction open, the child is forked, then the child either issues
(perhaps in error) a command to the database or shuts the handle down, am
I going to see any sort of corruption of the data on the back end?
I fully realize this is a Bad Thing, no argument there -- I'm just trying
to get a feel for my failure modes. If it's just going to be that the
parent sees the handle go away that's one thing, if I'm going to see weird
interleaving of commands from the parent and child or the back end's going
to get confused enough to corrupt the database it's something else
entirely.
-Dan
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
