Re: Sync Rep: First Thoughts on Code
От | Markus Wanner |
---|---|
Тема | Re: Sync Rep: First Thoughts on Code |
Дата | |
Msg-id | 4942ECF7.5040601@bluegap.ch обсуждение исходный текст |
Ответ на | Re: Sync Rep: First Thoughts on Code ("Fujii Masao" <masao.fujii@gmail.com>) |
Ответы |
Re: Sync Rep: First Thoughts on Code
|
Список | pgsql-hackers |
Hi, Fujii Masao wrote: > I'd like to define the meaning of "synch rep" again. "synch rep" means: > > (1) Transaction commit waits for WAL records to be replicated to the standby > before the command returns a "success" indication to the client. > > (2) The standby has (can read) all WAL files indispensable for recovery. Let me point out that - very much like the original Postgres-R algorithm - this guarantees committed transactions to be durable and consistent (no late aborts of conflicting transactions), but it does not guarantee that a transaction committed on one node is immediately visible on the other node. In that sense, it is not synchronous as commonly understood, because it does not "operate with all their parts in synchrony" [1], as implied by the term "synchronous". This might (and often has in the past) lead to confusion. It's certainly enough of a reason for me to rather use the term "eager replication". See [2] for a more in-depth explanation. I might also point out, that Jan Wieck called this very same approch "an asynchronous replication system by all means" [3]. Regards Markus Wanner [1]: Wikipedia on Synchronization http://en.wikipedia.org/wiki/Synchronization [2]: Postgres-R general mailing list, by Markus Wanner, subject: terms for database replication: synchronous vs eager http://lists.pgfoundry.org/pipermail/postgres-r-general/2008-September/000014.html [3]: Postgres General mailing list, by Jan Wieck, subject: terms for database replication: synchronous vs eager http://archives.postgresql.org/pgsql-hackers/2007-09/msg00631.php
В списке pgsql-hackers по дате отправления: