Re: [HACKERS] PGXLOG variable worthwhile?

On Wed, 18 Sep 2002, Tom Lane wrote:

> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> > 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?
>
> Let's put it this way: would you be in favor of adding a
> --please-don't-wipe-my-database-directory
> switch to the postmaster? And if you forget to specify that every time
> you start the postmaster, we do an instant "rm -rf $PGDATA"?
>
> Doesn't seem like a good idea, does it?
>
> Well, specifying the XLOG location on the command line or as an
> environment variable is just about as deadly as the above loaded-gun-
> pointed-at-foot scenario. You start the postmaster with the wrong
> context, even once, it's sayonara to your data integrity.
>
> The point of insisting that the XLOG location be recorded *inside*
> the data directory is to prevent simple admin errors from being
> catastrophic. Do you remember when we regularly saw trouble reports
> from people who'd corrupted their database indexes by starting the
> postmaster with different LOCALE environments at different times? We
> fixed that by forcing the locale collation order to be specified inside
> the database directory (in pg_control, but the details are not important
> here), rather than allowing it to be taken from postmaster environment.
>
> If we allow XLOG location to be determined by a postmaster switch or
> environment variable, then we *will* be opening the door for people
> to shoot themselves in the foot just like they used to do with locale.
>
> I learned something from those problems, and I do not intend to make
> the same mistake again.

Except that you are ... you are assuming that someone is going to edit
their postmaster.conf file correctly ... if you want to avoid making the
same mistake again, there should be some sort of 'tag' that associates the
files in the XLOG directory with the data directories themselves,
regardless of *how* the XLOG directory is referenced ... something that
links them at a level that an administrator *can't* make a mistake about
... all forcing the use of the postmaster.conf file is doing is reducing
options, it isn't making sure that the XLOG directory pointed to is
apporopraite for the data directory itself ...