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  (Simon Riggs <simon@2ndQuadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: So, why shouldn't SET CONSTRAINTS set a transaction snapshot?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: So, why shouldn't SET CONSTRAINTS set a transaction snapshot?