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

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

From: "Mark Woodward" <pgsql(at)mohawksoft(dot)com>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>
Subject: Re: pg_config, pg_service.conf, postgresql.conf ....
Date: 2006-02-28 04:52:43
Message-ID: 18614.24.91.171.78.1141102363.squirrel@mail.mohawksoft.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> Mark Woodward wrote:
>> > Mark,
>> >
>> >> Well, I'm sure that one "could" use debian's solution, but that's the
>> >> problem, it isn't PostgreSQL's solution. Shouldn't PostgreSQL provide
>> >> the mechanisms? Will debian support FreeBSD? NetBSD? Is it in the
>> >> PostgreSQL admin manual?
>> >>
>> >> We are talking about a feature, like pg_service.conf, now that people
>> >> notice it, we are saying "WOW, this is the API we should push." This
>> is
>> >> a functionality, IMHO, must be the responsibility of PostgreSQL.
>> >
>> > Then stop talking about it and write a patch.
>> >
>> > So far, you've failed to convince anyone else on this list that the
>> > functionality you suggest is actually useful for anyone other that
>> you,
>> > personally.  The only way you're going to do so is to put up some code
>> > somewhere other people can use it and prove that it's useful.
>>
>> Maybe I'm too used to working in engineering groups. I am trying to get
>> input for a project. Trying to iron out what the feature set should be
>> and
>> the objectives that should be attained. BEFORE I start coding.
>>
>> Just saying "submit a patch" is the antithesis to good engineering, it
>> works for hacking, but if I am going to develop a feature, I wish to do
>> it
>> right and have it appeal to the broadest possible audience, collect as
>> much input about the needs of users, etc.
>
> You are 100% right here.  Talking about it first is usually the best
> policy.

Thanks!
>
> One question I have is how this feature would be an improvement over
> just pointing pg_ctl at a postgresql.conf configuration file.  That
> config file has the ability to specify most if not all server
> parameters.

Like I have repeated a number of times, sometimes, there is more than one
database cluster on a machine. The proposed pg_clusters.conf, could look
like this:

pg_clusters.conf>>>>
[GEO]
DATADIR=/vol01/pggeo
PORT=5435

[ICDMDB]
DATADIR=/vol01/pgicdmdb
PORT=5434

[TOMLANE]
DATADIR=/vol03/pg74
PORT=5433
POSTMASTER=/usr/local/pg7.4.1/bin/postmaster

[POSTMASTER]
DATADIR=/vol02/pg90
PORT=5432

# Virtual target starts all?
[ALL]
DB0=GEO
DB1=ICDMDB
DB2=TOMLANE

<<<<<<<<<

pg_ctl start
(Finds and starts the "POSTMASTER" entry)

pg_ctl -S ICDMDB start
(Starts the ICDMDB cluster)

pg_ctl startall
or
pg_ctl -S [*|all] start
or
pg_ctl startall


Or maybe even "start" will start a virtual target "ALL"

In response to

Responses

pgsql-hackers by date

Next:From: John DeSoiDate: 2006-02-28 05:05:44
Subject: character encoding in StartupMessage
Previous:From: Bruce MomjianDate: 2006-02-28 04:50:24
Subject: Re: pg_config, pg_service.conf, postgresql.conf ....

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