-Original Message-
From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
Sent: Wed 7/28/2010 7:08 PM
To: guilla...@lelarge.info
Cc: Sean Brown; pgpool-general@pgfoundry.org
Subject: Re: [Pgpool-general] Order of Query Results
Le 28/07/2010 17:16, Sean Brown a écrit :
On Wednesday, July 28, 2010 10:56:27 am you wrote:
Le 28/07/2010 16:50, Sean Brown a écrit :
Does PgPool have an issue with the order of results from a query being
returned in a different order?
With the ongoing issue of our cluster falling out, we just had one member
fall out again and again, no error in PostgreSQLs log is recorded.
PgPool reports the possible last query was:
select * from carts where cart_id in (11835,11824,11819)
Specifically the error in PgPools log is:
read_kind_from_backend: 1 th kind D does not match with master or
majority connection kind ^@
2010-07-28 10:21:23 ERROR: pid 28242: kind mismatch among backends.
Possible last query was: select * from carts where cart_id in
(11835,11824,11819) kind details are: 1[D]
If I run that query on the remaining node and on the one that just fell
out, I get the same 3 results, but the orders of the records are
different.
The query you show doesn't ask for a specific order (no ORDER BY
clause), so each backend can send the data in whatever order they prefer.
That I understand, what I am wondering is if this will cause PgPool to
believe
there is an error in the information returned from the backends, even if
the
only difference is the difference in order?
If it does, I assume the best way to deal with it is add order by's to
every
query passed to pgpool?
That's actually really good questions, and I don't have an answer to
them. CC back the list to know if other people have an answer to give us.
No, pgpool does not care about the order of data returned by SELECT.
More details...
PostgreSQL returns data packet like this:
T(descriptions about tuple)
D(actual one raw tuple data)
D
D
:
:
C(indicates succeeded in sending data)
where each single capital letter is packet kind(see PostgreSQL docs
for more details). What pgpool actually does is, checking the packet
kind, not content of tuple data. So as long as same number of tuples
are returned from each backend, pgpool is happy.
I'm not sure what pgpool version Sean's uses, it seems it's a little
bit old (from the error message I guess). Also, majority connection
kind ^@ looks strange. ^@ = 0x00, which is not valid kind at all.
It seems something unusual is going on...
If self cantained test case is provided, I will be able to look into
this.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
Host is CentOS 5.5, PostgreSQL 8.4.4 and PgPool is 2.3.3
And just in case it matters, The ordering system we use that is the primary
user of our database is using a very old Python (1.5) and the old pg connector.
The test case is sort of an issue. We haven't been able to actually narrow down
any one thing that causes our problems. Usually, there are no errors printed
anywhere around the time where a node falls out. I had turned child_life_time
from 120 to 0 wondering if PgPool was killing a child that had a persistent
connection open (It seems FexEx shipping tool is kind of stupid in that way)
and pgpool held it together for a few days longer then usual, but eventually it
still fell apart.
Maybe the next time it dies (probably tomorrow) I'll have more log information.
___
Pgpool-general mailing list
Pgpool-general@pgfoundry.org
http://pgfoundry.org/mailman/listinfo/pgpool-general
