Re: tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)

On Feb 22, 2010, at 9:02 PM, Tom Lane wrote:

> Alvaro Herrera  writes:
>> Regarding hooks or events, I think postmaster should be kept simple:
>> launch at start, reset at crash recovery, kill at stop.  Salt and pepper
>> allowed but that's about it -- more complex ingredients are out of the
>> question due to added code to postmaster, which we want to be as robust
>> as possible and thus not able to cook much of anything else.
> 
> This is exactly why I think the whole proposal is a nonstarter.  It is
> necessarily pushing more complexity into the postmaster, which means
> an overall reduction in system reliability.  There are some things
> I'm willing to accept extra postmaster complexity for, but I say again
> that not one single one of the arguments made in this thread are
> convincing reasons to take that risk.

Would having a higher level process manager be adequate - one
that spawns the postmaster and a list of associated processes
(queue manager, job scheduler, random user daemons that are
used for database application maintenance). It sounds like
something like that would be able to start up and shut down
an entire family of daemons, of which the postmaster is the major
one, gracefully.

It could also be developed almost independently of core code,
at most it might benefit from a way for the postmaster to tell it
when it's started up successfully.

Cheers, Steve