> BTW : what is 'replication_stop_on_mismatch' and has it got anything to do > with this issue ?
replication_stop_on_mismatch only affects SELECT. So it does not anything to do with the issue. I have to admit that current document regarding replication_stop_on_mismatch is quite incorrect and hard to understand: "When set to true, pgpool-II degenerates the backends and keeps the service only with the Master DB if data mismatch occurs. If false, pgpool-II just terminates the query. Default is false." Probably enhanced description for this would be something like this. Please correct or raise questions. Grammatical corrections are welcome as well. "When set to true, if a backend returns different number of rows from other backends return in SELECT (or SHOW), pgpool-II degenerates it. This only take effects when the SELECT is running in an explicit transaction and replicate_select is set to true. If false, pgpool-II just terminates the session. Default is false." -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
