onなら、全てのエラーは現在のセッションを中止させます。 デフォルトではこれはoffに設定されているので、 FATALエラーのみがセッションを中止させます。

デフォルトであるonの場合、PostgreSQLはバックエンドのクラッシュの後、自動的に再初期化を行います。 この値を真のままにしておくことが、通常データベースの可用性を最大化する最適の方法です。 しかし、 PostgreSQLがクラスタウェアにより起動された時のような状況では、クラスタウェアが制御を獲得して、適切とみなすいかなる振る舞いをも行えるように再起動を無効にすることが有益かもしれません。

このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。

デフォルトであるoffに設定すると、PostgreSQLは変更されたデータファイルのファイルシステムへのフラッシュの失敗に対してPANICレベルのエラーを発生させます。 これによりデータベースサーバのクラッシュが引き起こされます。 このパラメータはサーバ起動時のみ設定可能です。

オペレーティングシステムによっては、カーネルキャッシュのページ内のデータの状態は、書き戻しの失敗の後は不明です。 このような状況では、データロスを避ける唯一の方法は、失敗が報告された後、可能ならば失敗の根本原因を調査して故障したハードウェアを交換したのち、WALからの回復することだけです。

onに設定すると、代わりにPostgreSQLはエラーを報告して実行を継続し、後のチェックポイントでデータのフラッシュをリトライします。 書き戻しの失敗が起きたときのオペレーティングシステムのバッファデータの扱いを調査した後でのみonに設定してください。

デフォルトであるfsyncに設定すると、PostgreSQLはクラッシュリカバリを開始する前に、再帰的にデータディレクトリ内のすべてのファイルを開いて同期します。 ファイルの探索は、WALディレクトリと設定されているテーブル空間へのシンボリックリンクを追跡します（他のシンボリックリンクは追跡しません）。 これはリプレイを開始する前に、すべてのWALとデータファイルをディスクに恒久的に書くことを確実にすることを意図しています。 これは、pg_basebackupで作られた複製も含めて、正しく停止されなかったデータベースクラスタを起動する際には必ず適用されます。

Linuxでは代わりに、オペレーティングシステムに対して、データディレクトリ、WALファイル、各々のテーブル空間（しかし、シンボリックリンクを通じて到達可能な他のファイルシステムを含みません）を含むファイルシステム全体を同期することを依頼するsyncfsが使えるかもしれません。 これは各々のファイルを一つ一つ開けることが必要ないため、fsyncを設定するよりもずっと速いかもしれません。 一方で、そのファイルシステムが多くのファイルを変更するアプリケーションも利用している場合、これらのファイルもディスクに書かれるので、遅くなるかもしれません。 更に、Linuxのバージョン5.8以前では、ディスクへの書き込み中に発生したI/OエラーがPostgreSQLに報告されないことがあり、関連エラーメッセージはカーネルログにのみ現れるかもしれません。

このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。