PostgreSQL复制中有个很重要的参数：synchronous_commit。它决定何时向客户端确认事务提交成功。这个参数不仅仅关于主备同步，还有更广泛的含义，对于单机PG实例也很有用。为了更好地理解，需要了解WAL记录的整个传播过程以及可以接受提交确认的各个阶段。这使得我们能够为每个事务选择不同级别的持久性。持久性的级别越低，确认越快，从而提高系统整体吞吐量和性能。
WAL传播
首先看下WAL传播过程。
PG内部函数pg_write()将WAL日志写入WAL段文件内，内部使用write()系统调用，并不保证数据刷写到磁盘。为了完成刷写，需要调用issue_xlog_fsync()，根据GUC参数wal_sync_method发出适当类型的fsync：
上图显示了所有的5个阶段：
1）WAL记录插入本地WAL BUFFER：WAL记录首先在WAL缓冲区中创建。由于多个后台进程将并发创建WAL，因此需要锁来包含。不同的后台进程将WAL BUFFER中的WAL持续写入WAL段文件。如果sychronous_commit设置为off，则不会立即刷写，而是依赖于wal_writer_delay的设置。
2）WAL write和WAL flush。对本地磁盘上的WAL段文件进行刷写是一个繁重的操作之一。PG在这方面做了很多优化，以避免频繁刷写。
3）远程写入。WAL记录写入远程操作系统缓存，但并没有刷新。数据可能会在操作系统缓存保留一段时间。除非需要解决主备同时崩溃的情况，否则可以考虑使用这种级别的持久性保护。
4）远程刷新。这个阶段，数据才真正写入远程备机的磁盘。所以此时崩溃也可以保证备机的数据是可用的。
5）远程应用。这个阶段，WAL记录在远程备机回放，并且正在运行的会话可以访问。
这样再看该参数的可用值意义：
1）off：关闭synchronous_commit可以使用off,0,false或者no。顾名思义，提交确认可以在将记录刷新到磁盘之前进行。通常称为异步提交。如果PG崩溃，最后几个异步提交可能会丢失。
2）local：WAL记录写入并刷写到本地磁盘。这种情况下，将本地WAL日志写入和刷写完成后才提交。
3）remote_write：WAL记录成功发送给备机，远程备机确认写入（不是刷写）
4）on：这个是默认值。可以使用on,true,yes或者1.根据是否有复制含义可能有所不同。若有复制，则导致等等“远程刷新”
5）remote_apply：直到备机接收到的事务回放了，才返回主机确认可以提交了。
如果没有同步备机synchronous_standby_names为空，则synchronous_commit：on、remote_apply、remote_write和local的设置都提供相同级别的同步级别：事务提交只等待本地刷新到磁盘。不同值对性能的影响：
off (async) > on (async) > remote_write (sync) > on|local (sync) > remote_apply (sync)
那么当选择完全异步提交synchronous_commit=off时，会丢失多少数据呢？
这依赖于wal_writer_delay的设置。默认是200ms。也就是每隔wal_writer_delay，WAL writer都会被唤醒并调用XLogBackgroundFlush()，将WAL刷写到磁盘。他会检查完全填充的WAL页，如果可用，则将WAL write到这个点。在良好负载下，WAL writer会将整个WAL BUFFER都write。在没有找到full pages的低负载情况下，仅刷写到上一个异步提交的位置。
如果超过wal_writer_delay或者自上次刷新以来写入的块超过wal_writer_flush_after，则WAL 被刷新到当前位置。这种安排保证了异步提交记录在事务完成后最多两次wal_writer_delay后到达磁盘。但是，PostgreSQL 以灵活的方式写入/刷新完整缓冲区，这是为了减少在每个 WAL writer周期填充多个 WAL 页面时在高负载下发出的写入次数。从概念上讲，这使得最坏情况延迟最多三个wal_writer_delay 周期。
在大多数情况下，损失将小于 wal_writer_delay 的两倍。但在最坏的情况下，它可能高达三倍。
