> Silently corrupting data goes totally against the usual Postgres spirit (which might be one of the reasons why the BDR patches haven't been accepted yet). Nor

> Silently corrupting data goes totally against the usual Postgres spirit (which might be one of the reasons why the BDR patches haven't been accepted yet). Normally, if $THING can't be guaranteed to be done right, then Postgres just doesn't offer the feature (or throws a specific error). There's a good set of scenarios, particularly globally distributed datastores, where latency makes it infeasible to make strong guarantees. That's what BDR was designed for. That's why you can configure conflict handling and add conflict handlers to resolve conflicts. And it's not "silently corrupting" things - it's logging the conflicts to postgresql's log and, if configured, to a historical table. > If handling transactions isn't feasible for BDR, then it should refuse BEGIN's instead of accepting them and silently corrupting data. That just depends on what you define as "handling transactions". You can have multi statement transactions which are atomic - something rather useful for a lot of usecases. Other sessions, on any node, will never see a partially applied set of DML from within a transaction. Also useful. I agree that it'd be helpful to expand BDR docs on the specifics of what consistency to expect when doing what.