Thread: Explicit configuration file
I have added the option of explicitly specifying a postgresql.conf (-C) file on
the command line. I have also added two config file entries:
pghbaconfig, and pgdatadir.
"pghbaconfig" allows multiple different databases running on the same machine
to use the same hba file, rather than the hard coded $PGDATA/pg_hba.conf.
"pgdatadir" works with the explicit configuration file so that the data
directory can be specified in the configuration file, not on the command line
or environment.
One can start postgres as:
postmaster -C /etc/pgsql/mydb1.conf
Postgres will get all its required information from "mydb1.conf."
Does anyone see any value to these mods? I wanted to be able to run multiple
PostgreSQL instances on the same machine, and having the ability to keep these
control files in a central location and share the HBA control files between
databases may be helpful for admins. It will certainly make my life easier.diff -r -u
postgresql-7.2b3/src/backend/libpq/hba.cpostgresql-7.2b3_conf/src/backend/libpq/hba.c
--- postgresql-7.2b3/src/backend/libpq/hba.c Sun Nov 11 23:29:23 2001
+++ postgresql-7.2b3_conf/src/backend/libpq/hba.c Sat Dec 8 10:46:51 2001
@@ -31,6 +31,8 @@
#include <unistd.h>
#include "libpq/libpq.h"
+#include "utils/guc.h"
+
#include "miscadmin.h"
#include "nodes/pg_list.h"
#include "storage/fd.h"
@@ -476,11 +478,20 @@
{
char *conf_file; /* The name of the config file we have to
* read */
-
- /* put together the full pathname to the config file */
- bufsize = (strlen(DataDir) + strlen(CONF_FILE) + 2) * sizeof(char);
- conf_file = (char *) palloc(bufsize);
- snprintf(conf_file, bufsize, "%s/%s", DataDir, CONF_FILE);
+ /* Explicit HBA in config file */
+ if(explicit_hbaconfig && strlen(explicit_hbaconfig))
+ {
+ bufsize = strlen(explicit_hbaconfig)+1;
+ conf_file = (char *) palloc(bufsize);
+ strcpy(conf_file, explicit_hbaconfig);
+ }
+ else
+ {
+ /* put together the full pathname to the config file */
+ bufsize = (strlen(DataDir) + strlen(CONF_FILE) + 2) * sizeof(char);
+ conf_file = (char *) palloc(bufsize);
+ snprintf(conf_file, bufsize, "%s/%s", DataDir, CONF_FILE);
+ }
file = AllocateFile(conf_file, "r");
if (file == NULL)
diff -r -u postgresql-7.2b3/src/backend/postmaster/postmaster.c
postgresql-7.2b3_conf/src/backend/postmaster/postmaster.c
--- postgresql-7.2b3/src/backend/postmaster/postmaster.c Mon Nov 12 00:43:24 2001
+++ postgresql-7.2b3_conf/src/backend/postmaster/postmaster.c Sat Dec 8 10:38:04 2001
@@ -409,10 +409,13 @@
* with the wrong argument. Death and destruction will occur.
*/
opterr = 1;
- while ((opt = getopt(argc, argv, "A:a:B:b:c:D:d:Fh:ik:lm:MN:no:p:Ss-:")) != EOF)
+ while ((opt = getopt(argc, argv, "A:a:B:b:c:C:D:d:Fh:ik:lm:MN:no:p:Ss-:")) != EOF)
{
switch (opt)
{
+ case 'C':
+ explicit_pgconfig = optarg;
+ break;
case 'D':
potential_DataDir = optarg;
break;
@@ -434,10 +437,24 @@
ExitPostmaster(1);
}
- checkDataDir(potential_DataDir); /* issues error messages */
- SetDataDir(potential_DataDir);
+ if(explicit_pgconfig)
+ {
+ char *datadir;
+ ProcessConfigFile(PGC_POSTMASTER);
+
+ datadir = (pgdatadir) ? pgdatadir : potential_DataDir;
+
+ checkDataDir(datadir);
+ SetDataDir(datadir);
+
+ }
+ else
+ {
+ checkDataDir(potential_DataDir); /* issues error messages */
+ SetDataDir(potential_DataDir);
- ProcessConfigFile(PGC_POSTMASTER);
+ ProcessConfigFile(PGC_POSTMASTER);
+ }
IgnoreSystemIndexes(false);
@@ -447,7 +464,7 @@
optreset = 1; /* some systems need this too */
#endif
- while ((opt = getopt(argc, argv, "A:a:B:b:c:D:d:Fh:ik:lm:MN:no:p:Ss-:")) != EOF)
+ while ((opt = getopt(argc, argv, "A:a:B:b:c:C:D:d:Fh:ik:lm:MN:no:p:Ss-:")) != EOF)
{
switch (opt)
{
@@ -467,6 +484,9 @@
case 'b':
/* Can no longer set the backend executable file to use. */
break;
+ case 'C':
+ /* Can no longer set configuration file */
+ break;
case 'D':
/* already done above */
break;
diff -r -u postgresql-7.2b3/src/backend/utils/misc/guc-file.c postgresql-7.2b3_conf/src/backend/utils/misc/guc-file.c
--- postgresql-7.2b3/src/backend/utils/misc/guc-file.c Fri Nov 23 08:27:33 2001
+++ postgresql-7.2b3_conf/src/backend/utils/misc/guc-file.c Sat Dec 8 09:48:55 2001
@@ -1682,16 +1682,24 @@
Assert(DataDir);
elevel = (context == PGC_SIGHUP) ? DEBUG : ERROR;
- /*
- * Open file
- */
- filename = malloc(strlen(DataDir) + strlen(CONFIG_FILENAME) + 2);
- if (filename == NULL)
+ /* Added for explicit config file */
+ if(!explicit_pgconfig)
{
- elog(elevel, "out of memory");
- return;
+ /*
+ * Open file
+ */
+ filename = malloc(strlen(DataDir) + strlen(CONFIG_FILENAME) + 2);
+ if (filename == NULL)
+ {
+ elog(elevel, "out of memory");
+ return;
+ }
+ sprintf(filename, "%s/" CONFIG_FILENAME, DataDir);
+ }
+ else
+ {
+ filename = strdup(explicit_pgconfig);
}
- sprintf(filename, "%s/" CONFIG_FILENAME, DataDir);
fp = AllocateFile(filename, "r");
if (!fp)
diff -r -u postgresql-7.2b3/src/backend/utils/misc/guc.c postgresql-7.2b3_conf/src/backend/utils/misc/guc.c
--- postgresql-7.2b3/src/backend/utils/misc/guc.c Tue Oct 30 00:38:56 2001
+++ postgresql-7.2b3_conf/src/backend/utils/misc/guc.c Sat Dec 8 09:54:22 2001
@@ -39,6 +39,10 @@
#include "utils/datetime.h"
#include "pgstat.h"
+/* Added for config file only startup MLW */
+char *explicit_pgconfig = NULL;
+char *explicit_hbaconfig = NULL;
+char *pgdatadir = NULL;
/* XXX these should be in other modules' header files */
extern bool Log_connections;
@@ -594,7 +598,14 @@
XLOG_sync_method_default, check_xlog_sync_method,
assign_xlog_sync_method
},
-
+ {
+ "hbaconfig", PGC_POSTMASTER, &explicit_hbaconfig,
+ "", NULL, NULL
+ },
+ {
+ "pgdatadir", PGC_POSTMASTER, &pgdatadir,
+ "", NULL, NULL
+ },
{
NULL, 0, NULL, NULL, NULL, NULL
}
diff -r -u postgresql-7.2b3/src/backend/utils/misc/postgresql.conf.sample
postgresql-7.2b3_conf/src/backend/utils/misc/postgresql.conf.sample
--- postgresql-7.2b3/src/backend/utils/misc/postgresql.conf.sample Sun Sep 30 14:57:45 2001
+++ postgresql-7.2b3_conf/src/backend/utils/misc/postgresql.conf.sample Sat Dec 8 10:52:28 2001
@@ -19,6 +19,15 @@
#========================================================================
+# Explicit configuration
+
+# Allows postgres to use an pg_hba.conf file
+# which is not in the database directory.
+# hbaconfig = '/etc/pghba.conf'
+
+# Allows Postgres to find its data directory
+# from this configuration file.
+# pgdatadir = '/u01/postgres'
#
# Connection Parameters
diff -r -u postgresql-7.2b3/src/include/utils/guc.h postgresql-7.2b3_conf/src/include/utils/guc.h
--- postgresql-7.2b3/src/include/utils/guc.h Mon Nov 5 12:46:36 2001
+++ postgresql-7.2b3_conf/src/include/utils/guc.h Sat Dec 8 10:04:36 2001
@@ -73,4 +73,9 @@
extern bool SQL_inheritance;
extern bool Australian_timezones;
+/* Added MLW */
+extern char *explicit_pgconfig;
+extern char *explicit_hbaconfig;
+extern char *pgdatadir;
+
#endif /* GUC_H */
> Does anyone see any value to these mods? I wanted to be able to run multiple > PostgreSQL instances on the same machine, and having the ability to keep these > control files in a central location and share the HBA control files between > databases may be helpful for admins. It will certainly make my life easier. Isn't it easier to just use symlinks? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > > > Does anyone see any value to these mods? I wanted to be able to run multiple > > PostgreSQL instances on the same machine, and having the ability to keep these > > control files in a central location and share the HBA control files between > > databases may be helpful for admins. It will certainly make my life > easier. > > Isn't it easier to just use symlinks? > There is a sort of chicken and egg poblem with PostgreSQL administration. Since the settings are not in the "etc" directory, you need to know where PostgreSQL is installed before you can administer it. If you have multiple systems, configured differently, you have to hunt around to find your PostgreSQL directory on the machine on which you are working. We use a "push" system to push out a whole PostgreSQL data directory to multiple boxes. It would be good to be able to specify default configuration differences between the master the slaves without having to edit the snap shot. At our site, all the configuration files are in a centralized directory and under CVS, except one. Guess which. Symlinks don't copy well via ssh. Having the configuration files outside a standard directory, ala "/etc" is not very UNIX like. I could run: initdb -D/u01/pgsql su pgsql -c "postgresql -C /etc/pgsql/mydb.conf" And get all the settings I specify without having to copy files. I could go on, and they are all just nit-picks to be sure, but it just seems "cleaner" to be able to put the configuration in a separate place than the data.
mlw writes: > I have added the option of explicitly specifying a postgresql.conf (-C) file on > the command line. I have also added two config file entries: > > pghbaconfig, and pgdatadir. > > "pghbaconfig" allows multiple different databases running on the same machine > to use the same hba file, rather than the hard coded $PGDATA/pg_hba.conf. That could be mildly useful, although symlinks make this already possible, and a bit clearer, IMHO. > "pgdatadir" works with the explicit configuration file so that the data > directory can be specified in the configuration file, not on the command line > or environment. So you exchange having to specify the data directory with having to specify the configuration file which specifies the data directory. This doesn't add any functionality, it only adds one more indirection. -- Peter Eisentraut peter_e@gmx.net
mlw wrote: > > Bruce Momjian wrote: > > > > > Does anyone see any value to these mods? I wanted to be able to run multiple > > > PostgreSQL instances on the same machine, and having the ability to keep these > > > control files in a central location and share the HBA control files between > > > databases may be helpful for admins. It will certainly make my life > > easier. > > > > Isn't it easier to just use symlinks? > > > > There is a sort of chicken and egg poblem with PostgreSQL administration. Since > the settings are not in the "etc" directory, you need to know where PostgreSQL > is installed before you can administer it. If you have multiple systems, > configured differently, you have to hunt around to find your PostgreSQL > directory on the machine on which you are working. > > We use a "push" system to push out a whole PostgreSQL data directory to > multiple boxes. It would be good to be able to specify default configuration > differences between the master the slaves without having to edit the snap shot. > > At our site, all the configuration files are in a centralized directory and > under CVS, except one. Guess which. > > Symlinks don't copy well via ssh. > > Having the configuration files outside a standard directory, ala "/etc" is not > very UNIX like. > > I could run: > initdb -D/u01/pgsql > su pgsql -c "postgresql -C /etc/pgsql/mydb.conf" > > And get all the settings I specify without having to copy files. > > I could go on, and they are all just nit-picks to be sure, but it just seems > "cleaner" to be able to put the configuration in a separate place than the > data. Perhaps, even use the standard GNU configure "sysconfigdir" setting to point to postgresql.conf, as well as pg_hba.conf. i.e. "$sysconfigdir/postgresql.conf. That should be easy enough, and hat would bring PostgreSQL in line with many of the common practices.
Peter Eisentraut wrote: > > mlw writes: > > > I have added the option of explicitly specifying a postgresql.conf (-C) file on > > the command line. I have also added two config file entries: > > > > pghbaconfig, and pgdatadir. > > > > "pghbaconfig" allows multiple different databases running on the same machine > > to use the same hba file, rather than the hard coded $PGDATA/pg_hba.conf. > > That could be mildly useful, although symlinks make this already possible, > and a bit clearer, IMHO. On systems which support symlinks, yes. Also, a system should be "self documenting" i.e. one should be able to put clues to why certain things were done. Symlinks allow one to do something, yes, but if I leave the company, someone besides me should be able to administrate the system I leave behind. Don't you consider symlinks as a kind of a hack around a basic flaw in the configuration process? Shouldn't the configuration file let you completely specify how your system is configured? > > > "pgdatadir" works with the explicit configuration file so that the data > > directory can be specified in the configuration file, not on the command line > > or environment. > > So you exchange having to specify the data directory with having to > specify the configuration file which specifies the data directory. This > doesn't add any functionality, it only adds one more indirection. Yes and no. There is an underlying methodology to most unix server programs, the configuration information goes in one place, and the data is in another. For people used to PostgreSQL, I don't think they see how alien it is to people that know how to admin UNIX, but not Postgres. Think about named, sendmail, apache, dhcpd, sshd, etc. All these programs have the notion that he configuration is separate from the working data. To see how they are configured, you just go to the "/etc" or "/etc/pgsql" directory and read the configuration file(s). With postgres, you need to know where, and go to the data directory, as ROOT (or the pg user) because you can't enter it otherwise, look at postgresql.conf, do an "ls -l" to see which parts are symlinked and which are not. If you have multiple PostgreSQL installations, you have to go to each directory and repeat the process. (hyperbole, I know) I just posted a reply to a message from Bruce, and in it I theorized that, maybe, even "sysconfigdir" could point to where postgresql.conf would be located by default. I am not suggesting we change the default behavior of PostgreSQL, I am merely suggesting that adding these features may make it more comfortable for the UNIX admin.
...
> I am not suggesting we change the default behavior of PostgreSQL, I am merely
> suggesting that adding these features may make it more comfortable for the UNIX
> admin.
istm to be a useful addition. Symlinks are not a substitute for a
configurable system, for the reasons Mark brought up.
- Thomas
mlw writes: > > That could be mildly useful, although symlinks make this already possible, > > and a bit clearer, IMHO. > > On systems which support symlinks, yes. All systems that are able to run PostgreSQL support symlinks. Really. > Also, a system should be "self documenting" i.e. one should be able to put > clues to why certain things were done. Symlinks allow one to do something, yes, > but if I leave the company, someone besides me should be able to administrate > the system I leave behind. > > Don't you consider symlinks as a kind of a hack around a basic flaw in the > configuration process? Elsewhere you stated that a certain aspect of the current situation is not very Unix-like. Well, symlinks are very Unix-like. They have been invented exactly for the purpose of sharing files for several purposes, while maintaining the identity of the "original" (else use hard links). They are not hacks, they can be nested and used recursively, they are self-documenting and they don't prevent you from adding your own documentation either. I don't want to be adding a new feature anytime someone doesn't like the tools the operating system already provides. > Shouldn't the configuration file let you completely specify how your > system is configured? Sure, it specifies how the PostgreSQL server behaves. It is not concerned with telling your operating system how to behave. > Think about named, sendmail, apache, dhcpd, sshd, etc. All these programs have > the notion that he configuration is separate from the working data. To see how > they are configured, you just go to the "/etc" or "/etc/pgsql" directory and > read the configuration file(s). named: Configuration and data files are both under /var/named. sendmail: is not a suitable example for a well-designed, easy-to-use software system. apache: Does not easily allow running multiple instances on one host. The virtual host setups I've seen put both configuration and data files under the same per-host directory. Imagine what a mess it would be otherwise. dhcpd, sshd: Only one instance per host supported/necessary. Ironically, if sendmail hadn't the bear it is, my former employer would never have switched to a certain alternative MTA and I would never have gotten the inspiration for creating the postgresql.conf file the way it is today. > With postgres, you need to know where, and go to the data directory, as ROOT > (or the pg user) because you can't enter it otherwise, look at postgresql.conf, Other users don't have a business reading that file. That's a feature. > do an "ls -l" to see which parts are symlinked and which are not. If you have > multiple PostgreSQL installations, you have to go to each directory and repeat > the process. (hyperbole, I know) The alternative is that you have to scan the startup code for each server (where would that be?) and check whether it has the -C option or not or whether it has been overridden somewhere to see which configuration it will end up using. All of this wouldn't be a problem if we only allowed at most one server per host. Then we could standardize on fixed locations for everything. But we do allow and many people do use more than one server instance per host, and there it can be a great mess finding out where everything belongs. Putting everything under one directory by default is undoubtedly the cleanest solution. If you want to spread things around, use the tools that the system gives you. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > > mlw writes: > > > > That could be mildly useful, although symlinks make this already possible, > > > and a bit clearer, IMHO. > > > > On systems which support symlinks, yes. > > All systems that are able to run PostgreSQL support symlinks. > > Really. Windows does not supprt symlinks. > > > Also, a system should be "self documenting" i.e. one should be able to put > > clues to why certain things were done. Symlinks allow one to do something, yes, > > but if I leave the company, someone besides me should be able to administrate > > the system I leave behind. > > > > Don't you consider symlinks as a kind of a hack around a basic flaw in the > > configuration process? > > Elsewhere you stated that a certain aspect of the current situation is not > very Unix-like. Well, symlinks are very Unix-like. They have been > invented exactly for the purpose of sharing files for several purposes, > while maintaining the identity of the "original" (else use hard links). > They are not hacks, they can be nested and used recursively, they are > self-documenting and they don't prevent you from adding your own > documentation either. I don't want to be adding a new feature anytime > someone doesn't like the tools the operating system already provides. This is a bogus argument, you must know that. Do you really beleive this? > > > Shouldn't the configuration file let you completely specify how your > > system is configured? > > Sure, it specifies how the PostgreSQL server behaves. It is not concerned > with telling your operating system how to behave. What are you talking about? I am saying that the configuration file should be able to specify how PostgreSQL works. This has nothing to do with configuring the OS. > > > Think about named, sendmail, apache, dhcpd, sshd, etc. All these programs have > > the notion that he configuration is separate from the working data. To see how > > they are configured, you just go to the "/etc" or "/etc/pgsql" directory and > > read the configuration file(s). > > named: Configuration and data files are both under /var/named. Wrong, named uses named.conf (typically in the /etc directory) to point to where its files are. And named has the "-c" option to specify which config fle to use. > > sendmail: is not a suitable example for a well-designed, easy-to-use > software system. Sendmail works great, it is dificult to configure, sure, but it does work quite well. And yes, sendmail has a "-C" option to use a different configuration fle. > > apache: Does not easily allow running multiple instances on one host. > The virtual host setups I've seen put both configuration and data files > under the same per-host directory. Imagine what a mess it would be > otherwise. Again, wrong. Apache is VERY easy to make run multiple instances. As a server, however, multiple instancs must run on different IP ports. One Apache process can listen on multple ports, or you can use different configuration files to specify how this works. In apache, the option for the configuration file is "-f" > > dhcpd, sshd: Only one instance per host supported/necessary. Ahh, again, wrong. dhcpd can be started to work on all the ethernet interfaces, or run one process for each, dhcpd uses the "-cf" option to specify which configuration file to use. sshd uses the "-f" option to specify which configuration to use, and more than one instance can be run on different ports. > > Ironically, if sendmail hadn't the bear it is, my former employer would > never have switched to a certain alternative MTA and I would never have > gotten the inspiration for creating the postgresql.conf file the way it is > today. The postgresql.conf file is a great start. It should just be more inclusive of configuration details. why not be able to specify the configuration file? Why not be able to specify the hba config file? Why not be able to specify where the data directory is? These are things that UNIX admins EXPECT to be in a configuration file, why NOT put them in? > > > With postgres, you need to know where, and go to the data directory, as ROOT > > (or the pg user) because you can't enter it otherwise, look at postgresql.conf, > > Other users don't have a business reading that file. That's a feature. That's not completely true either. One can take off group all read rights if they want it to be secret, however, securtity through obscurity is stupid and foolish. > > > do an "ls -l" to see which parts are symlinked and which are not. If you have > > multiple PostgreSQL installations, you have to go to each directory and repeat > > the process. (hyperbole, I know) > > The alternative is that you have to scan the startup code for each server > (where would that be?) and check whether it has the -C option or not or > whether it has been overridden somewhere to see which configuration it > will end up using. > > All of this wouldn't be a problem if we only allowed at most one server > per host. Then we could standardize on fixed locations for everything. > But we do allow and many people do use more than one server instance per > host, and there it can be a great mess finding out where everything > belongs. Putting everything under one directory by default is undoubtedly > the cleanest solution. If you want to spread things around, use the tools > that the system gives you. I find your arguments irrational. Why NOT allow postgres to behave as other UNIX server applications? If adding a feature neither hurts performance nor changes the default behavior, but provides more flexability for the admin, why NOT add it. Arguing that "Symlinks" are clean is completely rediculous. There are so many reasons why you DON'T want to use symlinks it is rediculous. Yes symlinks are a tool in UNIX, one of its great features, but I think I speak for most UNIX admins, if they can do something without a symlink, they would prefer to do so. Arguing that PostgreSQL should be limited to one instance per host, putting everything under one directory is he "cleanest" solution is absurd. Again, virtually every other server on UNIX has the notion of a configuration fle outside of its data, why is PostreSQL beter for not having this feature? Why is being different than other UNIX servers beter? Why is NOT having configuration options in the configuration file cleaner?
...
> Isn't it easier to just use symlinks?
Maybe. Sometimes. In some cases. But even in those cases, easier is not
always better.
We've had "the symlink discussion" from time to time in the past. Some
folks are very comfortable with symlinks as part of the PostgreSQL
design model. But I'm *very* uncomfortable with symlinks in that role.
istm that Mark's suggestion for a command line option to specify a
configuration file (hmm, probably one or two more too) is well within
the scope of a reasonable feature for a good user interface. Configuring
a system should not require creating symlinks imho, especially not by
hand.
- Thomas
mlw wrote: > > All systems that are able to run PostgreSQL support symlinks. > > > > Really. > > Windows does not supprt symlinks. Sure it does, windows does not call the symlinks, but it is used by the desktop links and behave the same as you would expect. They are sym-links, and CYGWIN does have symlinks. > Arguing that "Symlinks" are clean is completely rediculous. There are > so many reasons why you DON'T want to use symlinks it is rediculous. > Yes symlinks are a tool in UNIX, one of its great features, but I > think I speak for most UNIX admins, if they can do something without a > symlink, they would prefer to do so. Why? I mean your argument to want a seperate config file is one issue. But I don't see your point here. (I'v done unix admin for over 20 years). Chasing a symlink or finding a config file - both work.
Attachment
On Tuesday 11 December 2001 10:05 am, Thomas Lockhart wrote: > > Isn't it easier to just use symlinks? > Maybe. Sometimes. In some cases. But even in those cases, easier is not > always better. > We've had "the symlink discussion" from time to time in the past. Some > folks are very comfortable with symlinks as part of the PostgreSQL > design model. But I'm *very* uncomfortable with symlinks in that role. I most assuredly agree with Thomas and Mark on this issue. While some are very comfortable with symlinks in this role, I for one am not. I would like postgresql.conf to not live in PGDATA. I would like postgresql.conf to not get overwritten if I have to re-initdb. I would, in fact, like to be able to put several postgresql.conf's, named differently, too, in /etc/pgsql for consistency with things such as BIND, xinetd, sendmail, and virtually any other reasonable daemon. Suppose I host three databases on one box. One database is for a client named varitor, one is for ramifordistat, and one is for wgcr. I would love to have a /etc/pgsql with the three files varitor.conf, ramifordistat.conf, and wgcr.conf. Each config file would be able to specify the datadir (just like a webserver's config file specifies a pageroot, or BIND's named.conf specifies its datadir), as well as other unique config data such as IP address and/or port to bind to. Then, postmaster could be started on these three config files with, perhaps, 'postmaster --config-file=/etc/pgsql/wgcr.conf' and postmaster loads, with the right configuration, without specifying a datadir. To me, this is the natural way to do things. Further, it is easily scripted, as well as easily packaged. And the vast majority of other daemons do it this way. And allowing this way is not the same thing as trying to prevent it from being the existing way -- they can coexist. I just think, Peter, that you're being a mite rigid on this one. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> > Don't you consider symlinks as a kind of a hack around a basic flaw in the > > configuration process? > > Elsewhere you stated that a certain aspect of the current situation is not > very Unix-like. Well, symlinks are very Unix-like. They have been > invented exactly for the purpose of sharing files for several purposes, > while maintaining the identity of the "original" (else use hard links). > They are not hacks, they can be nested and used recursively, they are > self-documenting and they don't prevent you from adding your own > documentation either. I don't want to be adding a new feature anytime > someone doesn't like the tools the operating system already provides. Let me throw in my ideas. Clearly, symlinks work, and clearly, a special -C flag is more documenting than the symlinks. My issue is, should we add yet another configuration flag to an already flag-heavy command and let people use symlinks for special cases, or should we add the flag. I guess the question is whether the option will be used by enough people that the extra flag is worth the added complexity. There is added complexity. Every flag is evaluated by users to determine if the flag is of any use to them, even if they don't use it. I wonder if we should go one step further. Should we be specifying the config file on the command line _rather_ than the data directory. We could then specify the data directory location in the config file. That seems like the direction we should be headed in, though I am not sure it is worth the added headache of the switch. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> -----Original Message----- > From: mlw [mailto:markw@mohawksoft.com] > Sent: 11 December 2001 12:14 > Cc: PostgreSQL-development > Subject: Re: Explicit configuration file > > > > Peter Eisentraut wrote: > > > > mlw writes: > > > > > > That could be mildly useful, although symlinks make > this already > > > > possible, and a bit clearer, IMHO. > > > > > > On systems which support symlinks, yes. > > > > All systems that are able to run PostgreSQL support symlinks. > > > > Really. > > Windows does not supprt symlinks. No, but Cygwin does and that's the environment that PostgreSQL runs in. Other than that, I agree entirely with mlw (sorry Peter :-) ). If /etc/postgresql.conf included settings on the hba.conf file, ident.conf file & data directory (and anything else I've forgotten) to use then a new user could get up and running far quicker, and control every aspect of the server from /etc/postgresql.conf without mucking about with symlinks (which can be very confusing if working on a (convoluted) system setup by someone else and *not* otherwise documented) OR (and I think this is the important bit for a new user) having to modify their environment. More complex/multiple instance systems could easily use a -C, -cf -f or whatever option to specify an alternate config file. Just my 2 pennies worth... Regards, Dave.
Lamar wrote: > > I would like postgresql.conf to not > > get overwritten if I have to re-initdb. This is something I would also like. Bruce wrote: > I wonder if we should go one step further. Should we be specifying the > config file on the command line _rather_ than the data directory. We > could then specify the data directory location in the config file. That > seems like the direction we should be headed in, though I am not sure it > is worth the added headache of the switch. Yes, I vote for a -C switch for postmaster (postmaster -C /etc/postgresql.conf) and inclusion of PGDATA in postgresql.conf . Maybe even a new envvar PGCONFIG that a la long replaces PGDATA. Imho PGDATA does not really have a future anyway with tablespaces coming, and multiple directories where pgdata lives (root on hdisk1, pg_xlog on hdisk2 ...). Andreas
Bruce Momjian <pgman@candle.pha.pa.us> writes: > I wonder if we should go one step further. Should we be specifying the > config file on the command line _rather_ than the data directory. We > could then specify the data directory location in the config file. That > seems like the direction we should be headed in, though I am not sure it > is worth the added headache of the switch. That's what mlw is advocating--all the startup script has to know is the conf file location. I for one think it's totally worth doing, and it won't break any existing setups--if -C (or whatever) isn't specified, postmaster expects PGDATA on the command line and gets the donfig file from there; if it is, PGDATA comes from the config file. -Doug -- Let us cross over the river, and rest under the shade of the trees. --T. J. Jackson, 1863
Bruce Momjian wrote: > I wonder if we should go one step further. Should we be specifying the > config file on the command line _rather_ than the data directory. We > could then specify the data directory location in the config file. That > seems like the direction we should be headed in, though I am not sure it > is worth the added headache of the switch. That is what the patch I submitted does. In the postgresql.conf file, you can specify where the data directory is, as well as the pg_hba.conf file exists. The purpose I had in mind was to allow sharing of pg_hba.conf files and keep configuration separate from data. One huge problem I have with symlinks is an admin has to "notice" that two files in two separate directories, possibly on two different volumes, are the same file, so it is very likely the ramifications of editing one file are not obvious. If, in the database configuration file, pghbaconfig points to "/etc/pg_hba.conf" it is likely, that the global significance of the file is obvious. (Note: I don't nessisarily think "pghbaconfig" nor "pgdatadir" are the best names for the parameters, but I couldn't think of anything else at the time.) Symlinks are a perilous UNIX construct, yes, they make some things, that would otherwise be a horrible kludge, elegant, but they are also no substitute for a properly configurable application.
What about the common file having an entry for each 'instance' set up on the system. It could be formatted something like... Name DataDir ConfFile AutoStart then pg_ctl could be called with an Instance name and start or stop the instance. the initd script could scan the file looking for instances to start automatically. $0.02 mlw wrote: >Bruce Momjian wrote: > >>I wonder if we should go one step further. Should we be specifying the >>config file on the command line _rather_ than the data directory. We >>could then specify the data directory location in the config file. That >>seems like the direction we should be headed in, though I am not sure it >>is worth the added headache of the switch. >> > >That is what the patch I submitted does. > >In the postgresql.conf file, you can specify where the data directory >is, as well as the pg_hba.conf file exists. > >The purpose I had in mind was to allow sharing of pg_hba.conf files and >keep configuration separate from data. > >One huge problem I have with symlinks is an admin has to "notice" that >two files in two separate directories, possibly on two different >volumes, are the same file, so it is very likely the ramifications of >editing one file are not obvious. > >If, in the database configuration file, pghbaconfig points to >"/etc/pg_hba.conf" it is likely, that the global significance of the >file is obvious. > >(Note: I don't nessisarily think "pghbaconfig" nor "pgdatadir" are the >best names for the parameters, but I couldn't think of anything else at >the time.) > >Symlinks are a perilous UNIX construct, yes, they make some things, that >would otherwise be a horrible kludge, elegant, but they are also no >substitute for a properly configurable application. > >---------------------------(end of broadcast)--------------------------- >TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
It certainly can be a slippery slope. Dwayne Miller wrote: > > What about the common file having an entry for each 'instance' set up on > the system. > > It could be formatted something like... > > Name DataDir ConfFile AutoStart > > then pg_ctl could be called with an Instance name and start or stop the > instance. > the initd script could scan the file looking for instances to start > automatically. > > $0.02
On Tue, Dec 11, 2001 at 10:56:27PM -0500, Bruce Momjian wrote: > > My issue is, should we add yet another configuration flag to an already > flag-heavy command and let people use symlinks for special cases, or > should we add the flag. I guess the question is whether the option will > be used by enough people that the extra flag is worth the added > complexity. I can tell you that the Debian (and probably RedHat) packaged binaries would use this switch: It already installs pg_ident.conf, pg_hba.conf, and postgresql.conf in /etc/postgresql, and puts symlinks into the PGDATA dor pointing _back_ there, to keep the server happy. I'd forsee the symlinks just going away. > > There is added complexity. Every flag is evaluated by users to > determine if the flag is of any use to them, even if they don't use it. Most users never look at _any_ of the flags. Most users who _compile there own_ read the man page and evaluate the flags, I agree. > I wonder if we should go one step further. Should we be specifying the > config file on the command line _rather_ than the data directory. We > could then specify the data directory location in the config file. That > seems like the direction we should be headed in, though I am not sure it > is worth the added headache of the switch. Seems that's what's actually ben proposed, but in a backwards compatible way. Ross
mlw writes: > One huge problem I have with symlinks is an admin has to "notice" that > two files in two separate directories, possibly on two different > volumes, are the same file, so it is very likely the ramifications of > editing one file are not obvious. > > If, in the database configuration file, pghbaconfig points to > "/etc/pg_hba.conf" it is likely, that the global significance of the > file is obvious. How about making the "local" pg_hba.conf symlinked to /etc/pg_hba.conf? Should be the same, no? I guess I'm losing the symlink debate, but anyway... Consider this: What if I want to share my postgresql.conf file (because of the clever performance tuning) but not my pg_hba.conf file (because I have completely different databases and users in each server). I think that case should be covered as long as we're moving in this direction. I think looming in the back is the answer, "add an 'include' directive to postgresql.conf". -- Peter Eisentraut peter_e@gmx.net
Zeugswetter Andreas SB SD writes: > Imho PGDATA does not really have a future anyway with tablespaces coming, > and multiple directories where pgdata lives (root on hdisk1, pg_xlog on > hdisk2 ...). Probably true. The question is where the table space setup is going to be configured. (Some of it will be done within the system catalogs, but the log directories, etc. need to be configured externally.) If the answer is postgresql.conf then I don't think that's a good idea because it would make it impossible to use the same postgresql.conf for multiple servers. I guess that's impossible already because the port is configured there, but it *should* be possible, because else why would you want to have it in a global location. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > > mlw writes: > > > One huge problem I have with symlinks is an admin has to "notice" that > > two files in two separate directories, possibly on two different > > volumes, are the same file, so it is very likely the ramifications of > > editing one file are not obvious. > > > > If, in the database configuration file, pghbaconfig points to > > "/etc/pg_hba.conf" it is likely, that the global significance of the > > file is obvious. > > How about making the "local" pg_hba.conf symlinked to /etc/pg_hba.conf? > Should be the same, no? > > I guess I'm losing the symlink debate, but anyway... > > Consider this: What if I want to share my postgresql.conf file (because > of the clever performance tuning) but not my pg_hba.conf file (because I > have completely different databases and users in each server). I think > that case should be covered as long as we're moving in this direction. In my patch, if no pghbaconfig setting is made, then the default is to look in the data directory, as it has always done. If no pgdatadir is specified, then it will get the information the old way too. postmaster -C mysuperconfig.conf -D /u01/db Should work fine. > > I think looming in the back is the answer, "add an 'include' directive to > postgresql.conf". Yikes. Obviously that is next, however do we need this functionality? Will a few changes be enough, or do we need includes? Do we need includes within includes?
> Bruce Momjian wrote: > > > I wonder if we should go one step further. Should we be specifying the > > config file on the command line _rather_ than the data directory. We > > could then specify the data directory location in the config file. That > > seems like the direction we should be headed in, though I am not sure it > > is worth the added headache of the switch. > > That is what the patch I submitted does. > > In the postgresql.conf file, you can specify where the data directory > is, as well as the pg_hba.conf file exists. > > The purpose I had in mind was to allow sharing of pg_hba.conf files and > keep configuration separate from data. My issue is that once we put the data directory location in postgresql.conf, we can't share that with other installs because they need different data locations, so what have we really gained _except_ having the *.conf file in a different location. Seems any solution will need to allow the *.conf file itself to be shared. Here is an idea. Allow multiple -C parameters to be used, with the files read in order, with newer parameters overriding older ones. Seems this would be better than #includes. Now that I think of it, #include does the same thing. Instead of multiple -C, we have one file per instance and #include the global one, then set whatever we want. One major thing this does that _symlinks_ do not do is allow most parameters to be set globally for postgresql.conf, and for individual instances to override _part_ of the global file. Sorry I did not read the patch earlier. I was more responding to the emails. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > > > Bruce Momjian wrote: > > > > > I wonder if we should go one step further. Should we be specifying the > > > config file on the command line _rather_ than the data directory. We > > > could then specify the data directory location in the config file. That > > > seems like the direction we should be headed in, though I am not sure it > > > is worth the added headache of the switch. > > > > That is what the patch I submitted does. > > > > In the postgresql.conf file, you can specify where the data directory > > is, as well as the pg_hba.conf file exists. > > > > The purpose I had in mind was to allow sharing of pg_hba.conf files and > > keep configuration separate from data. > > My issue is that once we put the data directory location in > postgresql.conf, we can't share that with other installs because they > need different data locations, so what have we really gained _except_ > having the *.conf file in a different location. > > Seems any solution will need to allow the *.conf file itself to be > shared. > > Here is an idea. Allow multiple -C parameters to be used, with the > files read in order, with newer parameters overriding older ones. Seems > this would be better than #includes. > > Now that I think of it, #include does the same thing. Instead of > multiple -C, we have one file per instance and #include the global one, > then set whatever we want. > > One major thing this does that _symlinks_ do not do is allow most > parameters to be set globally for postgresql.conf, and for individual > instances to override _part_ of the global file. > > Sorry I did not read the patch earlier. I was more responding to the > emails. There is no reason that: postmaster -C /path/postgresql.conf -D /u01/mydb Would not work. (Just don't specify a data diectory)