Tim Holloway <mtsinc@southeast.net> writes:
> Foolishly or not, I designed the new PostgreSQL logging subsystem
> to run as a process. It's forked off a function called by the
> Postmaster main program right before the if(...)pmdaemonize
> statements -- meaning that the shared memory enviroment has been
> established, but the signals have not yet been attached.
I'd be inclined to think you should fork off after pmdaemonize rather
than before, but of course that makes no difference unless you're
using -S.
> When I issue the fork() call, it successfully creates a child process,
> but the child is DOA. Investigation reveals a signal 5 trace/breakpoint
> trap at the fork.
What did your investigation consist of? That could just be the result
of your debugger trying to step through the fork. Many Unix debuggers
don't cope very well with multi-process programs.
I'm still wondering why you are bothering with an extra process, though.
By the time you get done writing the required communication support,
you'll be adding quite a large amount of code, and at least one new
failure mode for Postgres, in return for what exactly? This design
isn't making sense to me, compared to just letting the backends issue
their own logging messages.
regards, tom lane