From: Kevin Grittner <Kevin.Grittner@wicourts.gov>
To: Markus Wanner <markus@bluegap.ch>
To: MARK CALLAGHAN <mdcallag@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Aidan Van Dyk <aidan@highrise.ca>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Date: Fri, 18 Mar 2011 08:40:22 -0500
Message-ID: <4D831A76020000250003BA82@gw.wicourts.gov> (raw)
In-Reply-To: <AANLkTi=B+cWE-pQJQM=zoA9=Zr25W7zPPMFvvBe11O4E@mail.gmail.com>
References: <E1PwMns-00047O-UU@gemulon.postgresql.org>
<4D741441.2090704@dunslane.net>
<1299454125.1696.6138.camel@ebony>
<4D74896C.5030402@enterprisedb.com>
<4D74DDFA.70800@dunslane.net>
<4D74E584.7080409@enterprisedb.com>
<4D74E9FA.7070202@dunslane.net>
<AANLkTinkzJ=UrLbThZy2KeQg+SjwYqj2r0mDomMwirB7@mail.gmail.com>
<4D74F3AE.9000802@dunslane.net>
<4D74FDEC.5040406@enterprisedb.com>
<4D74FF15.1070804@dunslane.net>
<1299513979-sup-1987@alvh.no-ip.org>
<4D832571.5030808@bluegap.ch>
<AANLkTi=B+cWE-pQJQM=zoA9=Zr25W7zPPMFvvBe11O4E@mail.gmail.com>
MARK CALLAGHAN <mdcallag@gmail.com> wrote:
> 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).
To be fair, what we're considering calling semi-synchronous is
something which tries to stay in synchronous mode but switches out
of it when necessary to meet availability targets. Your analogy
doesn't match up at all well -- at least without getting really
ugly.
> 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.
Then the only thing you would consider sync replication, as far as I
can see, is two phase commit, which we already have. So your use
case seems to be covered already, and we're trying to address other
people's needs. The guarantee that some people are looking for is
that a successful commit means that the data has been persisted on
two separate servers. Others want to try for that, but are willing
to compromise it for HA; in general I think they want to know when
the guarantee is not there so they can take action to get back to a
safer condition.
-Kevin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: Kevin.Grittner@wicourts.gov, markus@bluegap.ch, mdcallag@gmail.com, simon@2ndquadrant.com, alvherre@commandprompt.com, andrew@dunslane.net, heikki.linnakangas@enterprisedb.com, aidan@highrise.ca, pgsql-hackers@postgresql.org
Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
In-Reply-To: <4D831A76020000250003BA82@gw.wicourts.gov>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox