2024/11/14のマイナーリリースにより、timescaledb や他のいくつかの拡張機能とのバイナリ互換性が意図せず壊れていました。ResultRelInfo 構造体を以前のサイズに戻されたことで、影響を受けたエクステンションをビルドし直す必要がなくなりました。

§ § § §

CVE-2024-10978 の修正により、非対話的なソース（ ALTER {ROLE|DATABASE} コマンドや PGOPTIONS 環境変数など）から設定されたロールの設定が適用されなくなる問題が発生していましたが、修正されました。

§ § § § § §

以前は、論理レプリケーションを再起動すると、スロットの再起動ポイントが、pg_replication_slots で以前に通知されていた値よりも古い値として再計算されることがありました。 これは、たとえば WALファイルが後の restart_lsn 値に基づいて削除される可能性があるため、好ましくありません。その場合、レプリケーションの再起動に失敗します。

§ § § § §

以前は、不運なケースで、pg_rewind がプライマリからリカバリに必要なWAL ファイルを削除してしまうことがありました。

特に、WALファイルがアーカイブ可能であるものの、まだアーカイブされていない場合（つまり、.ready ファイルが作成されているとき）に問題がありました。 以前のpg_rewind この状況ではこれらの WAL ファイルを削除してしまいました。さらに、新しく昇格したノードから取得でもこれらのWAL ファイルがリサイクル・削除してしまうと、 pg_rewind を実行したノードはリカバリに必要な WAL ファイルを入手することができずリカバリが失敗していました。

§ § § §

これらのバグにより 統計データの損失、アサート失敗、または「ERROR: can only drop stats once」というエラーが発生する可能性がありました。

§ § §

以前までは実装の見落としによりカウントがされていませんでした。

§ § § § §

テーブルにデフォルト以外の演算子クラスオプションを持つインデックスがある場合、ALTER TABLE の一部の処理が失敗していました。

§ § § § §

このバグは、 configure 実行時に --enable-cassert オプションを利用してアサーション検査を有効にしたビルドでのみ影響があります。

§ § § §

トップレベル以外のテーブルの参照（例えば、 CTE 、サブクエリ、 security_invoker属性が true の ビュー、SQL で作成した関数によるテーブルの参照などがこれに該当します）において、 セキュリティポリシーの設定されたテーブルを参照する場合、その実行計画がクエリを実行したロールに依存することを記録していませんでした。これにより、あるユーザの権限の元で作成したプランを、同一セッションで別の権限のユーザが実行すると、本来出力すべき行が出力されない、あるいは逆に出力すべきでない行が出力されてしまう可能性がありました。(CVE-2024-10976)

暗号化のネゴシエーションが完了する前に libpq が受け取ったエラーメッセージはそのまま出力していたため、中間者攻撃によって利用される恐れがありました。これにより、エラーメッセージをあたかもクエリの結果であるかのように見せかけるなどの攻撃が可能になっていました。(CVE-2024-10977)

SQL標準では、SET SESSION AUTHORIZATION が副作用として SET ROLE NONE を実行することを要求していますが、この実装に問題があり、意図しない相互作用が発生していました。特に SET SESSION AUTHORIZATION を実行したトランザクションをロールバックすると、元々のロールが NONE でない場合でも NONE に変更されてしまい、ユーザーID がトランザクション開始前と変わってしまう可能性がありました。また、関数内の SET句で一時的に session_authorization を設定すると、同様の影響がありました。関連するバグとして、パラレルワーカーに対して current_setting('role') を実行すると、正しいロールではなく none を返してしまう問題がありました。(CVE-2024-10978)

PATH のようなプロセスの環境変数を操作可能であることは、攻撃者に任意のコードを実行される機会を与えることになります。このため、「信頼されたPL/Perl」はそのような能力を与えてはいけませんでした。環境変数の変更を warningメッセージとともに拒否する tied hash で %ENV を置き換える修正がされました。「信頼されないPL/perl (plperlu)」は、今までどおり環境変数を変更することも可能です。(CVE-2024-10979)

