Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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.


$ 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 
3/ Start and stop can specify all clusters (clearly some careful 
programming is needed to exec the right binaries in the case of multiple 

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



In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group