<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 1, 2016 at 10:22 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"><span class="">> On Thu, Jun 30, 2016 at 1:51 PM, Tatsuo Ishii <<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>> 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 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 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 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>
</span>> *Backend 1*<br>
<span class="">> log_statement = 'all'<br>
> client_min_messages = debug2<br>
><br>
</span>> *Backend 2*<br>
<span class="">> 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 an<br>
> extra log message form backend 1<br>
<br>
</span>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></blockquote><div><br></div><div>Thanks for pointing this out, This is definitely not intended and happening because of the side effect.</div><div>But I have been thinking about this, and couldn't think of any cleaner solution to solve this duplicate notice message. Although I think this is a very rare scenario, especially in a production environment to have some configurations where PG backend is forwarding the normal log messages to front-end client.</div><div>Also, if we have to decide between the current state (producing a kind mismatch error) vs this rare occurrence of duplicate LOG on the client side, I think we should choose this duplicate log as it is less harmful. But Offcource the best thing would be to solve this in a clean and efficient way.</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>