On Wed, Jul 11, 2012 at 6:41 AM, Shaun Thomas <sthomas@optionshouse.com> wrote:
>> 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.
>
>
> 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
> 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.
>
> That's basically what a RAID-1 does, and people have been fine with that for
> decades.
But RAID-1 as nominally seen is a fundamentally different problem,
with much tinier differences in latency, bandwidth, and connectivity.
Perhaps useful for study, but to suggest the problem is *that* similar
I think is wrong. I think your wording is even more right here than
you suggest: "That's *basically* what a RAID-1 does".
I'm pretty unhappy with many user-facing aspects of this formulation,
even though I think the fundamental need being addressed is
reasonable. But, putting that aside, why not write a piece of
middleware that does precisely this, or whatever you want? It can live
on the same machine as Postgres and ack synchronous commit when nobody
is home, and notify (e.g. page) you in the most precise way you want
if nobody is home "for a while".
--
fdr
