> >>>> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
