pg_resetwal — PostgreSQLデータベースクラスタの先行書き込みログやその他の制御情報を初期化する
pg_resetwal [ --force | -f ] [ --dry-run | -n ] [option...] [ --pgdata | -D ] datadir
pg_resetwalは、先行書き込みログ（WAL）を消去し、さらにオプションでpg_controlファイル内に保存された制御情報の一部を初期化します。
この機能は、これらのファイルが破損した場合に必要になることがあります。
このような破損などが原因でサーバを起動できない場合の最後の手段としてのみ、この機能を使用してください。
このコマンドを実行すると、サーバが開始できるようになるはずです。
ただし、不完全にコミットされたトランザクションが原因でデータベースのデータに矛盾が起こる可能性があることに注意してください。
コマンドの実行後は、ただちにデータをダンプし、initdbを実行し、リロードすべきです。
リロード後、矛盾がないか検査し、必要に応じて修復を行ってください。
このユーティリティの実行にはデータディレクトリへの読み込み/書き込みアクセス権限が必要となるため、サーバをインストールしたユーザのみが実行できます。
安全のため、データディレクトリをコマンドラインで指定する必要があります。
pg_resetwalは、環境変数PGDATAを使用しません。
pg_resetwalがpg_controlに対する有効なデータを判別できない場合、-f（force,強制）オプションを指定すれば強制的に処理を進めることができます。
その場合、欠落したデータは無難な値で代用されます。
ほとんどフィールドでは適切な値が使用されますが、次のOID、次のトランザクションIDとエポック時間、マルチトランザクションIDとそのオフセット、WAL開始位置の値については、手動の操作が必要な場合があります。
これらの値は下記で説明するオプションを使用して設定することができます。
すべてに対して正しい値を決定できない場合でも-fを使用することができますが、この場合は回復したデータベースを通常よりさらに注意深く検査する必要があります。
必ず、ただちにダンプおよびリロードを行ってください。
決して、ダンプを行う前にデータ変更などの操作を行ってはなりません。
そのような操作は、破損状態をさらに悪化させます。
-f--force
上で説明したように、pg_controlに有効なデータが確認できない場合でも、強制的にpg_resetwalの処理を実行します。
-n--dry-run
-n（no operation,操作なし）オプションを指定すると、pg_resetwalはpg_controlから再構築した値、および変更される値を出力して、何も変更せずに終了します。
これは主にデバッグと目的としたツールですが、pg_resetwalを実際に進める前の検査としても有用な場合があります。
-V--versionバージョン情報を表示して終了します。
-?--helpヘルプを表示して終了します。
以下のオプションはpg_resetwalがpg_controlを四でも適切な値を決定できない場合にのみ必要になります。
安全な値は以下で説明するようにして決定できます。
数値を引数として取る値については、0xの接頭辞をつけることで16進数の値を指定できます。
-c xid,xid--commit-timestamp-ids=xid,xidコミットの時刻が取り出せる最古のトランザクションIDと最新のトランザクションIDを手作業で設定します。
コミット時刻が取り出せる最古のトランザクションIDとして安全な値（1番目の部分）はデータディレクトリの下のpg_commit_tsディレクトリの中で、数値的に最小のファイル名を探すことで決定できます。
逆に、コミット時刻が取り出せる最新のトランザクションIDとして安全な値（2番目の部分）は同じディレクトリの中で、数値的に最大のファイル名を探すことで決定できます。
ファイル名は16進数になっています。
-e xid_epoch--epoch=xid_epoch次のトランザクションIDのエポック時間を手作業で設定します。
pg_resetwalで設定されるフィールドを除き、トランザクションIDのエポック時間は実際にはデータベース内のどこにも格納されません。
そのため、データベース自体だけを考えるのであれば、任意の値で動作するでしょう。
Slony-IやSkytoolsなどのレプリケーションシステムが確実に正しく動作するように、この値を調整しなければならない可能性があります。
その場合、適切な値は下流で複製されたデータベースの状態から得られるはずです。
-l walfile--next-wal-file=walfile次のWALセグメントファイル名を指定することでWAL開始位置を手動で設定します。
次のWALセグメントファイル名は、データディレクトリ以下のpg_walに現在存在するどのWALセグメントファイル名よりも大きくならなければなりません。
この名前も16進数で、3つの部分に分かれています。
最初の部分は「時系列ID」で、通常、この値は変更すべきではありません。
例えば、pg_wal内で最大のエントリが00000001000000320000004Aである場合は、-l 00000001000000320000004B以上を使用してください。
デフォルト以外のWALセグメントサイズを使用しているときには、WALファイル名の番号はシステム関数やシステムビューで報告されるLSNとは異なるということに注意してください。 このオプションはLSNではなくWALファイル名を引数に取ります。
pg_resetwal自体はpg_wal内のファイルを参照し、最後の既存のファイル名より大きな値をデフォルトの-l設定として選択します。
したがって、手作業による-lの調整は、オフラインアーカイブ内の項目などpg_walに現存しないWALセグメントファイルがあることに気づいた場合、または、pg_walの内容が完全に失われている場合にのみ必要とされます。
-m mxid,mxid--multixact-ids=mxid,mxid次のマルチトランザクションIDと最古のマルチトランザクションIDを手作業で設定します。
次のマルチトランザクションIDとして安全な値（1番目の部分）は、データディレクトリの下のpg_multixact/offsetsディレクトリの中で数値的に最大のファイル名を探し、1を加えてから65536(0x10000)を掛けることで決定できます。
逆に、最古のマルチトランザクションIDとして安全な値（-mの2番目の部分）は、同じディレクトリの中で数値的に最小のファイル名を探し、65536を掛けることで決定できます。
ファイル名は16進ですので、このための最も簡単なやり方は、オプション値を16進で指定子、ゼロを4つ追加することです。
-o oid--next-oid=oid次のOIDを手作業で設定します。
データベース内のOIDの最大値よりも大きな次のOIDを決定するには、上記のような簡単な方法はありません。 しかし、幸いにも、次のOIDの設定を正しく取得することは、それほど重要ではありません。
-O mxoff--multixact-offset=mxoff次のマルチトランザクションオフセットを手作業で設定します。
安全な値は、データディレクトリの下のpg_multixact/membersディレクトリの中で数値的に最も大きなファイル名を探し、1を加えてから、52352(0xCC80)を掛けることで決定できます。
ファイル名は16進数です。
他のオプションのような0をつけるだけの簡単な計算方法はありません。
--wal-segsize=wal_segment_size新たなWALセグメントサイズをメガバイトで設定します。 値には1から1024（メガバイト）の2の冪乗を設定しなければなりません。 詳しくはinitdbの同じオプションを参照してください。
pg_resetwalが存在する最も新しいWALセグメントファイルを超えたWAL開始位置を設定するとき、一部のセグメントサイズ変更は前のWALファイル名の再使用をひき起こす可能性があります。
あなたのアーカイブ戦略でWALファイル名のオーバーラップが問題を起こす場合には、このオプションと共にWAL開始位置を手動で設定する-lも使うことを推奨します。
-x xid--next-transaction-id=xid次のトランザクションIDを手作業で設定します。
安全な値は、データディレクトリの下のpg_xactディレクトリの中で数値的に最も大きなファイル名を探し、1を加えてから、1048576(0x100000)を掛けることで決定できます。
ファイル名は16進数であることに注意して下さい。
通常は、オプションの値も16進数で指定するのが最も簡単でしょう。
例えば、0011がpg_xactで最も大きなエントリであれば、-x 0x1200000とすれば良いです（後ろにゼロを5つ付けると、正しく掛け算をしたことになります）。
このコマンドは、サーバの稼動中に使用してはいけません。
pg_resetwalは、データディレクトリにサーバのロックファイルがあると、実行されません。
サーバがクラッシュした場合、ロックファイルがそのまま残される場合があります。
その場合は、ロックファイルを削除すればpg_resetwalを実行することができます。
しかし、そのようなことをする前に、まだ稼働中のサーバプロセスが一切ないことを慎重に確認してください。
pg_resetwalは同一のメジャーバージョンのサーバに対してのみ動作します。