Postgres is not a distributed database and doesn't have a single safe default for running it in a distributed configuration, including talking to it over network. It can't claim any consistency guarantee, so there is nothing for aphyr to test it for.
Even common highly available configurations take the route of no consistency guarantees by doing primitive async replication and primitive failover.
Postgres supports multi-master replication, among other replication models. This could provide an interesting target.
In a classic single node configuration, a confirmation that its transaction isolation behaviors exhibited the corresponding anomalies would be valuable.
Postgres doesn't natively support multi-master. (Although there are a variety of open source/proprietary offerings that add support for it to various degrees.)
PostgreSQL doesn't offer multi master replication. There are extensions that do, but if aphyr will evaluate them he should emphasize that he is treating them not the PostgreSQL (unless he finds a bug in PostgreSQL itself).
I think he did something similar for MySQL when evaluating the Galera cluster.
Jepsen reports often include two distinct types of analyses: correctness in a distributed storage system under a variety of failure scenarios, and in-depth analysis of consistency claims. Both examinations are extremely helpful.
In a single write master configuration, Postgres runs transactions concurrently, so the consistency analysis is still quite relevant.
I don’t think it’s a stretch to say that everyone expects Postgres to get top marks in this configuration and it would be worth confirming that this is the case.
But it was long ago, and maybe needs to be redone?
Edit: after re-reading it he treats it as a distributed system because client and server is over network. And that is true, it can also be thought of as a distributed system because as you said transactions are concurrent and are running as separate processes. Although in these cases you can't have a partition (which aphyr uses to find weaknesses), or maybe there is something equivalent that happens?
> PostgreSQL doesn't offer multi master replication.
Not in itself, but it does offer a PREPARE TRANSACTION - COMMIT PREPARED / ROLLBACK PREPARED extension that could be used to add such support in the future. This would not be unprecedented, as the simpler case of db sharding is already being supported via the PARTITION BY feature, combined with "FOREIGN" database access.
i'm not sure what you mean by pg not being a "distributed" database. it has replication and sharding functionalities that let it run in various clustering configuration. This looks enough to me to qualify it for aphyr tests.
Replication is read only, so at worst there's only delay when it is set up asynchronously, but ultimately it will be the same as master. The sharding part, do you mean FDW? I don't think PostgreSQL gives any consistency guarantees if you use them.
Even common highly available configurations take the route of no consistency guarantees by doing primitive async replication and primitive failover.