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

[Tatsuo Ishii]

Sorry for the delay.

We are doing a commercial support for pgpool. The pricing is 800,000
Japanese yen excluding TAX(about US $7k) per year including up to 4
PostgreSQL servers' support. If it's too high, I'd be happy to
continue the community support.

Any way...

Yes, this is a question too.

> [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?

One possibility is, the SELECT statement is inside a transaction.
Can you set log_statement = true so that you could see the SELECT
statement which causes the problem?
--
Tatsuo Ishii
SRA OSS, Inc. Japan

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