参照先テーブルがパーティションテーブルの場合、参照元テーブルがスタンドアローンのテーブルかパーティションテーブルかで、参照元テーブルに必要なカタログエントリが異なります。ATTACH/DETACH PARTITION コマンドは、このための変換を正しく行えていませんでした。特に、DETATCH PARTITION されてスタンドアローンのテーブルとなったテーブルには、外部キー制約トリガーが作成されていませんでした。このため、外部キー制約に違反する行が挿入されてしまう可能性がありました。また、DETACH PARTITION 後に再び ATTACH PARTITION を行った場合にも予期しないエラーで失敗することがありました。

この問題が発生してしまった場合、修正するには通常のテーブルに変更されたテーブルの不正な制約に対して ALTER TABLE DROP CONSTRAINT を実行し制約を削除した後、再度制約を追加します。もし制約の再追加が失敗した場合は、誤ったデータが挿入されている可能性があります。その場合は参照元テーブルと参照先テーブル間で一貫性を手動で再度確立し、その後制約を再度追加する必要があります。

不正な制約と、正しい制約を追加するためのコマンドは、以下のクエリを実行して生成できます。

SELECT conrelid::pg_catalog.regclass AS "constrained table",
       conname AS constraint,
       confrelid::pg_catalog.regclass AS "references",
       pg_catalog.format('ALTER TABLE %s DROP CONSTRAINT %I;',
                         conrelid::pg_catalog.regclass, conname) AS "drop",
       pg_catalog.format('ALTER TABLE %s ADD CONSTRAINT %I %s;',
                         conrelid::pg_catalog.regclass, conname,
                         pg_catalog.pg_get_constraintdef(oid)) AS "add"
FROM pg_catalog.pg_constraint c
WHERE contype = 'f' AND conparentid = 0 AND
   (SELECT count(*) FROM pg_catalog.pg_constraint c2
    WHERE c2.conparentid = c.oid) <>
   (SELECT count(*) FROM pg_catalog.pg_inherits i
    WHERE (i.inhparent = c.conrelid OR i.inhparent = c.confrelid) AND
      EXISTS (SELECT 1 FROM pg_catalog.pg_partitioned_table
              WHERE partrelid = i.inhparent));

ADD CONSTRAINT ステップは失敗する可能性があるため、上記のクエリの出力結果をファイルに保存し、各ステップごとに実行してください。

デフォルトの照合順序プロバイダとして libc を使用している場合、照合順序に C ロケールが使用されているかどうかを確認するテストでLC_COLLATE ではなく LC_CTYPE が誤ってチェックされていました。

これらの設定が同じである一般的なケースや、両方が C（またはそのエイリアスの POSIX）ではない場合には影響しません。しかし、LC_CTYPEが C で、LC_COLLATE が他のロケールである場合、誤った問い合わせ結果が発生し、文字列のインデックスが破損する可能性がありました。 このような設定を持つデータベースのユーザは、このアップデートをインストールした後、影響を受けるインデックスを再作成する必要があります。逆のケースで LC_COLLATE が C で、LC_CTYPE が他のロケールである場合、性能が低下しますが、実際のエラーは発生しませんでした。

問い合わせ内のキー列が登場する箇所に COLLATE句でパーティション定義と異なる照合順序を指定している場合に該当する可能性があります。このような実行計画では、誤った問い合わせ結果が生じる可能性がありました。

このバグは典型的には「ERROR: variable not found in subplan target lists」などのエラーを引き起こしました。

（add は SQL言語の単純なユーザ定義関数）
db=# SELECT add(array_length(array_agg(i)::numeric[],1)::integer) FROM n;

バグ報告されたのは以下のようなユーザ定義SQL関数の呼び出しでした。

本障害で誤った問い合わせ結果が生じる可能性がありました。

（17.0 ではエラーになる使用法）
CREATE TABLE t (a int);
INSERT INTO t VALUES(1), (2);
CREATE VIEW v AS SELECT a FROM t WHERE EXISTS (SELECT 1 FROM t);

MERGE INTO v USING (SELECT * FROM generate_series(1,1)) AS s(a)
  ON s.a = v.a WHEN NOT MATCHED BY SOURCE THEN DELETE;

