[Pgpool-general] pgpool detected difference of the number of inserted, updated, or deleted ...etc..

[Tatsuo Ishii]

Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

> When set to true, if a SELECT statement returns a result set of records
> different between the backends, the backends that differ from most
> frequent result set are degenerated. This is only valid if the SELECT
> statement is part of a transaction and replicate_select is set to true.
> If set to false, the session is terminated and the backends are not
> degenerated. Default is false.
> 
> - -Ramon
> 
> 
> On 06/08/2010 09:49 PM, Tatsuo Ishii wrote:
> > Thanks. Actgually "the backends that differ from the master are
> > degenerated" is different from the current implementaion. To choose
> > the victim backend, we use "decide by majority". Suppose we have 3
> > nodes and they return:
> > 
> > Node 0: A
> > Node 1: B
> > Node 2: B
> > 
> > Then the victim is Node 0.
> > 
> > Suppose we have 4 nodes:
> > 
> > Node 0: A
> > Node 1: A
> > Node 2: B
> > Node 3: B
> > 
> > Unfortunately no one looses. In this case we chose Node 2 & 3 as
> > victims since Node 0 votes A.
> > 
> > Can you please modify your proposal?
> > --
> > Tatsuo Ishii
> > SRA OSS, Inc. Japan
> > English: http://www.sraoss.co.jp/index_en.php
> > Japanese: http://www.sraoss.co.jp
> > 
> >> Here is my suggestion:
> >>
> >> When set to true, if a SELECT statement returns a result set of records
> >> different between the backends, the backends that differ from the master
> >> are degenerated. This is only valid if the SELECT statement is part of a
> >> transaction and replicate_select is set to true. If set to false, the
> >> session is terminated and the backends are not degenerated. Default is
> >> false.
> >>
> >> - -Ramon
> >>
> >>
> >> On 06/06/2010 10:25 PM, Tatsuo Ishii wrote:
> >>>> 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
> >>> Pgpool-general at pgfoundry.org
> >>> http://pgfoundry.org/mailman/listinfo/pgpool-general
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.10 (GNU/Linux)
> >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >>
> >> iEYEARECAAYFAkwO160ACgkQGIS0iEuhp4MFVACdFrC9kvAvN20wz3PK4afu3f15
> >> dRoAoMaVA1bwxHlQt3oXAPL6nQ2qpGB8
> >> =bEVA
> >> -----END PGP SIGNATURE-----
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkwPEU8ACgkQGIS0iEuhp4PYsQCfXgV5AoZeei4a9kyhNW5kcAPB
> StwAoJWzjEEtp0dEL7XhOytM65w1u2ww
> =Z9Qr
> -----END PGP SIGNATURE-----