> >>> If we remove --fsync-interval, resoponse time to user will not be
> delay.
> >>> Although, fsync will be executed multiple times in a short period.
> >>> And there is no way to solve the problem without --fsync-interval,
> >>> what
> >> should we do about it?
> >>
> >> I'm sorry, I didn't understand that.
> >
> > Here is an example.
> > When WAL is sent at 100ms intervals, fsync() is executed 10 times per
> second.
> > If --fsync-interval is set by 1 second, we have to wait SQL
> responce(kind of making WAL record) for 1 second, though, fsync() won't
> be executed several times in 1 second.
> > I think --fsync-interval meets the demands of people who wants to
> restrain fsync() happens for several time in short period, but what do
> you think?
> > Is it ok to delete --fsync-interval ?
>
> I still don't see the problem.
>
> In synchronous mode, pg_receivexlog should have similar logic as
> walreceiver does. It should read as much WAL from the socket as it can
> without blocking, and fsync() and send reply after that. And also fsync
> whenever switching to new segment. If the master sends WAL every 100ms,
> then pg_recevexlog will indeed fsync() 10 times per second. There's
> nothing wrong with that.
>
> In asynchronous mode, only fsync whenever switching to new segment.
>
> >> Yeah. Or rather, add a new message type, to indicate the
> >> synchronous/asynchronous status.
> >
> > What kind of 'message type' we have to add ?
> >
> > Do we need to separate 'w' into two types ? synchronous and
> asynchronous ?
> >
> > OR
> >
> > Add a new message type, kind of 'notify synchronous', and inform
> > pg_receivexlog of synchronous status when it connect to the server.
>
> Better to add a new "notify" message type. And pg_recevexlog should be
> prepared to receive it at any time. The status might change on the fly,
> if the server's configuration is reloaded.
Thanks for the reply.
> In synchronous mode, pg_receivexlog should have similar logic as walreceiver does.
OK. I understand that removing --fsync-interval has no problem.
> Better to add a new "notify" message type. And pg_recevexlog should be prepared to receive it at any time. The status
mightchange on the fly, if the server's configuration is reloaded.
OK. I'll consider it.
Regards,
--
Furuya Osamu