pg_restore --clean --dbname=my_database backup_file.sql
を実行してデータベースダンプを空のデータベースに復元すると、復元は成功しますが、次の警告メッセージが表示されます。
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 161; 1259 16549 TABLE example_table root
pg_restore: [archiver (db)] could not execute query: ERROR: table "example_table" does not exist
Command was: DROP TABLE public.example_table;
WARNING: errors ignored on restore: 1
メッセージが示すように、復元は成功しました。エラーがありましたが、pg_restore
はそれらを無視したと主張しています。また、データベースに手動でクエリを実行して、ダンプにあると予想したすべてのデータが復元後にデータベースに存在することを確認することもできました。
問題は、上記のコマンドが0ではなく1のステータスで終了したことです。データベースの復元をプログラムで実行する場合(このプロセスを自動化するときに実行する予定です)、スクリプトが確実に判断できる必要があるため、これは問題があります。復元が成功したかどうか。
pg_restore
に終了ステータスを判別するときに警告を無視させる方法はありますか?または、pg_restore
の代わりに、より正確な成功/失敗情報を取得できる方法はありますか?データベースを復元し、復元が成功したかどうかをプログラムで確実に判断するにはどうすればよいですか?
現在PostgreSQL9.1を使用していることに注意してください。
Postgresは、質問で言及されたエラーが比較的無害であることを実際には知りません。エラーが無視されるのはそのためではありません。 pg_restore
が実際にそのエラーを無視している理由は、pg_restore
がデフォルトで、復元プロセス中に発生するほぼすべてエラーを無視するように構成されているためです。復元の成功/失敗ステータスを気にする場合、これはおそらくあなたが望む動作ではありません。 pg_restore
または--exit-on-error
オプションを指定して--single-transaction
を実行すると、これは改善されますが、Postgresは、上記の質問のエラーを単なる警告ではなく、本格的な致命的なエラーとして扱います(繰り返しになりますが、その特定のコマンドが失敗しても問題がないことは実際にはわかりません)。
これに対する最善の解決策は、最初からエラーが発生しないようにするための手順を実行することです。この場合、pg_restore
を実行する前に、別のコマンドを使用して テーブルを削除 し、--clean
オプションを省略してこれを行う可能性があります。