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

On Tue, 2010-02-23 at 00:02 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> 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.

Nobody wants to weigh down and sink the postmaster.

What is wanted is a means to integrate parts of a solution that are
already intimately tied to Postgres. Non-integration makes the whole
Postgres-based solution less reliable and harder to operate. Postgres
should not assume that it is the only aspect of the server: in almost
all other DBMS features are built into the database: session pools,
trigger-based replication, scheduling, etc..

-- Simon Riggs           www.2ndQuadrant.com