[Pgpool-general] General pgpool locking issues

Tatsuo Ishii ishii at sraoss.co.jp
Sat Aug 5 02:03:54 UTC 2006


> On 8/2/06, Tatsuo Ishii <ishii at sraoss.co.jp> wrote:
> > > We turned debugging on and basically its finding a kind mismatch on a
> > > standard select.
> > >
> > > Ill try to pull together some logging data and send it your way.
> >
> > Ok.
> >
> > > Let me
> > > know what you find out about the weight distribution piece. Thanks.
> >
> > I found that pgpool does not allow weight = 0 and believe this is an
> > oversight. However load balance should work fine whatever weight is,
> > since in the load balance mode SELECT query should be sent to one of
> > the servers, not both and this means kind mismatch error should not
> > happen. I will wait for your logging data to find out what is wrong.

While waiting for reply back from John, I response to your concerns:

> I also have this "kind mismatch", that's why I'm not sure to keep
> using pgpool for replication. I haven't tried yet to use the load
> balance solution so my question can be inappropriate. If the SELECT
> request is sent only to one DB server, how can you know about a real
> database corruption ? If pgpool goes on sending datas to both DB, they
> can be different (because of a network problem or whatever) and no
> alarm will be sent...

Since both pgpool and PostgreSQL uses TCP/IP for communication, there
could be no data corruption on the wire. If you are experiencing that,
you might want to change you OS.

In my understanding "kind mismatch" errors occur when the user fail to
use appropreate locking technique(John's case seems the
exception. that's why I need to investigate).

pgpool allow users to choose appropreate locking strategy since the
strictness of data locking will be different for different use
case. 

BTW as far as I know, there's no replication system which checks data
consistency after replicating data. (check Slony-I for an example).

The bottom line is "kind mismatch" errors do not suggest the data
corruption, rather warn the your usage of pgpool.
--
Tatsuo Ishii
SRA OSS, Inc. Japan


More information about the Pgpool-general mailing list