このリリースは 12.8 からの修正リリース(2021年11月11日リリース)です。
12.X からのアップデートではダンプ、リストアは不要です。
しかしながら、本リリースで修正されたいくつかの障害により既にインデックスに破損が生じている可能性があるため、該当するインデックスを再構築することが推奨されます。
また、12.6 よりも前のバージョンから移行する場合には 12.6 のリリース情報も確認してください。
PostgreSQL 12.8 から 12.9 への変更点
14.1、13.5、12.9、11.14、10.19、9.6.24 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。
- PostgreSQLサーバが SSL暗号化または GSS暗号化においてハンドシェイクが完了するまでは外来データを拒絶するようになりました。 (Tom Lane) (14)(13)(12)(11)(10)(9.6)
- libpq が SSL暗号化または GSS暗号化のハンドシェイクが完了する前は、外来データを拒絶するようになりました。 (Tom Lane) (14)(13)(12)(11)(10)(9.6)
- 物理レプリケーションで、プライマリが部分的な WALレコードで終わっているWALセグメントを渡した後にクラッシュした場合について、修正されました。 (Álvaro Herrera) (14)(13)(12)(11)(10)(9.6)
- 並列VACUUM がインデックスを取りこぼさないように修正されました。 (Peter Geoghegan, Masahiko Sawada) (14)
- CREATE INDEX CONCURRENTLY が直近の準備されたトランザクションを待つように修正されました。 (Andrey Borodin) (14)(13)(12)(11)(10)(9.6)
- 同時作成をしているインデックスで、新たな行に対するエントリ追加の失敗を引き起こす可能性のある競合状態が回避されました。 (Noah Misch, Andrey Borodin) (14)(13)(12)(11)(10)(9.6)
- 対象インデックスに付加された演算子クラスのパラメータを維持するようにREINDEX CONCURRENTLY が修正されました。 (Michael Paquier) (14)(13)
- 組込オブジェクト以外を含んだデータベースを複製するときの共有依存関係の誤作成が修正されました。 (Aleksander Alekseev) (14)
- パーティションテーブルにアタッチあるいはデタッチしているテーブルについて、リレーションキャッシュが確実に無効化されるようになりました。 (Amit Langote, Álvaro Herrera) (14)(13)(12)(11)(10)
- 範囲型の作成時にパースツリーが破損する障害が、修正されました。 (Alex Kozhemyakin, Sergey Shinderuk) (14)
- 複合型のドメインの配列の要素の更新について修正されました。 (Tom Lane) (14)(13)(12)(11)
- FETCH FIRST WITH TIES と FOR UPDATE SKIP LOCKED の組み合わせが禁止されました。 (David Christensen) (14)(13)
- ALTER INDEX .. ALTER COLUMN .. SET (..) でのオプション指定が禁止されました。 (Nathan Bossart, Michael Paquier) (14)(13)
- numeric型の power() 関数で稀な場合の精度損失が修正されました。 (Dean Rasheed) (14)(13)(12)(11)(10)(9.6)
- Memoizeプランでハッシュ等価演算子の誤選択が回避されました。 (David Rowley) (14)
- 副問い合わせの式を関数にプルアップする際のプランナエラーが修正されました。 (Tom Lane) (14)(13)
- 列の範囲の見積に不完全な MCV のみのプランナ統計情報を信用して使わないように修正されました。 (Tom Lane) (14)(13)(12)(11)(10)
- サブトランザクション内でのポータルのスナップショット復旧について修正されました。 (Bertrand Drouvot) (14)(13)(12)(11)
- スナップショットのエクスポート後にトランザクションが失敗した場合に、正しくクリーンアップするようになりました。 (Dilip Kumar) (14)(13)(12)(11)(10)(9.6)
- スタンバイサーバでオーバーフローしたサブトランザクション追跡の周回を防止しました。 (Kyotaro Horiguchi, Alexander Korotkov) (14)(13)(12)(11)(10)(9.6)
- スタンバイサーバの昇格中に、(二相コミット機能の)準備されたトランザクションが適切に考慮されるようになりました。 (Michael Paquier, Andres Freund) (14)(13)(12)(11)(10)(9.6)
- EXPLAIN が WorkTableScanノードにアタッチされたフィルタ条件を表示しようとした時の予期せぬエラーが修正されました。 (Tom Lane) (14)
- ALTER INDEX コマンドを使ってテーブルの名前を変更する際に、正しいロックレベルを使用するように修正されました。 (Nathan Bossart, Álvaro Herrera) (14)(13)(12)
- オブジェクトとそのオブジェクトを所有するロールが並行して同時に削除された場合に null-pointer-dereference によるクラッシュが発生することがあり、回避されました。 (Álvaro Herrera) (14)(13)(12)(11)(10)(9.6)
- lo_export() または関連する関数が失敗した場合のスナップショット参照のリーク警告が防止されました。 (Heikki Linnakangas) (14)(13)(12)(11)(10)(9.6)
- CoerceToDomain式ノードの非効率なコード生成が修正されました。 (Ranier Vilela) (14)(13)
- いくつかのリスト操作で O(N^2) の動作が回避されるようになりました。 (Nathan Bossart, Tom Lane) (14)(13)
- B-tree のポスティングリスト分割に関する防御的な検査が追加されました。 (Peter Geoghegan) (14)(13)
- BRIN の float8 または float4 の minmax_multi_ops インデックスにNaN を挿入する時のアサート失敗が回避されました。 (Tomas Vondra) (14)
- 自動VACUUM のランチャープロセスが pg_log_backend_memory_contexts() の要求に対してより迅速に応答できるようになりました。 (Koyu Tanigawa) (14)
- 認証処理で使われる HMACハッシュ計算におけるメモリリークが修正されました。 (Sergey Shinderuk) (14)
- shared_memory_type が sysv の場合、huge_pages を on に設定することが禁止されました。 (Thomas Munro) (14)(13)(12)
- PL/pgSQL の RETURN QUERY文における、クエリ型のチェックが修正されました。 (Tom Lane) (14)
- 大域的でないデフォルト権限を正しくダンプするように、pg_dump が修正されました。 (Neil Chen, Masahiko Sawada) (14)(13)(12)(11)(10)(9.6)
- ダンプされるパーティションテーブルに対して、pg_dump が共有ロックを取得するようになりました。 (Tom Lane) (14)(13)(12)(11)(10)
- PostgreSQL 8.3 より前のサーバからトリガ定義をダンプしようとした際のpg_dump のクラッシュが修正されました。 (Tom Lane) (14)(13)(12)(11)
- pg_restore の無効なラージオブジェクトの TOCファイルに関するエラーメッセージ中の誤ったファイル名が修正されました。 (Daniel Gustafsson) (14)(13)(12)(11)(10)(9.6)
- ソケットレベルの障害発生後、pgbench がゼロ以外のステータスで終了するようになりました。 (Yugo Nagata, Fabien Coelho) (14)(13)(12)
- pg_amcheck が一時的なリレーションや、無効または準備ができていないインデックスをチェックしないようにしました。 (Mark Dilger) (14)
- contrib/amcheck がスタンバイサーバで実行される際に、UNLOGGEDテーブルをスキップするようになりました。 (Mark Dilger) (14)
- pg_stat_statements が最大 1GB 単位でクエリテキストファイルを読み込むようになりました。 (Tom Lane) (14)(13)(12)(11)(10)(9.6)
- postgres_fdw がデータ変換エラーを報告しようとする際に発生しうる NULLポインタのクラッシュが修正されました。 (Tom Lane) (14)(13)(12)(11)(10)(9.6)
- 内部実装の関数 GetSharedSecurityLabel() が、クリティカルなリレーションキャッシュエントリがまだ構築されていない新たに開始したセッションでも使用できるようになりました。 (Jeff Davis) (14)(13)(12)(11)(10)(9.6)
- TAPテストを実行する際、モジュール自体のディレクトリを PATH に含めるようになりました。 (Andrew Dunstan) (14)
- Windows のタイムゾーン名を IANAタイムゾーンに割り当てるのにCLDRプロジェクトのデータを利用するようになりました。 (Tom Lane) (14)(13)(12)(11)(10)(9.6)
- タイムゾーンデータファイルが tzdata release 2021e に更新されました。 (14)(13)(12)(11)(10)(9.6)
- float4 と float8 のハッシュ関数が NaN に対して均一の結果を生成するように修正されました。 (Tom Lane) (13)(12)(11)(10)(9.6)
- wal_level が minimal に設定されている時 CREATE TABLESPACE のクラッシュリカバリでのデータ損失が防止されました。 (Noah Misch) (13)(12)(11)(10)(9.6)
- パーティションテーブルがパブリケーションへ追加もしくは削除される際に、全てのパーティションのリレーションキャッシュが無効化されるようになりました。 (Hou Zhijie, Vignesh C) (13)
- FOR ALL TABLES と指定されたパブリケーションを作成もしくは削除する際に、リレーションキャッシュが無効化されるようになりました。 (Hou Zhijie, Vignesh C) (13)(12)(11)(10)
- 修飾子が指定されていない同じ型へのキャストを破棄しないようになりました。 (Tom Lane) (13)(12)(11)(10)(9.6)
- 現在のデータベースエンコーディングがサポートしていない ICU照合順序は作成できないようになりました。 (Tom Lane) (13)(12)(11)(10)
- {0} 内の括弧をキャプチャする際の正規表現エラーを回避するようになりました。 (Tom Lane) (13)(12)(11)(10)(9.6)
- 正規表現の後方参照が、本来マッチすべきでない時にマッチしてしまうのを防ぐようになりました。 (Tom Lane) (13)(12)(11)(10)(9.6)
- 反復ノード内の後方参照による正規表現の性能上のバグが修正されました。 (Tom Lane) (13)(12)(11)(10)(9.6)
- タイムゾーン付きの時刻を AT TIME ZONE に適用した際に、間違った結果を返す問題が修正されました。 (Tom Lane) (13)(12)(11)(10)(9.6)
- PlaceHolderVars の継承子テーブルへの転換の誤りが修正されました。 (Tom Lane) (13)(12)
- バックグラウンドワーカが LISTEN を実行できないようになりました。 (Tom Lane) (13)
- 他のバックエンドへの NOTIFY シグナル送信をトランザクションコミットの時に行うようになりました。 (Artur Zakirov, Tom Lane) (13)
- WITH HOLD オプションによって前トランザクションから保留されている NO SCROLL指定のカーソルの巻き戻しを、拒否するようになりました。 (Tom Lane) (13)(12)(11)
- WITH HOLD カーソルをトランザクション終了時点で保存するときに、既にカーソルが読み込み完了していた場合に、失敗しないように修正されました。 (Tom Lane) (13)(12)(11)
- 許可された最大長に増大したリレーションの検出が修正されました。 (Tom Lane) (13)(12)(11)(10)(9.6)
- DO INSTEADルールを展開するときに、データ変更を伴う CTE(WITH句)の存在を確認するようになりました。 (Greg Nancarrow, Tom Lane) (13)(12)(11)(10)(9.6)
- 拡張統計情報オブジェクトへの権限のない操作に対する誤ったパーミッションエラー報告が修正されました。 (Tomas Vondra) (13)(12)(11)(10)
- 並列ワーカの誤ったスナップショット処理が修正されました。 (Greg Nancarrow) (13)(12)(11)(10)
- 一時テーブルの TOASTテーブル変更を適切に無視するように、ロジカルデコーディングが修正されました (Bertrand Drouvot) (13)(12)(11)
- TOASTデータを正しく処理するために論理デコーディングのメモリ使用量計算が修正されました。 (Bertrand Drouvot) (13)
- walreceiverプロセスが、終了する前に全ての必要なアーカイブ通知ファイルを 作成するのを保証するようになりました. (Fujii Masao) (13)(12)(11)(10)(9.6)
- バックアップマニフェスト生成における WAL範囲の計算が、タイムライン変更が伴う場合について修正されました。 (Kyotaro Horiguchi) (13)
- SELECT .. FOR UPDATE を使うルールで疑似リレーション OLD、NEW にロック処理を行わないように修正されました。 (Masahiko Sawada, Tom Lane) (13)(12)(11)(10)(9.6)
- 集約の FILTER句のパーサ処理が修正されました. (Tom Lane) (13)(12)(11)(10)(9.6)
- ALTER TYPE/DOMAIN/OPERATOR .. SET が拡張のメンバシップを変更しないように修正されました。 (Tom Lane) (13)
- LLVM 内でのエラー後に LLVM状態のクリーンアップを試みないように修正されました。 (Andres Freund, Justin Pryzby) (13)(12)(11)
- SP-GiSTインデックスのスキャンが統計ビューでカウントされることを保証するようになりました。 (Tom Lane) (13)(12)(11)(10)(9.6)
- リカバリ中に recovery_min_apply_delay が変更された場合には、関連する待機間隔を再計算するようになりました。 (Soumyadeep Chakraborty, Ashwin Agrawal) (13)(12)(11)(10)(9.6)
- simplehash.h のハッシュテーブルが 2^32 要素を超えた場合に無限ループになる誤りを修正しました. (Yura Sokolov) (13)(12)(11)(10)
- ANALYZE実行における拡張統計の計算中のメモリ使用量が削除されました。 (Justin Pryzby, Tomas Vondra) (13)(12)(11)(10)
- AIX において libpq の関数が欠落しており、修正されました。 (Tony Reix) (13)
- 接続を試みている途中で malloc() に失敗してもエラー後に正しく回復できるように、ecpg が修正されました。 (Michael Paquier) (13)(12)(11)(10)(9.6)
- PL/pgSQL の CALL文の引数で呼ばれる STABLE の関数を誤って評価していたものが修正されました。 (Tom Lane) (13)(12)(11)
- PL/pgSQL で最も外側のブロックからの EXIT が可能になりました。 (Tom Lane) (13)(12)(11)(10)(9.6)
- pg_ctl のハードコーディングされた生成されたコマンド長の上限が取り除かれました。 (Phil Krylov) (13)(12)(11)(10)(9.6)
- RLS(行単位セキュリティ)ポリシーむけにテーブルごとの問い合わせ作成を回避することで、また、反復的な format_type() の呼び出しを回避することで、pg_dump の性能が改善されました。 (Tom Lane) (13)(12)(11)(10)(9.6)
- contrib/btree_gin の(char(n)ではなく)"char" 列に対するインデックスの誤りが修正されました。 (Tom Lane) (13)(12)(11)(10)(9.6)
- RISC-V アーキテクチャむけのスピンロックのサポートが追加されました。 (Marek Szuba) (13)(12)(11)(10)(9.6)
- OpenSSL 3.0.0 がサポートされました。 (Peter Eisentraut, Daniel Gustafsson, Michael Paquier) (13)(12)(11)(10)
- 作成した OpenSSL の BIO(I/O 抽象化)オブジェクトに正しい型識別子を設定するようになりました。 (Itamar Gafni) (13)(12)(11)(10)(9.6)
- libpq の静的リンクのための pkg-configファイルが修正されました。 (Peter Eisentraut) (13)(12)
- pg_regexec() が範囲外の search_start パラメータに対してより頑健になりました。 (Tom Lane) (13)(12)(11)(10)(9.6)
これまで TCP接続にデータを挿入できる中間者は、暗号化で保護されているはずのデータベースセッションの冒頭に平文データを投入可能でした。サーバが認証データを要求してこない場合(例えば SSL証明書認証のみを使っている場合)に限られますが、これを悪用して偽の SQLコマンドをサーバに送ることができました。(CVE-2021-23214)
これまで TCP接続にデータを挿入できる中間者は、暗号化で保護されているはずのデータベースセッションの冒頭に平文データを投入可能でした。libpq の問い合わせ応答以外の細かい振る舞いのために実現は容易ではありませんが、これを悪用してクライアントの最初の問い合わせに偽の応答を挿入することがおそらく可能でした。別の攻撃は、セッションの初期に送られたクライアントのパスワードやその他の機微データを抜き出すことです。これは前項のサーバ側脆弱性と組み合わせて可能となります。(CVE-2021-23222)
ダウンするプライマリが不完全な WALレコードの残りを書き込み完了できなかった場合、以前のクラッシュリカバリロジックでは、それをバックアップして、不完全な WALレコードの最初から WAL を上書きしました。スタンバイサーバは既にその WALセグメントのコピーを持っているかもしれないので、これは問題がありました。不整合な次セグメントに遭遇して、手動の介入なしにはリカバリできないことになりました。
本障害により、更新処理を実行中のプライマリのクラッシュ後にスタンバイがレプリケーション継続できなくなる可能性があり、対処策はスタンバイで WALファイルを手動削除して再起動することでした。
クラッシュ後の再起動時に WALセグメント境界を越えたバックアップをしないように修正されました。その代わりに、次の WALセグメントの始めに新しいタイプ(OVERWRITE_CONTRECORD)の WALレコードを書いて、不完全な WALレコードは無視しなければならないことを知らせるようになりました。
この修正を適用する場合、新しい WALレコードタイプが生じるようになるため、プライマリより先にスタンバイサーバをアップデートするのが良いです。
テーブルが min_parallel_index_scan_size を上回る 2つ以上のインデックスを持つ場合に、並列VACUUM が min_parallel_index_scan_size を下回るインデックスを処理していませんでした。この結果、これらのインデックスは VACUUM で除去済みのヒープ上のエントリに対する参照を持つことになって、破損した状態となる可能性があります。
この問題は並列VACUUM を行わない autovacuum には影響しません。発生条件に該当する、サイズの大小が異なる複数のインデックスを持っていて手動VACUUM を行ったことがあるテーブルについて、REINDEX を行うことが推奨されます。
準備されたトランザクションから直近に挿入された行が、新たなインデックスから無視されるかもしれませんでした。その結果、インデックスに依存する問い合わせが、その行を取りこぼすおそれがありました。
この問題に対する以前の修正は、CREATE INDEX CONCURRENTLY が検査したときに進行中の PREPARE TRANSACTIONコマンドを考慮できていませんでした。max_prepared_transactions > 0 の準備されたトランザクション(二相コミット)が有効なサーバでは、CONCURRENTLY指定で作成されたインデックスを全て REINDEXすることが推奨されます。
これにより破損したインデックスが生じる可能性があります。実際には稀にしか発生しないとみられますが、この誤りは潜在的に CONCURRENTLY指定を付けたあらゆるインデックス構築または再構築に影響する可能性があります。同時作成したインデックスの全てを REINDEXすることが推奨されます。
REINDEX CONCURRENTLY 実行後にデフォルトパラメータになってしまう現象が発生していました。
データベースの複製は、テンプレートデータベースから新たなデータベースを作成するとき行われます。本誤動作の結果 pg_shdepend の内容が不正になります。原理的には本障害でオブジェクトを所有しているロールが削除可能になってしまう可能性がありますが、本障害の実際の影響は限定的と考えられます。
本障害により、アタッチ/デタッチの後に既存のセッションからそのパーティションに対する直接の挿入/更新を行ったときに、アタッチ/デタッチ操作がリレーションキャッシュに反映されていないことによる、不適切な制約の適用等の誤動作を起こす可能性がありました。
CREATE TYPE がパースツリーの要素を誤って解放していて、続くイベントトリガや CREATE TYPE コマンドがプランキャッシュに格納されて後に再使用される場合に、(クラッシュや予期せぬエラー等の)問題が起きる可能性がありました。
「UPDATE tab SET fld[1].subfld = val」のようなコマンドが、配列要素が複合型ではなく複合型のドメインである場合に失敗して、クラッシュや誤った更新結果を引き起こしました。
(障害発生例/クラッシュが生じる) db=# CREATE TYPE typ11 AS (subfld1 int, subfld2 int); db=# CREATE DOMAIN dom11 AS typ11 NOT NULL; db=# CREATE TABLE tbl11 (id int, fld dom11[]); db=# INSERT INTO tbl11 VALUES (1, '{"(1,2)","(3,4)"}'::dom11[]); db=# UPDATE tbl11 SET fld[1].subfld1 = 1; server closed the connection unexpectedly
FETCH FIRST WITH TIES は同順位でない行を見つけるまで停止しないため、返すべき行数に加えてもう 1行を取り出す必要があります。また、現在の実装では FOR UPDATE が使われた場合は返さない行についてもロックを取得します。その結果、SKIP LOCKED オプションが指定された場合に望ましくない振る舞いが生じました。当面の対処として、この組み合わせが禁止されました。
以下の動作例では id=3 の行が応答に登場しない結果となります。
(望ましくない動作の例) db=# CREATE TABLE t12 (id int, n int); db=# INSERT INTO t12 VALUES (1,10),(2,10),(3,30),(4,40); db=# BEGIN; SELECT * FROM t12 ORDER BY n FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED; id | n ----+---- 1 | 10 2 | 10 (2 rows) (別セッションで以下を実行) db=# SELECT * FROM t12 ORDER BY n FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED; id | n ----+---- 4 | 40 (1 row)
これまでパーサが受け付けていて、ALTER TABLE の場合と同じパラメータが指定可能でしたが、これは文書記載がなく、実際には機能しない一方、オプションを付与するとその列やテーブルの削除ができなくなりました。
第一引数が 1 に非常に近い場合に不正確な結果が生じる可能性がありました。「^」演算子の左辺が 1 に近い場合についても同様に該当します。
本障害により、クラッシュまたは誤った問い合わせ結果が生じるおそれがありました。
FROM にある関数が FROM句の副問い合わせの出力をラテラル参照する場合で、副問い合わせを外側の問い合わせに平坦化が可能である場合、関数の式へコピーされた式は完全には処理されませんでした。その結果、プランの実行時にクラッシュを引き起こすおそれがありました。
(本障害でクラッシュを起こす問い合わせの例) db=# SELECT * FROM ( SELECT jsonb_path_query_array(mod->'lecs', '$[*]') AS lec FROM unnest(array['{"lecs": [{"id": "1"}]}'::jsonb]) AS um(mod)) AS ss, jsonb_to_recordset(ss.lec) AS j (id text);
ANALYZE で稀に MCV(most-common-values、最頻値)リストが作られてヒストグラムは作られないことがあります。このような場合、MCVリストのみでデータ全体をあらわせそうな場合に限って、MCVリストのみで列値の範囲を見積をするようになりました。
プロシージャがあるトランザクションをコミットやロールバックして、その次の明示的な動作が新たなサブトランザクション内である場合にスナップショット管理を誤っていました。その結果、不正なポインタが生じて、クラッシュを引き起こす可能性がありました。
典型的には PL/pgSQL で以下のような処理を行う場合に該当します。
FOR i IN 1..100 LOOP -- 何らかのループ BEGIN {問い合わせを実行} EXCEPTION {条件に応じて COMMIT や ROLLBACK を実行してループを継続} END; END LOOP;
この誤りは、同じセッションがスナップショットを再びエクスポートしようとした場合に限って問題を引き起こします。ありそうな該当シナリオは、レプリケーションスロットを作成して、それが何らかエラーで失敗して、その後に続けて他のレプリケーションスロットを作成しようとすることです。
予期せぬ「ERROR: clearing exported snapshot in wrong transaction state」が発生する動作が報告されました。
この誤りにより、スタンバイサーバで顕著な性能低下をもたらすおそれがあります。該当した場合、SubtransSLRU についての過大な処理量がはっきり現れました。
同時実行中のセッションが取得したスナップショットで、準備されたトランザクションが省略される可能性がある限られた時間帯がありました。その後、そのセッションがスナップショットを使用してデータを更新すると、誤った結果やデータの破損が発生する可能性がありました。
CTE (WITH句)を伴う問い合わせの EXPLAIN で、以下のエラーが出る動作が報告されました。
ERROR: could not find RecursiveUnion for WorkTableScan with wtParam 0
歴史的な理由から、ALTER INDEX ... RENAME はあらゆる種類のリレーションに適用できます。インデックス名を変更するのに必要なロックレベルは、テーブル等その他のリレーション名を変更する場合より低いのですが、ALTER INDEX を使った場合には対象がインデックス以外であっても、誤って低いロックレベルが使用されていました。
(誤動作例) db=# CREATE TABLE t24a (id int); CREATE TABLE t24b (id int); db=# BEGIN; db=*# ALTER TABLE t24a RENAME TO t24x; db=*# ALTER INDEX t24b RENAME TO t24y; db=*# ^Z (別セッションでロックを確認) db=# SELECT relation::regclass, locktype, mode FROM pg_locks WHERE relation IS NOT NULL; relation | locktype | mode ----------+----------+-------------------------- pg_locks | relation | AccessShareLock t24b | relation | ShareUpdateExclusiveLock t24a | relation | AccessExclusiveLock (3 rows)
以前は下記のようなメッセージが出力されましたが、実際のリークはほとんど害のないものでした。
WARNING: Snapshot reference leak: Snapshot 0x5634afd61cb8 still referenced
本修正は DOMEIN型の列に値を投入したり、DOMAIN型に型キャストする場合のエグゼキュータ処理を効率化します。
これにより、 (1)プライマリ上で多数の排他ロックを保持しているトランザクションをスタンバイでリプレイする場合、 (2)チェックポイント後に削除(unlink)されることになっているファイルが多数ある場合、 (3)ハッシュ集約に多くのバッチ(ディスク書き出し)が含まれる場合、 (4)pg_trgm が複雑な正規表現からインデックス可能な条件を抽出する場合、を含むいくつかのシナリオで処理速度低下が修正されました。
これらのうち、実際にユーザから報告されたのは (1) だけですが、それ以外も非効率なリスト削除により該当すると見られます。
この変更により、テーブルの TID の重複を含むインデックスの破損を検出できるようになります。
アサートを無効にした実運用むけビルドにおいては、このような場合、いくらか非効率的ですが間違ってはいないインデックスになります。
これまで数秒を要することがありました。
以前はこの設定は受け入れられていましたが、実装がないため何もしませんでした。
RETURN QUERY は、UPDATE RETURNING のようにタプルを返すことができる任意のクエリを受け入れるべきです。 v14 では誤って SELECT 以外のものを禁止していました。さらに、可変の RETURN QUERY EXECUTE では、クエリ型チェックがまったく適用されていませんでした。
大域的な(限定なしの)ALTER DEFAULT PRIVILEGES コマンドが関数の EXECUTE などデフォルトである権限を取り消した後、限定付きの ALTER DEFAULT PRIVILEGES コマンドが選択されたロールやスキーマに対してその権限を再び付与した場合、pg_dump は制限付きの権限付与を正しくダンプできませんでした。
pg_dump が子のパーティションのいずれかをロックすれば、パーティションテーブル自体に対する重要な DDL を防ぐのに十分であるためこの見落としはたいていの場合は無害なものでしたが、関連するロックが保持されないため、子のないパーティションテーブルをダンプするときに問題が発生する可能性がありました。
以前は以下のようなファイル名が空のエラーメッセージが表示されていました。
pg_restore: error: invalid line in large object TOC file "": ..
望ましい動作は実行を完了した後、ステータス 2 で終了することで、そのように修正されました。また、ソケットレベル障害のエラー報告が修正されました。
これにより、ほぼ確実に矛盾しているように見える、役に立たないリレーションのチェックが回避されます。
このようなテーブルは空になりますし、UNLOGGEDインデックスもすでにスキップするようになっているため、このようにするのが適切です。
2GB 以上のファイルを一度に読み込もうとするとすると失敗する可能性があるため、複数回に分けて読み込むようになりました。
(サードパーティモジュール以外で)影響があるのは contrib/sepgsql のみです。
これによりインストールされていないプログラムを検出できるようになりました。
initdb は新たなクラスタのタイムゾーンパラメータに、システムのタイムゾーンに対応した IANAタイムゾーンを設定しようとします。これまで Windows で利用していたマッピングテーブルは何年も前に生成され、更新も散発的にしか行われないため、エラーが含まれていたり、最近追加されたゾーンが存在していなかったりと問題がありました。既存インストレーションには影響はなく、新しく初期化されたデータベースクラスタにのみ影響します。
フィジー、ヨルダン、パレスチナ、サモアで夏時間法が変更され、バルバドス、クック諸島、ガイアナ、ニウエ、ポルトガル、トンガの歴史的修正が行われています。
また、Pacific/Enderbury は Pacific/Kanton に名称変更されました。また、Africa/Accra、America/Atikokan、America/Blanc-Sablon、America/Creston、America/Curacao、America/Nassau、America/Port_of_Spain、Antarctica/DumontDUrville、Antarctica/Syowa の各ゾーンは、近くのより人口の多いゾーンに統合されました。これらの名前はエイリアスとして残されています。
PostgreSQL は浮動小数点型は全ての NaN が等しいと見なすため、ハッシュ関数が IEEE 754 規格に従って NaN である全てのパターンに対して同じハッシュコードを生成することが重要です。今までそれができていなかったため、ハッシュインデックスやハッシュを伴った実行計画で、正規化されていない NaN値('-NaN'::float8 など)に対して、誤った問い合わせ結果がもたらされるおそれがありました。
このような NaN値が含まれる可能性がある場合には、浮動小数点型の列に対するハッシュインデックスを再作成することが推奨されます。
CREATE TABLESPACE から次のチェックポイントまでの間にサーバがクラッシュした場合、クラッシュリカバリが実施されても完全にデータが復元されない可能性がありました。wal_level が minimal 以外の場合には該当しません。
無効化が行われていなかったことによって、既存セッションでロジカルレプリケーションが誤動作を起こす可能性がありました。
無効化が行われていなかったことによって、既存セッションでロジカルレプリケーションが誤動作を起こす可能性がありました。
例えば、numeric(18,3) と定義されている f1列の場合、パーサは f1::numeric の様なキャストを実行時には影響がないという理由で破棄していました。しかし、外側にあらわれる型は、numeric(18,3) ではなく numeric であるべきです。これは再帰的な UNION など、より大きな構造の型を正しく解決するために重要です。
(ビュー定義で型キャストが無視される誤動作例) db=# CREATE TABLE t51 (f1 numeric(18, 3)); db=# CREATE VIEW v51 AS SELECT f1::numeric AS n1 FROM t51; db=# \d+ v51 View "public.v51" Column | Type | Collation | Nullable | Default | Storage | Description --------+---------------+-----------+----------+---------+---------+------------- n1 | numeric(18,3) | | | | main | View definition: SELECT t51.f1 AS n1 FROM t51;
旧動作が誤っていると考えられますが、非互換性を含む修正となります。
これまでは作成はできていましたが、実際には照合順序は使用できず、削除することもできない状態となっていました。
(.){0}...\1 の様な正規表現において、間違った後方参照番号が引き出され、下記のようなエラーやクラッシュ、アサート失敗が生じる可能性がありました。エラーを発生させずに後方参照がマッチしないと判断するように修正されました。
ERROR: invalid regular expression: invalid backreference number ERROR: invalid regular expression: quantifier operand invalid
正規表現エンジンは部分的なマッチを拒否した後のキャプチャした括弧のマッチデータ排除に関して不注意でした。これにより、定義された参照先がないために失敗するはずの場所で、後方参照が一致する可能性がありました。
(誤動作例) db=# select 'abcdef' ~ '^(.)\1|\1.'; ?column? ---------- t (1 row) (先頭で同文字が連続していないので部分マッチせず、全体としても f になるのが正しい)
後方参照のロジックが正しくなく、必要以上に時間を要する箇所がありました。幸いなことに、この問題はほとんどの場合に他の最適化によって顕在化することがありませんでした。
動的な TZ 略語でゾーンが指定されている場合に誤った問い合わせ結果が生じる可能性があります。
(報告された誤動作例、CLT は -03 または夏時間で -04) db=# SELECT '12:34 -02'::timetz AT TIME ZONE 'CLT'; timezone ------------------- 09:51:14-04:42:46 (1 row)
PlaceHolderVars は内部実装上のデータ構造です。この誤りにより、パーティションテーブルや継承テーブルを外部結合の外側(無ければ NULL になる側)に持つ問い合わせで、アサート失敗や実行計画の異常が生じる可能性がありました。実際の問題発生は稀であると考えられます。
実行するための基盤が無いため、実行されてしまうと単に NOTIFY によるキューのクリーンアップを妨げる結果となります。
この変更によってプロシージャ内の COMMIT 直後に通知を送信できるようになりました。また、ロジカルレプリケーションワーカが通知を送信できるようになりました。これまではアイドル状態にならないと送信されず、これらのことができませんでした。
長い間 NO SCROLL カーソルを逆方向にフェッチすることは禁止されていましたが、歴史的背景により、クエリを完全に巻き戻してから再度フェッチすることは禁止されていませんでした。この例外は、特に巻き戻しに必要なデータを全て保持していない可能性のある保留されたカーソルの場合には不整合を引き起こしました(クラッシュが報告されています)。最悪のケースを防ぐためにスクロールできない保留されたカーソルの巻き戻しを禁止するようになりました。
非互換性を含む修正となります。
クラッシュが生じる動作が報告されました。
これまでも 2^32 - 1 ブロックという最大長を超えてテーブルやインデックスを拡張する試みはストレージ処理の段階で拒絶されました。しかし、不整合な内部状態を防ぐにはより早い検知が必要で、バッファマネージャにおいてエラーを出すようになりました。
アサート失敗が報告されました。
これが行われなったため、安全でないパラレルプラン選択などの問題が生じるおそれがありました。ルールが適用される問い合わせの実行時に「ERROR: cannot assign XIDs during a parallel operation」が生じる動作が報告されました。
これからは、データ変更を伴う CTE を持つ問い合わせには DO INSTEDルールの適用はできず、そのことを示すエラーになります。
(修正後の振る舞い例) db=# CREATE TABLE t63a (i int); db=# CREATE TABLE t63b (i int); db=# CREATE RULE r63a AS ON INSERT TO t63a DO INSTEAD INSERT INTO t63b SELECT NEW.i; db=# WITH cte1 AS (DELETE FROM t63a RETURNING *) INSERT INTO t63a SELECT * FROM cte1; ERROR: INSERT...SELECT rule actions are not supported for queries having data-modifying statements in WITH
以前は意図したメッセージではなく以下のようなキャッシュルックアップエラーが出力されていました。
ERROR: cache lookup failed for type 27447
以前はトランザクション分離レベルが REPEATABLE READ よりも低かった場合、パラレルクエリで誤動作をすることがありました。
アサート失敗が報告されました。
ロジカルデコーディングは、ALTER TABLE によるヒープ書き換えなどで作られる一時テーブルの変更を通常は無視しますが、関連する TOASTテーブルについてそのようになっていませんでした。
これにより、パブリッシュされたテーブルを ALTER TABLE すると、その後で予期せぬエラーが生じることがありました。
アサート失敗やクラッシュを引き起こす可能性がありました。
通知ファイルとは archive_status ディレクトリ下に作られる.ready や .done のサフィックスを持ったファイルです。
これまで walreceiver はちょうど WALセグメント境界で終了した場合、最後に受信したセグメントの通知ファイル作成に失敗していました。その結果、スタンバイでセグメントをアーカイブするのが遅れていました.
昇格直後のベースバックアップがpg_veryfybackup で失敗するケースが報告されていました。
OLD や NEW を指定して SELECT .. FOR UPDATE を行うルールの実行で予期せぬエラーやクラッシュが生じていました。
FILTER式が単純な boolean型の列の場合に、誤った意味解釈が行われて仕様外の動作(即ち、誤った問い合わせ結果)が生じる可能性がありました。また、FILTER式自体が boolean型を返す集約である場合にはエラーを出すべきですが、そのようになっておらず、実行時にクラッシュを起こすことがありました。
(修正前バージョンでの障害発生例) db=# CREATE TABLE t71 (i int, b boolean); db=# INSERT INTO t71 VALUES (1, 't'),(2, 't'), (3, 'f'); db=# SELECT (SELECT max(0) FILTER (WHERE b IS TRUE)) FROM t71; max ----- 0 (1 row) db=# SELECT (SELECT max(0) FILTER (WHERE b)) FROM t71; -- 誤動作する max ----- 0 0 (3 rows) db=# SELECT (SELECT array_agg(z.b) FILTER (WHERE bool_or(z.i > 0)) FROM t71) FROM t71 z; -- クラッシュする server closed the connection unexpectedly
拡張のスクリプトで実行された ALTER .. SET は、ターゲットとなるオブジェクトが拡張のメンバになっていなかった場合に、それを拡張のメンバにしてしまうことがありました。
拡張のスクリプトがその拡張に属さないオブジェクトにアクセスする理由はほとんど無いため、これ自体は大きな問題はありません。しかし、ALTER TYPE .. SET はその型に依存するドメインにも再帰的に効果を及ぼすため、それらも拡張のメンバになり、拡張のアップグレードスクリプトで望まない副作用を引き起こしました。
これにより、致命的な LLVM のエラーが起きた後にバックエンドが終了する際に起こりうるクラッシュを防止します.
SP-GiST のコードでは、タプルのカウンタは正しく進む一方で、インデックススキャン回数の加算が欠落していました。
これにより設定変更が直ぐに効くようになります。
これは数百GB の work_mem が設定されていない限り顕在化しないため、実際には発生していなかったものと見られます。
コード再編成の誤りで以下のドキュメント記載された関数がエクスポートされていませんでした。
pg_encoding_to_char() pg_utf_mblen() pg_char_to_encoding() pg_valid_server_encoding() pg_valid_server_encoding_id()
ecpg を使うクライアントで pthread の mutex が残ったままになっていて、リソースリークやデッドロックを起こす恐れがありました。
静的関数は古いスナップショットを使って呼ばれており、そのため、セッションのトップレベルコマンドの開始後に行われたデータベースの変更が見えていませんでした。
明示的な RETURN を必要としないルーチンであれば、この使い方は有効でしたが、これまでは許されていませんでした。
これにより、例えば postmaster に渡すコマンドラインオプションを多数指定する場合の制限がなくなります。なお、pg_ctl が扱うパス名についての制限は未だあり、殆どの場合 MAXPGPATH(デフォルト1024)バイトで制限されます。
これらの変更はローカルサーバからのダンプでは重要ではありませんが、リモートサーバからのダンプではネットワーク往復が少なくなることで顕著なメリットがあります。
< や <= 演算子を使ったインデックススキャンが実行されたときに、誤った問い合わせ結果(返るべきエントリが返らない)が生じました。インデックス破損ではなく、検索ロジックの誤りに起因します。
この誤りは、おそらく OpenSSL のインストールを監査する類のタスクを行うコードでのみ問題となります。しかし、形としては OpenSSL API に違反しているため修正されました。
PostgreSQL 12 以降から、長らく正しい pkg-configファイルが提供されていませんでした。
pg_regexec() は PostgreSQL の正規表現機能の内部実装関数です。
search_start が文字列の終わりを過ぎている場合に、これまではクラッシュの可能性がありましたが、REG_NOMATCH を返すようになります。この場合はおそらく PostgreSQLコアコードでは生じませんが、拡張モジュールから使われるかもしれません。