Shaun Thomas <stho...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
