On Wed, Aug 13, 2014 at 5:55 PM, <furuyao@pm.nttdata.co.jp> wrote:
>> I don't think that it's good idea to control that behavior by using
>> --status-interval. I'm sure that there are some users who both want that
>> behavior and want set the maximum interval between a feedback is sent
>> back to the server because these settings are available in walreceiver.
>> But your version of --status-interval doesn't allow those settings at
>> all. That is, if set to -1, the maximum interval between each feedback
>> cannot be set. OTOH, if set to the positive number,
>> feedback-as-soon-as-fsync behavior cannot be enabled. Therefore, I'm
>> thinking that it's better to introduce new separate option for that
>> behavior.
>
> Thanks for the review!
> This patch was split option as you pointed out.
>
> If -r option is specified, status packets sent to server as soon as after fsync.
> Otherwise to send server status packet in the spacing of the --status-interval.
>
Hi,
I took a look at this patch.
I applied patch to master successfully, and did not get error with compiling.
Also it works fine.
One question is why reply_fsync is defined as volatile variable?
Sorry I could not understand reason of that.
Currently patch modifies argument of some function (e.g., Handle
CopyStream, Process LogDate Msg), and add the similar code to each
function.
I don't think it is good approach.
For example, I think that we should gather these code into one function.
Thought?
Regards,
-------
Sawada Masahiko
