このリリースは 13.8 からの修正リリース(2022年11月10日リリース)です。
13.X からのアップデートではダンプ、リストアは不要です。
しかしながら、13.7 よりも前のバージョンからアップデートする場合には、13.7 のリリース情報も参照してください。
PostgreSQL 13.8 から 13.9 への変更点
15.1、14.6、13.9、12.13、11.18、10.23 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。
- 大きなテーブルの最初以外のセグメントを削除できない問題が修正されました。 (Tom Lane) (15)
- 更新可能ビューへの INSERT で、複数行 VALUES句にある DEFAULTトークンの処理が修正されました。 (Tom Lane) (15)(14)(13)(12)(11)(10)
- 「ON SELECT」でない「_RETURN」という名前のルールが禁止されました。 (Tom Lane) (15)(14)(13)(12)(11)(10)
- 定数初期値で「SEARCH BREADTH FIRST」を使用する問い合わせがEXPLAIN VERBOSE でエラーを出さないようになりました。 (Tom Lane) (15)(14)
- 外部テーブルパーティションを含むパーティションテーブルでMERGE の使用が禁止されました。 (Álvaro Herrera) (15)
- ALTER TABLE ATTACH PARTITION 実行中に行われるパーティションごとの外部キー制約の構築が修正されました。 (Jehan-Guillaume de Rorthais, Álvaro Herrera) (15)(14)(13)(12)
- パーティションテーブルまたは継承されたテーブルの拡張統計を参照する際のプランナエラー発生が修正されました。 (Richard Guo, Justin Pryzby) (15)
- GINインデックスの高速挿入パスでの WAL操作の順序の誤りが修正されました。 (Matthias van de Meent, Zhang Mingli) (15)(14)(13)(12)(11)(10)
- トランザクションの開始とそのサブトランザクションの開始の間からリプレイが開始される場合の、論理デコードのバグが修正されました。 (Masahiko Sawada, Kuroda Hayato) (15)(14)(13)(12)(11)(10)
- 論理デコード中に、より多くの場所で割り込みを受け付けるようになりました。 (Amit Kapila, Masahiko Sawada) (15)(14)(13)(12)(11)(10)
- レプリケーションワーカで外部テーブルのパーティションにデータ同期を試みる動作が防止されました。 (Shi Yu, Tom Lane) (15)(14)(13)
- レプリケーションワーカでの関数構文エラー後のクラッシュを回避するようになりました。 (Maxim Orlov, Anton Melnikov, Masahiko Sawada, Tom Lane) (15)(14)(13)(12)(11)(10)
- アーカイバモジュールのシャットダウンコールバックの二重呼び出しを回避するようになりました。 (Nathan Bossart, Bharath Rupireddy) (15)
- テーブルアクセスメソッドを持たないテーブルへのアクセスに対して、プラン作成時の検査が追加されました。 (Tom Lane) (15)(14)(13)(12)
- 共有メモリ状態が破損しているときの postmaster のクラッシュが防止されました。 (Tom Lane) (15)(14)(13)(12)(11)(10)
- libpq がパイプラインモードのときに単一行モードを正しく処理するように修正されました。 (Denis Laxalde) (15)(14)
- コマンドラインクエリがキャンセルされた時の psql の終了ステータスが修正されました。 (Peter Eisentraut) (15)
- pg_basebackup でクロスプラットフォームのテーブルスペースの再配置を許可するようになりました。 (Robert Haas) (15)(14)(13)(12)(11)(10)
- 一部の CHECK制約に付加されたコメントを pg_dump がダンプできない問題が修正されました。 (Tom Lane) (15)
- CREATE DATABASE で oidパラメータが 2^31 を超えることができるように修正されました。 (Tom Lane) (15)
- pg_stat_statements で既に解放されたメモリへのアクセスが修正されました。 (zhaoqigui) (15)(14)(13)(12)(11)(10)
- LLVM 15 との非互換性が修正されました。 (Thomas Munro, Andres Freund) (15)(14)(13)(12)(11)
- どのようなマシンであってもスピンロックのために__sync_lock_test_and_set() が使えるようになりました。 (Tom Lane) (15)(14)(13)(12)(11)(10)
- 最近の macOS で起きるコンパイル障害を避けるために、シンボル「REF」が「REF_P」にリネームされました。 (Tom Lane) (15)(14)(13)(12)(11)(10)
- コンパイル時の非推奨の警告を避けるため、sprintf が使われなくなりました。 (Tom Lane) (15)(14)(13)(12)
- タイムゾーンデータファイルが tzdata release 2022f に更新されました。チリ、フィジー、イラン、ヨルダン、メキシコ、パレスチナ、シリアの夏時間法が変更と、チリ、クリミア、イラン、メキシコの歴史的な修正が含まれます。 (15)(14)(13)(12)(11)(10)
- VACUUM と並行に実行される更新で稀に起きていた PANIC が回避されました。 (Tom Lane, Jeff Davis) (14)(13)(12)
- AFTERトリガに対してタプルを保存する際の資源管理のバグが修正されました。 (Tom Lane) (14)(13)(12)
- パーティションごとの外部キー制約に対する制約名の生成が修正されました。 (Jehan-Guillaume de Rorthais) (14)(13)(12)
- パーティションインデックスを作るときの、インデックスの式と述語の誤った照合が修正されました。 (Richard Guo, Tom Lane) (14)(13)(12)(11)
- スタンバイ昇格後の WAL破損を防止するようになりました。 (Dilip Kumar, Robert Haas) (14)(13)(12)(11)(10)
- 論理デコード中に、間違ったスナップショットでシステムカタログを検査することを防止するようになりました。 (Masahiko Sawada) (14)(13)(12)(11)(10)
- パーティションテーブルのレプリカアイデンティティ設定についての無意味なチェックが除去されました。 (Hou Zhijie) (14)(13)
- SQL関数に渡される読み書き可能な拡張データムの取り扱いを修正しました。 (Tom Lane) (14)(13)(12)(11)(10)
- circle型の等価比較で NaN を適切に処理するように修正されました。 (Ranier Vilela) (14)(13)(12)
- Snowball辞書で過度に長い単語を語幹処理しないようになりました。 (Olly Betts, Tom Lane) (14)(13)(12)(11)(10)
- 文字列比較における解放後メモリアクセスが修正されました。 (Tom Lane) (14)(13)(12)(11)(10)
- スタックオーバーランに至るまでの再帰に対するさらなる防御(検査コード)が追加されました。 (Richard Guo, Tom Lane) (14)(13)(12)(11)(10)
- 非常に小さな work_mem と大きなタプル(1行が大きい)の組み合わせでハッシュテーブルのサイズを選択するときの、誤動作を回避するようになりました。 (Zhang Mingli) (14)(13)
- autovacuum launcherプロセスでメモリリークを回避するようになりました。 (Reid Thompson) (14)(13)(12)(11)(10)
- PL/pgSQL が RECORD として宣言されたパラメータを処理する能力が改善されました。 (Tom Lane) (14)(13)(12)(11)
- libpq内の NULL のコネクションポインタに対する欠落していた検査が追加されました。 (Daniele Varrazzo, Tom Lane) (14)(13)(12)(11)(10)
- ecpgで、複数の varchar または bytea 変数が同じ宣言内で宣言されている時の変数ストレージクラスの省略を修正しました。 (Andrey Sokolov) (14)(13)(12)(11)(10)
- postgres_fdwで、EvalPlanQual の実行計画むけに構築されたターゲットリストが、必要なすべての列を持つことになりました。 (Richard Guo, Etsuro Fujita) (14)(13)(12)(11)(10)
- プラットフォームの uuid_create() 関数からの不要な出力を拒否するようになりました。 (Nazir Bilal Yavuz) (14)(13)(12)(11)(10)
- 新しい Perlテストモジュールが標準インストールに含まれるようになりました。 (Álvaro Herrera) (14)(13)(12)(11)(10)
- NetBSD で、postmaster 起動時に動的シンボル解決を強制するようになりました。 (Andres Freund, Tom Lane) (14)(13)(12)(11)(10)
- clang 15 以降のコンパイラからの警告が出ないようになりました。 (Tom Lane) (14)(13)(12)(11)(10)
- VACUUM が btreeインデックスでのページ削除でページの親ダウンリンクを見つけるのに失敗した場合でも進行するように修正されました。 (Peter Geoghegan) (13)(12)(11)(10)
- 継承された更新で稀に生じる MULTIEXPR_SUBLINK のサブプランのエラーが修正されました。 (Tom Lane) (13)(12)(11)(10)
- 外側の問い合わせがグループ化セットを持つ場合、FROM のないサブクエリの平坦化を回避するようになりました。 (Tom Lane) (11)(10)
PostgreSQL は大きなテーブルを複数のファイル(通常 1ファイルあたり 1GB のファイル)に分割します。 テーブルを削除するロジックが壊れており、一時テーブルの削除と、通常テーブルを削除する WAL の再生の 2つのケースで、そのようなファイルの最初のファイル以外を削除しそこなうことがありました。 数ギガバイトの一時テーブルを日常的に作成するアプリケーションは、重大なディスク領域のリークを被る可能性がありました。
孤立した一時テーブルファイルは postmaster の起動時に削除されるため、15.1 に更新するだけで、一時テーブルのストレージのリークが解消されます。しかし、15.0 を使用中にデータベースがクラッシュし、その直前に大きなテーブルが削除された可能性がある場合、データベースディレクトリに「NNNN.NN」というパターンに従った名前のファイルがないか確認することが推奨されます。「NNNN」(「.NN」サフィックスなし)という名前の一致するファイルがない場合、これらのファイルは手動で削除する必要があります。
この障害により、「ERROR: cache lookup failed for type ..」エラーが発生したり、古いブランチではクラッシュの原因になることもありました。
(障害発生例) db=# CREATE TABLE t2 (a int, b text); db=# CREATE TABLE t2_hist (ts timestamptz DEFAULT now(), a int, b text); db=# CREATE VIEW v2 AS SELECT * FROM t2; db=# CREATE RULE r_t2_log AS ON INSERT TO v2 DO ALSO INSERT INTO t2_hist (a,b) VALUES (NEW.a, NEW.b); db=# INSERT INTO v2 VALUES (1, DEFAULT), (10, DEFAULT); ERROR: cache lookup failed for type 0
これにより、ビューの「ON SELECT」ルールと他のルールとの間の混乱が回避されます。
(問い合わせ自体は実行できる) db=# WITH RECURSIVE cte4 AS ( SELECT 1 AS x UNION ALL SELECT x + 1 FROM cte4 ) SEARCH BREADTH FIRST BY x SET y SELECT * FROM cte4 LIMIT 3; x | y ---+------- 1 | (0,1) 2 | (1,2) 3 | (2,3) (3 rows) (explain verbose を付けるとエラーになる) db=# explain (verbose) WITH RECURSIVE cte4 AS ( SELECT 1 AS x UNION ALL SELECT x + 1 FROM cte4 ) SEARCH BREADTH FIRST BY x SET y SELECT * FROM cte4 LIMIT 3; ERROR: record type has not been registered
MERGE で外部テーブルを直接ターゲットにすることは既に禁止されていましたが、このケースはサポートされておらず、理解できないエラーが発生していました。
「ERROR: unexpected operation: ...」のようなエラーが出ることが報告されました。修正により「ERROR: cannot execute MERGE on relation ...」が出るようになります。
以前は、新しく追加されたパーティションに対して、不正確または重複した制約が作成されることがありました。
問い合わせ実行に対して「ERROR: cache lookup failed for statistics object」というエラーが発生する場合がありました。
この間違いは、PostgreSQLのコア部分で悪影響を与えることは知られていませんが、一部の拡張機能で問題が発生していました。
これらのエラーは、デバッグビルドでのアサート失敗や、メモリリークを引き起こす可能性がありました。
これにより、レプリケーションワーカのシャットダウンが遅いという問題が改善されます。
パーティションテーブルは外部テーブルをパーティションとすることができますが、そのようなパーティションへの論理レプリケーションは今のところサポートされていません。実行しようとすると論理レプリケーションワーカのプロセスはこれまでクラッシュしていましたが、エラーを出すようになりました。
論理レプリケーションワーカで実行された SQL言語または PL/pgSQL言語のCREATE FUNCTION または DO コマンドで構文エラーが発生した場合、ワーカプロセスは nullポインターの逆参照またはアサート失敗でクラッシュしていました。
サブスクリプション側にそのようなトリガを定義した場合に現象が報告されました。
これにより、例えば「ON SELECT」ルールが欠落しているビューの使用など、一部のカタログ破損シナリオにおけるクラッシュが防止されます。そのような場合には「ERROR: cannot open relation ...」が出るようになりました。
postmasterプロセスは、共有メモリが破損した場合にも存続し、データベースの再起動を行うはずですが、コードのある 1箇所で対応が不十分でした。
パイプラインモードも有効である場合、単一行フラグが正しいタイミングでリセットされませんでした。
クエリがキャンセルされた場合、「psql -c query」は正常終了していました。他のエラーの場合と同様に、ゼロ以外のステータスで終了するようになりました。
--tablespace-mapping のリモートパスを Unixスタイルまたは Windowsスタイルの絶対パスにすることができるようになりました。これは、ソースサーバがローカルシステムとは異なる OS 上にある可能性があるためです。
このパラメータの最大値を見落としにより、ソースインストールにそれより大きい OID を持つデータベースが含まれている場合、pg_upgrade が成功しませんでした。
これは、拡張問い合わせプロトコルで発行された ROLLBACK コマンドをトラックしている時に発生します。デバッグビルドでは、これによりアサート失敗が発生しました。製品ビルドでは、目立った問題は発生しません。しかし、解放されたメモリが既に再利用されていた場合、クエリ文字列にゴミデータが格納される結果になると考えられます。
この GCC ビルトイン関数をサポートしているコンパイラを使っていさえすれば、新しいマシンアーキテクチャへポーティングが簡単になります。
また、Europe/Kiev ゾーンは Europe/Kyiv にリネームされました。さらに、以下のゾーンは 1970年以来承認されている時計のある人口の多い近傍のゾーンに併合されました:
Antarctica/Vostok、Asia/Brunei、Asia/Kuala_Lumpur、Atlantic/Reykjavik、 Europe/Amsterdam、Europe/Copenhagen、Europe/Luxembourg、Europe/Monaco、 Europe/Oslo、Europe/Stockholm、 Indian/Christmas、Indian/Cocos、Indian/Kerguelen、Indian/Mahe、Indian/Reunion、 Pacific/Chuuk、Pacific/Funafuti、Pacific/Majuro、Pacific/Pohnpei、 Pacific/Wake、Pacific/Wallis
(これは Arctic/Longyearbyen、Atlantic/Jan_Mayen、Iceland、Pacific/Ponape、Pacific/Truk、Pacific/Yap のうちの一つに既にリンクされているゾーンにも、間接的に影響します。)1970年以降に主張されたこれらゾーンとの差異が誤りであるようだと判明した後、America/Nipigon、America/Rainy_River、America/Thunder_Bay、Europe/Uzhgorod、Europe/Zaporozhye も近傍のゾーンに併合されました。
これらの全てのケースでは以前のゾーンの名前は別名として残されています。しかし、実際のデータはマージされたゾーンにあります。これらのゾーン併合は 1970年以前のタイムゾーンの歴史を失うことになります。これは timestamptz 表示の一貫性を期待するアプリケーションには問題となるかもしれません。例えば、保存されている値が「1944-06-01 12:00 UTC」の場合、以前は「1944-06-01 13:00:00+01」と表示されましたが、Europe/Stockholm が選択されている場合は「1944-06-01 14:00:00+02」となります。
より古いゾーンデータをリストアするオプションを付けたタイムゾーンデータファイルを作ることも可能ですが、この選択はたくさんの他の古い(かつ典型的には証明に乏しい) ゾーンデータを追加してしまうことになります。結果として、この上位変更を受け入れる場合よりも、以前のリリースの全体の変更は多くなってしまいます。
PostgreSQL は tzdb の移行を推奨してきましたが、知る限りではほとんどの主要なオペレーティングシステムのディストリビューションでも同様のことをやっています。しかしながら、もしこれらの変更があなたのアプリケーションに重要な問題を起こすならば、可能性のある解決方法は tzdb の後方互換オプションを使ってタイムゾーンデータファイルをローカルにビルドしてインストールする方法です(PACKRATDATAオプションと PACKRATLISTオプションを見てください)。
並行する VACUUM が UPDATE または DELETE で更新中のページの全ての可視フラグビットをセットするなら、その更新コマンドはそのビットをもう一度クリアする必要があります。しかし、いくつかのコードパスはそれに失敗し、PANIC で終了していました。
これはバージョン 14 と 15 で起きる可能性があることが知られています。それより前のブランチでは顕在化しないかもしれません。
正常な状態において「ERROR: tupdesc reference ... is not owned by resource owner ...」というエラーが出た後、「PANIC: ERRORDATA_STACK_SIZE exceeded」によるサービス全体の停止または再起動が発生しました。
最初に与えられた名前がそのパーティションの何らかの制約として既に使われていたら、新しい制約名が選ばれますが、意図した名前になっていませんでした。誤って「リレーション名__fkey」という制約名が生じていました。
パーティションテーブルにインデックスを作るときに、定義が一致する各パーティション上の既存インデックスを識別して、それを子インデックスとして取り込みしようとします。このとき、式の照合が正しく行われず、パーティション上の利用可能な既存インデックスが無視されて、重複したインデックスが作成されることがありました。
アーカイブリカバリ中の(スタンバイモードではない)PostgreSQLインスタンスが昇格するときに、最後に読み込もうとした WALセグメントが部分レコードで終わっていた場合、新しいタイムライン上に無効な WAL セグメントを書き込んでいました。
システムカタログを変更するトランザクションの途中でデコードが開始されると、デコーダがそれを認識できないことがあり、その結果、カタログ検索でそのトランザクションが進行中として扱われませんでした。
重要なのはリーフパーティションのレプリカアイデンティティの設定であり、それが親テーブルに設定されていない場合にエラーを投げる必要はありません。
インライン化されていない SQL関数が 2つ以上の場所で引数を使用し、そのうちの 1箇所で読み書き可能なデータムを上書きで変更できると期待した場合、後でそのパラメータを使用した時に間違った値が観測されました。
配列を引数に取る再帰的な SQL関数の実行で、誤った問い合わせ結果が生じるケースが報告されました。PostgreSQL本体内では拡張データム機構は、配列と複合型の値に対してのみ使用されています。
左側の円の半径が浮動小数点数の NaN であった場合、中心座標が同じで任意の半径を持つ円と等しいと見なされるようになりました。
入力単語が 1000バイトを超える場合、Snowballコードを通すのではなく、大文字小文字を揃えた後、そのまま返すようになりました。
この制限は、トルコ語の語幹機能における recursion-to-stack-overflow への既知問題から保護し、Snowballの語幹機能におけるその他の安全性や性能の問題に対する良い保険になると考えられます。
文字列比較関数の不適切なメモリ管理により、もはや割り当てられていないバッファに書き込みが生じて、そのメモリを現在使用している何かが壊れる可能性がありました。
これは、かなり長い文字列(1kB以上)で ICU照合順序が使用されている場合にのみ、発生しました。
巨大な SQL文で「ERROR: stack depth limit exceeded」のエラーを出さずに、バックエンドプロセスがクラッシュする動作が報告されていました。
以前からのバグであるにもかかわらず現場からの報告がないことから、この問題はバージョン15 より前のブランチでは顕在化しないと思われますが、確かではないため、各バージョン系列にバックパッチが行われました。
多相パラメータに対して行うのと同じように、セッション中に RECORDパラメータに渡される各具象型に対して、個別の関数キャッシュ項目を構築するようになりました。これにより、以前は「ERROR: type of parameter ... does not match that when preparing the plan」などのエラーで失敗していたいくつかの使用法が動作するようになりました。
libpq の関数は、NULL の PGconn 引数を検査して、クラッシュする代わりにエラーを出す、という慣習があります。PQflush() と PQisnonblocking() でこれが守られていなかったため修正されました。
これまで「static varchar str1[10], str2[20], str3[30];」を以下のように変換していました。
(不適切な出力例) static struct varchar_1 { int len; char arr[ 10 ]; } str1 ; struct varchar_2 { int len; char arr[ 20 ]; } str2 ; struct varchar_3 { int len; char arr[ 30 ]; } str3 ;
これにより「ERROR: variable not found in subplan target list」エラーが防止されます。EvalPlanQual は READ COMMITTED 隔離レベルの問い合わせで使われる処理です。
uuid-osspモジュールでは libc の uuid_create() がバージョン1 の UUID を生成すると期待していますが、最近の NetBSD のリリースでは、代わりにバージョン4 の (ランダムな) UUID を生成します。これを検査して、そうであればエラーを出すようになりました。
ドキュメントの、NetBSD の実装が uuid-ossp に使用可能という記載も削除されました。(バージョン4 の UUID が必要な場合には、uuid-ossp モジュールではなく、本体付属の関数 gen_random_uuid() を使ってください。)
PostgreSQL/Test/Cluster.pm と PostgreSQL/Test/Utils.pm をバージョン15 より前のブランチの標準インストールファイルに追加しました。これは、古いブランチで新しく書かれたテストコードを使いたい拡張のためです。
これにより、NetBSD 10 におけるダイナミックリンカでのデッドロックの危険性を回避できるようになりました。
エラーを投げるのではなく、むしろ問題を記録し、空のページを削除せずに続行するようになりました。以前は、バグのある演算子クラスまたは破損したインデックスにより、インデックスのバキューム処理がいつまでも完了せず、最終的に XID周回の問題につながっていました。
以下メッセージが ERROR から LOG に変更されます。「failed to re-find parent key in index ... for deletion target page ...」
構文 UPDATE tab SET (c1, ...) = (SELECT ... ) を継承テーブルやパーティション化された対象テーブルに使用すると、子テーブルが十分に異なっている場合、失敗することがありました。
これは通常、エグゼキュータでの一貫性チェックの失敗のエラーとして現れます。しかし、クラッシュや不正なデータ更新(すなわち論理的なデータ破損)も起こり得ます。
本構文の UPDATE に対して、「ERROR: invalid attribute number ...」などの予期せぬエラーの発生が報告されました。
この誤りは、アサート失敗や「ERROR: variable not found in subplan target list」 などのプランナエラーにつながる可能性があります。