(発生していたエラー)
ERROR:  XX000: wrong varnullingrels (b) (expected (b 4)) for Var 5/1
LOCATION:  search_indexed_tlist_for_var, setrefs.c:2847

この種の実行プランを持つスクロール可能なカーソルが開始点まで巻き戻され、その後再び前方に実行された場合、誤った問い合わせ結果が生じる可能性がありました。

ScalarArrayOp は「indexed_col IN (1,2,3) や indexed_col = ANY ('{1,2,3}'::int[]) のような検索条件で使われます。

誤った指定は適切に拒否されるようになりました。これまでは、COPY TO に対する FORCE_NULL、CSV以外の形式に対する FORCE_QUOTE などの、意味をなさない指定でもエラーになりませんでした。

1つのパーティションにタプルが蓄積されすぎたため、ハッシュ結合の内側を再パーティショニングした後、パーティションのすべてのタプルが同じ子パーティションに入っているかどうかを確認します。 これは、すべてのタプルが同じハッシュ値を持っていることを示し、さらに再パーティションしても状況は改善されません。このチェックは場合によっては機能せず、無駄な再パーティショニングが繰り返され、最終的には（メモリ不足、ディスク領域不足などの）リソース枯渇エラーに至っていました。

これは主として一部の検索が制限された search_path で実行されたことにより、CREATE INDEX コマンドが pg_catalog 外のオブジェクトを参照した場合に予期せぬエラーを引き起こす問題がありました。この修正により、親パーティションインデックスのコメントが子インデックスにコピーされることも防止されます。

本障害で以下のようなメッセージが発生するケースが報告されました。

ERROR:  operator class "..._ops" does not exist for access method "..."

アクセスメソッドに依存するテーブルが存在する場合、アクセスメソッドの削除はブロックされるべきですが、ブロックされていなかったため、その後に異常な動作が発生する可能性がありました。この修正は、この修正適用以降に作成されたパーティションテーブルの問題のみを防止することに注意してください。

このようなロケール名は他の場所では使用されないため、これは Windows でのみ問題となります。 このような名前がどのようなエンコーディングで表現されるかが非常に不明確であるため、問題となります（ロケール自体が使用するエンコーディングを定義しているため）。最近のPostgreSQLのリリースでは、その混乱により Windows ランタイムライブラリでアボートが発生する可能性がありました。新しいエラーメッセージに遭遇した場合は、Windows Locale Builder を使用して ASCII のみの名前で新しい複製ロケールを作成するか、tr-TR のような BCP 47準拠のロケール名の使用を検討してください。

最近コミットされたトランザクションを誤って処理してしまい、アサート失敗、または「ERROR: could not access status of transaction」というエラーが発生する可能性がありました。

並行する PREPARE TRANSACTION により、COMMIT PREPARED が完了したトランザクションについて、ディスク上の2フェーズコミットの状態を保持しているファイルを削除しない可能性がありました。すぐに悪影響が及ぶ可能性はありませんが、その後クラッシュが発生し、リカバリをすると「ERROR: could not access status of transaction」というエラーで失敗する可能性がありました。この場合、サービスを復元するためには残存したファイルを手動で削除する必要があります。

このコードパスでは、まだ再構築されていないインデックスを追跡するリストが適切に更新されなかったため、のちにアサート失敗やクラッシュが発生するリスクがありました。

通常の行更新では、トランザクションがロールバック可能なように、行の新しいバージョンが書き込まれます。ただし、特定のシステムカタログの更新は意図的にこのような形での更新は行わず、データを直接書き換えます。今回データを直接書き換える形での更新の効果が失われる可能性のある競合状態を修正されました。例えば、 pg_class.relhasindex をtrue に設定する更新が失われると、新しいインデックスの更新が妨げられ、それによりインデックスが破損する可能性がありました。

カタログキャッシュの古いデータを使用することで、データを直接書き換える形でのカタログの更新内容が失われないようになりました。

この状況は通常は発生しませんが、SQL 言語関数を B-tree サポートとして使用するなどのテストシナリオでは発生する可能性があります (これは実稼働環境での使用には遅すぎます)。発生した場合、無限に待機する可能性がありました。

