Hi, On 2014-03-07 09:50:15 -0800, Peter LaDow wrote: > Also, the on_exit_reset() does clear up the issue, and we have > implemented it as suggested in this thread (calling it immediately > after the fork() in the child). And Andres' keen eye noted we were > calling exit() after an exec() failure, rather than _exit(). Thank > you, Andres, for pointing out this error.
I actually didn't see any source code of yours ;), just answered Tom's question about what to do after exec() failed. There's several other wierd behaviours if you use exit() instead of _exit() after a fork, most prominently double flushes leading to repeated/corrupted output when you have have stream FILEs open in the parent. This is because the stream will be flushed in both, the parent (at some later write or exit) and the child (at exit). It's simply something that won't work well. > > I don't see any way it's be safe for a pg unaware library to start > > forking around and doing similar random things inside normal > > backends. > > We aren't exactly "forking around." We were trying to spawn an > asynchronous process without any ties to the postmaster. The important bit in the sentence you quote is "pg unaware library". My point is just that there are some special considerations you have to be aware of. fork() and exec() is a way to escape that environment, and should be fine. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
