From: | Alfred Perlstein <alfred(at)freebsd(dot)org> |
---|---|
To: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why we lost Uber as a user |
Date: | 2016-08-02 19:07:56 |
Message-ID: | D7C3E84D-0ACD-406F-B0FB-D22B3EF020B2@freebsd.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Aug 2, 2016, at 2:33 AM, Geoff Winkless <pgsqladmin(at)geoff(dot)dj> wrote:
>
>> On 2 August 2016 at 08:11, Alfred Perlstein <alfred(at)freebsd(dot)org> wrote:
>>> On 7/2/16 4:39 AM, Geoff Winkless wrote:
>>> 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.
>
>> Seriously?
>
> No, I make a habit of spouting off random arguments to a list full of
> people whose opinions I massively respect purely for kicks. What do
> you think?
>
>> 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.
>
> Writing values directly into file offsets is only problematic if
> something else has failed that has caused the file to be an inexact
> copy. If a different bug occurred that caused the primary key to be
> corrupted on the slave (or indeed the master), PK-based updates would
> exhibit similar propagation errors.
>
> To reiterate my point, uber's described problem came about because of
> a bug. Every software has bugs at some point in its life, to pretend
> otherwise is simply naive. I'm not trying to excuse the bug, or to
> belittle the impact that such a bug has on data integrity or on uber
> or indeed on the reputation of PostgreSQL. While I'm prepared to
> accept (because I have a job that requires I spend time on things
> other than digging through obscure reddits and mailing lists to
> understand more fully the exact cause) that in _this particular
> instance_ the bug was propagated because of the replication mechanism
> (although I'm still dubious about that, as per my comment above), that
> does _not_ preclude other bugs propagating in a statement-based
> replication. That's what I said is a nonsense argument, and no-one has
> yet explained in what way that's incorrect.
>
> Geoff
Geoff,
You are quite technical, my feeling is that you will understand it, however it will need to be a self learned lesson.
-Alfred
From | Date | Subject | |
---|---|---|---|
Next Message | Vladimir Sitnikov | 2016-08-02 19:09:03 | Re: Slowness of extended protocol |
Previous Message | Robert Haas | 2016-08-02 18:55:06 | Re: TODO item: Implement Boyer-Moore searching in LIKE queries |