Re: pg_receivexlog --status-interval add fsync feedback

On Fri, Oct 31, 2014 at 5:46 PM, <furuyao(at)pm(dot)nttdata(dot)co(dot)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?

Regards,

--
Fujii Masao