Re: Why we lost Uber as a user

From: Alfred Perlstein <alfred(at)freebsd(dot)org>
To: Geoff Winkless <pgsqladmin(at)geoff(dot)dj>, Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Why we lost Uber as a user
Date: 2016-08-02 07:11:05
Message-ID: aa69fbf2-9fb7-0b08-f783-b0b66f7fe0fe@freebsd.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

There's a valid point here, you're sending over commands at the block
level, effectively "write to disk at this location" versus "update this
record based on PK", obviously this has some drawbacks that are reason
for concern. Does it validate the move on its own? NO. Does it add to
the reasons to move away? Yes, that much is obvious.

Please read this thread:
https://www.reddit.com/r/programming/comments/4vms8x/why_we_lost_uber_as_a_user_postgresql_mailing_list/d5zx82n

Do I love postgresql? Yes.
Have I been bitten by things such as this? Yes.
Should the community learn from these things and think of ways to avoid
it? Absolutely!

-Alfred

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alfred Perlstein 2016-08-02 07:12:59 Re: Why we lost Uber as a user
Previous Message Kouhei Kaigai 2016-08-02 06:29:22 Re: Oddity in EXPLAIN for foreign/custom join pushdown plans