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. ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly