Re: Why we lost Uber as a user
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Alfred Perlstein <alfred@freebsd.org>
Cc: Geoff Winkless <pgsqladmin@geoff.dj>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2016-08-02T19:46:48Z
Lists: pgsql-hackers
On Tue, Aug 2, 2016 at 3:07 PM, Alfred Perlstein <alfred@freebsd.org> wrote: > You are quite technical, my feeling is that you will understand it, however it will need to be a self learned lesson. I don't know what this is supposed to mean, but I think that Geoff's point is somewhat valid. No matter how you replicate data, there is always the possibility that you will replicate any corruption along with the data - or that your copy will be unfaithful to the original. The possible advantage of logical replication rather than physical replication is that any errors you replicate will be logical errors rather than physical errors - so if the heap gets out of step with the indexes on the master, the same problem will not necessarily occur on the slave. On the flip side, despite what Uber found in their environment, physical replication tends to be high-performance because the replay is dead simple. Andres and others have done a good job making our logical decoding facility fast, but I believe it's still slower than plain old physical replication and probably always will be, and the trigger-based logical replication solutions are slower still. Consequently, I believe that both physical and logical replication have advantages, and that's why we should support both of them. Then, each individual user can make the trade-offs they prefer. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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