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: http://www.postgresql.org/mailpref/pgsql-hackers
