Tatsuo,

I don't have problem with your test case either. However, I don't think this is the case as what I mentioned. Under psql, I don't have FETCH_COUNT set, and when I do a select query on a big table it may take several seconds for the results to come back. If I do a ^C before any results come back I'll get failover. Anyway, if I have the FETCH_COUNT set to 1000, then I'll see results always come back right away, in this case, the ^C, after some results displayed, does not cause problem.

Thanks,
Gary
Yes, I have tried with pgpool-II 3.0.3 and PostgresSQL 9.0.3.  I have
created a small function which just idly sleeps for 20 seconds.

create function bar() returns int as 'select pg_sleep(20);select 1' language 
'sql';

Then I call the function and hit ^C from psql session. It worked as
expected.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

Thanks for the response.  No, I did not change the pgpool.conf when I
updated postgresql from 8.4 to 9.0.4.
By the way, did you try this under your environment without problem ?

Thanks,
Gary
I don't think of any idea which explains why you have the problem with
9.0 but you don't have with 8.4. Have you changed pgpool.conf?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

Hi,

I'm running pgpool2 3.0.1 with replication mode on two postgresql
9.0.4 db servers (updated from 8.4.4).  I have the 'replicate_select'
and 'replication_stop_on_mismatch' both set to 'true'.
I just noticed that under psql, if I cancel a long select sql (before
any output displayed), I'll get the following message and the pgpool
failed over.  I don't recall this happened with 8.4.4.  Can anyone
explain why and how to avoid this ?

[sd3ops1.ops1_admin].sd3ops1>   select * from file;
Cancel request sent
ERROR: kind mismatch among backends. Possible last query was: "select
* from file;" kind details are: 0[E: canceling statement due to user
request] 1[D]
HINT:  check data consistency among db nodes
server closed the connection unexpectedly
          This probably means the server terminated abnormally
          before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.


Thanks,
Gary

_______________________________________________
Pgpool-general mailing list
[email protected]
http://pgfoundry.org/mailman/listinfo/pgpool-general

_______________________________________________
Pgpool-general mailing list
[email protected]
http://pgfoundry.org/mailman/listinfo/pgpool-general

Reply via email to