synchronous_commit

指定在命令返回”success”指示给客户端之前，一个事务是否需要等待 WAL 记录被写入磁盘。

合法的值是{local,remote_write,remote_apply,on,off}

默认的并且安全的设置是on。

不同于fsync，将这个参数设置为off不会产生数据库不一致性的风险：一个操作系统或数据库崩溃可能会造成一些最近据说已提交的事务丢失，但数据库状态是一致的，就像这些事务已经被干净地中止。因此，当性能比完全确保事务的持久性更重要时，关闭synchronous_commit可以作为一个有效的代替手段。

这个参数可以随时被修改；任何一个事务的行为由其提交时生效的设置决定。因此，可以同步提交一些事务，同时异步提交其他事务。例如，当默认是相反时，实现一个单一多语句事务的异步提交，在事务中发出SET LOCAL synchronous_commit TO OFF。

单实例环境

on：

当数据库提交事务时，wal先写入 wal buffer 再写入 wal 日志文件，设置成on表示提交事务时需等待本地wal写入wal日志后才向客户端返回成功。

on 为默认设置，数据库非常安全，但性能有所损耗。

off：

当数据库提交事务时不需要等待本地 wal buffer 写入 wal 日志，随即向客户端返回成功，设置成off会给数据库带来一点风险：数据库宕机时最新提交的少量事务可能丢失，数据库重启后会认为这些事务异常终止，会rollback。

适用对数据库准确性要求不高同时追求数据库性能的的场景。

local：

local含义和on类似，表示提交事务时需要等待本地wal写入后才向客户端返回成功。

流复制环境

on：

表示流复制主库提交事务时，需等待备库接收主库发送的wal日志流并写入wal文件，之后才向客户端返回成功，简单的说on表示本地wal已落盘，备库的wal也已落盘，有两份持久化的wal，但备库此时还没有完成重做。

这个选项带来的事务响应时间较高。

remote_write：

表示流复制主库提交事务时，需等待备库接收主库发送的wal日志流并写入备节点操作系统缓存中，之后向客户端返回成功，这种情况下备库出现异常关闭时不会有已传送的wal日志丢失风险，但备库操作系统异常宕机就有已传送的wal丢失风险了，此时wal可能还没有完全写入备节点wal文件中，简单的说 remote_write 表示本地wal已落盘，备库的wal还在备库操作系统缓存中，也就是说只有一份持久化的wal。

这个选项带来的事务响应时间较低。

remote_apply：

表示流复制主库提交事务时，需等待备库接收主库发送的wal流并写入wal文件，同时备库已经完成重做，之后才向客户端返回成功，简单的说remote_apply 表示本地wal已落盘，备库wal已落盘并且已经完成重做，这个设置保证了拥有两份持久化的wal，同时备库也已经完成了重做。

这个选项带来的事务响应时间最高。

补充：postgresql wal日志部分参数

fsync

fsync ：控制wal日志刷新是否开启刷新到磁盘,此参数控制wal_sync_method参数的刷新方法,如果fsync为off,则wal_sync_method的方法是没有意义的,

如果没开启这个参数,则可能由于wal日志块没有刷新到磁盘永久存储而导致故障发生后实例出现块折断(oracle称其为block curruption)

wal_sync_method

wal_sync_method :wal日志刷新方法,可选值为open_datasync/fdatasync/fsync/fsync_writethrough/open_sync

linux系统默认为fdatasync,以open开头的在某些系统上不支持

wal_buffers

wal_buffers :wal缓冲区,默认为-1,大小为1/32的shared_buffer,最小不少于64k,最大不大于一个wal_segment(默认16M大小),一般保持默认即可,因为过了wal_writer_delay(默认200ms)总会刷新清空此缓存，设置太大了也用不上.

wal_writer_delay

wal_writer_delay:前面已经说过,这有点类似oracle和mysql的1s定时写日志策略,每隔这么长时间就会刷wal日志缓冲区的数据,然后sleep,到点后再刷，如此循环往复.

commit_delay

commit_delay :提交的延迟时间,如果设置了此参数,则会commit后延迟一段时间再进行提交,此机制可以合并其他事务进而一起进行组提交,不过合并的事务数是有限制的,要至少有commit_siblings参数个事务等待提交的时候才会延迟,所有当有大量事务的时候会延迟,而如果事务很稀少就不会再被延迟了.

commit_siblings

commit_siblings :组提交个数的最少个数,此参数上面已经进行说明