Re: Why we lost Uber as a user
Greg Stark <stark@mit.edu>
From: Greg Stark <stark@mit.edu>
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-03T10:29:39Z
Lists: pgsql-hackers
On Wed, Aug 3, 2016 at 3:30 AM, Alfred Perlstein <alfred@freebsd.org> wrote: > We may be saying the same thing, but still there is something to be said for > logical replication... also, didnt they show that logical replication was > faster for some use cases at Uber? There is certainly something to be said for logical replication just as there is something to be said for having regular pg_dumps which are logical exports of your database. But neither is a substitute for having real backups or a real standby database. They serve different purposes and solve different problems. But when you have a hardware failure or physical disaster the last thing you want to be doing is failing over to a different database that may or may not have the same data or same behaviour as your former primary. You want to switch over to a standby that is as near as possibly byte for byte identical and will behave exactly the same. If there was a bug in your primary the last time you want to find out about it and have to be dealing with fixing it is when you have a disaster in your primary and need to be back up asap. Honestly the take-away I see in the Uber story is that they apparently had nobody on staff that was on -hackers or apparently even -general and tried to go it alone rather than involve experts from outside their company. As a result they misdiagnosed their problems based on prejudices seeing what they expected to see rather than what the real problem was. -- greg
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