On Thu, 2 Feb 2006, Mark Woodward wrote:
> Now, the answer, obviously, is to create multiple postgresql database
> clusters and run postmaster for each logical group of databases, right?
> That really is a fine idea, but....
>
> Say, in pgsql, I do this: "\c newdb" It will only find the database that I
> have in that logical group. If another postmaster is running, obviously,
> psql doesn't know anything about it.
> >From the DB admin perspective, maybe there should be some heirarchical
> structure to this. What if there were a program, maybe a special parent
> "postmaster" process, I don't know, that started a list of child
> postmasters based on some site config? The parent postmaster would hold
> all the configuration parameters of the child postmaster processes, so
> there would only be on postgresql.conf.
>
> This also answers "how do we get postgresql options in a database,"
> because the parent postmaster only needs to bootstrap the others, it can
> be configured to run lean and mean, and the "real" settings can be
> inspected and changed at will. A trigger will send a HUP to child
> postmasters when their settings change. The parent postmaster only needs
> one connection for each child and one admin, right?
>
> Does anyone see this as useful?
Not as described above, no. Perhaps with a more concrete plan that
actually talks about these things in more details. For example, you posit
the \c thing as an issue, I don't personally agree, but you also don't
address it with a solution.