On 10/24/2014 01:24 PM, furu...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
