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

[Muhammad Usama]

On Tue, Jun 21, 2016 at 6:11 AM, Tatsuo Ishii <ishii at postgresql.org> wrote:

> > Hi Ishii-San
> >
> > Can you please have a look at the attached patch, It try to solve this
> > "Kind does not match .." problem by ignoring the notice messages while
> > reading the backend response in read_kind_from_backend() function
>
> Doesn't this patch simply ignore important messages like this?
>

Basically patch only ignores the notice log messages and these messages are
important, especially ones with severity level of WARNING and NOTICE, to
inform the user about some critical issue.
I may be wrong, but I don't think these log message are important in terms
of PG protocol flow. i.e. notice (kind = 'N') message only contains the log
 and is delivered to frontend (pgpool-II in our case) depending on
*client_min_messages* settings in postgresql.conf.
So I think it should be safe to ignore these.


>
> >>> ... WARNING: database "testdb" must be vacuum within 11000000
> transaction
>
> >
> >
> > On Tue, Apr 19, 2016 at 1:50 PM, Ahsan Hadi <ahsan.hadi at enterprisedb.com
> >
> > wrote:
> >
> >> I agree this cause lot of annoyance to pgpool users and something we
> >> should address for 3.6.
> >>
> >> Usama,
> >> Is this added to 3.6 wiki?
> >>
> >> On Fri, Apr 15, 2016 at 11:46 AM, Muhammad Usama <m.usama at gmail.com>
> >> wrote:
> >>
> >>> Hi
> >>>
> >>> pgpool throws ".. kind does not match.." error message when all the
> >>> attached backend nodes do not return the same response to the query.
> Although
> >>> this error message can be a symptom of the backend node sync issue in
> >>> most cases, but in case when the message kind of backend nodes differs
> >>> because one of the backend returned the notice response while the other
> >>> returned some other kind then that case should not be considered as an
> >>> error case.
> >>>
> >>> Consider the scenario where a pgpool is connected to three backend
> nodes
> >>> and pgpool is expecting to receive "[C] command complete" message from
> >>> all nodes for the last query. But while processing the query one of the
> >>> backend also produced a warning message.
> >>>
> >>> ... WARNING: database "testdb" must be vacuum within 11000000
> transaction
> >>>
> >>> Please note that the query was successful on all attached backend, but
> >>> one backend also produced an extra warning message along with the
> command
> >>> complete message.
> >>>
> >>> Now pgpool will throw an error something like
> >>>
> >>> ERROR: pid 720: read_kind_from_backend: 1 th kind N does not match
> >>> with master or majority connection kind C
> >>>
> >>> But since the node would also have sent the expected command complete
> >>> message after that warning notice, So Ideally, pgpool should ignore the
> >>> WARNING message and compare the subsequent message, and only throw an
> error
> >>> if the message from nodes after ignoring notification messages differs.
> >>>
> >>> What are your thoughts on this?
> >>>
> >>> Kind regards
> >>> Muhammad Usama
> >>>
> >>>
> >>> _______________________________________________
> >>> pgpool-hackers mailing list
> >>> pgpool-hackers at pgpool.net
> >>> http://www.pgpool.net/mailman/listinfo/pgpool-hackers
> >>>
> >>>
> >>
> >>
> >> --
> >> Ahsan Hadi
> >> Snr Director Product Development
> >> EnterpriseDB Corporation
> >> The Enterprise Postgres Company
> >>
> >> Phone: +92-51-8358874
> >> Mobile: +92-333-5162114
> >>
> >> Website: www.enterprisedb.com
> >> EnterpriseDB Blog: http://blogs.enterprisedb.com/
> >> Follow us on Twitter: http://www.twitter.com/enterprisedb
> >>
> >> This e-mail message (and any attachment) is intended for the use of the
> >> individual or entity to whom it is addressed. This message contains
> >> information from EnterpriseDB Corporation that may be privileged,
> >> confidential, or exempt from disclosure under applicable law. If you are
> >> not the intended recipient or authorized to receive this for the
> intended
> >> recipient, any use, dissemination, distribution, retention, archiving,
> or
> >> copying of this communication is strictly prohibited. If you have
> received
> >> this e-mail in error, please notify the sender immediately by reply
> e-mail
> >> and delete this message.
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20160621/f9925ea1/attachment.html>