3 ms·

From their own documentation the use case is reliable replication, and even reads would be horribly slow: "The drawbacks are high latency in both reads and wri

From their own documentation the use case is reliable replication, and even reads would be horribly slow: "The drawbacks are high latency in both reads and writes and low throughput. Pg_paxos cannot be used for high performance transactional systems. But it can serve very well for low-bandwith, reliable replication use cases."

dijit 10y ago
Better to wait for postgresql 9.6 which will have synchronous replication, write latency but not read. http://michael.otacoo.com/postgresql-2/postgres-9-6-feature-highlight-multi-sync-rep/ http://michael.otacoo.com/postgresql-2/postgres-9-6-feature-...
- ahachete 10y ago
  PostgreSQL supports synchronous replication since 9.1. What 9.6 will have is support for more than one synchronous replicated server. In any case, synchronous replication means that all of the participating servers have to participate in the replication process. If one of them slows down or hangs, replication (and your transaction) does not proceed. Paxos, on the contrary, can proceed when N/2+1 of the nodes are available. That's a huge difference, and it's irrespective of the latency and performance. In other words: while 9.6's synchronous replication is a really welcomed addition, a single miss-behaving node will halt transactions on the cluster, while pg_paxos will continue operating without problems. Both are meant for different use cases.
  - teraflop 10y ago
    This isn't quite true. As described in that blog post, you can configure Postgres to synchronously replicate to N servers but only wait for M responses. With M=N/2+1, you get the same availability as Paxos. The difference is that with Postgres' replication, when the master fails, write operations can't be executed until a new master is promoted. This has to be done carefully, because you want to make sure that no in-flight operations are still happening on the old master (aka STONITH), and that the most up-to-date slave becomes the new master. Paxos avoids the need for manual (or very delicately-automated) failover, at the cost of extra network round-trips and disk syncs on every operation.
    - ahachete 10y ago
      You are right. If you, effectively, configure it for M responses, you get the same availability. But there are more differences between both setups: - Paxos is master-less, so you can write to any node (there's no need for a master). - Failover is very tough to get it right. Indeed, other than consensus, there are no other bullet-proof solutions to achieve it under any circumstance, so relying on a master is a significant difference. Regarding the extra round-trips and syncs, they can be pipelined if wanted too. I wouldn't conclude this is necessarily slower (it of course depends on the Paxos imlementation) until properly benchmarked.
mslot 10y ago
Reads do involve making some network round-trips, but it's only a few milliseconds and there's no specific throughput limitation. Write throughput is limited by network latency. There is also a relaxed consistency mode in pg_paxos, which avoids making round-trips on reads, but might give stale results in case of failure.

dijit 10y ago

Better to wait for postgresql 9.6 which will have synchronous replication, write latency but not read. http://michael.otacoo.com/postgresql-2/postgres-9-6-feature-highlight-multi-sync-rep/ http://michael.otacoo.com/postgresql-2/postgres-9-6-feature-...

ahachete 10y ago
PostgreSQL supports synchronous replication since 9.1. What 9.6 will have is support for more than one synchronous replicated server. In any case, synchronous replication means that all of the participating servers have to participate in the replication process. If one of them slows down or hangs, replication (and your transaction) does not proceed. Paxos, on the contrary, can proceed when N/2+1 of the nodes are available. That's a huge difference, and it's irrespective of the latency and performance. In other words: while 9.6's synchronous replication is a really welcomed addition, a single miss-behaving node will halt transactions on the cluster, while pg_paxos will continue operating without problems. Both are meant for different use cases.
- teraflop 10y ago
  This isn't quite true. As described in that blog post, you can configure Postgres to synchronously replicate to N servers but only wait for M responses. With M=N/2+1, you get the same availability as Paxos. The difference is that with Postgres' replication, when the master fails, write operations can't be executed until a new master is promoted. This has to be done carefully, because you want to make sure that no in-flight operations are still happening on the old master (aka STONITH), and that the most up-to-date slave becomes the new master. Paxos avoids the need for manual (or very delicately-automated) failover, at the cost of extra network round-trips and disk syncs on every operation.
  - ahachete 10y ago
    You are right. If you, effectively, configure it for M responses, you get the same availability. But there are more differences between both setups: - Paxos is master-less, so you can write to any node (there's no need for a master). - Failover is very tough to get it right. Indeed, other than consensus, there are no other bullet-proof solutions to achieve it under any circumstance, so relying on a master is a significant difference. Regarding the extra round-trips and syncs, they can be pipelined if wanted too. I wouldn't conclude this is necessarily slower (it of course depends on the Paxos imlementation) until properly benchmarked.

mslot 10y ago

Reads do involve making some network round-trips, but it's only a few milliseconds and there's no specific throughput limitation. Write throughput is limited by network latency. There is also a relaxed consistency mode in pg_paxos, which avoids making round-trips on reads, but might give stale results in case of failure.