停止/ダウンしており、VACUUM.
http://suwala.eu/blog/2010/10/09/how-to-vacuum-postgresql/
上記の一連のコマンドに従って、最後の行を正しく実行できないようです。
$ postgres -D /var/lib/pgsql/data YOUR_DATABASE_NAME < /tmp/fix.sql
これにより、次のエラーが表示されます
postgres: invalid argument: "YOUR_DATABASE_NAME"
Try "postgres --help" for more information.
理由はありますか？
明確化
「YOUR_DATABASE_NAME」とサーバーで使用したデータ ディレクトリは正しいものです。
質問で参照されている「how-to-vacuum-postgresql」ページは、推奨するときに非常に悪いアドバイスを提供しVACUUM FULLます。必要なのはデータベース全体のバキュームだけです。これはVACUUM、データベース全体に対してデータベース スーパーユーザーとして実行するだけです (つまり、テーブル名を指定しません)。
AVACUUM FULLはバージョンによって動作が異なりますが、すばやく再利用できるようにデータベースによって保持されているヒープ ファイル内のすべての領域を削除し、OS に解放します。これは、使用可能なデータベースに戻るために必要な最小値よりも桁違いに遅くなる可能性があります。また、require OS 呼び出しの後にデータベースにスペースを再割り当てするための挿入または更新が行わVACUUM FULLれるため、データベースが大量に膨張していない限り、その後の実行が遅くなる可能性があります。(ただし、autovacuum をオフにすると、ひどい状態になる可能性がありますが、おそらく最初に立ち直って、後で整理することをお勧めします。)
バージョン 9.0 より前の別の問題は、テーブルのヒープ ファイルの肥大化は解消されますが、インデックス ファイルの肥大化が、場合によっては劇的に増加VACUUM FULLする傾向があることです。を発行する場合は、通常、その後に aを付けて、インデックスを適切な状態に戻す必要があります。VACUUM FULLREINDEX
質問で参照されているページは、 http: //www.postgresql.org/docs/8.3/interactive/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND の PostgreSQL ドキュメントでシングルユーザーを使用するためのアドバイスにも注意を払っていません。モード：
システムは安全シャットダウン モードに入るとコマンドを実行しないため、これを行う唯一の方法は、サーバーを停止し、シングル ユーザー バックエンドを使用して VACUUM を実行することです。シャットダウン モードは、シングル ユーザー バックエンドでは適用されません。シングル ユーザー バックエンドの使用方法の詳細については、postgres のリファレンス ページを参照してください。
他の人が言及しているように、自動バキュームをオフにすることが有益なユースケースはほとんどありません。自動バキューム アクティビティを大きなテーブルの明示的なバキュームで補うと便利な場合があります。自動バキュームの設定を調整したい場合もありますが、実際にはオフにしないでください。そうしないと、パフォーマンスが低下し、トランザクションが発生します。 ID ラップアラウンドの問題が定期的に発生します。自動バキュームがメンテナンスを実行しているときにパフォーマンスの低下に気付いた人は、トリガーの攻撃性を下げたいという本能を持っている場合がありますが、それは通常逆効果です。通常、自動バキュームのコスト制限パラメータを調整して作業のペースを調整する方が、メンテナンスが必要なテーブルを無視するよりも優れています。