Toggle navigation
タイプ: enum
デフォルト: on
コンテキスト: user
再起動: false
値: [local, remote_write, remote_apply, on, off]

トランザクションのコミットがクライアントに成功の報告を返す前に、WALレコードがディスク上に書き込まれるまで待つかどうかの指定をします。有効な値はonremote_applyremote_writelocal、およびoffです。デフォルトかつ安全な設定はonです。offの場合、クライアントに成功を報告する時点とトランザクションが本当にサーバクラッシュに対して安全になるまでの間に遅延が発生する場合があります。(遅延は最大で、wal_writer_delayの3倍です。)fsyncと異なり、このパラメータをoffに設定することによって、データベースの一貫性が損なわれる可能性はありません。オペレーティングシステムやデータベースのクラッシュにより最近コミットされたということになっているトランザクションの一部が失われる可能性がありますが、これらのトランザクションが正常にアボートされた時とデータベースの状態は変わりません。ですので、synchronous_commitを無効にすることは、トランザクションの信頼性が確実であることよりも性能が重要である場合に有効な方法です。詳細はwal-async-commitを参照してください。

synchronous_standby_namesが空文字でない場合は、このパラメータは、WALレコードが、スタンバイサーバに複製されるまでトランザクションコミットを待機するか否かも制御します。onに設定すると、現在の同期スタンバイがトランザクションのコミットレコードを受け取り、記憶装置に吐き出したことを報告するまでコミットは待機します。このモードでは、プライマリおよびすべての同期スタンバイがデータベース記憶装置の故障を被った場合を除いて、トランザクションが失われないことが保証されます。remote_applyに設定すると、現在の同期スタンバイがトランザクションのコミットレコードを受け取って適用し、スタンバイ上で発行されたクエリから見えるようになったことを報告するまでコミットは待機します。remote_writeに設定すると、現在の同期スタンバイがトランザクションのコミットレコードを受け取り、スタンバイのオペレーティングシステムに書き出したことを報告するまでコミットは待機します。この設定は仮にPostgreSQLのスタンバイインスタンスがクラッシュしたとしても、データ保護を保証するのに充分です。しかし、スタンバイがオペレーティングシステムのレベルでクラッシュした場合はこの限りではありません。データが必ずしもスタンバイの永続的な記憶装置に到達したとは言えないからです。最後に、local設定は、コミットがローカルにディスクに吐出されるまで待機しますが、レプリケーションされるまでは待機しません。これは通常同期レプリケーションが使用されている場合は望ましい設定ではありませんが、完全さのために提供されています。

もし synchronous_standby_names が設定されていなければ、onremote_applyremote_write および local の設定は全て同一の同期レベルを提供します。すなわちトランザクションのコミットはローカルディスクへの吐き出しのみを待機します。

このパラメータはいつでも変更可能です。どのトランザクションの動作も、コミット時に有効であった設定によって決まります。したがって、一部のトランザクションのコミットを同期的に、その他を非同期的にすることが可能で、かつ、有用です。例えば、デフォルトが同期コミットの場合に複数文トランザクションを一つだけ非同期にコミットさせるためには、トランザクション内でSET LOCAL synchronous_commit TO OFFを発行します。

推奨事項 [EN]

If data integrity is less important to you than response times (for example, if you are running a social networking application or processing logs) you can turn this off, making your transaction logs asynchronous. This can result in up to wal_buffers or wal_writer_delay * 2 worth of data in an unexpected shutdown, but your database will not be corrupted. Note that you can also set this on a per-session basis, allowing you to mix “lossy” and “safe” transactions, which is a better approach for most applications.

件のコメント