Re: location of the configuration files

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Oliver Elphick <olly(at)lfix(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: location of the configuration files
Date: 2003-02-16 03:03:56
Message-ID: 200302152203.56392.lamar.owen@wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Saturday 15 February 2003 21:06, Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > Shouldn't we be consistent and have initdb use the datadir set in the
> > config file, which could be supplied by a ./configure switch?

> That'd mean there is no way to perform an initdb into a nonstandard
> location without first hand-preparing a config file. I don't much care
> for that.

Six of one and half-dozen of another. And that's my real point. We do things
quite differently from many other standard services, even those which are
built from the ground up for multiple instances. Making things more
consistent for admins, even if it's not what we are used to or what we might
like (because it's familiar) should at least be thought about. I'm not
advocating changing just for the sake of change; but getting a new fresh look
at our current setup can't hurt.

> > I'm looking at a packager point of view here. The initdb is done well
> > after the package is made, and installed. It would be ideal from this
> > point of view to have things fully configured pre-initdb (and thus
> > pre-packaging).

> This point of view means that no post-configure knowledge can be
> applied. We might as well forget the separate initdb step altogether
> and have "make install" do it.

I wouldn't complain. Although that isn't conducive to the multiple instance
case. The necessary post-configure knowledge would be in the instance
postgresql.conf file. One place for it. But this is hypothetical; fishing
around the waters here at this point. Realize that my own packages apply an
initdb automatically if an install isn't found the first time the system
initscript is started. It is virtually automatic. With the multiple
postmaster support, creating a couple of files and a symlink (for the
initscript), and starting the new initscript symlink does all the dirty work.
But it could be easier.

> I realize that from a packager's point of view, the separate initdb step
> is not very useful. But it is from my point of view.

Would you mind elucidating which point of view is yours? General idea of who
else might have the same point of view, and why you find the initdb in its
current form to be more useful than alternatives. Again, I'm fishing for
knowledge -- if nothing else it gives me an answer to those users who send me
nastygrams about the way things are right now.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-02-16 05:16:44 Re: location of the configuration files
Previous Message Ross J. Reedstrom 2003-02-16 02:21:51 Re: psql and readline