PostgreSQLが起動可能/復元可能になるのを待つ方法は？

カスタムLinuxディストリビューションを実行している仮想マシンでPostgreSQL 8.2.1から9.2へのアップグレードをテストしています。アップグレード手順は次のとおりです。

1. pgサービスを開始する
2. すべてのDBをバキュームします（これが必要かどうかは不明です）
3. バックアップ pg_dumpall
4. pgサービスを停止します
5. データが格納されているディレクトリを移動します（/var/pg;これはシンプルな単一サーバーのセットアップです）
6. PostgreSQL 9.2をインストールする
7. initdb
8. サーバーを起動する
9. ダンプされたデータを復元する
10. reindexdb すべてのDB
11. referential_constraintsビューを再作成する
12. すべてのDBをバキュームします（このアップグレード後にAFAIKが必要です）

この手順は、1つのホストで問題なく動作し、問題なくバックアップおよび復元できます。データベースポイントが異なる1〜7の別のマシンでは正常に動作しますが、sleep 1after を追加しない限りサーバーは起動しません。initdbそれでも、「データベースシステムが起動中」であるため、ダンプされたデータを復元できません。これらのひどいハックを除いて、これに対処する標準的な方法は何ですか？

1. sleepどちらかの操作の前に、十分な時間をかけてください。
2. 動作するまで、または十分なタイムアウトになるまでループするか、
3. 簡単なクエリを受け入れるか、タイムアウトに達するまでループします。

編集：「ソリューション」は結局機能しませんでした。データベースが復元を実行する準備ができていることを確認するには何が必要ですか？

initdbは終了するまで戻りません。そのため、initdbとサーバーの起動の間に一時停止は必要ありません。PostgreSQLにはバグがあり、最初にすべてをディスクにフラッシュせずに完了しました。私は今のところ左については知りませんが、バグの性質はあなたがそれらについて常に知っているわけではないということです。

pg_ctlコマンドを使用してデータベースを起動する場合は、「-w」パラメーターを使用して、起動が完了するまで待機してから戻ります。特別なことは何もしません。「まだ準備ができていますか？」あなたのためのループ。

サーバーが起動する前に再生する必要のある大量のデータでサーバークラッシュが発生した場合、pg_ctlの待機中に "-t"で設定されたタイムアウトが小さすぎる可能性があることに注意してください。

ソースデータベースのpg_dumpを実行する前に、ソースデータベースをVACUUMする理由はありません。ダンプが少し速くなるかもしれませんが、掃除機自体はその改善よりも時間がかかります。

の ワーキング壊れたソリューションは、関連するポートが使用されているかどうかを繰り返し確認するようにinitスクリプトを変更することでした。1分経っても表示されない場合は、起動に失敗したと見なされます。疑似コード：

start() {
    pg start
    checks=0
    while checks < 30:
        return true if the port is in use
        sleep 2
        checks++
    return false
}

編集：これは十分ではないことが判明しました。復元手順：

PGOPTIONS='--client-min-messages=warning' psql \
    --no-psqlrc \
    --variable=ON_ERROR_STOP=1 \
    --quiet \
    --log-file="$restore_log" \
    --single-transaction \
    --username postgres \
    --file="$sql_backup"

エラーメッセージ：

psql: FATAL:  the database system is starting up