Re: Why we lost Uber as a user
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Alfred Perlstein <alfred@freebsd.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>, Robert Haas <robertmhaas@gmail.com>, Geoff Winkless <pgsqladmin@geoff.dj>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2016-08-03T13:33:07Z
Lists: pgsql-hackers
On Tue, Aug 2, 2016 at 10:33:15PM -0400, Bruce Momjian 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. > > So, for statement replication, it is not a question of whether the code > has bugs, but that the replay is not 100% possible in all cases, unless > you switch to some statement-row-lock hybrid ability. Oh, and one more problem with statement-level replication is that the overhead of statement replay is high, as high as it was on the master. That leaves minimal server resources left to handle read-only workloads on the slave. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Advance backend's advertised xmin more aggressively.
- 94028691609f 9.5.0 cited
-
Improve snapshot manager by keeping explicit track of snapshots.
- 5da9da71c44f 8.4.0 cited