新しいカーソルの設定中に、このビューを検査するユーザー定義コードが呼び出される可能性があり、その場合、NULL ポインタの間接参照が発生します。設定が完了していないカーソルを除外するように pg_cursors ビューの定義を修正されました。

進行中のトランザクションのロジカルデコーディング中に、属性のデフォルトのトースト値を取得しながらトーストテーブルをスキャンしますが、このスキャン中に、システムテーブルのスキャンが進行中であることを示すフラグを初期化していませんでした。

ロジカルデコーディングでは、長時間実行されるトランザクションの処理中に深刻なメモリの浪費が発生し、 メモリ不足に伴う障害が発生することがありました。この問題への対応として、論理レプリケーション中に受信したタプルデータを格納するために、より小さいデフォルトのブロックサイズを使用するようになりました。

以前の四半期リリースでの同様の修正と同じように、このケースでは、そのような関数に間違ったスナップショットが渡され、外部トランザクションの開始以降に変更された行の古い値が表示されることがありました。

他のケースとは異なり、オプション値の末尾の空白が拒否されていました。例えば、これは ecpg の使用時に問題となることが判明しています。

実際に問題になることは通常なさそうですが、定数配列の開始直前の位置を読み取ろうとする可能性がありました。

ACL (権限) 列の表示を伴うコマンドは、9.4 より前のバージョンには存在しない関数を使用していたため、非常に古い PostgreSQL サーバーでは失敗していました。

1ミリ秒未満の間隔が指定された場合は、間隔 0 (実行間の待機なし)と同じように扱われるようになります。

-d または --dbname が指定されていない場合、pg_basebackup とpg_receivewal は、データベース名フィールドに「replication」が含まれる ~/.pgpass のエントリと一致しませんでした。

機能上の問題は発生しませんでしたが、重複したスラッシュがエラーメッセージに表示され、混乱が生じる可能性がありました。

他のセッションの一時テーブルのインデックス再構築は機能しませんが、一部のコードパスでそれらをスキップするチェックが欠落していたため、不要な障害が発生されました。

ARM プラットフォーム上で JIT コンパイルを使用すると、生成されたコードは32ビットを超える再配置距離をサポートできず、生成されたコードの配置が不適切になると、大容量メモリシステムでサーバークラッシュが発生する可能性がありました。

long が 32 ビットのプラットフォーム (特に Windows) では、このコーディングは2038年以降に失敗します。ほとんどの失敗は表面的なものにすぎませんが、特にpg_ctl start がハングする可能性がありました。

この tzdata リリースでは、古い System-V 互換ゾーン名を変更して、対応する地理的ゾーンを複製します。たとえば、「PST8PDT」は「America/Los_Angeles」の別名になります。主な目に見える結果は、標準化されたタイムゾーンの導入前のタイムスタンプの場合、ゾーンは指定された場所のローカル平均太陽時を表すと見なされることです。たとえば、「PST8PDT」では、「1801-01-01 00:00」などの timestamptz 入力は、以前は「1801-01-01 00:00:00-08」とレンダリングされていましたが、現在は「1801-01-01 00:00:00-07:52:58」とレンダリングされます。

また、メキシコ、モンゴル、ポルトガルの歴史的修正が行われています。特に、Asia/Choibalsan は、主にこれらのゾーン間の違いが信頼できないデータに基づいていることが判明したため、現在では別のゾーンではなく、「Asia/Ulaanbaatar」の別名となっています。

この構成はサポートされておらず、これを作成する他の方法でもすでに失敗するようになっています。

PostgreSQL 16 では、クエリプルアップロジックの過度に楽観的な単純化により、以前のバージョンほど一部のクエリを最適化できていませんでした。

事前ソートが必要なほど大きい（maintenance_work_mem または shared_buffers よりも大きい）ハッシュインデックス構築する場合、最初のソートフェーズは中断可能ですが、挿入フェーズではループになり中断できませんでした。

1キロバイトより大きなオブジェクトを構築する際に、重複したキーを含むオブジェクトや不完全なオブジェクトが生成されたり、重複したキーが存在すると誤って報告されたりする可能性がありました。

