在 postgresql 14 用 postgres 用户试了一下 SET fsync = on 和 SET LOCAL fsync = on 都不起作用了，直接报错 ERROR: parameter "fsync" cannot be changed now。用 SET 语句理论上是可以实现，但多执行一条 SET 语句，对事务的整体执行时间有一定影响。无非是参数作用域的问题，在 session 级设置就不用每次事务执行一下 SET 语句。//@恰饭家族:不用参数的！事务内用一条sql语句开启fsync同步写盘！共用此连接的其它sql依然是异步写盘！所以是最科学的方案！//@zhh-4096:这个方式的确是个折中方案，实现也不难，只是需要在客户端创建连接时配置一个参数，因为 jdbc 没有设置 fsync 的 api，需要在一个特殊的 jdbc 连接中执行这种事务。//@恰饭家族:PG默认fsync，可以关掉，然后程序可以决定对哪一个事务按需开启fsync，如转账事务，更科学！

@zhh-4096

不管开不开启实时 fsync，都不会破坏数据库的完整性，只是对用户体验不同而已。开启实时 fsync 后，如果数据写硬盘失败了，用户可以马上获得错误通知，然后让用户决定是重试还是取消；不开启实时 fsync，用户收到成功消息后，若写硬盘失败了，再让用户重试确实体验不好，但是99.99％的场景体验更好。