PostgreSQL 8.2.6文書
前のページ巻戻し付録 E. リリースノート早送り次のページ

E.53. リリース7.4.2

リリース日: 2004-03-08

このリリースは7.4.1の様々な不具合を修正したものです。

E.53.1. 7.4.2バージョンへの移行

7.4.Xからの移行の場合は ダンプ/リストアは必要ありません。 しかし、これは初期の7.4.Xシステムカタログの内容に存在した2つのエラーの修正を組み込む最も簡単な方法としてお勧めできます。 7.4.2のinitdbを使用したダンプ、initdb、再ロードという流れにより、自動的にこの問題が修正されます。

この2つのエラーのより深刻な点は、anyarrayデータ型が間違った整列ラベルを持っていたことです。 pg_statisticシステムカタログがanyarray型の列を使用しているため、これは問題です。 この間違ったラベル付けにより、doubleで整列された列(float8やtimestampなど)をWHERE句に含む問い合わせの計画を作成中、プランナは間違った推定を行ない、最悪はクラッシュしてしまいます。 initabや後述の手作業による修復手順に従って、全てのインストレーションでこのエラーを修復することを強く推奨します。

あまり深刻ではないエラーは、SETの代わりにUPDATE pg_settingsを使用できるようにpg_settingsシステムビューの出力がpublicに対して更新アクセス可能すべきでした。 これは、initdbや手作業で修正することができますが、UPDATE pg_settingsを使用したいのでない限り修正する必要はありません。

initdbを実行したくなければ、以下の手順でpg_statisticを修正することができます。 データベーススーパーユーザで実行してください。 

-- clear out old data in pg_statistic:
DELETE FROM pg_statistic;
VACUUM pg_statistic;
-- this should update 1 row:
UPDATE pg_type SET typalign = 'd' WHERE oid = 2277;
-- this should update 6 rows:
UPDATE pg_attribute SET attalign = 'd' WHERE atttypid = 2277;
--     
-- At this point you MUST start a fresh backend to avoid a crash!
--
-- repopulate pg_statistic:
ANALYZE;

これは稼働中のデータベースに対して行なうことができますが、変更したデータベースで実行中の全てのバックエンドは、pg_statisticを安全に更新させるために、再起動されなければなりません。

pg_settingsエラーを修復するには単に以下を実行してください。 

GRANT SELECT, UPDATE ON pg_settings TO PUBLIC;

上述の手順は、template1を含むインストレーションの全てのデータベースに対して行なわなければなりません。理想をいえばtemplate0にも行なってください。 テンプレートデータベースに対して修復を行なわないと、将来作成されるデータベースに同じエラーが含まれることになります。 template1は他のデータベースと同様の方法で修正できますが、template0の修正には更に手順が必要です。 まず、任意のデータベースから以下を発行してください。 

UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';

次にtemplate0に接続し、上の手順を実行してください。 最後に以下を実行してください。 

-- re-freeze template0:
VACUUM FREEZE;
-- and protect it against future alterations:
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';

E.53.2. 変更点

リリース7.4.2には、リリース7.3.6で行なわれた修正に加え、以下の修正が組み込まれています。

前のページホーム次のページ
リリース7.4.3上に戻るリリース7.4.1