I prefer set this parameter to true by knowing if there is a synchronization problem in the servers, in the other hand, if in the servers there is a problem like this, the users should not be affected. In the oficial documentation says:
When set to true, if all backends don't return the same packet kind, the backends that differ from most frequent result set are degenerated. A typical use case is a SELECT statement part of a transaction, replicate_select set to true, and SELECT returning a different number of rows among backends. Non-SELECT statements might trigger this though. For example, a backend succeeded in an UPDATE, while others failed. Note that pgpool does NOT examine the content of records returned by SELECT. If set to false, the session is terminated and the backends are not degenerated. Default is false. Regards. ________________________________________ De: [email protected] [[email protected]] En nombre de Diego Ayala [[email protected]] Enviado el: lunes, 27 de junio de 2011 8:59 Para: [email protected] Asunto: [Pgpool-general] parameters replication_stop_on_mismatch Good morning, I have installed the 3.0.3 version of pgPool-II, I wonder what benefits would have true or false triggering, the parameter replication_stop_on_mismatch, which is the recommended option ..? thanks, Diego _______________________________________________ Pgpool-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
