PostgreSQL关闭fsync是会损坏整库还是仅损坏当前操作的表？

禁用fsync = off后一旦出现操作系统崩溃、硬件掉电、PostgreSQL进程异常终止等情况，大概率会导致整个数据库集群损坏，仅影响单张操作表属于极小概率的特例，具体逻辑和实际经验如下：

• PostgreSQL的所有持久化操作，包括WAL预写日志、数据页、存储元数据的系统目录表的落盘，都依赖fsync确保数据确实写入磁盘而非停留在操作系统缓存中。关闭fsync后，所有磁盘IO的刷盘时机完全由内核调度，没有任何强制落盘保障。
• 异常故障发生时，极容易出现数据写入不一致的情况：比如部分WAL日志落盘、部分未落盘，或者系统目录表的修改未落盘但用户表数据已落盘，这种不一致会直接破坏PostgreSQL整个集群的校验逻辑，启动时会直接报页损坏错误，绝大多数情况都无法正常拉起集群，更不是仅损坏单张表就能解决的问题。
• 就算运气好只有某张用户表的脏页没有刷盘，也大概率会因为事务状态不一致导致整张表无法访问，甚至触发整个库的查询异常。

实际生产环境的故障案例里，私自关闭fsync后出现掉电故障的场景，无一例外都是整个库无法启动，只能从最近的备份恢复，数据丢失时长从几小时到几天不等，几乎没有出现过仅单表损坏的情况。

如果追求性能调整，不要在生产环境修改fsync参数，可以优先优化慢SQL、调整共享缓冲区参数、升级存储硬件，只有完全不需要数据可靠性的临时测试场景可以临时关闭该参数，且需要提前做好全量备份。

内容的提问来源于stack exchange，提问作者J.M.