On Wed, Aug 13, 2014 at 5:55 PM, <furu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
