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
