[Pgpool-general] "kind does not match"

[Jeff Davis]

On Wed, 2006-10-18 at 13:06 -0400, Bill Moran wrote:
> In response to Jeff Davis <pgpool at j-davis.com>:
> 
> > On Wed, 2006-10-18 at 11:48 -0400, Bill Moran wrote:
> > > googles on this have turned up nothing.
> > > 
> > > I'm running two instances of PostgreSQL 8.1.4 on the same machine 
> > > (different ports) for evaluation purposes.  pgpool seems to be starting
> > > fine, but I can't connect with psql:
> > > # psql -U pgsql -h 127.0.0.1 -p 9999 template1
> > > psql: server closed the connection unexpectedly
> > >         This probably means the server terminated abnormally
> > >         before or while processing the request.
> > > 
> > > Running pgpool with -nd reveals the following error when I try to
> > > connect:
> > > 2006-10-18 11:40:03 DEBUG: pid 55189: I am 55189 accept fd 6
> > > 2006-10-18 11:40:03 DEBUG: pid 55189: Protocol Major: 1234 Minor: 5679 database:  user:
> > > 2006-10-18 11:40:03 DEBUG: pid 55189: SSLRequest: sent N; retry startup
> > > 2006-10-18 11:40:03 DEBUG: pid 55189: Protocol Major: 3 Minor: 0 database: template1 user: pgsql
> > > 2006-10-18 11:40:03 ERROR: pid 55189: read_kind: kind does not match between backends master(82) secondary(69)
> > > 
> > > What does that mean?  Do I need to provide config files or any more
> > > information?
> > 
> > I think that happens when you have load_balance_mode false and
> > replication on. Pgpool will select from both servers and if the results
> > don't match, it causes that error.
> > 
> > I don't use that mode, so I could be mistaken. Hope this helps.
> 
> Thanks for the input, Jeff, but setting load_balance_mode to true doesn't
> change the behaviour.
> 


Ah, I think this might be the problem (this is from the docs in the
tarball, but doesn't appear on the site):

"
Deadlocks
Deadlocks across the backends cannot be detected. For example:

(tellers table is partitioned using the following rule)
  tid <= 10  --> node 0
  tid >= 10  --> node 1

A) BEGIN;
B) BEGIN;
A) SELECT * FROM tellers WHERE tid = 11 FOR UPDATE;
B) SELECT * FROM tellers WHERE tid = 1 FOR UPDATE;
A) SELECT * FROM tellers WHERE tid = 1 FOR UPDATE;
B) SELECT * FROM tellers WHERE tid = 11 FOR UPDATE;
In the case above, a single node cannot detect the deadlock, so pgpool-
II will continually wait for the response. This phenomenon occurs with
other queries that acquire row level locks. To avoid this problem, set
replication_timeout.

Also, if a deadlock occurs in one node, transaction states in each node
will not be consistent. Therefore, pgpool-II terminates the process if a
deadlock is detected.

pool_read_kind: kind does not match between master(84) slot[1] (69)
"

Are deadlocks on one node a possible problem?

If not, send the config and maybe that will reveal something.

Regards,
	Jeff Davis