Thread: All forked up

All forked up

From
Tim Holloway
Date:
I need some Unix guidance.

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.

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.

How do I prevent this? I presume you can mask it, but is that really
what I want to do?
  TIA,
    Tim Holloway


Re: [HACKERS] All forked up

From
Tom Lane
Date:
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