Re: Synchronous Standalone Master Redoux - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Synchronous Standalone Master Redoux
Date
Msg-id m2liiq72ca.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: Synchronous Standalone Master Redoux  (Shaun Thomas <sthomas@optionshouse.com>)
List pgsql-hackers
Shaun Thomas <sthomas@optionshouse.com> writes:
>> Regardless of what DRBD does, I think the problem with the
>> async/sync duality as-is is there is no nice way to manage exposure
>> to transaction loss under various situations and requirements.

Yeah.

> Which would be handy. With synchronous commits, it's given that the protocol
> is bi-directional. Then again, PG can detect when clients disconnect the
> instant they do so, and having such an event implicitly disable

It's not always possible, given how TCP works, if I understand correctly.

> synchronous_standby_names until reconnect would be an easy fix. The database
> already keeps transaction logs, so replaying would still happen on
> re-attach. It could easily throw a warning for every sync-required commit so
> long as it's in "degraded" mode. Those alone are very small changes that
> don't really harm the intent of sync commit.

We already have that, with the archives. The missing piece is how to
apply that to Synchronous Replication…

> That's basically what a RAID-1 does, and people have been fine with that for
> decades.

… and we want to cover *data* availability (durability), not just
service availability.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support


pgsql-hackers by date:

Previous
From: Shaun Thomas
Date:
Subject: Re: Synchronous Standalone Master Redoux
Next
From: Tom Lane
Date:
Subject: Re: Support for array_remove and array_replace functions