Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > if you pull the power plug, the transaction that was just being > committed might be committed on the master, but not yet on the > standby. > For me, that's enough to call it "synchronous replication". It > provides useful guarantee to the client. I don't think most people would expect full 2PC behavior from something called "synchronous replication" -- I agree that a guarantee that a successful commit means it has been written to the master and at least one replica is sufficient. > you could argue for an even stricter definition, requiring > atomicity so that if a transaction is not successfully replicated > for any reason, including crash, it is rolled back in the master > too. That would require 2PC. I'm not sure you can say it breaks atomicity; if proper procedures are followed on recovery, all servers will either reflect the transaction or not, right? It seems to me what you lose is the ability to know whether a transaction for which commit was requested and for which there had not yet been a reply at the time of failure is going to be in your recovered database. In this particular regard it is no different from a standalone or async replication, and you would need 2PC with a proper transaction manager to do better. Getting that additional guarantee may not be worth the performance hit for most people. We train our users to save (or make) a paper copy of whet they were entering if a crash occurs (which, of course, is very rare, but does happen), so they can check the state of it on recovery. It is, of course, important for the programmers to use appropriate database transaction boundaries so that the database is always in a state with internal integrity and from which users can determine the state and proceed on their own. I think we should document the issues, of course. If there is really a demand for a stricter "sync rep" feature, I think it must be built on top of 2PC and some particular transaction manager, which seems a though that makes it pgfoundry material. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
