Re: Proposal for 9.1: WAL streaming from WAL buffers - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Proposal for 9.1: WAL streaming from WAL buffers
Date
Msg-id 201006300206.o5U26IO14657@momjian.us
Whole thread Raw
In response to Re: Proposal for 9.1: WAL streaming from WAL buffers  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Proposal for 9.1: WAL streaming from WAL buffers
List pgsql-hackers
Simon Riggs wrote:
> On Mon, 2010-06-21 at 18:08 +0900, Fujii Masao wrote:
> 
> > The problem is not that the master streams non-fsync'd WAL, but that the
> > standby can replay that. So I'm thinking that we can send non-fsync'd WAL
> > safely if the standby makes the recovery wait until the master has fsync'd
> > WAL. That is, walsender sends not only non-fsync'd WAL but also WAL flush
> > location to walreceiver, and the standby applies only the WAL which the
> > master has already fsync'd. Thought?
> 
> Yes, good thought. The patch just applied seems too much.
> 
> I had the same thought, though it would mean you'd need to send two xlog
> end locations, one for write, one for fsync. Though not really clear why
> we send the "current end of WAL on the server" anyway, so maybe we can
> just alter that.

Is this a TODO?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + None of us is going to be here forever. +


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: warning message in standby
Next
From: Robert Haas
Date:
Subject: Re: Cannot cancel the change of a tablespace