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  (Geoff Winkless <pgsqladmin@geoff.dj>)
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:

Previous
From: Kouhei Kaigai
Date:
Subject: Re: Oddity in EXPLAIN for foreign/custom join pushdown plans
Next
From: Alfred Perlstein
Date:
Subject: Re: Why we lost Uber as a user