Re: Why we lost Uber as a user - Mailing list pgsql-hackers
From | Alfred Perlstein |
---|---|
Subject | Re: Why we lost Uber as a user |
Date | |
Msg-id | aa69fbf2-9fb7-0b08-f783-b0b66f7fe0fe@freebsd.org Whole thread Raw |
In response to | Re: Why we lost Uber as a user (Geoff Winkless <pgsqladmin@geoff.dj>) |
Responses |
Re: Why we lost Uber as a user
|
List | pgsql-hackers |
<p><br /><br /><div class="moz-cite-prefix">On 7/28/16 4:39 AM, Geoff Winkless wrote:<br /></div><blockquote cite="mid:CAEzk6feRoM6wMqKVsHjfyL0+GrEUDicQ+fbTBmqTtdQsSYCBGw@mail.gmail.com"type="cite"><p dir="ltr">On 28 Jul 2016 12:19,"Vitaly Burovoy" <<a href="mailto:vitaly.burovoy@gmail.com" moz-do-not-send="true">vitaly.burovoy@gmail.com</a>>wrote:<br /> ><br /> > On 7/28/16, Geoff Winkless <<a href="mailto:pgsqladmin@geoff.dj"moz-do-not-send="true">pgsqladmin@geoff.dj</a>> wrote:<br /> > > On 27 July 2016at 17:04, Bruce Momjian <<a href="mailto:bruce@momjian.us" moz-do-not-send="true">bruce@momjian.us</a>> wrote:<br/> > ><br /> > >> Well, their big complaint about binary replication is that a bug can<br /> >>> spread from a master to all 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 databasebug that<br /> > > occurs when you run a statement on the master, it seems there's a decent<br /> > >chance that that same bug is going to occur when you run the same statement<br /> > > on the slave.<br /> >><br /> > > Obviously it depends on the type of bug and how identical the slave is, but<br /> > > statement-levelreplication certainly doesn't preclude such 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, their PKs are the same, but other columns<br /> > differ).<p dir="ltr">I readthe article. It affected slaves as well as the master.<p dir="ltr">I quote:<br /> "because of the way replication works,this issue has the potential to spread into all of the databases in a replication hierarchy"<p dir="ltr">I maintainthat this is a nonsense argument. Especially since (as you pointed out and as I missed first time around) the bugactually occurred at different records on different slaves, so he invalidates his own point.<p dir="ltr">Geoff</blockquote>Seriously?<br /><br /> There's a valid point here, you're sending over commands at the blocklevel, effectively "write to disk at this location" versus "update this record based on PK", obviously this has somedrawbacks that are reason for concern. Does it validate the move on its own? NO. Does it add to the reasons to moveaway? Yes, that much is obvious.<br /><br /> Please read this thread:<br /><a class="moz-txt-link-freetext" href="https://www.reddit.com/r/programming/comments/4vms8x/why_we_lost_uber_as_a_user_postgresql_mailing_list/d5zx82n">https://www.reddit.com/r/programming/comments/4vms8x/why_we_lost_uber_as_a_user_postgresql_mailing_list/d5zx82n</a><br /><br/> Do I love postgresql? Yes. <br /> Have I been bitten by things such as this? Yes.<br /> Should the community learnfrom these things and think of ways to avoid it? Absolutely!<br /><br /> -Alfred
pgsql-hackers by date: