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.
> 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".
- Heikki
