On Mon, Aug 19, 2013 at 4:20 AM, Heikki Linnakangas <hlinnakan...@vmware.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers