[Pgpool-general] pgpool-II 2.0.1: "pool_process_query: 1 th kind D does not match with master connection kind C" error

[Anthony MacKinnon]

Thanks for your reply.

I've added answers to yours questions below.

One thing we found in the latest documentation is that SERIAL columns
require a LOCK TABLE. We are not currently doing that and it would be
somewhat painful for us since we are using views in a lot of places. Before
we go ahead and try this, do you think that it could be causing the sync
issues we are seeing?

In order to get things working as fast as possible, it would be great to get
on a phone call with you to discuss this further. We would be happy to pay
for your time.

Regards,
Anthony

-----Original Message-----
From: Tatsuo Ishii [mailto:ishii at sraoss.co.jp] 
Sent: Monday, December 03, 2007 6:27 PM
To: perry.casson at waypointinfo.com
Cc: pgpool-general at pgfoundry.org
Subject: Re: [Pgpool-general] pgpool-II 2.0.1: "pool_process_query: 1 th
kind D does not match with
master connection kind C" error

> We are testing pgpool-II-2.0.1 in replication mode and are trying to
figure out why pgpool-II is
> deprecating.  In our cases the system will usually run fine for 30-90
minutes processing dozens of
> transactions/second then we get the following error: pool_process_query: 1
th kind D does not
match
> with master connection kind C and then pgpool drops all nodes but the
master
> 
> In every case we have found it will always happen after a specific very
large select statement
(see
> pid1118.log).  This statement is valid and similar statements have been
ran 1000's of times before
> the error occurs.

Can you be more specific? I mean If pgpool says "1 th kind D does not
match with master connection kind C", there must be data difference
among tables in both servers. Since you know the SELECT statement that
causes the error, you could manualy issues the SELECT and see
the data difference in tables. Can you veryfy it?

[Anthony] We are running in load balance mode with replication, which means
that SELECT statements do not get executed on all nodes, correct? How does
pgpool detect a data difference in this case?

> I've started to look through the source code to try to figure out what's
going on but that's going
> to be a slow process just to understand what should be happening.
> 
> Keen to get this resolved and could arrange access to these servers if
required or clues on how to
> resolve this.

How do you INSERT/UPDATE
some_customer.wp_point,wp_sentinelconfig.gpstime? If it's default to
CURRENT_TIMESTAMP, it will not be safe for pgpool since it depends on
the timing of query execution on db1 and db2, which will not be
identical.

[Anthony] We do not use CURRENT_TIMESTAMP. All the timestamps we use are
input data or generated in code before the insert.


--
Tatsuo Ishii
SRA OSS, Inc. Japan