>You might find that doing on_exit_reset() in the child would fix the
>worst problems, but it still sounds chancy as heck.
Thanks for that. The fork() is certainly more convenient than exec'g something
else - hopefully OK since we're just prototyping something.
Quick question: where is _exit_re
Alvaro Herrera writes:
> You probably should close any open file descriptors too, just to be
> safe. (Or do we set FD_CLOEXEC on them?)
We don't. It'd take an extra syscall per open(), which seems like rather
a lot of overhead to deal with a case we aren't even trying to support.
Excerpts from Tom Lane's message of mar ago 10 19:49:18 -0400 2010:
> Offhand the only clean way I can see to launch a child process is to
> fork *and exec something*.
You probably should close any open file descriptors too, just to be
safe. (Or do we set FD_CLOEXEC on them?)
--
Álvaro Herrera
Jay Flattery writes:
>> What exactly is that child process doing? It sure sounds like it thinks
>> it's a valid backend.
> Actually it's not doing anything, as I'm just trying to work it all out -
> just a
> bunch of printfs and waits.
> But the library is a PG_MAGIC_MODULE.
> I tried killin
Thanks for your reply
>> I now fork() a process in _PG_Init() (both processes interact), but when I
>> shutdown postgre I get: LOG: failed to find proc 0x1331110 in ProcArray
>What exactly is that child process doing? It sure sounds like it thinks
>it's a valid backend.
Actually it's not doi
Jay Flattery writes:
> I have some functions written in C that are dynamically loaded. I persist
> some
> state between function calls, initialised by _PG_init. This works fine
OK...
> I now fork() a process in _PG_Init() (both processes interact), but when I
> shutdown postgre I get: LOG: f
Hi there,
I have some functions written in C that are dynamically loaded. I persist some
state between function calls, initialised by _PG_init. This works fine
I now fork() a process in _PG_Init() (both processes interact), but when I
shutdown postgre I get: LOG: failed to find proc 0x1331110
