From: Simon Riggs <simon@2ndQuadrant.com>
To: Jim Nasby <jim@nasby.net>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Sync Rep Design
Date: Fri, 31 Dec 2010 01:38:32 +0000
Message-ID: <1293759512.1892.29387.camel@ebony> (raw)
In-Reply-To: <795581D6-9C8B-4DE3-B99F-CA7120FE6BFB@nasby.net>
References: <1293729972.1892.23804.camel@ebony>
<4D1CC47E.7050207@kaltenbrunner.cc>
<1293735853.1892.24886.camel@ebony>
<AANLkTi=SvN2KQ1Tzh-tRKcXD0i2FyWFBbbR=kXXdepqN@mail.gmail.com>
<795581D6-9C8B-4DE3-B99F-CA7120FE6BFB@nasby.net>
On Thu, 2010-12-30 at 18:47 -0600, Jim Nasby wrote:
> On Dec 30, 2010, at 3:27 PM, Robert Haas wrote:
> >> synchronous_replication (boolean)
> >> Specifies whether transaction commit will wait for WAL records
> >> to be replicated before the command returns a "success"
> >> indication to the client.
> >
> > The word "replicated" here could be taken to mean different things,
> > most obviously:
> >
> > - slave has received the WAL
> > - slave has fsync'd the WAL
> > - slave has applied the WAL
>
> I think that comment is valid for the entire set of docs, actually. The document goes out of its way to avoid simple phrases like "replicated", but doesn't spell out exactly what is happening, ie:
>
> "Synchronous replication offers the ability to guarantee that all changes
> made by a transaction have been transferred to at least one remote
> standby server. This is an extension to the standard level of durability
> offered by a transaction commit. This is referred to as semi-synchronous
> replication."
>
> Reading that, I'm left with the sense that this isn't a simple matter of "Oh, the data has been replicated to the slave before commit returns", but nothing does a good job of clearly explaining what the distinction is and what it means. This section:
>
> "The guarantee we offer is that the application will not receive
> explicit acknowledgement of the successful commit of a transaction until
> the WAL data is known to be safely received by the standby. Hence this
> mechanism is technically "semi synchronous" rather than "fully
> synchronous" replication."
>
> does provide some enlightenment, but it's at the end of the section. I think it would be best if there was a section right at the beginning that talked about the data quality issue of sync replication and how we're avoiding it with our semi-sync solution.
I'm happy to change the docs. It's the first draft...
If that's the only problem you've got, then I'm feeling good.
Any problems with the user interface itself?
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
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-hackers@postgresql.org
Cc: simon@2ndQuadrant.com, jim@nasby.net, robertmhaas@gmail.com, stefan@kaltenbrunner.cc
Subject: Re: Sync Rep Design
In-Reply-To: <1293759512.1892.29387.camel@ebony>
* 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