Re: [COMMITTERS] pgsql: Fast promote mode skips checkpoint at end of recovery. - Mailing list pgsql-hackers

On Wed, Feb 6, 2013 at 12:43 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> 2. I don't like demoting the trigger file method to a second class
>> citizen. I think we should make all functionality available through both
>> methods. If there was a good reason for deprecating the trigger file
>> method, I could live with that, but this patch is not such a reason.
>
> I don't understand why we introduced a second method if they both will
> continue to be used. I see no reason for that, other than backwards
> compatibility. Enhancing both mechanisms suggests both will be
> supported into the future. Please explain why the second mode exists?

I agree that we should be pushing people towards pg_ctl promote.  I
have no strong opinion about whether backward-compatibility for the
trigger file method is a good idea or not.  It might be a little soon
to relegate that to second-class status, but I'm not sure.

>> 4. I think fast promotion should be the default. Why not? There are
>> cases where you want the promotion to happen ASAP, and there are cases
>> where you don't care. But there are no scenarios where you want
>> promotion to be slow,
>
> Not true. Slow means safe and stable, and there are many scenarios
> where we want safe and stable. (Of course, nobody specifically
> requests slow). My feeling is that this is an area of exposure that we
> have no need and therefore no business touching. I will of course go
> with what others think here, but I don't find the argument that we
> should go fast always personally convincing. I am willing to relax it
> over time once we get zero field problems as a result.

I'm skeptical of the idea that we shouldn't default to fast-promote
because the fast-promote code might be buggy.  We do sometimes default
new features to off on the grounds that they might be buggy - Hot
Standby got an on/off switch partly for that reason - but usually we
only add a knob if there's some plausible reason for wanting to change
the setting independently of the possibility of bugs.  For instance,
in the case of Hot Standby, another of the reasons for adding a knob
was that people wanted a way to make sure that they wouldn't
accidentally connect to the standby when they intended to connect to
the master.  That may or may not have been a sufficiently *good*
reason, but it was accepted as justification at the time.

So I would ask this question: why would someone want to turn off
fast-promote mode, assuming for the sake of argument that it isn't
buggy?  I think there might be good reasons to do that, but I'm not
sure what they are.  I doubt it will be a common thing to want.  I
think most people are going to want fast-promote, but many may not
know enough to request it, which means that if it isn't the default,
the code may not get much testing anyway.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company