PostgreSQL configuration
About a year or two ago I submitted a configuration patch that allowed
PostgreSQL to be fully configured by postgresql.conf -- enabling data and
configuration to be in separate locations. The idea was that, like most
UNIX systems, that the configuration file could be stored in the /etc
directory (or /etc/postgres or /usr/etc or whatever) and it could contain
all the various system directory and file locations, like pg_hba, and so
on.
There was a lot of debate about it, and I don't recall many arguments
against this sort of configuration strategy, only that there was a dislike
of my patch because it wasn't an all encompassing re-write of the
configuration system.
I have been maintaining it for the various versions of PostgreSQL since
that time for my own use, can we re-open this debate? It has been a good
deal of time with no progress, and I don't think anyone can deny that a
more flexable configuration based on the idea that configuration and data
are in SEPARATE locations is important.
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?
I guess I should search the archive for the old discussion. If someone
have a link please post :-)
--
/Dennis Bj�rklund
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.
(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.
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.
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.)
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.
How many systems have you been asked to inspect for problems? It is one of
the things I do for a living. On many systems, I can just look in the
'/etc' directory for most of what I need. If they are running PostgreSQL,
I have to look around and figure out where the database is located.
Dennis Bjorklund <db@zigo.dhs.org> writes:
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 recollection of the arguments against were first that and second
reliability --- there was concern about getting config and data of
multiple installations mixed up if they weren't kept together. In the
worst case you could conceivably bollix an installation unrecoverably
that way. (Right now I do not think there is anything quite that
critical in postgresql.conf, but someday there might be. My very vague
recollection is that the proposed patch changed things so that WAL and
DATA directories would be separately specified in the config file; if
correct, mismatching them definitely would be a great chance to shoot
oneself in the foot.)
I've recently had some very unpleasant experiences trying to install
test versions of MySQL on machines that already had older versions
installed normally. It seems that MySQL *will* read /etc/my.cnf if it
exists, whether it's appropriate or not, and so it's impossible to have
a truly independent test installation, even though you can configure it
to build/install into nonstandard directories. Let's not emulate that
bit of brain damage.
regards, tom lane
On Thu, Apr 08, 2004 at 10:31:44AM -0400, Tom Lane wrote:
I've recently had some very unpleasant experiences trying to install
test versions of MySQL on machines that already had older versions
installed normally. It seems that MySQL *will* read /etc/my.cnf if it
exists, whether it's appropriate or not, and so it's impossible to have
a truly independent test installation, even though you can configure it
to build/install into nonstandard directories. Let's not emulate that
bit of brain damage.
A counterexample of Apache shows that you can easily use -f or another
command line option to point the server to alternate master config
file (which I believe is the same with MySQL). From that config
files, another files can be included, making it easy to share pieces
of configuration, or separate them in any way.
--
------------------------------------------------------------------------
Honza Pazdziora | adelton@fi.muni.cz | http://www.fi.muni.cz/~adelton/
.project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
Only self-confident people can be simple.
I have the file location discussion in my 7.4 hold mailbox:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
I am going to revisit it the next month and see if I can get all the
opinions merged into a plan everyone can agree on. I think it can be
done.
---------------------------------------------------------------------------
Tom Lane wrote:
Dennis Bjorklund <db@zigo.dhs.org> writes:
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 recollection of the arguments against were first that and second
reliability --- there was concern about getting config and data of
multiple installations mixed up if they weren't kept together. In the
worst case you could conceivably bollix an installation unrecoverably
that way. (Right now I do not think there is anything quite that
critical in postgresql.conf, but someday there might be. My very vague
recollection is that the proposed patch changed things so that WAL and
DATA directories would be separately specified in the config file; if
correct, mismatching them definitely would be a great chance to shoot
oneself in the foot.)I've recently had some very unpleasant experiences trying to install
test versions of MySQL on machines that already had older versions
installed normally. It seems that MySQL *will* read /etc/my.cnf if it
exists, whether it's appropriate or not, and so it's impossible to have
a truly independent test installation, even though you can configure it
to build/install into nonstandard directories. Let's not emulate that
bit of brain damage.regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Tom Lane wrote:
I've recently had some very unpleasant experiences trying to install
test versions of MySQL on machines that already had older versions
installed normally. It seems that MySQL *will* read /etc/my.cnf if it
exists, whether it's appropriate or not, and so it's impossible to have
a truly independent test installation, even though you can configure it
to build/install into nonstandard directories. Let's not emulate that
bit of brain damage.regards, tom lane
It seems to me that this is a packaging problem and not a postgresql
problem. If someone wants to package PostgreSQL so that there's a
symlink to a config file in /etc/pgsql or vice versa for the main
database they're welcome to do that, and why not? As for test
databases, there's already a -D for the datadir, why not add a -C for
the config file as many software packages allow. Then packagers could
put the config file anywhere they wanted. I would certainly welcome
this feature as it would allow for easy tweaking/benchmarking.
I agree that we should avoid the viral-like MySQL configuration plague.
As to pgsql AT mohawksoft.com requested, here are a few widely used
software packages that keep configuration close to the data, some in
/var, some in /usr:
Mailman
OpenSSL
Cyrus-IMAP
Apache I believe doesn't install anything to /etc/ when you build from
source.
Honza Pazdziora <adelton@informatics.muni.cz> writes:
On Thu, Apr 08, 2004 at 10:31:44AM -0400, Tom Lane wrote:
It seems that MySQL *will* read /etc/my.cnf if it
exists, whether it's appropriate or not, and so it's impossible to have
a truly independent test installation, even though you can configure it
to build/install into nonstandard directories. Let's not emulate that
bit of brain damage.
A counterexample of Apache shows that you can easily use -f or another
command line option to point the server to alternate master config
file (which I believe is the same with MySQL).
According to
http://www.mysql.com/documentation/mysql/bychapter/manual_Using_MySQL_Programs.html#Option_files
/etc/my.cnf will be read if it exists, no matter what you say on the
command line. So AFAICS the only way to make a private installation is
to make sure that you have overridden each and every setting in
/etc/my.cnf in a private config file that you do control. This is
tedious and breakage-prone, of course.
regards, tom lane
Dennis Bjorklund <db@zigo.dhs.org> writes:
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 recollection of the arguments against were first that and second
reliability --- there was concern about getting config and data of
multiple installations mixed up if they weren't kept together. In the
worst case you could conceivably bollix an installation unrecoverably
that way. (Right now I do not think there is anything quite that
critical in postgresql.conf, but someday there might be. My very vague
recollection is that the proposed patch changed things so that WAL and
DATA directories would be separately specified in the config file; if
correct, mismatching them definitely would be a great chance to shoot
oneself in the foot.)
The patch I had kept the directory layout as one single setting, just that
postgresql,conf was able to contain the location of pg_hba.conf,
pg_ident.conf, and the data directory.
Thus, one could start PostgreSQL as:
postmaster -C /etc/postgres/webdb.conf
Which would allow full configuration from that one file.
I've recently had some very unpleasant experiences trying to install
test versions of MySQL on machines that already had older versions
installed normally. It seems that MySQL *will* read /etc/my.cnf if it
exists, whether it's appropriate or not, and so it's impossible to have
a truly independent test installation, even though you can configure it
to build/install into nonstandard directories. Let's not emulate that
bit of brain damage.
MySQL is, in general, unpleasent, but that is more or less a packaging issue.
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
Robert Treat <xzilla@users.sourceforge.net> writes:
On Thu, 2004-04-08 at 09:49, pgsql@mohawksoft.com wrote:
(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.
In any case, you will never get such a proposal past the core
developers, because we all run multiple PG installs per machine.
My primary development machine currently has six postmasters alive
on it (7.0, 7.1, ..., 7.4 + CVS tip); my alternate machine has five
installations on it, though not all are alive since I've not had reason
to restart them all since last reboot; even the laptop I'm physically
typing on right now has more than one Postgres installation on it.
And practically any time someone allows me access to a machine of
theirs to check out some kind of portability issue, I'll build a test
installation in my guest-account home directory, rather than muck with
their live server.
So, don't bother proposing anything that makes it even slightly harder
to run multiple servers per machine. It will not happen. End of
discussion.
regards, tom lane
On Thu, Apr 08, 2004 at 11:32:19AM -0400, Tom Lane wrote:
A counterexample of Apache shows that you can easily use -f or another
command line option to point the server to alternate master config
file (which I believe is the same with MySQL).According to
http://www.mysql.com/documentation/mysql/bychapter/manual_Using_MySQL_Programs.html#Option_files
/etc/my.cnf will be read if it exists, no matter what you say on the
command line. So AFAICS the only way to make a private installation is
to make sure that you have overridden each and every setting in
:-) I never used that "feature" so was never bitten by it. Anyway,
Apache HTTP server seems to do it the right way, doesn't it?
--
------------------------------------------------------------------------
Honza Pazdziora | adelton@fi.muni.cz | http://www.fi.muni.cz/~adelton/
.project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
Only self-confident people can be simple.
Robert Treat <xzilla@users.sourceforge.net> writes:
On Thu, 2004-04-08 at 09:49, pgsql@mohawksoft.com wrote:
(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.In any case, you will never get such a proposal past the core
developers, because we all run multiple PG installs per machine.
My primary development machine currently has six postmasters alive
on it (7.0, 7.1, ..., 7.4 + CVS tip); my alternate machine has five
installations on it, though not all are alive since I've not had reason
to restart them all since last reboot; even the laptop I'm physically
typing on right now has more than one Postgres installation on it.
And practically any time someone allows me access to a machine of
theirs to check out some kind of portability issue, I'll build a test
installation in my guest-account home directory, rather than muck with
their live server.So, don't bother proposing anything that makes it even slightly harder
to run multiple servers per machine. It will not happen. End of
discussion.
The problem with this conversation is that you assume the functionality
desired would affect your methodology in any way.
All I am asking for, and this is what my patch did, was add a few entries
to postgresql.conf. "data_dir, hba_conf, and ident_conf. A later version
of the patch added "include" and "runtime_pidfile."
These features allow a postgreSQL system to be fully configurable via a
postgresql.conf file. It may, in fact, make it easier to have multiple
installs.
Tom Lane wrote:
Honza Pazdziora <adelton@informatics.muni.cz> writes:
On Thu, Apr 08, 2004 at 10:31:44AM -0400, Tom Lane wrote:
It seems that MySQL *will* read /etc/my.cnf if it
exists, whether it's appropriate or not, and so it's impossible to have
a truly independent test installation, even though you can configure it
to build/install into nonstandard directories. Let's not emulate that
bit of brain damage.A counterexample of Apache shows that you can easily use -f or another
command line option to point the server to alternate master config
file (which I believe is the same with MySQL).According to
http://www.mysql.com/documentation/mysql/bychapter/manual_Using_MySQL_Programs.html#Option_files
/etc/my.cnf will be read if it exists, no matter what you say on the
command line. So AFAICS the only way to make a private installation is
to make sure that you have overridden each and every setting in
/etc/my.cnf in a private config file that you do control. This is
tedious and breakage-prone, of course.
Yes. But we don't have to do that.
If we're truly concerned about the possibility of multiple installations
attempting to use the same config, then the answer is simple: require
that the location of the config file be specified on the command line
and don't compile a default location into the binary. Similarly, don't
take the value from an environment variable.
Packaged installations won't have trouble with this: they supply a startup
script which would pass the appropriate argument to the postmaster.
If we want to be a bit paranoid (justifiable if you've got really
important data on the line), we could also require that a version
string exist in the config file. If the version string doesn't match
the version of the postmaster being started, the postmaster exits with
an error (and a hint of what to set the version string to and what the
name of the version string parameter is). That way, even if you screw
up on the command line, you won't hose a database by starting the wrong
version of the postmaster against it. Not sure if this would break
anything, though.
--
Kevin Brown kevin@sysexperts.com
In the last exciting episode, kevin@sysexperts.com (Kevin Brown) wrote:
If we want to be a bit paranoid (justifiable if you've got really
important data on the line), we could also require that a version
string exist in the config file. If the version string doesn't match
the version of the postmaster being started, the postmaster exits with
an error (and a hint of what to set the version string to and what the
name of the version string parameter is). That way, even if you screw
up on the command line, you won't hose a database by starting the wrong
version of the postmaster against it. Not sure if this would break
anything, though.
How would this differ from the present situation where
$PGDATA/PG_VERSION is already required to match against the
postmaster?
As far as I can see, the only thing that is to be changed by the
proposal is that instead of postgresql.conf being in $PGDATA, it might
be found somewhere else. (And perhaps pg_hba.conf and pg_ident.conf
will also be located in that mystical "somewhere else.")
The change that _might_ be relevant would be to put a version string
into postgresql.conf so that there would be _two_ matches made, not
just one:
- $PGDATA/PG_VERSION is required to match the postmaster;
- $SOMEWHERE_ELSE/postgresql.conf's variable "version" is required to
match the postmaster.
But I think Tom put it pretty well when he commented that all of the
core developers make extensive use of the notion of having _many_
backends around, and therefore would oppose any proposal that would
make it less convenient to do that.
Core folk aren't likely to write up patches designed to shoot
themselves in the foot this way, nor are they likely to accept patches
that clearly do so.
--
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/linuxxian.html
"There's no longer a boycott of Apple. But MacOS is still a
proprietary OS." -- RMS - June 13, 1998
Kevin Brown wrote:
If we're truly concerned about the possibility of multiple installations
attempting to use the same config, then the answer is simple: require
that the location of the config file be specified on the command line
and don't compile a default location into the binary. Similarly, don't
take the value from an environment variable.Packaged installations won't have trouble with this: they supply a startup
script which would pass the appropriate argument to the postmaster.
In order to keep with existing practice, you could say that you have to
supply *either* a config file, which points to the data dir etc., *or* a
data dir, in which case the config files must be in the data dir. I very
much agree with the idea of not compiling in a default config file location.
If we want to be a bit paranoid (justifiable if you've got really
important data on the line), we could also require that a version
string exist in the config file. If the version string doesn't match
the version of the postmaster being started, the postmaster exits with
an error (and a hint of what to set the version string to and what the
name of the version string parameter is). That way, even if you screw
up on the command line, you won't hose a database by starting the wrong
version of the postmaster against it. Not sure if this would break
anything, though.
It won't start now if there's a version mismatch, and that's nothing
whatever to do with the config file - it matches against the PG_VERSION
file. We're already rightly paranoid on this point.
cheers
andrew
Robert Treat <xzilla@users.sourceforge.net> writes:
On Thu, 2004-04-08 at 09:49, pgsql@mohawksoft.com wrote:
(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.
In any case, you will never get such a proposal past the core
developers, because we all run multiple PG installs per machine. My
primary development machine currently has six postmasters alive on it
(7.0, 7.1, ..., 7.4 + CVS tip); my alternate machine has five
installations on it, though not all are alive since I've not had reason
to restart them all since last reboot; even the laptop I'm physically
typing on right now has more than one Postgres installation on it. And
practically any time someone allows me access to a machine of theirs to
check out some kind of portability issue, I'll build a test installation
in my guest-account home directory, rather than muck with their live
server.
So, don't bother proposing anything that makes it even slightly harder
to run multiple servers per machine. It will not happen. End of
discussion.
I'll just post the README file at the bottom for a reference, but it
PostgreSQL can appear completely unchanged, but with the addition of just
two command line arguments, work "better" in situations where this sort of
functionality is desired, I don't see why people would wish it not to be
included.
If there are issues with coding style, or other finer details, I would be
very much willing to address any issues. Personally, I think the
requirement of using symlinks to synthesize this functionality is a hard
sell to many administrators.
::::::::::
This patch enables PostgreSQL to be far more flexible in
its configuration methodology.
Specifically, It adds two more command line parameters, "-C"
which specifies either the location of the postgres
configuration file or a directory containing the configuration
files, and "-R" which directs PostgreSQL to write its runtime
process ID to a standard file which can be used by control
scripts to control PostgreSQL.
A patched version of PostgreSQL will function as:
--- Configuration file ---
postmaster -C /etc/postgres/postgresql.confThis will direct the postmaster program to use the
configuration file "/etc/postgres/postgresql.conf"
--- Configuration Directory ---
postmaster -C /etc/postgresThis will direct the postmaster program to search the
directory "/etc/postgres" for the standard configuration
file names: postgresql.conf, pg_hba.conf, and pg_ident.conf.
--- Run-time process ID ---
postmaster -R /var/run/postmaster.pidThis will direct PostgreSQL to write its process ID number
to a file, /var/run/postgresql.conf
--- postgresql.conf options ---
Within the configuration file there are five additional
parameters: include, hba_conf,ident_conf, data_dir, and
runtime_pidfile.They are used as:
include = '/etc/postgres/debug.conf'
data_dir = '/vol01/postgres'
hba_conf = '/etc/postgres/pg_hba_conf'
ident_conf = '/etc/postgres/pg_ident.conf'
runtime_pidfile = '/var/run/postgresql.conf'
The "-D" option on the command line overrides the "data_dir"
in the configuration file.
The "-R" option on the command line overrides the
"runtime_pidfile" in the configuration file.
If no hba_conf and/or ident_conf setting is specified, the default
$PGDATA/pg_hba.conf and/or $PGDATA/pg_ident.conf will be used.
If the "-C" option specifies a diretcory, pg_hba.conf and pg_ident.conf
files must be in the specified directory.
This patch is intended to move the PostgreSQL configuration out of the
data directory so that it can be modified and backed up as well as answer
some of the issues with deploying PostgreSQL in an FHS (File Hierarchy
Standard) way.
This patch is also useful for running multiple servers with the same
parameters:
postmaster -C /etc/postgres/postgresql.conf -D /VOL01/postgres -p 5432
postmaster -C /etc/postgres/postgresql.conf -D /VOL02/postgres -p 5433
To apply the patch, enter your PostgreSQL source directory, and run:
cat pgec-PGVERSON.patch | patch -p 1
Import Notes
Resolved by subject fallback
On Fri, 9 Apr 2004, Christopher Browne wrote:
...Tom ... commented that all of the core developers make extensive use
of the notion of having _many_ backends around, and therefore ...Core folk aren't likely to write up patches designed to shoot
themselves in the foot this way ...
I's not just core developers who use this feature.
For a program that's trying to be compatabile with Oracle,
MySQL, MSSQLServer and PostgreSQL for backends, it's nice
to have 7.3.X, 7.4.X, heck, even 7.0 family postgresql's
running. And indeed, all except SQLServer (another guy's
doing this one) are running on my machine.
I test frequently against whatever database(s) are running on
my development mahines. I test rarely against databases that
aren't. Anything that makes that harder would be bad for developers
using PostgreSQL as well as for the core team.
Ron
On Fri, 9 Apr 2004, Christopher Browne wrote:
...Tom ... commented that all of the core developers make extensive use
of the notion of having _many_ backends around, and therefore ...Core folk aren't likely to write up patches designed to shoot
themselves in the foot this way ...I's not just core developers who use this feature.
For a program that's trying to be compatabile with Oracle,
MySQL, MSSQLServer and PostgreSQL for backends, it's nice
to have 7.3.X, 7.4.X, heck, even 7.0 family postgresql's
running. And indeed, all except SQLServer (another guy's
doing this one) are running on my machine.I test frequently against whatever database(s) are running on
my development mahines. I test rarely against databases that
aren't. Anything that makes that harder would be bad for developers
using PostgreSQL as well as for the core team.
This is so frustrating, NO ONE IS TRYING TO MAKE IT HARDER! All the patch
that I propose does is ADD functionality. Two command line switches, and
five config file entries:
include = '/etc/postgres/debug.conf'
data_dir = '/vol01/postgres'
hba_conf = '/etc/postgres/pg_hba_conf'
ident_conf = '/etc/postgres/pg_ident.conf'
runtime_pidfile = '/var/run/postgresql.conf'
I am neither suggesting nor implementing any change in the current default
behavior of PostgreSQL. I am merely adding features that would make it
easier to do things like configure from a centralized directory which is
different than the data directory, the ability to included
"sub-configuration" like specific tuning or debug info, and to write a
usable PID file for standard UNIX admin scripts.
pgsql@mohawksoft.com writes:
I am neither suggesting nor implementing any change in the current default
behavior of PostgreSQL. I am merely adding features that would make it
easier to do things like configure from a centralized directory which is
different than the data directory, the ability to included
"sub-configuration" like specific tuning or debug info, and to write a
usable PID file for standard UNIX admin scripts.
Well, let's take it one piece at a time here.
I can see some value in providing "#include" functionality in
postgresql.conf (and the other config files too). I'm not convinced
that it's a must-have, because the desired contents of the config files
tend to change with each new PG version. But to the extent that you're
admining multiple clusters of the same version, it would have some use.
Moving the PID file out of the data directory is actively dangerous,
because we use that file as part of the safety interlock against
starting multiple postmasters in the same data directory. I suppose
we could offer an option to write a second copy of the PID file at
a different place, but I'm not seeing what that buys except confusion
(especially if two postmasters are mistakenly instructed to put their
copied PID files at the same place).
The whole idea of having multiple command-line switches to pick config
and data separately bothers me. ISTM this would mostly create great new
opportunities to shoot yourself in the foot (by accidentally picking the
wrong combination), without nearly enough benefit to outweigh the risk.
Possibly this perspective is somewhat developer-centric --- I'm sure
I manually start postmasters far more often than the average person.
But then this whole discussion seems of interest only to people with
outlier requirements; the existing setup works fine for the average user
with only one Postgres installation.
Could we compromise on just adding #include functionality? ISTM that
would cover the desire for separate config and data directories. You
could keep a postgresql.conf file in each data directory that simply
says
#include /etc/postgres/debug.conf
and likewise for other config files. Doesn't that accomplish what you
want?
regards, tom lane
