Обсуждение: 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.

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)