with the exception that this will never be consistent.
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).
If handling transactions isn't feasible for BDR, then it should refuse BEGIN's instead of accepting them and silently corrupting data.
If handling transactions across tables isn't feasible for BDR, it should blow up once you touch more than one table, forcing you to roll the whole transaction (which has so far only touched one table) back.
It's totally fine if your tool can't do $THING. Especially in matters of multi master replication which is a really hard problem. However, I would really want your tool to be honest about its deficiencies and tell me so I can try to find a workaround.
(Of course this could also just be a "simple" bug at which point, you can disregard this rant and just fix the issue :p)
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.
I stand corrected. Still, it would be useful if there was a mode when it blew up because that would make sure the data is always consistent even if the application forgets to check the historical table.
> which might be one of the reasons why the BDR patches haven't been accepted yet
That's primarily because they've not been submitted as a whole. Many individual parts of BDR have been submitted & integrated into postgres. Simplified versions of others (the logical decoding output plugin, the apply side, replication set management) have been submitted recently and are being reviewed. I don't think any major part has been wholly rejected - changed during review, surely and heavily.
Two servers independently committed conflicting transactions, which is always a possibility for multi-master in the general case. You can't have independence and dependence on the same variable at the same time.
Now, maybe BDR could do better for the case the author is concerned about, but the author hasn't explained what it should do and why it's better.
The author seems to want the entire conflicting transaction to be rejected, but it's already been committed on the remote node so I don't see how that helps. They will never be back in sync again until you sort it out.
You should use BDR in cases where you can come up with some reasonable conflict resolution. For instance, allow inventory to go negative, and inform one customer of a delay with their order.
In many scenarios these restrictions are unacceptable, and dealing with potential inconsistencies is the smaller (but y no means small) evil. If you indeed need it, you need to design your spoliation accordingly.
There are workloads where it's easy to deal with such problems. If there are only inserts, without constraints there often not much to do. In other cases you can simply accept rare inconsistencies.
Quite often the majority of writes don't need to care, but a small portion needs to be much more careful. E.g by using distributed 2pc, or BT always going through a specific node.
Then there is Oracle's MySQL Cluster (never seen that in production, no idea how well it works) and Percona's MariaDB Galera Cluster, which… well: https://aphyr.com/posts/328-jepsen-percona-xtradb-cluster
What MySQL calls "master master" is actually "master slave".
> "You would be paying that 70ms cost four different times."
Right, and either you're willing to pay that cost OR temporary inconsistency is acceptable to you. BDR doesn't warp the speed of light.
Also: If bank accounts are involved, inconsistency is not acceptable. Someone will bankrupt you. That's not BDR's fault.
Fun fact: a large portion of bank accounting systems are not fully consistent. It's a but scary at first, but of you think about it, it's not that surprising: e.g. not all ATMs and shops are always online, particularly in the past. Many systems also couldn't and some still can't, keep up with the full load on peak times in a central manner.
FWIW: I'm not particularly happy about the name either. But we fought over names so long that agreeing on something subpar was better than not having the feature. It was originally named changeset extraction. Not sure if that'd have been better.