PostgreSQLを異なるメジャーバージョン（9.1から9.3など）からアップグレードするには、基本的に3つの方法があります。
pg_dumpを使用したアップグレード
最初の（できれば推奨される）方法は、新しい（9.3）バージョンのバイナリを使用して古い（9.1）バージョンのダンプを行い、新しいバージョンで作成された新しいクラスターに復元することです。
このアプローチは、一般に低速ですが、最も実現可能です。より高速にするための1つのヒントは、並行性の使用です。並列ジョブでダンプするには、次を実行できます。
$ pg_dump --format=directory --jobs=4 --no-synchronized-snapshots --file=/path/to/mydump mydatabase
持っているデータベースごとにそれを行い、--jobs=4値を任意の値に調整する必要があります（2からコアの数までのいくつかの値をテストし、どちらがより高速になるかを確認します）。また、このフェーズでは、データベースに誰も接続する必要はありません。変更すると、ダンプが破損します（非セキュアオプションのため--no-synchronized-snapshots）。
その後、次のコマンドを使用して、新しいインスタンスにダンプを復元できますpg_restore。
$ createdb <options> -T template0 mydatabase
$ pg_restore --exit-on-error --jobs=4 --dbname=mydatabase /path/to/mydump
その後ANALYZE、データベースで実行することをお勧めします。
$ vacuumdb --analyze-only mydatabase
（時間に余裕がある場合は、データベース--analyzeに対してのみ実行しVACUUM、可視性マップを更新します）
pg_upgradeを使用したアップグレード
別のオプションは、contribpg_upgradeを使用することです。この--link方法を使用すると、PostgreSQLを非常に高速にアップグレードできます。
使用する前に、データディレクトリ全体のバックアップを作成する必要があり--linkます。モードでは、何か問題が発生した場合、両方のデータ（新旧）が失われる可能性があるためです。また、ドキュメント全体と特に下部の注意事項を読んでください（pg_upgradeにはいくつかの制限があります）。
更新：--check決定的なコマンドを実行する前にオプションを使用してください。また、大規模なデータベースの場合、このコマンドをスクリーンセッションで実行することをお勧めします。
トリガーベースのレプリケーションツールを使用したアップグレード
バージョンをアップグレードする別のオプションは、トリガーに基づいた複製ツールを使用することです。Slony、Bucardo、Londisteのように。
これは、可能な限り最小のダウンタイムを必要とするオプションですが、作業するのが最も難しいオプションです。
そのためには、マスターが現在のバージョン（9.1）で、スレーブが新しいバージョン（9.3）であるマスタースレーブを構築する必要があります。次に、最初の同期を待機し（システムはまだ運用中）、その後、データベースに接続している全員を閉じ（ダウンタイムはここから始まります）、スレーブが追いつくのを待ち、マスター（スレーブ）に昇格させ、すべてのクライアント/アプリケーションをこの新しいバージョンにリダイレクトします。これで完了です。
Slonyのドキュメントには、Slonyを使用してPostgreSQLをアップグレードするための段階的な手順が記載されています。
どちらを選ぶか
まあ、いつものように、再開：
- dump + restoreは最も信頼性が高いですが、一般的には最も遅いものです（ただし、並列処理によりかなり良い結果が得られます）
- pg_upgradeは、ダウンタイムを最小限に抑えるための最適なオプションの1つです（使用できる場合は、制限を確認してください）。大規模なデータベースでも数分しかかかりません。
- トリガーレプリケーションは、間違いなく可能な限り最小のダウンタイム（ゼロに近い）を与えるものですが、達成するのは本当に難しく、経験のある人（PostgreSQLとレプリケーションツールの両方）にのみお勧めします。
私が助けてくれることを願っています。がんばろう。