|Cc:||<simon(at)2ndquadrant(dot)com>, <masao(dot)fujii(at)gmail(dot)com>, <sawada(dot)mshk(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, <teranishih(at)nttdata(dot)co(dot)jp>|
|Subject:||Re: pg_receivexlog --status-interval add fsync feedback|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> > 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
> > 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 . 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
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.
|Next Message||Amit Kapila||2014-10-31 09:51:17||Re: Lockless StrategyGetBuffer() clock sweep|
|Previous Message||Andres Freund||2014-10-31 06:41:46||Re: tracking commit timestamps|