Re: Should we remove "not fast" promotion at all? - Mailing list pgsql-hackers

On 08.08.2013 20:15, Josh Berkus wrote:
> Bruce, all:
>
>> We seem to be all over the map with the fast promotion code --- some
>> people don't trust it, some people want an option to enable the old
>> method, and some people want the old method removed.
>
> Having read over this thread, the only reason given for retaining any
> ability to use "old" promotion code is because people are worried about
> "fast" promotion being buggy.  This seems wrong.
>
> Either we have confidence is fast promotion, or we don't.  If we don't
> have confidence, then either (a) more testing is needed, or (b) it
> shouldn't be the default.  Again, here, we are coming up against our
> lack of any kind of broad replication failure testing.

Well, I don't see much harm in keeping the old behavior as an 
undocumented escape hatch, as it is now. The way I'd phrase the current 
situation is this: 9.3 now always does "fast promotion". However, for 
debugging and testing purposes, you can still trigger the old behavior 
by manually creating a file in $PGDATA. That should never be necessary 
in the field, however.

There's one thing that irks me with the current situation, however: if 
you use 9.2 version of pg_ctl against a 9.3 server, it will 
inadvertently trigger slow promotion, because it creates the "promote" 
file. Since fast mode is the default, and not only the default but the 
only documented mode, it's confusing if you can accidentally trigger the 
old behavior like that.

And it's even worse if you use 9.3 pg_ctl against a 9.2 server: it will 
create a filed called "fast_promote" and return success, but it won't 
actually do anything.

I think "promote" file should trigger the fast promotion, and the 
filename to trigger the slow mode should be called "fallback_promote" or 
"safe_promote" or something like that. There wasn't any good reason to 
change the filename primarily used. It might even break people's scripts 
for no good reason, if people are creating the $PGDATA/promote file 
themselves without using pg_ctl.

(I raised this back in April, but Simon argued strongly for the current 
situation. I never understood why. 
http://www.postgresql.org/message-id/517798AE.30203@vmware.com)

- Heikki