以前はこれらの状態ではクエリ ID がわかりませんでしたが、報告されるようになりました。

以前利用していた xmlXPathCompile() は、2.13.4より前のバージョンでは再帰によるスタックオーバーフローが発生する可能性があったため、代わりに xmlXPathCtxtCompile() を使用するようされました。

空白で区切られたノードのインデントが失敗する問題が修正され、末尾に改行が追加されないようになりました。

通常、REINDEX CONCURRENTLY は、他のテーブルに対する他の REINDEX CONCURRENTLY 操作を待たない最適化を行いますが、 他の REINDEX CONCURRENTLY が述語または式を含むインデックスを処理している場合は、その中に他のテーブルにアクセスするユーザー定義コードが含まれている可能性があるため、この最適化は適用できませんでした。

修正前は、他の REINDEX CONCURRENTLY を待機していなかったため、競合状態が発生し、一貫性のない動作が発生する可能性がありました。

「SELECT」の「ORDER BY」項目が単なる識別子である場合、SQL92 との互換性のため、パーサーはまずそれを「SELECT」の出力列名として検索します。しかし、 ビューの定義で利用されているルールの処理は、SQL99 の解釈に従っており、そのような名前を出力ではなく入力列名であると想定しています。したがって、このような操作は推奨されないものの、ある列が「SELECT」の出力リストに名前を変更され、「ORDER BY」で使用される入力列と一致するように変更された場合、ビューの表示結果が不正になる可能性がありました。

この問題は、サブクエリの WHERE 条件が常に偽である場合など、実行計画からサブクエリが最適化によって完全に取り除かれた場合に、 サブクエリのRECORD 型出力のフィールドを表示しようとした際に発生することがありました。プラン内には元のフィールド名を識別するための情報が残らないため、代わりに「fN」という形式で N 番目のレコード列を表示するようになりました。

「USING」句の出力は変換後の列に書き込まれるため、列の内容を指定している生成式の結果を破壊してしまうため、 「USING」句を指定した場合エラーとするようになりました。

このようなハードウェアでは、stats_reset タイムスタンプ列にゴミが含まれていました。

数値リテラルの後に識別子が続くことは許可しておらず、その間には空白が必要なため、{ interger }{ ident_start }のようなトークンパターンを利用していました。しかしながら、{ ident_start }にマルチバイト文字が続く場合が想定されていなかったため、クライアントへのレポートおよびログファイルにおいて、不正なエンコーディングとしてエラー出力されていました。

これにより、レプリケーション起点が進むとソースサーバーはそのデータを再度送信しなくなるため、トランザクションが失われる可能性がありました。

TLSv 1.3のステートフル セッションチケットの送信を防止するための変更により、誤って TLSv 1.2のステートレスチケットの送信が再度有効になっていました。クライアントに TLS セッション再開( session resumption )がサポートしていると誤解されないようにすることを意図していましたが、一部のクライアントは依然としてサポートしていると考えていました。

動作中に変更可能な設定は「SET」句で変更できますが、パラレルワーカー内では上記の 2 つの設定が変更できませんでした。

クライアント側で利用されるため、スレッドセーフではないことは問題がありました。

この関数はメモリ不足時に exit() を呼び出しますが、呼び出し元のコードは既に割り当て失敗を適切に処理しているため、この動作はライブラリとしては適切ではありませんでした。

v15 以降、テーブルが UNLOGGED のときに IDENTITY 列を管理するシーケンスだけを LOGGED に設定したり、その逆を行ったりすることが可能になっています。ただし、バイナリアップグレードモードではその状況を再現する pg_dump が失敗し、そのようなシーケンスが存在すると pg_upgrade は失敗していました。シーケンスの永続性が作成時に正しく設定できるように、「ADD/ALTER COLUMN GENERATED AS IDENTITY」に新しいオプションを導入して修正されました。したがって、このようなシーケンスを含むデータベースからのダンプは、このマイナーバージョン以降のサーバーにのみロードできます。

これは当初の意図でしたが、ソース履歴が常に空として出力されていました。

これは以前は許可されていましたが、テーブルに対するデフォルト以外のアクセスメソッドの導入時に機能しなくなっていました。