Thread: Re: [GENERAL] PGXLOG variable worthwhile?

On Wed, 2002-09-18 at 22:24, Marc G. Fournier wrote:
> On Wed, 18 Sep 2002, Bruce Momjian wrote:
>
> > Sorry, I don't see the logic here.  Using postgresql.conf, you set it
> > once and it remains set until you change it again.  With -X, you have to
> > use it every time.  I think that's where the votes came from.
>
> Ah, so you are saying that you type out your full command line each and
> every time you start up the server?  I know, in my case, I have a shell
> script setup that I edit my changes in so that I don't have to remember
> ...

the effort/danger of editing a shell script can't be less than editing
postgresql.conf

>
> > You argued that -X and GUC make sense, but why add -X when can get it
> > done at once in postgresql.conf.  Also, consider changing the location
> > does require moving the WAL files, so you already have this extra step.
> > Adding to postgresql.conf is easy.  I don't think you can just point it
> > at a random empty directory on startup.  Our goal was to reduce params
> > to postmaster/postgres in favor of GUC, not add to them.
>
> I don't disagree that editing postgresql.conf is easy, but its not
> something that ppl would naturally thing of ... if I want to move a
> directory with most servers I run, I will generally do a man to find out
> what command options are required to do this change, and, if none are
> provided, just create a god-forsaken symlink ...

I don't know if I agree with that. Most servers (apache for instance) have
configuration variables on where files are going to live, not command line
options.

>
> The man page for postmaster should have something in it like:
>
> -X <directory> Specifies an alternate location for WAL files.  Superseded
>                by setting xlog_path in postmaster.conf
>

Well, as with most (all?) GUC variables, wouldn't you have the option of doing
postmaster -o "pgxlog=/dev/null" and have the same functionality as -X ?

> Hell, if you are going to remove -X because its 'easier to do it in
> postmaster.conf', you should be looking at removing *all* command line
> args that are better represented in the postmaster.conf file ...
>

Generally speaking people should be looking to avoid useing command line flags
and useing whats in the postgresql.conf, IMHO.

<snip>
>
> the GUC value should override the command line option, agreed ... but the
> ability to use the command line should not be removed just because some
> ppl aren't competent enough to adjust their startup scripts if they change
> their system ...
>

Shouldn't this work the other way around? Use what's in the conf file unless I
explicitly state otherwise? IIRC that's how it works with -i

Robert Treat

--
LAMP :: Linux Apache {middleware} PostgreSQL

On Thu, 19 Sep 2002, Robert Treat wrote:

> I don't know if I agree with that. Most servers (apache for instance) have
> configuration variables on where files are going to live, not command line
> options.

Not where it involves *critical* files:

OPTIONS
       -R libexecdir
                   This option is only available  if  Apache  was
                   built  with the SHARED_CORE rule enabled which
                   forces the Apache core code to be placed  into
                   a  dynamic shared object (DSO) file. This file
                   is searched in a hardcoded path under  Server-
                   Root  per default. Use this option if you want
                   to override it.

> Well, as with most (all?) GUC variables, wouldn't you have the option of
> doing postmaster -o "pgxlog=/dev/null" and have the same functionality
> as -X ?

True, but then that negates the whole argument about not having a command
line option, no?  Which I believe was the whole argument on this ... no?

> Shouldn't this work the other way around? Use what's in the conf file
> unless I explicitly state otherwise? IIRC that's how it works with -i

God, I wish I had thought to note it at the time ... one of the things I
did when I dove into this was to check how various Unix daemons were doing
it, now I can't recall which I was looking at that mentioned the config
file overriding the command line options, but you are correct, the command
line should override the conf file ...