Re: PostgreSQL configuration - Mailing list pgsql-hackers

From Robert Treat
Subject Re: PostgreSQL configuration
Date
Msg-id 1081457086.5161.52.camel@camel
Whole thread Raw
In response to Re: PostgreSQL configuration  (pgsql@mohawksoft.com)
Responses Re: PostgreSQL configuration  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 2004-04-08 at 09:49, pgsql@mohawksoft.com wrote:
> > On Thu, 8 Apr 2004 pgsql@mohawksoft.com wrote:
> >
> >> more flexable configuration based on the idea that configuration and
> >> data
> >> are in SEPARATE locations is important.
> >
> > Why is it important and wouldn't it just make it harder to have several
> > database clusters (for example with different locale) or several versions
> > of pg installed at the same time?
> 
> My patch did not remove any functionality, it merely augmented it.
> 
> To say that it would make it more difficult to deploy multiple databases
> is misleading for (2) reasons.
> 
> (1) It need not do that, because the configuration system would seem
> unchanged for those who do not wish to use it in this way.
> 

True, but it is more difficult to deal with multiple databases if one
configures there system in the fashion... debian packages their
installations this way via symlinks so i've experience the difficulty
first hand. .

> (2) I would bet that *most* deployments of PostgreSQL only use one
> database environment per server, so I'm not even sure that it would be an
> issue for the majority of current or prospective users.
> 

except that when doing major version upgrades, i find it far better
practice to install multiple versions on the machine whenever possible,
even if you only intend to run a single version. 

> It is all well and good to say "our way is better," (with which I do not
> agree) but there are, more or less, if not "standards," "standard
> concepts" from which good software design follows. Besides PostgreSQL,
> name one popular open source project that is widely used that stores its
> configuration information inside its data repository. From the "new user"
> perspective, configuration within the data directory is an alien concept.
> 

i remember refuting this last time and i have to say something again
because this is equally misleading... apache does things this way if you
build from source, and there are others as well. 

> >From a sysadmin perspective, having configuration in a standard location
> makes sense. It makes these things easy to backup, archive, and put under
> version control. (Many sysadmins put machine configuration under version
> control to see what changes are made over time.)

and i would say that right now the way postgresql does it is much
easier. when you first get on a machine and need to find the webroot of
an apache install, theres no telling where it could be simply because a
lot of packagers do package things up differently.  

> 
> Finally, I'm not suggesting removing any functionality, I am suggesting
> that configuration can and should be able to be located in a standard
> location and the the configuration be able to point to the data volume.
> 

IIRC part of the problem with the initial patch/proposal is that it had
implementation issues following a couple of OS guidelines/specs, and
there was an issue with the pid. 

One potential bonus I would see to this type of functionality is that on
some servers I have multiple postgresql.confs on a server tuned to
specific tasks at hand... ie one for a pg_restore vs. one for normal
operations... it would be nice to point the db at a specific one rather
than having to copy files back and forth.

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL



pgsql-hackers by date:

Previous
From: "Nolte, Ronald C."
Date:
Subject: postgres/pgtcl & windows
Next
From: "Dann Corbit"
Date:
Subject: Re: Small suggestion on build script