From: Simon Riggs <simon@2ndQuadrant.com>
To: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Sync Rep Design
Date: Sat, 01 Jan 2011 17:29:20 +0000
Message-ID: <1293902960.1892.61053.camel@ebony> (raw)
In-Reply-To: <4D1F60B4.1060408@kaltenbrunner.cc>
References: <1293729972.1892.23804.camel@ebony>
<4D1CC47E.7050207@kaltenbrunner.cc>
<1293735853.1892.24886.camel@ebony>
<4D1CEEAF.8050209@kaltenbrunner.cc>
<1293744235.1892.26478.camel@ebony>
<4D1D93F1.80602@kaltenbrunner.cc>
<1293791171.1892.36233.camel@ebony>
<AANLkTinq-Aii-6fG-QGXUGnkVUdy3rYt71kEb2aA9y7B@mail.gmail.com>
<4D1F3437.10503@kaltenbrunner.cc>
<AANLkTi=U6xzMpsrFbZkjQHrSnR_n+M9iGLrx0p8a4n+j@mail.gmail.com>
<4D1F4453.50903@kaltenbrunner.cc>
<1293900957.1892.60412.camel@ebony>
<4D1F60B4.1060408@kaltenbrunner.cc>
On Sat, 2011-01-01 at 18:13 +0100, Stefan Kaltenbrunner wrote:
> On 01/01/2011 05:55 PM, Simon Riggs wrote:
> >
> > It appears to me there has been substantial confusion over alternatives,
> > because of a misunderstanding about how synchronisation works. Requiring
> > confirmation that standbys are in sync is *not* the same thing as them
> > actually being in sync. Every single proposal made by anybody here on
> > hackers that supports multiple standby servers suffers from the same
> > issue: when the primary crashes you need to work out which standby
> > server is ahead.
>
> aaah that was exactly what I was after - so the problem is that when you
> have a sync standby it will technically always be "in front" of the
> master (because it needs to fsync/apply/whatever before the master).
> In the end the question boils down to what is "the bigger problem" in
> the case of a lost master:
> a) a transaction that was confirmed on the master but might not be on
> any of the surviving sync standbys (or you will never know if it is) -
> this is how I understand the proposal so far
No that cannot happen, the current situation is that we will fsync WAL
on the master, then fsync WAL on the standby, then reply to the master.
The standby is never ahead of the master, at any point.
> b) a transaction that was not yet confirmed on the master but might have
> been applied on the surving standby before the desaster - this is what I
> understand "confirm from all sync standbys" could result in.
Yes, that is described in the docs changes I published.
(a) was discussed, but ruled out, since it would require any crash/immed
shutdown of the master to become a failover, or have some kind of weird
back channel to give the missing data back.
There hasn't been any difference of opinion in this area, that I am
aware of. All proposals have offered (b).
--
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, stefan@kaltenbrunner.cc, robertmhaas@gmail.com, jeff.janes@gmail.com
Subject: Re: Sync Rep Design
In-Reply-To: <1293902960.1892.61053.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