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

From Tom Lane
Subject Re: Proposal for 9.1: WAL streaming from WAL buffers
Date
Msg-id 13213.1276527772@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal for 9.1: WAL streaming from WAL buffers  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: Proposal for 9.1: WAL streaming from WAL buffers  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
Fujii Masao <masao.fujii@gmail.com> writes:
> On Fri, Jun 11, 2010 at 11:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Well, we're already not waiting for fsync, which is the slowest part.

> No, currently walsender waits for fsync.

No, you're mistaken.

> Walsender tries to send WAL up to xlogctl->LogwrtResult.Write. OTOH,
> xlogctl->LogwrtResult.Write is updated after XLogWrite() performs fsync.

Wrong.  LogwrtResult.Write tracks how far we've written out data,
but it is only (known to be) fsync'd as far as LogwrtResult.Flush.

> But that change would cause the problem that Robert pointed out.
> http://archives.postgresql.org/pgsql-hackers/2010-06/msg00670.php

Yes.  Possibly walsender should only be allowed to send as far as
LogwrtResult.Flush.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Typo in plperl doc ?
Next
From: Robert Haas
Date:
Subject: Re: warning message in standby