Mark Woodward wrote:
Admittedly, given that the binaries are likely to be in the
cluster-owners default PATH, it is not as hard to find them as the data
directory. However, this is all about convenience it would seem, since
(for many *nix platforms) two simple searches will give you most of what
is needed:
$ locate postmaster
$ locate pg_hba.conf
That's not the issue.
I find it frustrating sometimes because when I describe one scenario,
people debate it using other scenarios. Maybe I lack the communications
skills to convey the problem accurately.
I think you are describing what you want very clearly. However I suspect
people will want the solution to your scenario to be sufficiently
general to help theirs too - which can sometimes be frustrating when you
see your idea suffer "scope creep", but just as often can mean your idea
gets critiqued and melded into something better that you would have
thought of alone - well that's what I've found anyway :-).
Lets say you are an admin at XYZ Services Corp. You have 20 data centers
world wide. In each data center, you have 10 to 1000 PostgreSQL servers.
Through your VPN you can access any one of the machines in any data center
through a simple IP address, thanks to your VPN.
Second Scenario:
You are the same admin at the same XYZ corp. An electrician pulls the
breaker in the data center and your systems go down (This actually happend
to one installation I worked on). A couple of the admins in charge of some
of the boxes are on vacation and "accidentally" forgot to bring their cell
phones.
A few of the systems didn't come up correctly. You need to find the
correct databases. Unfortunately there are more database cluster
directories than there should be, and the admin hadn't yet documented
which was which. You don't even know how to test if they are.
Your site is down, you are very stressed, you are cursing the guy that
didn't write this stuff down. Since there is no facility to bring up
multiple PG databases, there is no standard to follow.
Wouldn't it be nice, to be able to do "pg_ctl startall?" Or better yet,
just have this in the startup?
Absolutely -
In keeping with the idea of providing a mechanism for such:
I'm wondering if adding an options to "pg_ctl register" to register
clusters with a global registry and adding another option to pg_ctl for
start|stop all.
e.g:
$ pg_ctl register [-R [filename]] [-N servicename] [-U username] [-P
password] [-D datadir] [-w] [-o options]
$ pg_ctl [-A] [-R [filename]] start|stop
The idea being:
1/ Maintaining a global cluster registry is optional.
2/ The choice of file location is optional (guess a sensible default is
needed).
3/ Start and stop can specify all clusters (clearly some careful
programming is needed to exec the right binaries in the case of multiple
versions!).
This does not solve the issue of a registry file not being up to date,
but provides a simple means to *keep* it up to date - just search for
clusters that are not in the registry file and add 'em with 'pg_ctl
register -R'.
Cheers
Mark
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
