> > 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
pg_receivexlog-fsync-feedback-v7.patch
Description: pg_receivexlog-fsync-feedback-v7.patch
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
