Tom Lane wrote:
Fujii Masao <masao.fu...@gmail.com> writes:
The problem is that fsync needs to be issued too frequently, which would
be harmless in asynchronous replication, but not in synchronous one.
A transaction would have to wait for the primary's and standby's fsync
before returning a "success" to a client.
Surely that is exactly what is *required* if the user has asked for
synchronous replication.
This a distressingly common thing people get wrong about replication.
You can either have synchronous replication, which as you say has to be
slow: you must wait for an fsync ACK from the secondary and a return
trip before you can say something is committed on the primary. Or you
can get better performance by not waiting for all of those things, but
the minute you do that it's *not* synchronous replication anymore. You
can't get high-performance and true synchronous behavior; you have to
pick one. The best you can do if you need both is work on accelerating
fsync everywhere using the standard battery-backed write cache technique.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com www.2ndQuadrant.com
