Bruce Momjian <br...@momjian.us> wrote: > Heikki Linnakangas wrote:
>> They want to have the cake and eat it too. But they're not >> actually getting that. What they actually get is extra latency >> when things work, with no gain in durability. > > They are getting guaranteed durability until they get a > notification --- that seems valuable. When they get the > notification, they can reevaluate if they want that tradeoff. My first reaction to this has been that if you want synchronous replication without having the system wait if the synchronous target goes down, you should configure an alternate target. With the requested change we can no longer state that when a COMMIT returns with an indication of success that the data has been persisted to multiple clusters. We would be moving to a situation where the difference between synchronous is subtle -- either way the data may or may not be on a second cluster by the time the committer is notified of success. We wait up to some threshold time to try to make the success indication indicate that, but then return success even if the guarantee has not been provided, without any way for the committer to know the difference. On the other hand, we keep getting people saying they want the database to make the promise of synchronous replication, and tell applications that it has been successful even when it hasn't been, as long as there's a line in the server log to record the lie. Or, more likely, to record the boundaries of time blocks where it has been a lie. This appears to be requested because other products behave that way. I'm torn on whether we should cave to popular demand on this; but if we do, we sure need to be very clear in the documentation about what a successful return from a commit request means. Sooner or later, Murphy's Law being what it is, if we do this someone will lose the primary and blame us because the synchronous replica is missing gobs of transactions that were successfully committed. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
