Horton
Menu

Re: Why we lost Uber as a user

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndquadrant.com>
To: Greg Stark <stark@mit.edu>
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-17T19:51:57Z
Lists: pgsql-hackers 
On 17 August 2016 at 12:19, Greg Stark <stark@mit.edu> wrote:
> On Wed, Aug 17, 2016 at 1:36 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> Something I didn't see mentioned that I think is a critical point: last I
>> looked, HOT standby (and presumably SR) replays full page writes. That means
>> that *any* kind of corruption on the master is *guaranteed* to replicate to
>> the slave the next time that block is touched. That's completely the
>> opposite of trigger-based replication.
>
> Yes, this is exactly what it should be doing and exactly why it's
> useful. Physical replication accurately replicates the data from the
> master including "corruption" whereas a logical replication system
> will not, causing divergence and possible issues during a failover.

Yay! Completely agree.

Physical replication, as used by DRBD and all other block-level HA
solutions, and also used by other databases, such as Oracle.

Corruption on the master would often cause errors that would prevent
writes and therefore those changes wouldn't even be made, let alone be
replicated.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, 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.