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
|
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: