Обсуждение: Explicit config patch 7.2B4

I guess I will maintain this for people who want it.

This allows

postmaster -C /etc/pgsql/mydb.conf

The "-C" option specifies a configuration file.

In the config file there are two more options:

datadir = '/u01/postgres'
hbaconfig = '/etc/pgsql/pg_hba.conf'

The "datadir" option specifies where the postgresql data directory resides. (My
original patch used the setting "pgdatadir" in which the "pg" seemed
redundant.)

The "hbaconfig" specifies where postgresql will look for the pg_hba.conf file.

If the "-D" option is specified on the command line, it overides the "datadir"
option in the config file. (This is a different behavior than my original
patch)

If No "datadir" is specified, it must be specified either on the command line
or the normal PGDATA environment variable.

If no "hbaconfig" setting is set, the it will look for pg_hba.config in the
data directory as always.

One can start many databases with the same settings as:

postmaster -C /path/default.conf -p 5432 -D /path/name1
postmaster -C /path/default.conf -p 5433 -D /path/name2
postmaster -C /path/default.conf -p 5434 -D /path/name3diff -r -u postgresql-7.2b4/src/backend/libpq/hba.c
postgresql-7.2b4_config/src/backend/libpq/hba.c
--- postgresql-7.2b4/src/backend/libpq/hba.c    Sun Nov 11 23:29:23 2001
+++ postgresql-7.2b4_config/src/backend/libpq/hba.c    Sun Dec 16 08:27:06 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.2b4/src/backend/postmaster/postmaster.c
postgresql-7.2b4_config/src/backend/postmaster/postmaster.c
--- postgresql-7.2b4/src/backend/postmaster/postmaster.c    Tue Dec  4 11:17:48 2001
+++ postgresql-7.2b4_config/src/backend/postmaster/postmaster.c    Sun Dec 16 09:14:30 2001
@@ -419,10 +419,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;
@@ -444,10 +447,24 @@
         ExitPostmaster(1);
     }

-    checkDataDir(potential_DataDir);    /* issues error messages */
-    SetDataDir(potential_DataDir);
+    if(explicit_pgconfig)
+    {
+        /* Allow command line option to overide config file. */
+        ProcessConfigFile(PGC_POSTMASTER);
+
+        if(!potential_DataDir  && pgdatadir)
+            potential_DataDir = pgdatadir;
+
+        checkDataDir(potential_DataDir);
+        SetDataDir(potential_DataDir);
+    }
+    else
+    {
+        checkDataDir(potential_DataDir);    /* issues error messages */
+        SetDataDir(potential_DataDir);

-    ProcessConfigFile(PGC_POSTMASTER);
+        ProcessConfigFile(PGC_POSTMASTER);
+    }

     IgnoreSystemIndexes(false);

@@ -457,7 +474,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)
         {
@@ -477,6 +494,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;
Only in postgresql-7.2b4_config/src/backend/postmaster: postmaster.c.orig
diff -r -u postgresql-7.2b4/src/backend/utils/misc/guc-file.c postgresql-7.2b4_config/src/backend/utils/misc/guc-file.c
--- postgresql-7.2b4/src/backend/utils/misc/guc-file.c    Wed Dec 12 08:33:26 2001
+++ postgresql-7.2b4_config/src/backend/utils/misc/guc-file.c    Sun Dec 16 08:33:32 2001
@@ -1682,16 +1682,29 @@
     Assert(DataDir);
     elevel = (context == PGC_SIGHUP) ? DEBUG : ERROR;

-    /*
-     * Open file
-     */
-    filename = malloc(strlen(DataDir) + strlen(CONFIG_FILENAME) + 2);
+    /* Added for explicit config file */
+    if(!explicit_pgconfig)
+    {
+        /*
+         * Use environmental config
+         */
+        filename = malloc(strlen(DataDir) + strlen(CONFIG_FILENAME) + 2);
+        sprintf(filename, "%s/" CONFIG_FILENAME, DataDir);
+    }
+    else
+    {
+        /*
+         * Use explicit file
+         */
+        filename = strdup(explicit_pgconfig);
+    }
+
     if (filename == NULL)
     {
         elog(elevel, "out of memory");
         return;
     }
-    sprintf(filename, "%s/" CONFIG_FILENAME, DataDir);
+

     fp = AllocateFile(filename, "r");
     if (!fp)
diff -r -u postgresql-7.2b4/src/backend/utils/misc/guc.c postgresql-7.2b4_config/src/backend/utils/misc/guc.c
--- postgresql-7.2b4/src/backend/utils/misc/guc.c    Tue Oct 30 00:38:56 2001
+++ postgresql-7.2b4_config/src/backend/utils/misc/guc.c    Sun Dec 16 08:34:17 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
+    },
+    {
+        "datadir", PGC_POSTMASTER, &pgdatadir,
+        "", NULL, NULL
+    },
     {
         NULL, 0, NULL, NULL, NULL, NULL
     }
diff -r -u postgresql-7.2b4/src/backend/utils/misc/postgresql.conf.sample
postgresql-7.2b4_config/src/backend/utils/misc/postgresql.conf.sample
--- postgresql-7.2b4/src/backend/utils/misc/postgresql.conf.sample    Sun Sep 30 14:57:45 2001
+++ postgresql-7.2b4_config/src/backend/utils/misc/postgresql.conf.sample    Sun Dec 16 08:34:38 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.
+# datadir = '/u01/postgres'

 #
 #    Connection Parameters
diff -r -u postgresql-7.2b4/src/include/utils/guc.h postgresql-7.2b4_config/src/include/utils/guc.h
--- postgresql-7.2b4/src/include/utils/guc.h    Mon Nov  5 12:46:36 2001
+++ postgresql-7.2b4_config/src/include/utils/guc.h    Sun Dec 16 08:27:06 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 */

mlw <markw@mohawksoft.com> writes:

> I guess I will maintain this for people who want it.

I'd definitely encourage you to try to get it into 7.3 when that
opens--the list seems to be generally positive about it, and as long
as existing setups work as-is (which seems to be the case) I think
it's a valuable addition.

-Doug
-- 
Let us cross over the river, and rest under the shade of the trees.  --T. J. Jackson, 1863

On Sun, Dec 16, 2001 at 09:35:58AM -0500, mlw wrote:
> This allows
> 
> postmaster -C /etc/pgsql/mydb.conf

Nice.

> In the config file there are two more options:
> 
> datadir = '/u01/postgres'
> hbaconfig = '/etc/pgsql/pg_hba.conf'

What about pg_ident.conf?

-- 
marko

mlw writes:

> This allows
>
> postmaster -C /etc/pgsql/mydb.conf
>
> The "-C" option specifies a configuration file.

I'm still not happy about this, because given a pre-configured or already
running system it is difficult or impossible to find out which
configuration file is being used.  This offsets in many ways the improved
usability you're trying to achieve.

I think an 'include' directive for postgresql.conf would solve this
problem more generally (since it allows many more sharing models) and
would also give us a good tool when we get to the configuration of
alternative storage locations.

Probably a command-line option could prove useful for testing purposes,
etc., but I feel that by default the configuration should be written down
in some easy-to-find file.  This is consistent with the move away from
command-line options that we have made with postgresql.conf.

Probably we could make the option -C to mean "imagine an include directive
written at the very start [or end?] of $PGDATA/postgresql.conf".  With the
default empty file this would achieve exactly the same thing as you're
trying.

Comments?

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut wrote:
> 
> mlw writes:
> 
> > This allows
> >
> > postmaster -C /etc/pgsql/mydb.conf
> >
> > The "-C" option specifies a configuration file.
> 
> I'm still not happy about this, because given a pre-configured or already
> running system it is difficult or impossible to find out which
> configuration file is being used.  This offsets in many ways the improved
> usability you're trying to achieve.

I do not agree. A command line option which points to a configuration file IS
the standard way to start a server under UNIX.

> 
> I think an 'include' directive for postgresql.conf would solve this
> problem more generally (since it allows many more sharing models) and
> would also give us a good tool when we get to the configuration of
> alternative storage locations.

An include directive would be useful, obviously, but it is not in exclusion of
a more flexible configuration file.

> 
> Probably a command-line option could prove useful for testing purposes,
> etc., but I feel that by default the configuration should be written down
> in some easy-to-find file.  This is consistent with the move away from
> command-line options that we have made with postgresql.conf.

I am having the hardest time understanding your antipathy toward an explicit
configuration file. I just don't have any idea of why you are fighting it so
hardly. As far as I can see there is no reason not to do it, and every other
important server on UNIX supports this construct.

Again, I just don't get it. Standards are standards, and an explicit
configuration file is a defacto standard.

> 
> Probably we could make the option -C to mean "imagine an include directive
> written at the very start [or end?] of $PGDATA/postgresql.conf".  With the
> default empty file this would achieve exactly the same thing as you're
> trying.

The WHOLE idea is to get away from a configuration file mixed with the data. I
think the notion of having configuration contained in the same location as data
is bad. Furthermore, forcing this construct is worse.
> 
> Comments?

I really don't understand why you don't want this. There isn't a single
important UNIX server which forces its configuration file to be contained
within its data / operational directory. Not one. Why is postgresql "better"
for being less flexible?

What is the harm in including this functionality?

On Sunday 16 December 2001 05:23 pm, Peter Eisentraut wrote:
> I'm still not happy about this, because given a pre-configured or already
> running system it is difficult or impossible to find out which
> configuration file is being used.  This offsets in many ways the improved
> usability you're trying to achieve.

Would -C and its argument not be written to $PGDATA/postmaster.opts if 
started with pg_ctl?  I've not looked at the patch directly, but it would be 
regular behaviour for that to show up, right?  If it's in postmaster.opts, 
then it's trivial to examine and determin where things are coming from.

> I think an 'include' directive for postgresql.conf would solve this
> problem more generally (since it allows many more sharing models) and
> would also give us a good tool when we get to the configuration of
> alternative storage locations.

I like an include directive.  But not for the reasons you like it.

> Probably we could make the option -C to mean "imagine an include directive
> written at the very start [or end?] of $PGDATA/postgresql.conf".  With the
> default empty file this would achieve exactly the same thing as you're
> trying.

No -- he's trying to get the config out of $PGDATA.  The config 
_does_not_belong_with_the_data_.  While it _could_ be put there if the admin 
chooses, it should not be tied to $PGDATA.

I'll have to echo Mark's query, though: Why are you fighting this, Peter?  
This functionality mirrors the standard behaviour for daemons.  Name a 
standard daemon package other than postgresql that automatically assumes the 
config is with dynamic data, and overwrites an existing config when the 
dynamic data area is reinitialized.

I'm willing to compromise to a degree on this issue.  However, Mark already 
has working code.  Sounds like a candidate for a patch -- maybe even a 
feature patch.  And I'll admit to some desire to apply this patch for the 
RPMset -- but I probably won't, as the RPMset shouldn't do anything that 
drastic.  However, it wouldn't surprize me  in the least for a distributor 
such as Red Hat to apply this patch.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar.owen@wgcr.org> writes:
> I'll have to echo Mark's query, though: Why are you fighting this, Peter?  

Peter's not the only one who's unhappy.

> This functionality mirrors the standard behaviour for daemons.

That's been Mark's primary argument all along, and what it ignores is
that the standard behavior for daemons is designed around the assumption
that a system is running only one copy of any given daemon.  That's a
fine assumption for most daemons but an unacceptable one for Postgres.

I'm prepared to accept some kind of compromise on this issue, but I'm
really tired of hearing the useless "other daemons do it this way"
argument.  Could we hear some more-relevant argument?

I rather liked Peter's idea of treating the feature as an implicit
inclusion.  Maybe there's an even-better approach out there, but so far
that's the best idea I've heard.

> Name a standard daemon package other than postgresql that
> automatically assumes the config is with dynamic data, and overwrites
> an existing config when the dynamic data area is reinitialized.

initdb will not overwrite an existing config.  Try it.

> However, it wouldn't surprize me  in the least for a distributor 
> such as Red Hat to apply this patch.

Oh, I doubt it...
        regards, tom lane        Red Hat Database project

Tom Lane <tgl@sss.pgh.pa.us> writes:

> That's been Mark's primary argument all along, and what it ignores is
> that the standard behavior for daemons is designed around the assumption
> that a system is running only one copy of any given daemon.  That's a
> fine assumption for most daemons but an unacceptable one for Postgres.

I'd say that's not completely accurate.  I've seen and run sites with
more than one {httpd, sendmail} running.  The basic idea is:

* If no config file is specified, either look for it in a standard place, or complain bitterly.  Sendmail looks for
/etc/sendmail.cf(usually); Apache looks in a place configured at compile time (/etc/httpd/conf/httpd.conf on RedHat
systems).

* If a config file *is* specified, use it.  It tells you where to look  for other stuff (queue directory, webserver
rootor whatever).
 

The above scheme is used by many different daemons and is *perfectly*
conducive to running multiple copies.  What makes you say it isn't?

> I'm prepared to accept some kind of compromise on this issue, but I'm
> really tired of hearing the useless "other daemons do it this way"
> argument.  Could we hear some more-relevant argument?

How is a patch that (a) perfectly preserves existing behavior, and (b) 
allows for more flexibility in configuration, a bad thing?

I'm not going to lose a lot of sleep if Mark's patch isn't adopted.  I
will say, however, that as a long-time Un*x sysadmin (Ultrix, Irix,
Solaris, BSD, Linux) PG's method of configuration struck me as a bit
weird when I first saw it.  It obviously does the job, but I like the
idea of giving users and packagers a configuration method that's still
sufficiently flexible and is more familiar to some.

My $0.02...

-Doug
-- 
Let us cross over the river, and rest under the shade of the trees.  --T. J. Jackson, 1863

Tom Lane wrote:
> 
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > I'll have to echo Mark's query, though: Why are you fighting this, Peter?
> 
> Peter's not the only one who's unhappy.

I still do not understand why.

> 
> > This functionality mirrors the standard behaviour for daemons.
> 
> That's been Mark's primary argument all along, and what it ignores is
> that the standard behavior for daemons is designed around the assumption
> that a system is running only one copy of any given daemon.  That's a
> fine assumption for most daemons but an unacceptable one for Postgres.

It makes NO such argument at all! It allows an admin to explicitly share a
configuration file (or not). I allows for one central place in which multiple
configuration files can be stored and backed up. It allows for the explicit
sharing of pg_hba.conf files. (It was noted that pg_ident.conf should be added,
I am looking at it.)

Most of all it does these things WITHOUT symlinks. Most admins I know like
symlinks as a method of working around a short coming in a product, but would
rather have the configurability designed into the product.

I wrote this patch to make it easier for me to administer multiple databases on
one machine. To make it easier for UNIX admins to follow the dba's trail. I
wrote this so a system was a bit more self documenting without having to follow
symlinks.

> 
> I'm prepared to accept some kind of compromise on this issue, but I'm
> really tired of hearing the useless "other daemons do it this way"
> argument.  Could we hear some more-relevant argument?

This something else I don't understand. Why would you NOT give an admin the
sort of configurability they expect?

> 
> I rather liked Peter's idea of treating the feature as an implicit
> inclusion.  Maybe there's an even-better approach out there, but so far
> that's the best idea I've heard.

In my eyes, "implicit" means unexpected. I love the idea of an include
directive, that is a great idea, but it does not address the separation of data
and config.

People new to PostgreSQL will look for he config in /usr/local/pgsql/etc, but
it won't be there. You can specify the config directory with configure
(sysconfdir), but it is never used.

> 
> > Name a standard daemon package other than postgresql that
> > automatically assumes the config is with dynamic data, and overwrites
> > an existing config when the dynamic data area is reinitialized.
> 
> initdb will not overwrite an existing config.  Try it.

That's good to know.

> 
> > However, it wouldn't surprize me  in the least for a distributor
> > such as Red Hat to apply this patch.
> 
> Oh, I doubt it...

Tom, I really don't understand the resistance. It seem irrational to me, and I
am really trying to figure it out.

Obviously you must have your reasons, but all I've read thus far is the
argument that "PostgreSQL is different than other daemons." Maybe I'm pushing
too hard for this and making people defensive, but I just don't get it.

The core reasons for this patch:
(1) Move configuration out of $PGDATA and into some centralized location. I do
not know of a single admin that would object to this.
(2) Allow admins to share the pg_hba.conf file.

I try to get pg_ident when I get a chance, that's a good idea.

The one thing about this I do not like is that it is a "share all" or "share
none" solution. An include directive would be helpful here, but I think it is a
good start.

Tom Lane <tgl@sss.pgh.pa.us> writes:

> That's been Mark's primary argument all along, and what it ignores is
> that the standard behavior for daemons is designed around the assumption
> that a system is running only one copy of any given daemon.  That's a
> fine assumption for most daemons but an unacceptable one for Postgres.

I don't think there would be that much problems with it, but you can
always have defaults in one location and allow them to be overridable.

> > However, it wouldn't surprize me  in the least for a distributor 
> > such as Red Hat to apply this patch.
> 
> Oh, I doubt it...
> 
>             regards, tom lane
>             Red Hat Database project

Don't. I'd do it in a heartbeat - I'd love to have /etc/postgresql/
with defaults. Configuration files should not be located in /var.

regards, Trond Eivind Glomsrød
developer, Red Hat Linux developer
-- 
Trond Eivind Glomsrød
Red Hat, Inc.

On Mon, 2001-12-17 at 12:22, mlw wrote:
> > That's been Mark's primary argument all along, and what it ignores is
> > that the standard behavior for daemons is designed around the assumption
> > that a system is running only one copy of any given daemon.  That's a
> > fine assumption for most daemons but an unacceptable one for Postgres.
>
> It makes NO such argument at all! It allows an admin to explicitly share a
> configuration file (or not). I allows for one central place in which multiple
> configuration files can be stored and backed up. It allows for the explicit
> sharing of pg_hba.conf files. (It was noted that pg_ident.conf should be added,
> I am looking at it.)
>
> Most of all it does these things WITHOUT symlinks. Most admins I know like
> symlinks as a method of working around a short coming in a product, but would
> rather have the configurability designed into the product.
>
> I wrote this patch to make it easier for me to administer multiple databases on
> one machine. To make it easier for UNIX admins to follow the dba's trail. I
> wrote this so a system was a bit more self documenting without having to follow
> symlinks.

As Debian packager I would very much like to see a more convenient and
controllable configuration system.

Ross described last week the Debian method of symlinking the real config
files in /etc/postgresql to $PGDATA/; this method is forced on us by
Debian policy, which requires that all config files be in /etc.  The
undesired result is that it is not convenient to run multiple servers on
a single machine using the Debian package.

I am currently considering a method of getting round this by creating a
subdirectory of /etc/postgresql for each server instance, but it would
be nice to be able to share global options in more convenient ways than
by multiplying symlinks.

--
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
    "For I say, through the grace given unto me, to every      man that is among you: Do not think of yourself more
highly than you ought, but rather think of yourself      with sober judgement, in accordance with the measure      of
faithGod has given you."            Romans 12:3  

On Sunday 16 December 2001 11:13 pm, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > This functionality mirrors the standard behaviour for daemons.

> That's been Mark's primary argument all along, and what it ignores is
> that the standard behavior for daemons is designed around the assumption
> that a system is running only one copy of any given daemon.  That's a
> fine assumption for most daemons but an unacceptable one for Postgres.

Really?  Most daemons allow a default config location, and then either allow 
or require a config file path on the command line.  AOLserver _requires_ the 
path on the command line; named allows it, sendmail allows it, etc.

I routinely run multiple nameds on machines behind NAT.  Just a simple config 
file path away.  I routinely run multiple instances of other programs as well.

Note that neither I, Mark, Doug, or anyone else is asking for a change in the 
default behavior.  I personally just want it to be _allowed_ behavior.  
Nothing more; nothing less.

> I rather liked Peter's idea of treating the feature as an implicit
> inclusion.  Maybe there's an even-better approach out there, but so far
> that's the best idea I've heard.

I rather dislike the idea that $PGDATA is where the config file lives.  I 
quite particularly dislike the 'implicit include' idea.

> > Name a standard daemon package other than postgresql that
> > automatically assumes the config is with dynamic data, and overwrites
> > an existing config when the dynamic data area is reinitialized.

> initdb will not overwrite an existing config.  Try it.

Ok, I'll concede that.  But having postgresql.conf in $PGDATA makes it more 
difficult for an admin to wipe $PGDATA and start over.  For that matter, 
pg_hba.conf is there, too, and I disagree that users should be forced to put 
it in $PGDATA.

> > However, it wouldn't surprize me  in the least for a distributor
> > such as Red Hat to apply this patch.

> Oh, I doubt it...

>             regards, tom lane
>             Red Hat Database project

Having seen Trond's reply, I have to laugh....as I _know_ he disagrees with 
you (and knew such before he replied -- this has been a thorn in his side for 
awhile.  Might prove to be an interesting 'discussion' inside RH over it.  
But, again, an 'optional' command line switch should be a no-brainer.  It 
just seems to me to be rather unproductive to not allow people more 
flexibility in a regular way.  Symlinks are not the answer, either.

But RH is not the only distributor of PostgreSQL. And, for the record, the 
Debian packages already do something very similar.  Wouldn't it be better for 
the core package to support this, rather than each distributor doing it 
differently from each other?
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Marko Kreen wrote:
> 
> On Sun, Dec 16, 2001 at 09:35:58AM -0500, mlw wrote:
> > This allows
> >
> > postmaster -C /etc/pgsql/mydb.conf
> 
> Nice.
> 
> > In the config file there are two more options:
> >
> > datadir = '/u01/postgres'
> > hbaconfig = '/etc/pgsql/pg_hba.conf'
> 
> What about pg_ident.conf?

I will submit a complete patch that includes pg_ident.conf as well.

Here is a question for the great minds here:

If a user has used the "-C" option, as in:

postmaster -C /etc/pgsql/mydb.conf

Should I then, and first, see if there is a "/etc/pgsql/pg_hba.conf" or
"/etc/pgsql/pg_ident.conf" and use it as an explicit path?


How about:

postmaster -C /etc/pgsql

Should I then look for:

/etc/pgsql/postgresql.conf
/etc/pgsql/pg_hba.conf
/etc/pgsql/pg_ident.conf

?

Just curious what you think.

On Monday 17 December 2001 12:56 pm, mlw wrote:
> Here is a question for the great minds here:
> If a user has used the "-C" option, as in:

> postmaster -C /etc/pgsql/mydb.conf

> Should I then, and first, see if there is a "/etc/pgsql/pg_hba.conf" or
> "/etc/pgsql/pg_ident.conf" and use it as an explicit path?

> How about:
> postmaster -C /etc/pgsql

I agree to both; of course, this should be overrideable in the conf file.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

I was looking around, and for this to be a good patch, I have to add it
to "postgres" as well as "postmaster."


In the 7.1.3 source, there is a command line option "-C" (don't show
version number) which seems to have been depricated in 7.1.x (no longer
documented, but still active.)

Is is "-C" dangerous at this stage? Should I use another command line
option?

Trond Eivind Glomsrød writes:

> Don't. I'd do it in a heartbeat - I'd love to have /etc/postgresql/
> with defaults. Configuration files should not be located in /var.

This problem has already been solved with symlinks a long time ago.
Nothing new here.  In fact, for users that are accustomed to the
"original" source distribution it'd be a much easier-to-understand
approach.  (Whether it's "better" in the general sense is being
discussed.)

-- 
Peter Eisentraut   peter_e@gmx.net

On Monday 17 December 2001 03:58 pm, Peter Eisentraut wrote:
> Trond Eivind Glomsrød writes:
> > Don't. I'd do it in a heartbeat - I'd love to have /etc/postgresql/
> > with defaults. Configuration files should not be located in /var.

> This problem has already been solved with symlinks a long time ago.
> Nothing new here.

Using symlinks is a workaround, not a solution.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

mlw writes:

> Is is "-C" dangerous at this stage? Should I use another command line
> option?

Use -C and eliminate/ignore the other use.

-- 
Peter Eisentraut   peter_e@gmx.net

On Mon, Dec 17, 2001 at 12:56:53PM -0500, mlw wrote:
> Marko Kreen wrote:
> > On Sun, Dec 16, 2001 at 09:35:58AM -0500, mlw wrote:
> > > In the config file there are two more options:
> > >
> > > datadir = '/u01/postgres'
> > > hbaconfig = '/etc/pgsql/pg_hba.conf'

> I will submit a complete patch that includes pg_ident.conf as well.
> 
> Here is a question for the great minds here:
> 
> If a user has used the "-C" option, as in:
> 
> postmaster -C /etc/pgsql/mydb.conf
> 
> Should I then, and first, see if there is a "/etc/pgsql/pg_hba.conf" or
> "/etc/pgsql/pg_ident.conf" and use it as an explicit path?

It should search them only if they are not mentioned in .conf, I
guess.

> How about:
> 
> postmaster -C /etc/pgsql
> 
> Should I then look for:
> 
> /etc/pgsql/postgresql.conf
> /etc/pgsql/pg_hba.conf
> /etc/pgsql/pg_ident.conf

One suggestion to you: try to think how different approaches
look when documented.  User must be able to predict program
behaviour only by looking at docs.  If 3 lines of C add
2 messy paragraphs to docs, then it is probably unnecessary
'feature'.  Also what if I say '-C /etc/pgsql/db.conf' and there 
is no pg_hba.conf there.  It should give error, not go secretly
searching it in $PGDATA.

-- 
marko

mlw writes:

> If a user has used the "-C" option, as in:
>
> postmaster -C /etc/pgsql/mydb.conf
>
> Should I then, and first, see if there is a "/etc/pgsql/pg_hba.conf" or
> "/etc/pgsql/pg_ident.conf" and use it as an explicit path?

> How about:
>
> postmaster -C /etc/pgsql
>
> Should I then look for:
>
> /etc/pgsql/postgresql.conf
> /etc/pgsql/pg_hba.conf
> /etc/pgsql/pg_ident.conf

I like the latter better because of the symmetry of -C with -D.

Btw., the following issues still need to be addressed:

- Location of SSL certificate files (Are they appropriate for /etc?  What does Apache do?)

- Location of secondary password files.  By default they should probably track pg_hba.conf.  Is that enough?

- Location of charset.conf and the associated recode tables

For a start, putting all of these under -C is probably sufficient.  More
complicated setups can be achieved using symlinks. ;-)

