<div dir="ltr">Hi Yugo Nagata,<div><br></div><div>Thanks for catching this, Since most of the time we test the watchdog by running multiple instances on same machine so this issue would never appear in our test environment,</div><div>I believe you fix is spot on and unfortunately as far as I can think of there is not much we can do for backward compatibility and have to live with that to fix this issue.</div><div><br></div><div> Thanks</div><div>Best Regards</div><div>Muhammad Usama<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 24, 2017 at 12:33 PM, Yugo Nagata <span dir="ltr"><<a href="mailto:nagata@sraoss.co.jp" target="_blank">nagata@sraoss.co.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 24 Aug 2017 16:31:51 +0900<br>
Yugo Nagata <<a href="mailto:nagata@sraoss.co.jp">nagata@sraoss.co.jp</a>> wrote:<br>
<br>
Sorray, the previous attachment is incorrect.<br>
I attached a revised one.<br>
<div class="HOEnZb"><div class="h5"><br>
> Hi Usama,<br>
><br>
> There is the recent bug report about wd_authkey.<br>
><br>
> 0000333: watchdog fails to add node to master when wd_authkey is not an empty string; pgpool member shuts down<br>
> <a href="http://www.pgpool.net/mantisbt/view.php?id=333" rel="noreferrer" target="_blank">http://www.pgpool.net/<wbr>mantisbt/view.php?id=333</a><br>
><br>
> We have the same issue report recently from our client. In my analysis, this is a bug<br>
> due to the commit [1]. This changed the definition of tv_sec that is used to check wd_authkey<br>
> so that this was affected by the clock of OS. So, if there is a lag between two nodes' clocks,<br>
> the wd_authkey check fails.<br>
><br>
> A simple solution is not to use tv_sec in the wd_authkey check as the attached patch.<br>
> However, one concern is that this is a specification change and that this also will break<br>
> back-compatibility. Of course, we can diallow watchdog cluster to have Pgpool-II of different<br>
> minor-versions. Although this is already implicit restriction of watchdog, we can make this<br>
> explicit restriction by checking other Pgpool-II node's version when receiving watchdog<br>
> packet.<br>
><br>
> What do you think about it?<br>
><br>
> [1] <a href="http://www.pgpool.net/pipermail/pgpool-committers/2017-April/003945.html" rel="noreferrer" target="_blank">http://www.pgpool.net/<wbr>pipermail/pgpool-committers/<wbr>2017-April/003945.html</a><br>
><br>
> --<br>
> Yugo Nagata <<a href="mailto:nagata@sraoss.co.jp">nagata@sraoss.co.jp</a>><br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Yugo Nagata <<a href="mailto:nagata@sraoss.co.jp">nagata@sraoss.co.jp</a>><br>
</font></span><br>______________________________<wbr>_________________<br>
pgpool-hackers mailing list<br>
<a href="mailto:pgpool-hackers@pgpool.net">pgpool-hackers@pgpool.net</a><br>
<a href="http://www.pgpool.net/mailman/listinfo/pgpool-hackers" rel="noreferrer" target="_blank">http://www.pgpool.net/mailman/<wbr>listinfo/pgpool-hackers</a><br>
<br></blockquote></div><br></div></div></div>