[Pgpool-general] parameters replication_stop_on_mismatch

Lazaro Rubén García Martinez lgarciam at vnz.uci.cu
Mon Jun 27 13:53:35 UTC 2011


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: pgpool-general-bounces at pgfoundry.org [pgpool-general-bounces at pgfoundry.org] En nombre de Diego Ayala [netdiego81 at gmail.com]
Enviado el: lunes, 27 de junio de 2011 8:59
Para: pgpool-general at pgfoundry.org
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



More information about the Pgpool-general mailing list