如果开启，任何错误都将终止当前会话。 默认情况下它被设置为 off， 因此只有 FATAL 错误才会终止会话。

当设置为 on（这是默认值）时， PostgreSQL 会在后端崩溃之后自动重新初始化。 把这个值保持为 on 通常是最大化数据库可用性的最佳方式。 然而，在某些情况下， 例如当 PostgreSQL 由集群软件调用时， 禁用重启可能有用， 这样集群软件就能获得控制权并采取它认为合适的任何行动。

这个参数只能在 postgresql.conf 文件中或服务器命令行上设置。

当设置为 off（这是默认值）时， PostgreSQL 在把修改过的数据文件刷写到文件系统失败时将抛出 PANIC 级别的错误。 这会导致数据库服务器崩溃。 这个参数只能在服务器启动时设置。

在某些操作系统上，写回失败之后内核页缓存中数据的状态是未知 的。 在某些情况下它可能被完全遗忘，使得重试变得不安全； 第二次尝试可能被报告为成功， 而实际上数据已经丢失。 在这些情况下，避免数据丢失的唯一方式是在报告任何失败之后从 WAL 恢复，最好是在调查失败的根本原因并更换任何有故障的硬件 之后。

如果设置为 on， PostgreSQL 将改为报告一个错误但继续运行， 这样数据刷写操作可以在稍后的检查点中重试。 只有在调查了操作系统在写回失败情况下对缓冲数据的处理之后， 才应把它设置为 on。

当设置为 fsync（这是默认值）时， PostgreSQL 会在崩溃恢复开始之前递归地打开并同步数据目录中的所有文件。 对文件的搜索会跟随 WAL 目录和每个已配置表空间的符号链接 （但不跟随任何其他符号链接）。 这是为了确保在重放更改之前所有 WAL 和数据文件都持久地存储在 磁盘上。 每当启动一个没有干净关闭的数据库集群时这都会适用， 包括用 pg_basebackup 创建的副本。

在 Linux 上，可以改用 syncfs， 让操作系统同步包含数据目录、WAL 文件和每个表空间的文件系统 （但不同步可能通过符号链接到达的任何其他文件系统）。 这可能比 fsync 设置快得多，因为它不需要逐个打开每个文件。 另一方面，如果一个文件系统被其他修改大量文件的应用程序共享， 它可能更慢，因为那些文件也会被写到磁盘上。 此外，在 5.8 之前的 Linux 版本上， 向磁盘写数据时遇到的 I/O 错误可能不会报告给 PostgreSQL， 相关的错误消息可能只出现在内核日志中。

这个参数只能在 postgresql.conf 文件中或服务器命令行上 设置。