【SQL】pg_dumpしたデータでリストア失敗【PostgresSQL】

[事象1]
pg_dumpコマンドで出力したデータを別のサーバーのDBにpsqlコマンドでリストアしたら重複キーエラーが発生した。

補足:実際はレコードのinsertは成功、つまり重複レコードが入ってしまった。その後の主キー制約の作成で重複キーエラーが出力されていた。
postgresのダンプデータの順序は、レコードをcopyした後に主キー制約作成（インデックス作成）という順序になっているらしく、この様な状態となった。

これだけ聞くとPostgreSQLのダンプのバグのように思えるが、実際は違うようだ。

[調査]
元のDB（pg_dumpを実行したDB）を見ると元のDBが壊れていた。
事象としては以下のselect文で結果が違うと言う不可思議な現象だった。

①whereで主キー指定したselect 文
②whereで主キー以外を指定したselect文

これらの結果は一緒になる想定だったのだが、実行すると結果が違って、②の方が数十行多く出力されていた。
このテーブルには、主キーが設定されていたにも関わらず、明らかに重複キーの状態でテーブルに登録されていた。
これによりインデックスと生テーブルに不一致が発生したと判断した。
つまり、インデックスは正しいが、テーブルには重複レコードが存在している。

因みにpostgresはupdateする際は、追記型つまり内部で行をコピー＆元の行に削除フラグをたてているはず。この削除フラグの変更が失敗したのではないかと思う。

元のDBが壊れた理由は不明。訳あって調査出来ず。

[復旧]
2回ほど復旧を実施した。もとのDBは運用環境のため、触る事が出来ない。そのため、リストア先DBの復旧を行った。リストア前、リストア後の復旧を行った。とある事情により、それぞれ違う方法を使用した。

(a)ダンプデータを修正して再リストア
中途半端にリストアしたDBは破棄して、ダンプデータをviで修正（重複レコード削除）して再度リストア。
この方法はダンプデータが巨大だとかなり時間がかかる。と言うか、でかすぎるとエディタがまともに動かなくなる。一応、ダンプデータは5GB程度だったかな？なのでこれでも復旧出来た。また、バイナリダンプの場合は使用出来ない。

(b)中途半端にリストアされたDBを復旧
select row_number over partition byで重複レコードを探す。group by having countでも良い。その結果から残したい行のinsert文を作成。
で、重複レコードを二行とも削除（主キー制約作成失敗しているため、A5では片方ずつの削除が出来なかった）。
で作成したinsert文を実行。その後、失敗していた主キー制約を作成して復旧完了。こちらは復旧の仕方が正しいのか不安がある。