Re: pg_receivexlog --status-interval add fsync feedback

> >>>> What set of options would you pass if you want to use it as a
> >>>> synchronous standby? And if you don't? Could we just have a single
> >> "--synchronous"
> >>>> flag, instead of -F and --reply-fsync?
> >>>
> >>> If you set "synchronous_commit" as "remote_write", the options would
> >> be different .
> >>> The set of options in each case, see the following.
> >>>
> >>>
> >>> Synchronous standby(synchronous_commit=on)
> >>> --fsync-interval=-1
> >>> --reply-fsync
> >>> --slot=slotname
> >>>
> >>> Synchronous standby(synchronous_commit=remote_write)
> >>> --fsync-interval=-1
> >>> --reply-fsync
> >>>
> >>> Asynchronous
> >>> There are no relative options.
> >>>
> >>>
> >>> Well, if the response time delay(value of
> >> "--status-interval=interval") is acceptable, "--reply-fsync" is
> >> unnecessary.
> >>> Instead of "--reply-fsync", using "--synchronous"(which summarizes
> >> the "--reply-fsync" and "fsync-interval = -1") might be easy to
> >> understand. Although, in that case, "--fsync-interval=interval"
> >> would be fixed value. Isn't there any problem ?
> >>
> >> I think we should remove --fsync-interval and --reply-fsync, and just
> >> have a --synchronous option, which would imply the same behavior you
> >> get with --fsync-interval=-1 --reply--fsync.
> >>
> >> That leaves the question of whether pg_receivexlog should do fsyncs
> >> when it's not acting as a synchronous standby. There isn't any real
> >> need to do so. In asynchronous mode, there are no guarantees anyway,
> >> and even without an fsync, the OS will eventually flush the data to
> disk.
> >>
> >> But we could do even better than that. It would be best if you didn't
> >> need even the --synchronous flag. The server knows whether the client
> >> is a synchronous standby or not. It could tell the client.
> >
> > 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.
>
> > In asynchronous mode, I think there is no problem since the
> specification is same with release version.
> >
> >> The server knows whether the client is a synchronous standby or not.
> >> It could tell the client.
> >
> > When notifying the synchronous/asynchronous mode to the client from
> > the server, do we need to change the format of the Message ?
>
> Yeah. Or rather, add a new message type, to indicate the
> synchronous/asynchronous status.

Thanks for the reply.

> > 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 ?

> >> The server knows whether the client is a synchronous standby or not.
> >> It could tell the client.
> >
> > When notifying the synchronous/asynchronous mode to the client from
> > the server, do we need to change the format of the Message ?
>
> 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.

Regards,

--
Furuya Osamu