Re: pg_config, pg_service.conf, postgresql.conf ....

From: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
To: Mark Woodward <pgsql(at)mohawksoft(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, kleptog(at)svana(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_config, pg_service.conf, postgresql.conf ....
Date: 2006-02-22 22:11:47
Message-ID: 43FCE1A3.8060703@paradise.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2006-02-22 22:51:29 Re: Attempting upgrade path; is this possible?
Previous Message Stephan Szabo 2006-02-22 22:09:05 Re: Request: set opclass for generated unique and primary