Re: Should we remove "not fast" promotion at all?

On Mon, Aug 19, 2013 at 4:20 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> 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.

+1.

...Robert