<div dir="ltr">Hi Ishii-San<div><br></div><div>Thanks for your valuable input on this, I have pushed the patch to the master branch.</div><div>Do we also need to back port to all branches?<br><div class="gmail_extra"><br></div><div class="gmail_extra">Regards</div><div class="gmail_extra">Muhammad Usama</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 13, 2016 at 7:02 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> On Fri, Jul 1, 2016 at 10:22 AM, Tatsuo Ishii <<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>> wrote:<br>
><br>
>> > On Thu, Jun 30, 2016 at 1:51 PM, Tatsuo Ishii <<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>><br>
>> wrote:<br>
>> ><br>
>> >> Usama,<br>
>> >><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<br>
>> the<br>
>> >> > best choice. The attached version 2 of the patch does the same as<br>
>> >> suggested.<br>
>> >><br>
>> >> 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>
>> >><br>
>> ><br>
>> > The original bug report listed a case where one of the PostgreSQL server<br>
>> > was throwing a warning message because of transaction wrap around and was<br>
>> > suggesting to perform vacuum. The original query was not a VACUUM<br>
>> command.<br>
>> ><br>
>> ><br>
>> >> Any suggestion to trigger kind mismatch errors in streaming<br>
>> >> replication mode?<br>
>> >><br>
>> ><br>
>> > Yes I ran into similar issue and mimicking the exact reported scenario<br>
>> and<br>
>> > getting the transaction wrap around warning is a very hard to generate.<br>
>> > So I tested the patch by setting the lower value of client_min_messages<br>
>> > variable on one of the backend servers and also set log_statement = 'all'<br>
>> ><br>
>> > i.e.<br>
>> > *Backend 1*<br>
>> > log_statement = 'all'<br>
>> > client_min_messages = debug2<br>
>> ><br>
>> > *Backend 2*<br>
>> > log_statement = 'all'<br>
>> > client_min_messages = notice<br>
>> ><br>
>> ><br>
>> > Doing this ensures that one server will always send a original query as a<br>
>> > log message back to client application. And after that I tested the patch<br>
>> > using SET commands, since they are sent to all attached backends and<br>
>> > because of different client_min_messages backend settings I was getting<br>
>> an<br>
>> > extra log message form backend 1<br>
>><br>
>> Looks like now NOTICE messages are duplicated according to the number<br>
>> of backends if the SQL command is sent to each backend.<br>
>><br>
>> Before:<br>
>><br>
>> test=# begin;<br>
>> LOG: statement: begin;<br>
>> BEGIN<br>
>><br>
>> After your patch:<br>
>><br>
>> test=# begin;<br>
>> LOG: statement: begin;<br>
>> LOG: statement: begin;<br>
>> BEGIN<br>
>><br>
>> I'm not sure if this is a desirable change.<br>
>><br>
><br>
> Thanks for pointing this out, This is definitely not intended and happening<br>
> because of the side effect.<br>
> But I have been thinking about this, and couldn't think of any cleaner<br>
> solution to solve this duplicate notice message. Although I think this is a<br>
> very rare scenario, especially in a production environment to have some<br>
> configurations where PG backend is forwarding the normal log messages to<br>
> front-end client.<br>
> Also, if we have to decide between the current state (producing a kind<br>
> mismatch error) vs this rare occurrence of duplicate LOG on the client<br>
> side, I think we should choose this duplicate log as it is less harmful.<br>
> But Offcource the best thing would be to solve this in a clean and<br>
> efficient way.<br>
<br>
</div></div>Yeah, I couldn't think of any better solution neither. It's apparent<br>
that solving the existing kind mismatch error problem is very<br>
important. I agree that we should choose living with duplicate log<br>
messages in rare cases. Let's leave your patch as it is and<br>
commit/push it.<br>
<br>
Best regards,<br>
<div class="HOEnZb"><div class="h5">--<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></div>