<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 30, 2016 at 1:51 PM, Tatsuo Ishii <span dir="ltr"><<a href="mailto:ishii@postgresql.org" target="_blank">ishii@postgresql.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Usama,<br>
<span class=""><br>
> Totally agreed on both the points. I think you have a valid point and<br>
> unconditionally forwarding all the kind = N messages to frontend is the<br>
> best choice. The attached version 2 of the patch does the same as suggested.<br>
<br>
</span>Thanks for the patch. BTW, I had hard time to test the patch. The<br>
original problem report was talking about VACUUM case, but in<br>
streaming replication mode, VACUUM is sent to primary node only and<br>
kind mismatch error can't happend with VACUUM command.<br></blockquote><div><br></div><div>The original bug report listed a case where one of the PostgreSQL server was throwing a warning message because of transaction wrap around and was suggesting to perform vacuum. The original query was not a VACUUM command. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Any suggestion to trigger kind mismatch errors in streaming<br>
replication mode?<br></blockquote><div><br></div><div>Yes I ran into similar issue and mimicking the exact reported scenario and getting the transaction wrap around warning is a very hard to generate.</div><div>So I tested the patch by setting the lower value of client_min_messages variable on one of the backend servers and also set log_statement = 'all' <br><br></div><div>i.e.</div><div><b>Backend 1</b></div><div>log_statement = 'all'<br></div><div>client_min_messages = debug2<br></div><div><br></div><div><div><b>Backend 2</b></div></div><div>log_statement = 'all'<br></div><div>client_min_messages = notice<br></div><div><br></div><div><br></div><div>Doing this ensures that one server will always send a original query as a log message back to client application. And after that I tested the patch using SET commands, since they are sent to all attached backends and because of different client_min_messages backend settings I was getting an extra log message form backend 1</div><div><br></div><div><br></div><div>Best Regards</div><div>Muhammad Usama</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5"><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_en.php</a><br>
Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
</div></div></blockquote></div><br></div></div>