Re: pg_receivexlog --status-interval add fsync feedback

On 10/08/2014 07:23 AM, furuyao(at)pm(dot)nttdata(dot)co(dot)jp wrote:
>> 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.

- Heikki