<p dir="ltr">On 28 Jul 2016 12:19, "Vitaly Burovoy" <<a
href="mailto:vitaly.burovoy@gmail.com">vitaly.burovoy@gmail.com</a>>wrote:<br /> ><br /> > On 7/28/16, Geoff
Winkless<<a href="mailto:pgsqladmin@geoff.dj">pgsqladmin@geoff.dj</a>> wrote:<br /> > > On 27 July 2016 at
17:04,Bruce Momjian <<a href="mailto:bruce@momjian.us">bruce@momjian.us</a>> wrote:<br /> > ><br /> >
>>Well, their big complaint about binary replication is that a bug can<br /> > >> spread from a master
toall slaves, which doesn't happen with statement<br /> > >> level replication.<br /> > ><br /> >
><br /> > > I'm not sure that that makes sense to me. If there's a database bug that<br /> > > occurs
whenyou run a statement on the master, it seems there's a decent<br /> > > chance that that same bug is going to
occurwhen you run the same statement<br /> > > on the slave.<br /> > ><br /> > > Obviously it depends
onthe type of bug and how identical the slave is, but<br /> > > statement-level replication certainly doesn't
precludesuch a bug from<br /> > > propagating.<br /> > ><br /> > > Geoff<br /> ><br /> >
Please,read the article first! The bug is about wrong visibility of<br /> > tuples after applying WAL at slaves.<br
/>> For example, you can see two different records selecting from a table<br /> > by a primary key (moreover,
theirPKs are the same, but other columns<br /> > differ).<p dir="ltr">I read the article. It affected slaves as well
asthe master.<p dir="ltr">I quote:<br /> "because of the way replication works, this issue has the potential to spread
intoall of the databases in a replication hierarchy"<p dir="ltr">I maintain that this is a nonsense argument.
Especiallysince (as you pointed out and as I missed first time around) the bug actually occurred at different records
ondifferent slaves, so he invalidates his own point.<p dir="ltr">Geoff