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

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