説明されている問題の主題
PostgreSQLでデータベースを操作する場合、データベースクラスターが初期化されたロケールを覚えておく必要があります-これは、このPostgreSQLインストールのすべてのデータベースのデータが格納されるディレクトリの名前（通常は
/var/lib/pgsql/data ）です。
問題
今日、私はそのような問題に遭遇しました。 クエリで
lower()関数を使用した場合、キリル文字の小文字への縮小は行われませんでしたが、英語の値は喜んで「減少」しました。
問題を解決する最初の試み
インターネットの半分でのグーグル検索では、検索したデータベースが
UTF-8エンコーディング（私の場合、誤ってデフォルトの
SQL_ASCIIであった場合）であればいいという情報が得られました。
わかった すぐに言ってやった！ データを失うことなく、新しいエンコードでデータベースを再作成する方法に関する指示を比較的迅速に見つけました。
[bash]
＃su-postgres
〜vacuumdb --full --analyze --username postgres --dbname mydatabase
〜pg_dump mydatabase -Ft -v -U postgres -f /tmp/mydatabase.tar
〜dropdb mydatabase --username postgres
〜createdb --encoding UNICODE mydatabase --username postgres
〜pg_restore /tmp/mydatabase.tar | psql --dbname mydatabase --username postgres
〜vacuumdb --full --analyze --username postgres --dbname mydatabase
チェックにより、このデータベースのデータは劣化しませんでしたが、必要なアクション（
lower()関数を使用した
lower()へのキャストはとにかく行われませんでした
lower()問題の解決策は興味深いものになります。
Googleの継続的な読み物に加えて、このPostgreSQLサーバーのデータベースクラスターは「C」ロケールで初期化され、ファンキーな
lower()および
upper()には多くの意味があることに気付きました。
既存のデータベースとその中のデータを破壊することなく、データベースクラスターを再初期化する方法を理解する必要がありました。 同時に、このサーバーは実稼働
crontabです。一部のデータダンプは1時間に1回サーバー（
crontab ）にマージされます。 良いことは、再初期化のための無料の「ウィンドウ」がないほど多くの生産ではないことです。
60分30分で準備できる「窓」
営業日の終わりまで、1.5時間と60分間続く1つの無料「ウィンドウ」がありました。
地元のラップトップでウォームアップすることから始めることにしました。 ここで、オペレーティングシステムの違いに言及する価値があります。ラップトップ-Ubuntu 8.10、サーバー-CentOS5。3つのターミナルウィンドウと別のテキストエディターウィンドウを準備したので、準備作業を開始しました。
まず、最初の方法は2つに分割する必要がありました。既存のデータのダンプと、クラスターの再初期化後の復元です。
データベースダンプは強い苦情なしで行われ、同じデータベースに接続しているユーザーに
pg_dropは2、3回だけです（
pg_drop を閉じることにしました ）。
それから、かなり珍しい場所（
/usr/lib/postgresql/8.3/bin ）に隠されたコマンド（
initdb ）が見つかり（
Ubuntuの場合 ）、必要なパラメーターで実行されました。
[bash]
＃su-postgres
〜vacuumdb --full --analyze --username postgres --dbname mydatabase
〜pg_dump mydatabase -Ft -v -U postgres -f /tmp/mydatabase.tar
〜dropdb mydatabase --username postgres
〜initdb --locale = ru_RU.utf8 data /
くそー！ エラー...うーん、データベースクラスターディレクトリの内容を手動で削除する必要があることがわかりました。
警告！ すぐにrm -rf data/*しないでください。 私はラップトップでそれをやった後にこれを理解しました、そして回復後、サーバーへのユーザーアクセス権（ pg_hba.conf保存されています）は失われました。
変更中は、
pg_hba.confコピーをどこかに作成する必要があります。
[bash]
〜cpデータ/ pg_hba.conf /home/cr0t/pg_hba.2009.03.24_1654.conf
ディレクトリの内容を削除し、PostgreSQLデーモンを停止した後、クラスターはエラーなしで再初期化されました。
[bash]
〜終了
＃/etc/init.d/postgresql stop
＃su-postgres
〜rm -rfデータ/ *
〜initdb --locale = ru_RU.utf8 data /
サーバーを再起動し、ダンプから古いデータベースを「正しい」ロケールで初期化された新しいクラスターに復元するために残っただけです。
[bash]
〜終了
＃/etc/init.d/postgresql start
＃su-postgres
〜createdb --encoding UNICODE mydatabase --username postgres
〜pg_restore /tmp/mydatabase.tar | psql --dbname mydatabase --username postgres
〜vacuumdb --full --analyze --username postgres --dbname mydatabase
成功。 まとめ
これらの成功したアクションの後、
lower()関数はキリル文字を正しく「押し」始めました。 誰もが幸せです。 しかし、カスタムPostgreSQLロールについても考えませんでした（これが、バージョン8.xでユーザーが知られるようになった方法です）。 彼らはいなくなった。 良いものは、すべてをカップルで作成する必要がありました。
しかし、それらの多くを持っている人は、注意してください、私の間違いを繰り返さないでください！PS複数のデータベースがある場合に再初期化する手順
私の場合、破壊して3つのベースを復元する必要がありました。
この問題を解決するには、いくつかのアクションの追加の繰り返しのみを追加して、ダンプを削除してから復元する必要があります（必要に応じ
て、自動化スクリプトを作成することもできます ）。
[bash]
＃su-postgres
〜vacuumdb --full --analyze --username postgres --dbname mydb1
〜pg_dump mydb1 -Ft -v -U postgres -f /tmp/mydb1.tar
〜dropdb mydb1 --username postgres
〜vacuumdb --full --analyze --username postgres --dbname mydb2
〜pg_dump mydb2 -Ft -v -U postgres -f /tmp/mydb2.tar
〜dropdb mydb2 --username postgres
〜vacuumdb --full --analyze --username postgres --dbname mydb3
〜pg_dump mydb3 -Ft -v -U postgres -f /tmp/mydb3.tar
〜dropdb mydb3 --username postgres
〜cp data / pg_hba.conf ./
〜終了
＃/etc/init.d/postgresql stop
＃su-postgres
〜rm -rfデータ/ *
〜initdb --locale = ru_RU.utf8 data /
〜cp pg_hba.conf data /
〜終了
＃/etc/init.d/postgresql start
＃su-postgres
〜createdb --encoding UNICODE mydb1 --username postgres
〜pg_restore /tmp/mydb1.tar | psql --dbname mydb1 --username postgres
〜vacuumdb --full --analyze --username postgres --dbname mydb1
〜createdb --encoding UNICODE mydb2 --username postgres
〜pg_restore /tmp/mydb2.tar | psql --dbname mydb2 --username postgres
〜vacuumdb --full --analyze --username postgres --dbname mydb2
〜createdb --encoding UNICODE mydb3 --username postgres
〜pg_restore /tmp/mydb3.tar | psql --dbname mydb3 --username postgres
〜vacuumdb --full --analyze --username postgres --dbname mydb3
私のブログの
夏のコードからのクロスポスト
この投稿はFreeBSDで最近公開されたPatchim UTF-8 Collationに似ていますが 、 FreeBSDに固有の問題の解決策はそこに記載されているようですが、Ubuntuには引用しています。 問題を解決したとき、この情報は使用しませんでした。Googleで読むだけです。カルマをありがとう！ 、PostgreSQLブログに移動しました。