<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 24, 2017 at 4:29 PM, Tatsuo Ishii <span dir="ltr"><<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think the restriction (to use watchdog clusters, each Pgpool-II<br>
major/minor versions are exactly same) is not big deal for users.<br>
<br></blockquote><div>Yes that is correct, the restriction to use same major/minor version in one cluster is not a problem and there may not be any use case where someone</div><div>would be inclined towards that. The only thing I was worried about is the update procedure where a user would want to update the Pgpool-II version while eliminating</div><div>the downtime. But that is a little grey area currently and I was thinking of creating a lab environment and perform the tests to come up with the strategy and a document</div><div>clearly explaining the recommended procedures to upgrade the cluster from different versions of Pgpool-II with minimal/no-downtime.</div><div>Other than that imposing the restriction of similar versions of Pgpool-II should not be of any concern for any type of use case.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So I prefer to go with the change Yugo proposed.<br></blockquote><div><br></div><div>Yes, exactly Yugo's patch is good and we should go with it,.</div><div><br></div><div>Thanks</div><div>Best Regards</div><div>Muhammad Usama</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Best regards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/index_<wbr>en.php</a><br>
Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.<wbr>jp</a><br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
> Hi Yugo Nagata,<br>
><br>
> Thanks for catching this, Since most of the time we test the watchdog by<br>
> running multiple instances on same machine so this issue would never appear<br>
> in our test environment,<br>
> I believe you fix is spot on and unfortunately as far as I can think of<br>
> there is not much we can do for backward compatibility and have to live<br>
> with that to fix this issue.<br>
><br>
> Thanks<br>
> Best Regards<br>
> Muhammad Usama<br>
><br>
> On Thu, Aug 24, 2017 at 12:33 PM, Yugo Nagata <<a href="mailto:nagata@sraoss.co.jp">nagata@sraoss.co.jp</a>> wrote:<br>
><br>
>> 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>
>><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<br>
>> 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,<br>
>> this is a bug<br>
>> > due to the commit [1]. This changed the definition of tv_sec that is<br>
>> used to check wd_authkey<br>
>> > so that this was affected by the clock of OS. So, if there is a lag<br>
>> 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<br>
>> attached patch.<br>
>> > However, one concern is that this is a specification change and that<br>
>> this also will break<br>
>> > back-compatibility. Of course, we can diallow watchdog cluster to have<br>
>> Pgpool-II of different<br>
>> > minor-versions. Although this is already implicit restriction of<br>
>> watchdog, we can make this<br>
>> > explicit restriction by checking other Pgpool-II node's version when<br>
>> receiving watchdog<br>
>> > packet.<br>
>> ><br>
>> > What do you think about it?<br>
>> ><br>
>> > [1] <a href="http://www.pgpool.net/pipermail/pgpool-committers/" rel="noreferrer" target="_blank">http://www.pgpool.net/<wbr>pipermail/pgpool-committers/</a><br>
>> 2017-April/003945.html<br>
>> ><br>
>> > --<br>
>> > Yugo Nagata <<a href="mailto:nagata@sraoss.co.jp">nagata@sraoss.co.jp</a>><br>
>><br>
>><br>
>> --<br>
>> Yugo Nagata <<a href="mailto:nagata@sraoss.co.jp">nagata@sraoss.co.jp</a>><br>
>><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>
>><br>
</div></div></blockquote></div><br></div></div>