Re: pg_receivexlog --status-interval add fsync feedback

On Fri, Oct 24, 2014 at 11:21 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> On 10/24/2014 01:24 PM, furuyao@pm.nttdata.co.jp wrote:
>>>>>
>>>>> Sorry, I'm going around in the circle. But I'd like to say again, I
>>>>> don't think this is good idea. It prevents asynchronous
>>>>> pg_receivexlog from fsyncing WAL data and sending feedbacks more
>>>>> frequently at all. They are useful, for example, when we want to
>>>>> monitor the write location of asynchronous pg_receivexlog in almost
>>>>> realtime. But if we adopt the idea, since feedback cannot be sent
>>>>> soon in async mode, pg_stat_replication always returns the
>>>
>>> not-up-to-date location.
>>>>
>>>>
>>>> Why not send a message every 10 seconds when its not sync rep?
>>>
>>>
>>> Or even after every write(). It's a tiny amount of network traffic
>>> anyway.
>>
>>
>> I understand that send feedback message frequently will keep
>> pg_stat_replication up-to-date state.
>>
>> Are there really no needs who wants to fsync even in async mode ?
>> I think the people who dislike Data lost will like that idea.
>
>
> The OS will not sit on the written but not fsync'd data forever, it will get
> flushed to disk in a few seconds even without the fsync. It's just that
> there is no guarantee on when it will hit the disk, but there are no strong
> guarantees in asynchronous replication anyway.

This makes me come up with the idea about adding new GUC parameter like
wal_receiver_fsync so that a user can disable walreceiver to fsync WAL after
every write(). IOW, it can allow walreceiver to work like current
pg_receivexlog.

One problem of the above idea is that the startup process can replay WAL
which has not been fsync'd yet. This violates the WAL rule. To resolve this,
the startup process would need to ensure that WAL to replay has already been
fsync'd, and otherwise issue the fsync. This basically makes the WAL replay
longer, but we can reduce the amount of I/O by walreceiver.

This seems also useful even with synchronous replication if synchronous_commit
is set to remote_write. Since walreceiver doesn't issue the fsync and can focus
on receiving and writing WAL, the performance of replication would be improved.

>> Nevertheless in sync or async, returning feedback and executing
>> fsync() same as like walreceiver is such a problem?
>
>
> Probably would be OK. It would increase the I/O a lot, thanks to a lot of
> small writes and fsyncs, which might be surprising for a tool like
> pg_receivexlog.
>
> One idea is to change the default behavior to be like walreceiver, and
> fsync() after every write. But provide an option to get the old behavior,
> "--no-fsync".

I'm OK with this. That is, by default, pg_receivexlog issues the fsync and
sends the feedback message back after every write(). But something like
--no-fsync is specified, WAL file is fsync'd only when it's closed and
a feedback message is sent back only when --status-interval time is elapsed.

Regards,

-- 
Fujii Masao