> > We seem to be going in circles. You suggested having two options,
> > --feedback, and --fsync, which is almost exactly what Furuya posted
> > originally. I objected to that, because I think that user interface
> is
> > too complicated. Instead, I suggested having just a single option
> > called --synchronous, or even better, have no option at all and have
> > the server tell the client if it's participating in synchronous
> > replication, and have pg_receivexlog automatically fsync when it is,
> > and not otherwise [1]. That way you don't need to expose any new
> > options to the user. What did you think of that idea?
>
> I think it's pretty weird to make the fsync behavior of the client is
> controlled by the server.
>
> I also don't think that fsync() on the client side is useless in
> asynchronous replication. Yeah, it's true that there are no
> *guarantees* with asynchronous replication, but the bound on how long
> the data can take to get out to disk is a heck of a lot shorter if you
> fsync frequently than if you don't. And on the flip side, that has a
> performance impact.
>
> So I actually think the design you proposed is not as good as what was
> proposed by Furuya and Simon. But I don't feel incredibly strongly about
> it.
Thanks for lots of comments!!
I fixed the patch.
As a default, it behave like a walreceiver.
Same as walreceiver, it fsync and send a feedback after fsync.
When --no-fsync is specified, it will fsync only wal has switched.
feedback message is specified by --status-interval.
Regards,
--
Furuya Osamu
