WALの調整についての詳細は項26.3も参照してください。
fsync（boolean） このオプションがオンであれば、PostgreSQLサーバはfsync()システム・コールを発行したり、もしくは同等の方法で（wal_sync_methodを参照）更新が物理的にディスクに書き込まれたかの確証を得ようと試みます。これはオペレーティングシステムもしくはハードウェアがクラッシュした後、確実にデータベースクラスタを一貫した状態に復旧させることができます。
とは言っても、fsyncの使用は性能を悪化させます。トランザクションがコミットされると、PostgreSQLは、オペレーティングシステムがログ先行書き込みをディスクに吐き出すまで待機しなければなりません。fsyncを無効にすると、オペレーティングシステムは、書き込みの緩衝化（バッファリング）、順序付け、そして遅延に関して最善の行動を取ることができます。これは大幅に性能を向上させます。とは言っても、システムがクラッシュすれば、最後のいくつかのコミットされたトランザクションは、一部もしくは完全に失われる可能性があります。最悪の場合、修復不可能なデータの破壊が発生します。（データベースソフトウェアそのもののクラッシュは、ここでは危険要因では ありません。オペレーティングシステムレベルのクラッシュが破壊の危険性を引き起こします。）
この危険性のため、fsyncに対する普遍的に正しい設定は存在しません。常にfsyncを無効にする管理者がいる一方、何か不都合が発生した場合に明確な再起動ポイントが存在する様な時は、初期の大量読み込みの際にのみ無効にする管理者もいます。さらに常にfsyncを有効にする管理者もいます。デフォルトは、最大限の信頼性の確保のため、fsyncを有効にしてあります。もし使用しているオペレーティングシステム、ハードウェア、電力会社（もしくはバッテリーバックアップ）を信頼するのであれば、fsyncを無効にすることを検討しても良いでしょう。
このオプションはサーバの起動時、もしくはpostgresql.confファイルで設定可能です。このオプションをオフにする場合、full_page_writesも同時に無効にすることを検討してください。
wal_sync_method（string） WALの更新をディスクへ強制するのに使用される方法です。fsyncがオフの場合この設定は役に立ちません。と言うのは更新が全く強制されないからです。取り得る値は以下のものです。
open_datasync
（open() option O_DSYNCでWALファイルの書き込み）
fdatasync
（コミット毎にfdatasync()を呼び出し）
fsync_writethrough
（ディスク書き込みキャッシュ何でもをライトスルーさせるため、コミット毎にfsync()を呼び出し）
fsync
（コミット毎にfsync()を呼び出し）
open_sync
（open() option O_SYNCでWALファイルの書き込み）
全てのプラットホームでこれら全ての選択肢が使えるわけではありません。サポートされているデフォルトは、上記のリストの一番最初の方法です。このオプションはサーバの起動時、もしくはpostgresql.confファイルで設定可能です。
full_page_writes（boolean）このオプションがオンの場合PostgreSQLサーバはディスクページの全ての内容を、チェックポイントの後、そのページの最初の変更過程でWALに書き込みます。
このパラメータは現在無視され（常にonとして扱われる）ます。と言うのは、offにすると、ハードウェアもしくはOSレベルの故障が発生したとしてもクラッシュから復帰することに失敗するからです。将来のリリースで修正されるか、パラメータ自体を完全に削除することになります。
wal_buffers（integer）WALデータ用に共有メモリ内に割り当てられたディスクページバッファの数です。デフォルトは8です。データはそれぞれのトランザクションコミット時にディスクに書き出されるため、設定としては、1つの典型的なトランザクションによって生成されるWALデータを保存できる充分な大きさであることのみが必要です。このオプションはサーバ起動時のみ設定可能です。
このパラメータを増加させると、使用しているオペレーティングシステムのデフォルト構成が許容するSystem V共有メモリの限界を越えた要求をPostgreSQLが行う原因となることがあります。必要であれば、どの様にしてこのパラメータを調整するかについて項16.4.1を参照ください。
commit_delay（integer） コミットレコードをWALバッファに書き込む時と、バッファをディスクに吐き出す時のミリ秒単位の時間差遅延です。システム負荷が高く、指定期間内にコミット準備ができたトランザクションが複数存在した場合、ゼロ以外の遅延時間であれば複数のトランザクションを一度のfsync()システムコールのみで、与えられた周期以内でコミットすることができます。しかし、もし他のトランザクションがコミットできる状態にならなければ、この遅延は無駄になります。と言うことは、サーバプロセスがそのコミットレコードを書き込んだ瞬間に他のトランザクションが進行している commit_siblingsにだけ少なくとも実行されます。デフォルトの値はゼロ（遅延無し）です。
commit_siblings（integer） commit_delay遅延を実行する前に必要とされる同時に開いているトランザクションの最小数です。より大きい値は、遅延周期の間に、少なくとも1つの他のトランザクションがコミットの準備を整わせることを確実にします。デフォルトは5です。
checkpoint_segments（integer）自動的WALチェックポイント間の最大間隔をログファイルセグメント（それぞれのセグメントは通常16メガバイト）で指定します。デフォルトは3です。このオプションはサーバの起動時、もしくはpostgresql.confファイルのみで設定可能です。
checkpoint_timeout（integer）自動的WALチェックポイント間の最大間隔を秒単位で指定します。デフォルトは300秒です。このオプションはサーバの起動時、もしくはpostgresql.confファイルのみで設定可能です。
checkpoint_warning（integer） チェックポイントセグメントファイルが溢れることが原因で起きるチェックポイントが、ここで指定した秒数よりも頻繁に発生する場合、サーバログにメッセージを書き出します（これは、checkpoint_segmentsを呼び出す必要があることを示唆しています）。デフォルトは30秒です。零の場合は警告を出しません。
archive_command（string）一連のWALファイルの完了したセグメントの格納を実行するシェルコマンドです。 もしこの文字列が空であれば（デフォルトです）、WAL格納処理は無効です。 文字列内のいかなる%pは、格納されるファイルのパス名で置き換えられ、そして、どんな%fはファイル名のみ置換します。 （このパス名はサーバの作業用ディレクトリ、つまりクラスタのデータディレクトリからの相対パスです。） コマンド内で実際の%文字を埋め込むには%%を使用します。より詳しくは項23.3.1を参照ください。このオプションはサーバの起動時、もしくはpostgresql.confファイルのみで設定可能です。
成功した場合に限って、またその時に限って、ゼロで抜ける状態を返す様にすることがこのコマンドでは重要です。以下に例を示します。
archive_command = 'cp "%p" /mnt/server/archivedir/"%f"' archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows