このリリースは 14.3 からの修正リリース(2022年6月16日リリース)です。
14.X からのアップデートではダンプ、リストアは不要です。
しかしながら、本リリースで修正された障害により既にインデックスに破損が生じている可能性があるため、該当するインデックスを再構築することが推奨されます。項目 1番を参照してください。
また、14.3 よりも前のバージョンからアップデートする場合には、14.3 のリリース情報も参照してください。
PostgreSQL 14.3 から 14.4 への変更点
本リリースは 14.4 バージョン単独です。
- CONCURRENTLYオプションを付与したインデックス作成または再作成で、インデックス破損の可能性があり、防止されました。 (Álvaro Herrera) (14)
- 非決定的な等価関数に対して Memorizeプランノードが堅牢になりました。 (David Rowley) (14)
- Memorizeプランの誤ったコスト見積もりが修正されました。 (David Rowley) (14)
- 複合型に対するドメインを返す関数の結果を行全体の変数で参照する問い合わせ処理が修正されました。 (Tom Lane) (14)
- プランナで GROUPING 関数で参照されている副問い合わせをプルアップする(上位の問い合わせに統合する)ときに、「ERROR: variable not found in subplan target list」が生じる問題が修正されました。 (Richard Guo) (14)
- pg_stat_get_subscription() 関数がゴミデータを含んだ追加の行を返す可能性があり、防止されました。 (Kuntal Ghosh) (14)
- クライアント文字エンコーディングがマルチバイト文字エンコーディングで、データベースの文字エンコーディングが SQL_ASCII の場合における、COPY FROM のエラー検査が修正されました。 (Heikki Linnakangas) (14)
- XMLTABLE や JSON_TABLE に多すぎる列別名を付加した場合のクラッシュが回避されました。 (Álvaro Herrera) (14)
- ビューやルールを(ダンプ出力や psql での表示のため)逆コンパイルする際、それが他で参照されうる場合には、SELECT 出力列の「AS "?column?"」別名句を見せるようになりました。 (Tom Lane) (14)
- 暗黙的に作成された演算子族がイベントトリガに通知されるようになりました。 (Masahiko Sawada) (14)
- スタンバイサーバの昇格中にリスタートポイントが実行されている時に行われるコントロールファイルの更新が、修正されました。 (Kyotaro Horiguchi) (14)
- 大規模トランザクションの論理レプリケーション中に、スタンバイの wal_receiver_timeout を発動させないようになりました。 (Wang Wei, Amit Kapila) (14)
- 無効なタイムゾーン省略形ファイルを読み取る際のファイルクローズ漏れが防止されました。 (Kyotaro Horiguchi) (14)
- カスタムサーバパラメータの短い説明に NULL を指定できるようになりました。 (Steve Chavez) (14)
- libpq で SSL秘密鍵の誤った所有者チェックが削除されました。 (Tom Lane) (14)
- ecpg でサーバ接続が失われた場合のエラーを適切に報告するようになりました。 (Tom Lane) (14)
- pg_amcheck でサーバ接続が失われた場合のクラッシュが修正されました。 (Tom Lane) (14)
- PL/Perl のテストケースが Perl 5.36 で動作するように調整されました。 (Dagfinn Ilmari Mannsaker) (14)
- PostgreSQL ビルド中に複数の OpenLDAP がインストールされている場合に、古い libldap_r ライブラリを誤って使用しないように configure が修正されました。 (Tom Lane) (14)
バージョン14 で追加された最適化のため、CREATE INDEX ... CONCURRENTLY と REINDEX ... CONCURRENTLY が時々インデックスエントリ作成に失敗していました。その結果、誤った問い合わせ結果が生じる可能性があります。本修正でこの最適化が取り消されました。
CONCURRENTLYオプションを付与して作成された全てのインデックスをバージョンアップ後に再作成することが推奨されています。
データ型の等価関数またはハッシュ関数が各呼び出しで一貫性に欠ける結果を返す場合に、Memorize がクラッシュを起こす可能性がありました。これからは、そのような場合にエラー「ERROR: could not find memoization table entry」が出るようになります。
この誤りにより、それが最善でない場合でも Memorize が使われたり、Memorizeノードにおける巨大なハッシュ表の初期化のためにエグゼキュータの起動時間が非常に長くなったりしました。
(修正前のエラー動作例) db=# CREATE TYPE ctyp4 AS (c1 boolean, c2 boolean); db=# CREATE DOMAIN dom4 AS ctyp4 NOT NULL; db=# CREATE FUNCTION f_ctyp4() RETURNS ctyp4 LANGUAGE sql AS $$ SELECT (true, true) $$; db=# CREATE FUNCTION f_dom4() RETURNS dom4 LANGUAGE sql AS $$ SELECT (true, true) $$; (複合型を返す場合は動作する) db=# SELECT f_ctyp4 FROM f_ctyp4(); f_ctyp4 ------------------------ (t,t) (1 row) (複合型のドメインを返す場合にエラーになっていた - 修正後は動作する) db1=# SELECT f_dom4 FROM f_dom4(); ERROR: type dom4 is not composite
(修正前バージョンでのエラー発生例) db=# CREATE TABLE t5 AS SELECT generate_series(1, 100)::int i ; db=# SELECT GROUPING(ss.x) FROM t5 CROSS JOIN LATERAL ( SELECT (SELECT t5.i) as x) ss GROUP BY ss.x; ERROR: variable not found in subplan target list
pg_stat_get_subscription() 関数は pg_stat_subscription ビューから使われます。
このバグにより、正しいデータに対しても「ERROR: invalid byte sequence for encoding "UTF8": 0xe5」などの入力データが不正であるという偽性のエラーが生じる可能性がありました。
そのような問い合わせに適切なエラーを返すようになりました。これまでは奇妙なエラーが出たり、クラッシュしたりしていました。
(修正後の動作、f(v1,v2) で実際の列数より多く別名が指定されている) db=# SELECT * FROM XMLTABLE (ROW () PASSING null COLUMNS v1 timestamp) AS f (v1, v2); ERROR: XMLTABLE function has 1 columns available but 2 columns specified (14.3 でのエラーメッセージ) ERROR: no relation entry for relid 0
これまでは、自動生成されたこの別名は常に隠されていましたが、結果としてビューやルールがリストア不能になる稀なケースがありました。
以前は、CREATE OPERATOR CLASS によって演算子族が暗黙的に作成された場合、イベントトリガに通知されませんでした。
以前は、リスタートポイント完了時にコントロールファイルの最終チェックポイントのフィールドが誤って更新される可能性があり、次の通常チェックポイント完了前にサーバがクラッシュした場合、PANIC が発生して再起動に失敗する可能性がありました。
以前は、プライマリサーバ上の大規模トランザクションが(おそらく変更されたテーブルがパブリッシュされていないために)スタンバイにデータを送信しない場合、スタンバイがタイムアウトする可能性がありました。キープアライブメッセージを定期的に送信することで修正されました。
このような場合には無害な警告メッセージが生じることがありました。
短い説明は SHOW ALL の description などに表示されるもので、以前は、拡張でここに NULL を指定していると表示処理がクラッシュしていました。
以前のマイナーリリースで、サーバでの SSL秘密鍵のアクセス権チェック方式を libpq にも適用しましたが、所有者チェックまで同様に行うべきではありませんでした。鍵ファイルにアクセス可能であるけれども所有者と異なるユーザでクライアントを実行するときに、予期せぬエラーが生じることがありました。
(エラー例: rootで root以外のユーザが所有者の鍵ファイルを指定して psqlを実行) $ su - # PGSSLCERT=/ssl/cert.pem PGSSLKEY=/ssl/key.pem PGSSLROOTCERT=/ssl/rcert.pem \ PGSSLMODE=verify-ca psql -h localhost -U postgres -d postgres psql: error: private key file "key.pem" must be owned by the current user or root
接続が失われた場合などに、libpq で生成されたエラー結果を誤って処理していたため、有用なエラーメッセージではなく「(null)」と出力されていました。また、古いリリースではクラッシュする可能性がありました(本修正は 10.x 以降に適用されています、次リリース 13.8、12.12、11.17、10.22 に含まれます)。
接続が失われた場合などに、libpq で生成されたエラー結果を誤って処理していたため、クラッシュが生じていました。