[pgpool-hackers: 1669] Re: kind does not match error in pgpool

[Muhammad Usama]

On Thu, Jun 30, 2016 at 1:51 PM, Tatsuo Ishii <ishii at postgresql.org> wrote:

> Usama,
>
> > Totally agreed on both the points. I think you have a valid point and
> > unconditionally forwarding all the kind = N messages to frontend is the
> > best choice. The attached version 2 of the patch does the same as
> suggested.
>
> Thanks for the patch. BTW, I had hard time to test the patch. The
> original problem report was talking about VACUUM case, but in
> streaming replication mode, VACUUM is sent to primary node only and
> kind mismatch error can't happend with VACUUM command.
>

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.


> Any suggestion to trigger kind mismatch errors in streaming
> replication mode?
>

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.
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'

i.e.
*Backend 1*
log_statement = 'all'
client_min_messages = debug2

*Backend 2*
log_statement = 'all'
client_min_messages = notice


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


Best Regards
Muhammad Usama




>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20160630/262d4ba0/attachment.html>