Tom Lane wrote: <blockquote cite="mid:24069.1258037544@sss.pgh.pa.us" type="cite"><pre wrap="">Fujii Masao <a
class="moz-txt-link-rfc2396E"href="mailto:masao.fujii@gmail.com"><masao.fujii@gmail.com></a> writes:
</pre><blockquotetype="cite"><pre wrap="">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. </pre></blockquote><pre wrap="">
Surely that is exactly what is *required* if the user has asked for
synchronous replication. </pre></blockquote> This a distressingly common thing people get wrong about replication. You
caneither have synchronous replication, which as you say has to be slow: you must wait for an fsync ACK from the
secondaryand a return trip before you can say something is committed on the primary. Or you can get better performance
bynot waiting for all of those things, but the minute you do that it's *not* synchronous replication anymore. You
can'tget high-performance and true synchronous behavior; you have to pick one. The best you can do if you need both is
workon accelerating fsync everywhere using the standard battery-backed write cache technique.<br /><br /><pre
class="moz-signature"cols="72">--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
<a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a> <a
class="moz-txt-link-abbreviated"href="http://www.2ndQuadrant.com">www.2ndQuadrant.com</a>
</pre>
