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:[EMAIL PROTECTED] > Sent: Monday, December 03, 2007 6:27 PM > To: [EMAIL PROTECTED] > Cc: pgpool-general@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 > _______________________________________________ Pgpool-general mailing list Pgpool-general@pgfoundry.org http://pgfoundry.org/mailman/listinfo/pgpool-general