On 19 August 2013 09:20, Heikki Linnakangas <hlinnakan...@vmware.com> wrote:
> 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.

+1, again.

I have removed this item from the 9.4 open items list, since this
issue has already been resolved.

 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to