Re: PGXLOG variable worthwhile? - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: PGXLOG variable worthwhile?
Date
Msg-id 3D920960.8E020AC5@Yahoo.com
Whole thread Raw
In response to Re: PGXLOG variable worthwhile?  (Curt Sampson <cjs@cynic.net>)
Responses Re: PGXLOG variable worthwhile?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: PGXLOG variable worthwhile?  (Curt Sampson <cjs@cynic.net>)
List pgsql-hackers
Curt Sampson wrote:
> 
> On Tue, 24 Sep 2002, Jan Wieck wrote:
> 
> > And AFAICS it is scary only because screwing that up will simply corrupt
> > your database. Thus, a simple random number (okay, and a timestamp of
> > initdb) in two files, one in $PGDATA and one in $PGXLOG would be a
> > totally sufficient safety mechanism to prevent starting with the wrong
> > XLOG directory.
> 
> But still, why set up a situation where your database might not
> start? Why not set it up so that if you get just *one* environment
> or command-line variable right, you can't set another inconsistently
> and screw up your start anyway? Why store configuration information
> outside of the database data directory in a form that's not easily
> backed up, and not easily found by other utilities?

With the number of screws our product has, there are so many
possible combinations that don't work, why worry about one more
or less?

Seriously, if you move around files, make symlinks or adjust
config variable to reflect that, there's allways the possibility
that you fatfinger it and cannot startup. The point is not to
make it pellethead-safe so that the damned thing will start
allways, but to make it pellethead-safe so that an attempt to
start with wrong settings doesn't blow away the whole server.

> 
> It's almost like people *don't* want to put this in the config file
> or something....

I want to have it it the config file. Just that that doesn't
prevent anything. And if we have a "signature" file in the xlog
and data directories, you can make it dummy-safe as you like ...
if the config option is set wrong, first search for it on all
drives before bailing out and if found, postmaster corrects the
config setting. That way the admin can play hide and seek with
our database ... ;-)


Jan

-- 

#======================================================================#
# It's easier to get forgiveness for being wrong than for being
right. #
# Let's break this rule - forgive
me.                                  #
#==================================================
JanWieck@Yahoo.com #


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: CVS checkout errors
Next
From: Jan Wieck
Date:
Subject: Re: PGXLOG variable worthwhile?