web-dev-qa-db-ja.com

成功すると終了コードが1になることがある場合、pg_restoreが成功したかどうかを確実に判断するにはどうすればよいですか?

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を使用していることに注意してください。

19
Ajedi32

Postgresは、質問で言及されたエラーが比較的無害であることを実際には知りません。エラーが無視されるのはそのためではありません。 pg_restoreが実際にそのエラーを無視している理由は、pg_restoreがデフォルトで、復元プロセス中に発生するほぼすべてエラーを無視するように構成されているためです。復元の成功/失敗ステータスを気にする場合、これはおそらくあなたが望む動作ではありません。 pg_restoreまたは--exit-on-errorオプションを指定して--single-transactionを実行すると、これは改善されますが、Postgresは、上記の質問のエラーを単なる警告ではなく、本格的な致命的なエラーとして扱います(繰り返しになりますが、その特定のコマンドが失敗しても問題がないことは実際にはわかりません)。

これに対する最善の解決策は、最初からエラーが発生しないようにするための手順を実行することです。この場合、pg_restoreを実行する前に、別のコマンドを使用して テーブルを削除 し、--cleanオプションを省略してこれを行う可能性があります。

15
Ajedi32