Re: Why we lost Uber as a user
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: Robert Haas <robertmhaas@gmail.com>,
Alfred Perlstein <alfred@freebsd.org>,
Geoff Winkless <pgsqladmin@geoff.dj>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2016-08-02T21:14:30Z
Lists: pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes: > With physical replication, there is the concern that a bug in *just* the > physical (WAL) side of things could cause corruption. Right. But with logical replication, there's the same risk that the master's state could be fine but a replication bug creates corruption on the slave. Assuming that the logical replication works by issuing valid SQL commands to the slave, one could hope that this sort of "corruption" only extends to having valid data on the slave that fails to match the master. But that's still not a good state to be in. And to the extent that performance concerns lead the implementation to bypass some levels of the SQL engine, you can easily lose that guarantee too. In short, I think Uber's position that logical replication is somehow more reliable than physical is just wishful thinking. If anything, my money would be on the other way around: there's a lot less mechanism that can go wrong in physical replication. Which is not to say there aren't good reasons to use logical replication; I just do not believe that one. regards, tom lane
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