On Tue, 2010-10-05 at 12:11 -0700, Josh Berkus wrote: > B. Eventual Inconsistency > ------------------------- > If we have a quorum commit, it's possible for any individual standby to > be indefinitely ahead of any standby which is not needed by the quorum. > This means that: > > -- There is no clear criteria for when a standby which is not needed for > quorum should be considered no longer a synch standby, and > -- Applications cannot make assumptions that synch rep promises some > specific window of synchronicity, eliminating a lot of the value of > quorum commit.
Point B seems particularly dangerous. When you lose one of the systems and the lagging server becomes required for quorum, then all of a sudden you could be facing a huge delay to commit the next transaction (because it needs to catch up on a lot of WAL replay). This can happen even without a network problem at all, and seems very likely to result in the lagging system being considered "down" due to a timeout. Not good, because the reason it is required for quorum is because another standby just went down. In other words, a lagging standby combined with a timeout mechanism is essentially useless, because it will never catch up in time to be a part of the quorum. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers