Re: Why we lost Uber as a user

Craig Ringer <craig@2ndquadrant.com>

From: Craig Ringer <craig@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Jim Nasby <Jim.Nasby@bluetreble.com>, Kevin Grittner <kgrittn@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, "Joshua D. Drake" <jd@commandprompt.com>, Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, Alfred Perlstein <alfred@freebsd.org>, Geoff Winkless <pgsqladmin@geoff.dj>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2016-08-17T14:39:16Z
Lists: pgsql-hackers
On 17 August 2016 at 21:35, Bruce Momjian <bruce@momjian.us> wrote:


>
> > I saw from the Uber article that they weren't going to per-row logical
> > replication but _statement_ replication, which is very hard to do
> > because typical SQL doesn't record what concurrent transactions
> > committed before a new statement's transaction snapshot is taken, and
> > doesn't record lock order for row updates blocked by concurrent activity
> > --- both of which affect the final result from the query.
>
> I assume they can do SQL-level replication when there is no other
> concurrent activity on the table, and row-based in other cases?


I don't know, but wouldn't want to assume that. A quick search suggests
they probably define that away as nondeterministic behaviour that's allowed
to cause master/replica differences, but no time to look deeply.

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Advance backend's advertised xmin more aggressively.

  2. Improve snapshot manager by keeping explicit track of snapshots.