jinhualuo

Yes, if multi-masters change the same rows of same table, it would cause conflict.

Consensus protocol like raft, has limitation: it requires low delay among the nodes, so normally, it would be deployed in the same data-center. Moreover, if all changes (conflict or not), handled by consensus protocol, the performance would be bad. In fact, data-centers are normally loose coupling (the application normally choose the same data-center as the data source/target). So data-centers just need somehow light-weighted conflict resolution.

pgcat lww, just like Cassandra, provides counter column concept, which is used to retain each change among data-centers, and simple aggregation helper function there. pgcat lww is done by pg trigger, so if you need customization of your business, you could modify the trigger function to fit it.

I would try to do more test for performance, especially in product environment.

Detect the target table is easy, but it seems tricky to redirect the flow to pg build-in logical replication (not necessary to re-implement it, especially it was written in C language, so redirection is the right way).

In fact, you could use pg logical replication directly for some cases like big and real-time data flows. But currently, it has one big flaw: bi-directional replication or multi-master replication is impossible, where it would cause dead cycle loops, because it do not filter any origin currently, you could check function pgoutput_origin_filter.

And, even if the filter is right, it still lacks of conflict solution, but pgcat could help there, and you don't need to use pgcat, because pgcat has trigger way to resolve conflict, you could check pgcat_setup_lww command.

Yes, the template generated sql would bring some overhead. But it's the cost for flexibility: The target table would not be limited to base table. It could be a view, a foreign table, partitioned table, or citus distributed table. And, it also support table name mapping.