-- 
Peter Eisentraut   peter_e@gmx.net

On Tue, 2001-12-18 at 17:24, Peter Eisentraut wrote:
> - Location of SSL certificate files (Are they appropriate for /etc?  What
>   does Apache do?)

Using Apache and modssl under debian linux, the certs live in
/etc/apache.  Similarly, crypto keys for Nessus live in /etc/nessusd.
So /etc/postgresql would be reasonable.

--
Andrew G. Hammond     mailto:drew@xyzzy.dhs.org
http://xyzzy.dhs.org/~drew/
56 2A 54 EF 19 C0 3B 43 72 69 5B E3 69 5B A1 1F
613-389-5481
5CD3 62B0 254B DEB1 86E0  8959 093E F70A B457 84B1
"To blow recursion you must first blow recur" -- me

> Using Apache and modssl under debian linux, the certs live in
> /etc/apache.  Similarly, crypto keys for Nessus live in /etc/nessusd.
> So /etc/postgresql would be reasonable.

Just a note from a FreeBSD (ie. a decent filesystem standard layout) it
horrifies me to see post-install packages put stuff in /etc/.  Of course,
whomever writes the FreeBSD port will override this default and put it in
/usr/local/etc/pgsql.

Chris

On Wed, 19 Dec 2001, Christopher Kings-Lynne wrote:

> > Using Apache and modssl under debian linux, the certs live in
> > /etc/apache.  Similarly, crypto keys for Nessus live in /etc/nessusd.
> > So /etc/postgresql would be reasonable.
>
> Just a note from a FreeBSD (ie. a decent filesystem standard layout) it
> horrifies me to see post-install packages put stuff in /etc/.  Of course,
> whomever writes the FreeBSD port will override this default and put it in
> /usr/local/etc/pgsql.

Which is why I avoid rpm, deb, package, etc.  The support nightmare it
causes when vendors start upchucking various bits and pieces of the
program all over the drive.  Then the poor user tries explaining what
he did or tried to do in /var, /etc, /opt and a bunch of other places
(up to and not necessarily excluding the trunk of the car) and figuring
out something as simple as where a certain file is so the permissions
can be verified or where the include files and libraries happen to be
hiding.

No, this is not an invite for the discussion of whether or not vendors
should or should not scatter files all over the filesystem.  It's only
a statement of what it causes on the support end - no, not all people
contact the vendor of the os when they have a problem with a program.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking       Online Campground Directory    http://www.camping-usa.com      Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================

On Tue, 2001-12-18 at 22:27, Vince Vielhaber wrote:
> On Wed, 19 Dec 2001, Christopher Kings-Lynne wrote:
>
> > > Using Apache and modssl under debian linux, the certs live in
> > > /etc/apache.  Similarly, crypto keys for Nessus live in /etc/nessusd.
> > > So /etc/postgresql would be reasonable.
> >
> > Just a note from a FreeBSD (ie. a decent filesystem standard layout) it
> > horrifies me to see post-install packages put stuff in /etc/.  Of course,
> > whomever writes the FreeBSD port will override this default and put it in
> > /usr/local/etc/pgsql.
>
> Which is why I avoid rpm, deb, package, etc.  The support nightmare it
> causes when vendors start upchucking various bits and pieces of the
> program all over the drive.  Then the poor user tries explaining what
> he did or tried to do in /var, /etc, /opt and a bunch of other places
> (up to and not necessarily excluding the trunk of the car) and figuring
> out something as simple as where a certain file is so the permissions
> can be verified or where the include files and libraries happen to be
> hiding.
>
> No, this is not an invite for the discussion of whether or not vendors
> should or should not scatter files all over the filesystem.  It's only
> a statement of what it causes on the support end - no, not all people
> contact the vendor of the os when they have a problem with a program.

Funny, I have exactly the same opinion about stuff scattered all over
the filesystem, but that's one of the reasons I like debian. They don't
scatter stuff, they organize it.  And, at least to me things make sense
that way.  Config files are under /etc.  All of them.  For every
package.

Since it's utterly impossible to get a whole bunch of different people
to agree about where stuff belongs, or even to have a rational
discussion on the topic, having the distros impose this sort of thing by
fiat seems to be the only way to get any kind of consistency at all.

Honestly, I really don't give a damn what filesystem layout I end up
using, as long as it's reasonably simple and logical.

However I will say that personally, I like having a path that's less
than a gigabyte.  Debian delivers that for me.  But hey, to each their
own.

ObFlame: BSD sux.  That little devil looks kinda fruity to me, and I'll
bet Tux could whup his ass.

--
Andrew G. Hammond     mailto:drew@xyzzy.dhs.org
http://xyzzy.dhs.org/~drew/
56 2A 54 EF 19 C0 3B 43 72 69 5B E3 69 5B A1 1F
613-389-5481
5CD3 62B0 254B DEB1 86E0  8959 093E F70A B457 84B1
"To blow recursion you must first blow recur" -- me

On 19 Dec 2001, Andrew G. Hammond wrote:

> ObFlame: BSD sux.  That little devil looks kinda fruity to me, and I'll
> bet Tux could whup his ass.

I was going to respond until I saw this.  I don't waste my time with
children.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking       Online Campground Directory    http://www.camping-usa.com      Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================

Vince Vielhaber <vev@michvhf.com> writes:

> On 19 Dec 2001, Andrew G. Hammond wrote:
> 
> > ObFlame: BSD sux.  That little devil looks kinda fruity to me, and I'll
> > bet Tux could whup his ass.
> 
> I was going to respond until I saw this.  I don't waste my time with
> children.
> 
> Vince.

What, you didn't see the ObFlame: disclosure.  It seemed like a fairly
obvious joke to me.

I agree with Andrew.  One of the things that I like about Debian is
that all of the config files for every package that is installed via
the Debian packaging system is somewhere in /etc.  Yes, this makes it
difficult (sometimes) to translate the documentation for packages that
expect to have that information somewhere else, but it is very useful
for those cases (like PostgreSQL for example) that put the
configuration files somewhere totally strange (the application's data
directory is not where Unix admins start looking for config files).

The long and the short of it is that pretty much every Unix has a
preference for where the configuration files, data files, log files,
etc, should go, and the various users probably aren't ever going to
simply agree that one way is better than the rest.  After all, if
there is one common trait among Unix admins it is the belief in a "one
true way."  Unfortunately, that "one true way" seems to vary radically
depending on which Unix admin you talk to.  I might agree with Debian
that configuration files belong in /etc, you might feel that they
belong somewhere else.  Currently, however, it doesn't matter what we
want.  The configuration files end up in the PostgreSQL data directory
whether we like it or not.  We can use symlinks to pretend that these
files are somewhere else, but we can't really move them.

Being able to configure the placement of these files would be a huge
win.  We can always default to leaving the files right where they
currently are, but making this configurable would help those people
who package PostgreSQL for one organization or another tremendously.
And since most of PostgreSQL's users end up using the version supplied
by their vendor (whether it's a FreeBSD port or a RedHat RPM or
whatever) it clearly is a win to give these packagers the flexibility
they need.

Not that any of you should listen to me, as I am just some random
PostgreSQL user who happens to be subscribed to HACKERS because I
wanted to see what the real scoop on 7.2 was :).

Jason

On 19 Dec 2001, Jason Earl wrote:

> Vince Vielhaber <vev@michvhf.com> writes:
>
> > On 19 Dec 2001, Andrew G. Hammond wrote:
> >
> > > ObFlame: BSD sux.  That little devil looks kinda fruity to me, and I'll
> > > bet Tux could whup his ass.
> >
> > I was going to respond until I saw this.  I don't waste my time with
> > children.
> >
> > Vince.
>
> What, you didn't see the ObFlame: disclosure.  It seemed like a fairly
> obvious joke to me.

I fail to see how it was appropriate to the subject or this list.
And "ObFlame" means 'obligatory flame' meaning he was obligated to
add the flame.  I fail to see why he'd be obliged to flame for no
reason.


Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net        56K Nationwide Dialup from $16.00/mo
atPop4 Networking       Online Campground Directory    http://www.camping-usa.com      Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================