バージョンごとのドキュメント一覧

20.14. エラー処理 #

<title>Error Handling</title>
exit_on_error (boolean) #

If on, any error will terminate the current session. By default, this is set to off, so that only FATAL errors will terminate the session. onなら、全てのエラーは現在のセッションを中止させます。 デフォルトではこれはoffに設定されているので、 FATALエラーのみがセッションを中止させます。

restart_after_crash (boolean) #

When set to on, which is the default, <productname>PostgreSQL</productname> will automatically reinitialize after a backend crash. Leaving this value set to on is normally the best way to maximize the availability of the database. However, in some circumstances, such as when <productname>PostgreSQL</productname> is being invoked by clusterware, it may be useful to disable the restart so that the clusterware can gain control and take any actions it deems appropriate. デフォルトであるonの場合、PostgreSQLはバックエンドのクラッシュの後、自動的に再初期化を行います。 この値を真のままにしておくことが、通常データベースの可用性を最大化する最適の方法です。 しかし、 PostgreSQLがクラスタウェアにより起動された時のような状況では、クラスタウェアが制御を獲得して、適切とみなすいかなる振る舞いをも行えるように再起動を無効にすることが有益かもしれません。

This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。

data_sync_retry (boolean) #

When set to off, which is the default, <productname>PostgreSQL</productname> will raise a PANIC-level error on failure to flush modified data files to the file system. This causes the database server to crash. This parameter can only be set at server start. デフォルトであるoffに設定すると、PostgreSQLは変更されたデータファイルのファイルシステムへのフラッシュの失敗に対してPANICレベルのエラーを発生させます。 これによりデータベースサーバのクラッシュが引き起こされます。 このパラメータはサーバ起動時のみ設定可能です。

On some operating systems, the status of data in the kernel's page cache is unknown after a write-back failure. In some cases it might have been entirely forgotten, making it unsafe to retry; the second attempt may be reported as successful, when in fact the data has been lost. In these circumstances, the only way to avoid data loss is to recover from the WAL after any failure is reported, preferably after investigating the root cause of the failure and replacing any faulty hardware. オペレーティングシステムによっては、カーネルキャッシュのページ内のデータの状態は、書き戻しの失敗の後は不明です。 このような状況では、データロスを避ける唯一の方法は、失敗が報告された後、可能ならば失敗の根本原因を調査して故障したハードウェアを交換したのち、WALからの回復することだけです。

If set to on, <productname>PostgreSQL</productname> will instead report an error but continue to run so that the data flushing operation can be retried in a later checkpoint. Only set it to on after investigating the operating system's treatment of buffered data in case of write-back failure. onに設定すると、代わりにPostgreSQLはエラーを報告して実行を継続し、後のチェックポイントでデータのフラッシュをリトライします。 書き戻しの失敗が起きたときのオペレーティングシステムのバッファデータの扱いを調査した後でのみonに設定してください。

recovery_init_sync_method (enum) #

When set to <literal>fsync</literal>, which is the default, <productname>PostgreSQL</productname> will recursively open and synchronize all files in the data directory before crash recovery begins. The search for files will follow symbolic links for the WAL directory and each configured tablespace (but not any other symbolic links). This is intended to make sure that all WAL and data files are durably stored on disk before replaying changes. This applies whenever starting a database cluster that did not shut down cleanly, including copies created with <application>pg_basebackup</application>. デフォルトであるfsyncに設定すると、PostgreSQLはクラッシュリカバリを開始する前に、再帰的にデータディレクトリ内のすべてのファイルを開いて同期します。 ファイルの探索は、WALディレクトリと設定されているテーブル空間へのシンボリックリンクを追跡します(他のシンボリックリンクは追跡しません)。 これはリプレイを開始する前に、すべてのWALとデータファイルをディスクに恒久的に書くことを確実にすることを意図しています。 これは、pg_basebackupで作られた複製も含めて、正しく停止されなかったデータベースクラスタを起動する際には必ず適用されます。

On Linux, <literal>syncfs</literal> may be used instead, to ask the operating system to synchronize the whole file systems that contain the data directory, the WAL files and each tablespace (but not any other file systems that may be reachable through symbolic links). This may be a lot faster than the <literal>fsync</literal> setting, because it doesn't need to open each file one by one. On the other hand, it may be slower if a file system is shared by other applications that modify a lot of files, since those files will also be written to disk. Furthermore, on versions of Linux before 5.8, I/O errors encountered while writing data to disk may not be reported to <productname>PostgreSQL</productname>, and relevant error messages may appear only in kernel logs. Linuxでは代わりに、オペレーティングシステムに対して、データディレクトリ、WALファイル、各々のテーブル空間(しかし、シンボリックリンクを通じて到達可能な他のファイルシステムを含みません)を含むファイルシステム全体を同期することを依頼するsyncfsが使えるかもしれません。 これは各々のファイルを一つ一つ開けることが必要ないため、fsyncを設定するよりもずっと速いかもしれません。 一方で、そのファイルシステムが多くのファイルを変更するアプリケーションも利用している場合、これらのファイルもディスクに書かれるので、遅くなるかもしれません。 更に、Linuxのバージョン5.8以前では、ディスクへの書き込み中に発生したI/OエラーがPostgreSQLに報告されないことがあり、関連エラーメッセージはカーネルログにのみ現れるかもしれません。

This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。