Re: tie user processes to postmaster was:(Re: [HACKERS] scheduler in core) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)
Date
Msg-id 20100223150032.GC3672@alvh.no-ip.org
Whole thread Raw
In response to Re: tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs wrote:

> 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..

Yeah, back when autovac wasn't integrated, it was a pain to work with --
the need to start and stop it separately from postmaster was a hard task
to manage.  The Debian init script used to have some very ugly hacks to
work with it.  Having it now integrated makes thing *so* much easier.
Giving postmaster the ability to manage other processes (whether
directly or through a supervisor) would make people lives simpler as
well.

I think it was Dimitri who said that even if postmaster is running but
the connection pooler is down, the system is effectively down for some
users, and thus you really want postmaster to be able to do something
about it.  I cannot agree more.  (You can set up monitoring and such,
but this is merely working around the fact that it doesn't work in the
first place.)

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: A thought on Index Organized Tables
Next
From: Tatsuo Ishii
Date:
Subject: Re: function side effects