Skip site navigation (1) Skip section navigation (2)

Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Aidan Van Dyk <aidan(at)highrise(dot)ca>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Date: 2010-04-29 17:42:14
Message-ID: 4BD9C4F6.8030805@2ndquadrant.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Aidan Van Dyk wrote:
> It's all about the path of least *suprise*.  My "least suprise" would
> have been that a similar config I have now with my PITR slaves would
> pretty much still work, and not suddenly start accepting connections,
> and even worse, at some later date when I've already verified that it
> was doing what I expected with the configuration.
>   

The first time I setup a system to test HS, when I got to the point 
where the slave was up and running as a standard warm standby, I 
expected there to be something else I had to do in order for it to be 
available for queries.  When I fired up psql and I was able to run 
queries without doing anything extra, I was surprised--but it was that 
fun, everything just works when I expected it to be harder than that 
kind of surprise.

One of the reasons the version number was bumped up to 9.0 was to put 
people on warning that they should not assume their old setups would 
port forward without behavioral changes.  The fact that existing 
warm-standby server users will be surprised to find they can run queries 
without doing anything special could be considered under that banner.  
If you feel that's not obvious enough, that could argue for more 
prominent documentation of that fact, rather than turning it off.  The 
idea that it should be made harder to enable just to protect the 
expectations current users, and therefore introduce yet another place 
where PostgreSQL is less friendly to get started with than it could be, 
is backwards from the perspective of making things as easy as possible 
for new users.

Arguing from a usability standpoint needs to consider both new and 
existing user requirements, and those are quite opposed to one another 
in terms of what default makes more sense IMHO.  Now, if the argument is 
from the perspective of "this adds performance/reliability issues that 
weren't there before", and those go away if the feature is disabled by 
default, that's a respectable and indisputable reason to do so.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com   www.2ndQuadrant.us


In response to

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2010-04-29 17:42:40
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Previous:From: Simon RiggsDate: 2010-04-29 17:39:47
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

pgsql-committers by date

Next:From: Joshua D. DrakeDate: 2010-04-29 17:42:40
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct
Previous:From: Simon RiggsDate: 2010-04-29 17:39:47
Subject: Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group