PostgreSQL 9.1的同步复制事务需要等待同步复制节点的 xlog flush ACK 才可以结束事务（即等待xlog写入磁盘）。
而异步复制事务不需要standby的ACK。
在2012-01的commitFest中有一个关于新的复制模式的主题, 目前已经处于commited状态。
这个patch允许在standby节点的recovery.conf配置文件，加入了1个replication_mode参数，可选的参数值为，async, write, fsync, replay.
1. async
顾名思义代表这个standby是异步standby。
2. write
代表primary节点需要等待standby节点将接收到的xlog写入内存。
3. fsync
代表primary节点需要等待standby节点将接收到的xlog写入磁盘。
4. replay
代表primary节点需要等待standby节点将接收到的xlog完成恢复。
在write, fsync, replay模式下面，standby增加了一个XLogRecPtr消息，分别用来发送当前已经写入内存，磁盘，或完成恢复的location。
只有当primary接收到的XLogRecPtr中的location大于主节点正在等待的COMMIT location时，才可返回success给客户端。
还记不记得9.1的同步复制同一时刻只支持一台节点成为sync standby节点，其他的都是异步复制节点。
所以又有一个patch是关于quorum的。
在主节点的postgresql.conf参数中增加了一个quorum参数，默认等于0。记录的是需要收到ACK的STANDBY节点个数。
当系统中存在多个sync standby节点时，主节点必须接收到大于或等于quorum配置的个数个sync standby节点的replication ACK，事务才可返回给客户端success消息。
quorum个数大于当前系统中sync standby个数时以sync standby个数为准。
系统中没有sync standby节点但是配置的quorum>0时不受影响。
【小结】
1. 由于write模式返回的是xlog写入内存的位置，比flush到磁盘快很多，因此带来同步复制的性能增强，当然也带来了少许风险，如主节点和sync standby节点同时DOWN机是有风险的。
性能提升如下 :
synchronous_commit = on
tps = 424.510843 (including connections establishing)
tps = 420.767883 (including connections establishing)
tps = 419.715658 (including connections establishing)
tps = 428.810001 (including connections establishing)
tps = 337.341445 (including connections establishing)
synchronous_commit = write
tps = 550.752712 (including connections establishing)
tps = 407.104036 (including connections establishing)
tps = 455.576190 (including connections establishing)
tps = 453.548672 (including connections establishing)
tps = 555.171325 (including connections establishing)
2. quorum 参数降低了上面提到的风险问题，因为可以允许多个同步复制standby节点。