Subject: Re: Sync Rep Design
From: Simon Riggs <simon@2ndQuadrant.com>
To: Joshua Tolley <eggyknap@gmail.com>
Cc: Aidan Van Dyk <aidan@highrise.ca>, Robert Treat <rob@xzilla.net>,
	Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>,
	pgsql-hackers@postgresql.org
In-Reply-To: <4d1d4d96.c605ec0a.1af2.ffffb7ef@mx.google.com>
References: <1293729972.1892.23804.camel@ebony>
	<4D1CC47E.7050207@kaltenbrunner.cc> <1293735853.1892.24886.camel@ebony>
	<AANLkTi=dr9TuYRLMWjPkJdL1Jjg+TAJXPJQbLGiN1Pag@mail.gmail.com>
	<AANLkTinV4hNPfBcozG-e+63-0BAxbhnsJdhVmdOu356A@mail.gmail.com>
	<4d1d4d96.c605ec0a.1af2.ffffb7ef@mx.google.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 31 Dec 2010 11:51:55 +0000
Message-ID: <1293796315.1892.37351.camel@ebony>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Thu, 2010-12-30 at 20:26 -0700, Joshua Tolley wrote:
> 2) initiate fsync on the primary first
> >    - In this case, the slave is always slightly behind.  If if your
> > primary falls over, you don't give commit messages to the clients,
> but
> > if it recovers, it might have committed data, and slaves will still
> be
> > able to catch up.
> > 
> > The thing is that currently, even without replication, #2 can
> happen.
> 
> For what little it's worth, I vote for this option, because it's a
> problem that can already happen (as opposed to adding an entirely new
> type of problem to the mix).

This proposal provides #2, so your wish is met.

-- 
 Simon Riggs           http://www.2ndQuadrant.com/books/
 PostgreSQL Development, 24x7 Support, Training and Services