On Tue, 2010-02-23 at 00:02 -0500, Tom Lane wrote: > Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers