On Mon, Nov 10, 2014 at 7:19 PM, <furu...@pm.nttdata.co.jp> wrote: >> On Fri, Oct 31, 2014 at 5:46 PM, <furu...@pm.nttdata.co.jp> wrote: >> >> > 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. >> >> On second thought, flipping the default behavior seems not worthwhile >> here. >> Which might surprise the existing users and cause some troubles to them. >> I'd like to back to the Heikki's original suggestion like just adding >> --synchronous option. That is, only when --synchronous is specified, WAL >> is flushed and feedback is sent back as soon as WAL is received. >> >> I changed the patch heavily in that way. Please find the attached patch. >> By default, pg_receivexlog flushes WAL data only when WAL file is closed. >> If --synchronous is specified, like the standby's WAL receiver, sync >> commands are issued as soon as there is WAL data which has not been flushed >> yet. Also status packets are sent back to the server just after WAL data >> is flushed whatever --status-interval is set to. I added the description >> of this behavior to the doc. >> >> Thought? > > I think it's as you pointed out. > Thank you for the patch. > I did a review of the patch. > There was no problem.
So I'm thinking to push the patch. Does anyone object to that? Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
