Hash: RIPEMD160

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?
Yes. But there is an easy solution, asuming you are using DBI:

$dbh->{InactiveDestroy} = 1;

This tells DBI not to do anything special when inside of DESTROY. Set
on the kids immediately after forking.
I don't currently have a wedge into the parts of the programs that're
forking. I'd hoped to avoid having to, but at this point I'm thinking that
was a touch naive. (I'm also thinking I may want to hassle Rafael into
putting a post-fork handler into 5.10, but that's a separate issue)
"the child processes often aren't even doing any database access"

Often aren't? This should be "never", period, unless the parent contracts
to stop doing database access after the fork. You can't have two processes
sharing a handle.
The child processes are supposed to get their own handles; there's some
caching involved, but the cache checks pids. That doesn't mean the
children all do get their own handles, just that they're supposed to.

Regardless, at this point I'm sufficiently convinced that things will
potentially be bad (or at least annoying) enough that it warrants fixing
it now, rather than just putting it off and relying on error traps.


Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 8 of 8 | next ›
Discussion Overview
grouppgsql-general @
postedNov 13, '07 at 5:02p
activeNov 13, '07 at 7:56p



site design / logo © 2019 Grokbase