HN Reader

Interesting, i always see attempts to make these types of database tools as super interesting but then I think about all the undocumented edge cases that can come up and they scare me off.

Many many years ago I worked on a monitoring tool that itself needed to be highly available, and we needed a solution like this. Ever since that time I've done everything in my power to avoid it.

What are the real world cases you built this for? And how can someone like me who has been bruised by past experiences get comfortable with it?

Bear in mind this no longer provides the same consistency model as PostgreSQL does. It's not a straightforward extension of the nice serializable world. That might not be what you expect given the name, this does not provide a strict serializable consistency model.

See https://jepsen.io/consistency/models for a classification of consistency models.

What are the pros and cons of this compared to CockroachDB?

You do not want multi-master. If you think you do, think again.

Source: I have operated a large multi-master Postgres cluster.

If both nodes approve an update on the same primary key, what happens? I don't see this crucial detail described in the README

how do they resolve write conflict????

Hi, How do You guys resolve the application database DDL issue when multimaster is in use? One node gets updated, DDL is will be replicated (?) to second node, which is used by not-jet-updated application which is not compatible with updated database structure. This problem has bugged me for a while. And second and similar issue with most replication setups is let's take for postgis for example. Again in one node this extension gets updated. Now what? Data will be replicated to node which is not jet updated and cause whole system to be not functional.

pgactive?

Third party, multi master postgres is such an old idea, it was done in Perl...

https://github.com/bucardo/bucardo