Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
| От | Robert Haas |
|---|---|
| Тема | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |
| Дата | |
| Msg-id | AANLkTimATgm3Dt-vOPL9CyqvfJ4knkgmJ_srB7iyfaiz@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. (MARK CALLAGHAN <mdcallag@gmail.com>) |
| Список | pgsql-hackers |
On Fri, Mar 18, 2011 at 9:16 AM, MARK CALLAGHAN <mdcallag@gmail.com> wrote: > On Fri, Mar 18, 2011 at 9:27 AM, Markus Wanner <markus@bluegap.ch> wrote: >> Google invented the term "semi-syncronous" for something that's >> essentially the same that we have, now, I think. However, I full >> heartedly hate that term (based on the reasoning that there's no >> semi-pregnant, either). > > We didn't invent the term, we just implemented something that Heikki > Tuuri briefly described, for example: > http://bugs.mysql.com/bug.php?id=7440 > > In the Google patch and official MySQL version, the sequence is: > 1) commit on master > 2) wait for slave to ack > 3) return to user > > After step 1 another user on the master can observe the commit and the > following is possible: > 1) commit on master > 2) other user observes that commit on master > 3) master blows up and a user observed a commit that never made it to a slave > > I do not think this sequence should be possible in a sync replication > system. But it is possible in what has been implemented for MySQL. > Thus it was named semi-sync rather than sync. Thanks for the insight. That can't happen with our implementation, I believe. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: