On Tue, Jun 15, 2010 at 12:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
Hmm.. I agree that xlogctl->LogwrtResult.Write indicates the byte position
we've written. But in the current XLogWrite() code, it's updated after
XLogWrite() calls issue_xlog_fsync(). No?
Of course, the backend-local LogwrtResult.Write is updated before
issue_xlog_fsync(), but it's not available by walsender.
Am I missing something?
>> 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.
Yes, in order to avoid that problem, walsender should wait for WAL
to be fsync'd before sending it.
But I'm worried that this would slow down the performance on the master
significantly because WAL flush and WAL streaming are not performed
concurrently and the backend must wait for both in a serial manner.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center