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

From Jan Wieck
Subject Re: PGXLOG variable worthwhile?
Date
Msg-id 3D9311E3.CE82FB89@Yahoo.com
Whole thread Raw
In response to Re: PGXLOG variable worthwhile?  (Curt Sampson <cjs@cynic.net>)
Responses Re: PGXLOG variable worthwhile?  (Curt Sampson <cjs@cynic.net>)
List pgsql-hackers
Curt Sampson wrote:
> 
> On Wed, 25 Sep 2002, Jan Wieck wrote:
> 
> > 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?
> 
> That's just silly, so I won't even bother replying.

Curt,

it might sound silly on first sight and isolated. But it was in reply
to:

>>> 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?

Apply that argumentation to all of our commandline switches and config
options and we end up with something that behaves like Microsoft
products ... they know everything better, you cannot tune them, they
work ... and you needed a bigger machine anyway.

I am absolutely not in favour of the PGXLOG environment variable. But if
someone else wants it, it doesn't bother me because I wouldn't use it
and it cannot hurt me.

I am simply against this "I think it's wrong so you have to change your
behaviour" attitude. 


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: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: Insert Performance
Next
From: Tom Lane
Date:
Subject: Re: Insert Performance