トップレベル以外のテーブルの参照（例えば、 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」に新しいオプションを導入して修正されました。したがって、このようなシーケンスを含むデータベースからのダンプは、このマイナーバージョン以降のサーバーにのみロードできます。

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

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

永続オブジェクトの作成、削除ができる攻撃者により、SQLコードのインジェクションが可能でした。そのコードは pg_dump を起動するロール（しばしばスーパーユーザです）の権限で、並列 pg_dump のセッションから実行されます。シーケンスのようなオブジェクトを悪意のコードを実行するビューや外部テーブルで置き換えることで、攻撃が行われます。これを防ぐため、ビルトインでないビューの展開および外部テーブルへのアクセスを無効にできる新たな設定パラメータ restrict_nonsystem_relation_kind が導入されました。デフォルトは ''（空文字列）で、カンマ区切りで view や foreign-table を指定します。この設定が pg_dumpコマンド内で SET で指定されるようになります。攻撃を防ぐにはサーバと pg_dumpコマンドの両方のアップデートが必要です。(CVE-2024-7348)

内側のリレーションが制約でユニークな結合キーを持つと分かっている場合に、外側のリレーションに結合キーの重複した行があるとき、マージが誤動作を起こす可能性がありました。

（誤動作例）
db1=# CREATE TABLE t2 (a int UNIQUE, b int);
db1=# INSERT INTO t2 SELECT g, g % 100 FROM generate_series(1,1000) g;
db1=# CREATE INDEX ON t2 (b);
db1=# ANALYZE t2;
db1=# SET enable_hashjoin TO off;
db1=# SET enable_nestloop TO off;
db1=# SELECT * FROM t2 t2out WHERE NOT EXISTS
        (SELECT 1 FROM t2 t2in WHERE t2in.b = t2out.a) AND t2out.b < 2;

→ Nested Loop Anti Join や Hash Right Anti Join の場合には正しく動作するが、
   Merge Right Anti Join を使った実行プランでは少ない件数が返る。

長時間実行中のトランザクションを伴う切断されたスタンバイサーバがプライマリサーバに再接続した後に、プライマリでの VACUUM 処理が、どのタプルが除去可能かについて混乱する可能性があり、その結果、無限ループに陥ることがありました。

アサート失敗が報告されました。アサートを無効にした実稼働むけビルドでは、クラッシュや誤動作が生じる可能性があります。

（障害発生例）
db1=# CREATE TABLE t_inh_p (a int);
db1=# CREATE TABLE t_inh_c () INHERITS (t_inh_p);
db1=# DROP TABLE t_inh_c;
db1=# CREATE TABLE pt (a int) PARTITION BY LIST (a);
db1=# ALTER TABLE pt ATTACH PARTITION t_inh_p FOR VALUES IN (1);
db1=# INSERT INTO t_inh_p VALUES (1);
db1=# UPDATE t_inh_p SET a = 2 WHERE a = 1;
→ ここでアサート失敗が生じる（正常動作はパーティション制約違反のエラー）

パーティションテーブル（親テーブル）に制約と関連付かないインデックスがあって、そのパーティション（子テーブル）に同等の制約のインデックスがある場合、パーティションをデタッチするときにアサート失敗が生じたり、システムテーブル pg_constraint の coninhcount列が誤った値になりました。

db1=# CREATE TABLE pt5 (a int) PARTITION BY LIST (a);
db1=# CREATE TABLE p5 PARTITION OF pt5 FOR VALUES IN (1);
db1=# ALTER TABLE p5 ADD PRIMARY KEY (a);
db1=# CREATE UNIQUE INDEX ON pt5 (a);
db1=# ALTER TABLE pt5 DETACH PARTITION p5;
→ ここでアサート失敗か、以下が 0 ではなく -1 になる。
db1=# SELECT coninhcount FROM pg_constraint WHERE conname = 'p5_pkey';

エグゼキュータはプラン作成と実行の間でパーティションがデタッチされないと想定していましたが、CONCURRENTLY指定を使う場合にはその前提は成り立ちません。パーティションテーブルに対する問い合わせ実行で、そのようなタイミングのときに、アサート失敗や以下のようなエラーが発生しました。

ERROR:  missing relpartbound for relation ..
ERROR:  could not match partition child tables to plan elements

パーティションが無くなったパーティションテーブルに対する最初の ANALYZE でrelhassubclass = f の変更をするときに reltuples = 0 の変更が失われていました。

SQL の CALL文は多様OUT引数に対して正しいデータ型を解決できず、「ERROR: cannot display a value of type anyelement」などのエラーや、クラッシュを引き起こしました。

なお、PL/pgSQL 内の CALL は問題ありません。

（障害動作例）
db1=# CREATE PROCEDURE pro1 (i1 IN anynonarray, o1 OUT anynonarray)
        LANGUAGE sql AS $$ SELECT i1; $$;
db1=# CALL pro1('aa'::text, NULL);
ERROR:  cannot display a value of type anynonarray

CALL が、トランザクションブロック内のアトミックなコンテキストで実行された場合に、誤って外側トランザクションの開始時点のスナップショットが STABLE関数に渡されて、古い値が参照されていました。

（誤動作例）
db1=# CREATE TABLE t9 AS SELECT 0 AS x;
db1=# CREATE FUNCTION f_get_x() RETURNS int STABLE LANGUAGE plpgsql AS
      $$ DECLARE r int; BEGIN SELECT x INTO r FROM t9; RETURN r; END; $$;
db1=# CREATE PROCEDURE f_print_x(x int) LANGUAGE plpgsql AS 
      $$ BEGIN RAISE NOTICE 'f_print_x(%)', x; END; $$;
db1=# BEGIN;
db1=# DO $$ BEGIN
            UPDATE t9 SET x = x + 1;
            RAISE NOTICE 'f_get_x(%)', f_get_x();
            CALL f_print_x(f_get_x());
            UPDATE t9 SET x = x + 1;
            RAISE NOTICE 'f_get_x(%)', f_get_x();
            CALL f_print_x(f_get_x());
            END $$;
NOTICE:  f_get_x(1)
NOTICE:  f_print_x(0)   （← 正しくは 1）
NOTICE:  f_get_x(2)
NOTICE:  f_print_x(0)   （← 正しくは 2）
db1=# ROLLBACK;

'T12:34:56' のような書き方を再び許容するようになりました。PostgreSQL 15.x 以前では受け入れられていましたが、16.0 以降で「ERROR: invalid input syntax for type ...」のエラーになっていました。

money型に対する算術関数はこれまでオーバーフロー検査をしていませんでした。そのため、オーバーフローする場合に誤った問い合わせ結果が生じていました。

（誤動作例）
db1=# SELECT '92233720368547758.07'::money + '0.01'::money;
          ?column?
-----------------------------
 -$92,233,720,368,547,758.08
(1 row)
→ 修正後は「ERROR:  money out of range」エラーが出る。

これまでスケール引数は（文書に記載なく）正負 2000桁までに制限されていて、それを越える場合には、誤った問い合わせ結果が返っていました。numeric型の上限に合わせた桁数を上限とするように修正されました。

（誤動作例 - 本来全て「1000」にならないといけない）
db1=# SELECT substr(round(1.234e1999, -1999)::text, 1, 4);
 substr
--------
 1000
(1 row)

db1=# SELECT substr(round(1.234e2000, -2000)::text, 1, 4);
 substr
--------
 1000
(1 row)

db1=# SELECT substr(round(1.234e2001, -2001)::text, 1, 4);
 substr
--------
 1200
(1 row)

（誤動作ケース - 期待される正しい出力は「-8192PB」）
db1=# SELECT pg_size_pretty('-9223372036854775808'::bigint);
       pg_size_pretty
----------------------------
 -9223372036854775808 bytes
(1 row)

このような場合に、これからは NULL を返すようになります。本関数は pg_sequences ビューの中で使われるもので文書化されていません。

（プライマリサーバで実行 - これで UNLOGGED のシーケンスが作られる）
db1=# CREATE UNLOGGED TABLE t14 (id serial);

（スタンバイサーバで実行 - 修正前バージョンではエラーになる）
db1=# SELECT * FROM pg_sequences ;
ERROR:  could not open file "base/18077/18108": No such file or directory

マニュアルでは websearch_to_tsquery() の入力中の記号は、ダッシュ(-) と引用符(") の特別な場合を除き無視されることになっています。しかしながら、括弧といくつかの記号が or の直前に現れた場合、or が演算子ではなく or という単語として扱われる動作がありました。

（or は引用符で囲わない限り演算子）
db1=# select websearch_to_tsquery('simple', 'cat or dog');
 websearch_to_tsquery
----------------------
 'cat' | 'dog'
(1 row)

（誤動作例 - 括弧があると or が演算子として扱われない）
db1=# select websearch_to_tsquery('simple', '(tom cat) or dog');
     websearch_to_tsquery
------------------------------
 'tom' & 'cat' & 'or' & 'dog'
(1 row)

以下の INSERT が正しくエラーになるようになりました。

（修正前バージョンでは a = '{}' で行が挿入される）
db1=# CREATE TABLE t16 (a int[]);
db1=# INSERT INTO t16 (a[-2147483648:2147483647]) VALUES ('{}');
ERROR:  array size exceeds the maximum allowed (134217727)

バージョン 16.1、15.5、14.10、13.13、12.17、11.22 で修正された、CVE-2023-5869 の件と似ていますが、本障害では配列は空で終わるので無害です。

一部のコードパスでは、非決定的な照合順序の使用において「ERROR: pg_strnxfrm() returned unexpected result」のエラーが発生する可能性がありました。

TOASTテーブルを持つシステムカタログにインプレース更新を行う場合に問題が発生します。該当するのは pg_database だけです。pg_database の情報を使う SQL (例えば GRANT .. ON DATABASE .. など) で古い情報が使われてしまう可能性がありました。

対象の列が更新不能である場合、その旨のエラーを出すべきですが、検査が漏れており、後のコードから「ERROR: attribute number N not found in view targetlist」という意味が理解しにくいエラーメッセージが生じていました。

（修正前の動作例）
db1=# CREATE TABLE t19 (id int);
db1=# CREATE VIEW v19 AS SELECT id, id * 2 AS c_2id FROM t19;
db1=# INSERT INTO v19 VALUES (1, 2);
ERROR:  cannot insert into column "c_2id" of view "v19"
DETAIL:  View columns that are not columns of their base relation are not updatable.
db1=# INSERT INTO v19 VALUES (1, DEFAULT);
ERROR:  attribute number 2 not found in view targetlist

これまで、WITH RECURSIVE の問い合わせで UNION の 2つ目の枝に自己参照が無いけれども ORDER BY のような別の場所に自己参照がある場合に、役に立たない内部的なエラーメッセージが出ていました。

（修正前の動作例）
db1=# WITH RECURSIVE x(n) AS (WITH x1 AS (SELECT 1 FROM x)
        SELECT 0 UNION SELECT * FROM x1) SELECT * FROM x;
ERROR:  missing recursive reference
（→ 修正後のメッセージは以下）
ERROR:  recursive reference to query "x" must not appear within a subquery

db1=# WITH RECURSIVE x(n) AS (
        SELECT 0 UNION SELECT 1 ORDER BY (SELECT n FROM x)) SELECT * FROM x;
ERROR:  missing recursive reference
（→ 修正後のメッセージは以下）
ERROR:  ORDER BY in a recursive query is not implemented

このコマンドは（通常は serial型の列により）テーブルに紐づくシーケンスについても LOGGED と UNLOGGED の切り替えを行いますが、シーケンスについてロック取得されていませんでした。このため、同時に実行される nextval() の結果が失われる可能性がありました。

トランザクションで遅延された AFTERトリガを発生させる操作を実行して、その後、トリガ実行に至る前にそのトリガが DROP された場合に該当します。これまでは「ERROR: could not find trigger NNNN」エラーを出していましたが、動作が変更されました。この場合は何もしない方が良いと判断されました。

ある拡張が作成したテーブルの列単位権限を GRANT した場合に、関連する pg_init_privs のエントリが拡張を削除した後にも残っていました。これはテーブルの OID が再利用されない限りは無害です。pg_init_privs に残ったエントリは、OID が一致するテーブルの pg_dump 出力に影響を与える可能性があります。

問い合わせ（INSERT）が更新可能ビューを通してターゲットテーブルにON CONFLICT を用いたアクセスする場合、利用可能なインデックスがある場合でも、それが無いというエラーが生じていました。

（エラー発生例）
db1=# CREATE TABLE t24 (js jsonb);
db1=# CREATE UNIQUE INDEX ON t24 ((js ->> 'key'));
db1=# CREATE VIEW v24 AS SELECT * FROM t24;
db1=# INSERT INTO v24 VALUES ('{"key": "value"}')
        ON CONFLICT ((js ->> 'key')) DO NOTHING;
ERROR:  there is no unique or exclusion constraint matching the ON CONFLICT specification

権限チェックにより、通常は他セッションの一時テーブルの行を参照・更新することは防止されますが、ALTER TABLE で定義変更をすることは可能でした。永続テーブルを継承する一時テーブルを作ることで、スキーマ pg_temp_NNN を指定することなく、他セッション一時テーブルの ALTER TABLE を試みることができてしまいました。

（現象再現例）
db1=> CREATE TABLE t25(i int);
db1=> CREATE TEMP TABLE t25tt () INHERITS (t25);

（別セッションで実行）
db1=> ALTER TABLE t25 ADD c text;
ERROR:  could not open file "base/18077/18239": No such file or directory
　→ アサート有のビルドならアサート失敗／列追加に成功してしまう場合もある

（修正後のエラー）
ERROR:  cannot alter temporary tables of other sessions

このような CREATEコマンドは、統計情報の式の列参照で列番号を適切に調整できませんでした。その結果、無効な統計オブジェクトが作られて、後で問題が生じました。典型的には元テーブルが削除された列を持っていて、列番号の付け直しが必要になる場合です。

（障害発生例）
db1=# CREATE TABLE t26s (a text, b text, c text);
db1=# CREATE STATISTICS es26 ON (a || c) FROM t26s;
db1=# ALTER TABLE t26s DROP COLUMN b;
db1=# CREATE TABLE t26t (LIKE t26s INCLUDING STATISTICS);
db1=# \d t26t
ERROR:  invalid attnum 3 for relation "t26t"

一部の場合では、外側の問い合わせのある行で計算された集約結果が、後の行でそうすべきでないときに再利用されるおそれがありました。これは外側の問い合わせがハッシュ集約で実装された DISTINCT を用いているときだけ起きると見られていますが、他の場合もありえます。

本障害により誤った問い合わせ結果が生じます。

（誤動作例 - min も 1、2、3 となるのが正しい結果）
db1(5432)=# CREATE TABLE t27 (f1 int4);
db1(5432)=# INSERT INTO t27 VALUES (1),(2),(3);
db1(5432)=# SET enable_sort TO off;
db1(5432)=# SELECT f1, (SELECT DISTINCT min(t27in.f1) FROM t27 t27in
              WHERE t27in.f1 = t27out.f1) FROM t27 t27out;
 f1 | min
----+-----
  1 |   1
  2 |   1
  3 |   1
(3 rows)

バージョン 16.0 で整数リテラルがアンダースコアを含むことが可能になりました。この変更で「$1_234」などを単一トークンとして扱うようになりましたが、これは正しく機能しませんでした。位置パラメータのシンボルは $ とそれに続く数字のみに戻されました。

エラー状態は（エラー位置を示す文字列のために）JITコンパイルされたコードを持つ動的にロードされたモジュールへのポインタを含むことができます。一部のコードパスでモジュールはエラー報告が処理される前にモジュールがアンロードされる可能性があり、エラー位置を示す文字列にアクセスがあったとき、SIGSEGV がもたらされました。

報告されたエラーがそれだけでない限り、libxml2 からの「chunk is not well balanced」エラーを抑止するようになりました。これにより 2.13.x とそれ以前のバージョンとのエラー報告の一貫性を保ちます。以前のバージョンではこのメッセージは冗長であったり、完全に間違っていたりしたので、2.13.x では報告されるケースの数が大幅に減りました。

シャットダウン時のチェックポイント の WALレコードでスタンバイのリプレイを開始すると、プライマリで準備されているがまだコミットされていないトランザクションは、進行中であると正しく認識されます。しかし、サブトランザクション（セーブポイントまたは PL/pgSQL の例外ブロックで生じる）については考慮されず、中止されたものとして扱われていました。

これにより、準備されたトランザクションが後でコミットされた場合に、コミットされた内容が REPEATABLE READ 分離レベルの別トランザクションにおいて途中から参照可能になる、といった不整合が発生していました。

場合によっては、WALストリーム内のレプリケーションスロットの開始ポイントがトランザクション内のポイントに設定され、アサート失敗が発生したり、デコード結果が不正確になったりすることがありました。

同時にスロットの作成・削除を行うとタイミングによって現象が発生しました。アサートが有効なビルドではアサート失敗も発生します。

パーティションテーブル（親テーブル）が、列が追加されている等、物理的に異なる行タイプのパーティション（子テーブル）を持つとして、そのようなパーティションテーブルの変更をパブリッシュするときに、wal sender プロセスでメモリリークが生じました。

これらのイベントの処理関数では現在メモリコンテキストを TopMemoryContext に切り替える可能性があり、その結果、切り替え前に割り当てられたデータについて、セッション存続期間でのリークが発生しました。少なくとも、受信した問い合わせと Bind メッセージに付加されたパラメータのエンコード変換でリークが観察されました。

統計情報の共有メモリにアタッチされた新しいバックエンドプロセスは参照カウントを増加させましたが、終了時にカウントを減少させていませんでした。2^32 セッションが作られた後、参照カウントが 0 にオーバーフローして、その後のバックエンドプロセス起動が「ERROR: could not attach to ...」エラーで失敗する可能性がありました。

SLRUセグメントを削除しようとするプロセスは、checkpointerプロセスとデッドロックする可能性がありました。

Windowsは接続のリモート側が切断された後に FD_CLOSE イベントを1回だけ報告します。タイミングが悪いと、その報告を見逃し、さらに入力を期待して無期限に、または少なくともタイムアウトが経過するまで待機する可能性がありました。

結果としてクライアント側が切断したことの検知が遅れて、「FATAL: sorry, too many clients already」などが生じる原因となりました。

最後のバイトが不完全なマルチバイト文字で構成されている場合、入力バッファの末尾から数バイト離れる可能性がありました。通常は無害ですが、原理的にはクラッシュを引き起こす可能性がありました。

セッションチケットの受信が TLSセッション再開がサポートされていることを意味すると考えるクライアントで発生するおそれのある障害を、これにより回避できます。

これまでも無効にしていましたが、OpenSSL 1.1.1 以降の TLSv1.3 に対応した無効化の指定が必要でした。

参照された関数を削除して集約として再作成するなど、大がかりな変更を行った際に、「ERROR: unexpected plan node type ..」などの予期せぬエラーが発生する可能性がありました。

（障害動作例 - 単純なSQL関数を PL/pgSQL関数から呼び出す）
db1=# CREATE FUNCTION f41() RETURNS int LANGUAGE sql AS $$ SELECT 1 + 1 $$;
db1=# CREATE FUNCTION f41caller() RETURNS int LANGUAGE plpgsql AS $$
        DECLARE x int; BEGIN x := f41simple(); RETURN x; END $$;
db1=# SELECT f41caller();
 f41caller
-----------
         2
(1 row)

（単純な関数を作り直して同セッション内で再度実行するとエラーになる）
db1=# DROP FUNCTION f41;
db1=# CREATE FUNCTION f41() RETURNS SETOF int LANGUAGE sql AS
        $$ SELECT g FROM (VALUES (1),(2)) AS g (g) LIMIT 1; $$;
db1=# SELECT f41caller();
ERROR:  unexpected plan node type: 311
CONTEXT:  PL/pgSQL function f41caller() line 1 at assignment

PostgreSQL 16.x では整数リテラルにアンダースコアを含めることができますが、PL/pgSQL は「FOR i IN 1_001..1_003」ような文を正しく処理できていませんでした。

（エラー発生例 - 「1_001」と「..」の間に空白がない場合にエラーとなる）
db1=# CREATE FUNCTION test(cnt int) RETURNS int LANGUAGE plpgsql AS $$
      DECLARE i integer;
      BEGIN
        FOR i IN 1_001..1_005 LOOP
          cnt := cnt + 1;
        END LOOP;
        RETURN cnt;
     END; $$;
ERROR:  syntax error at or near "1_001."

AS句で異なる列定義リストを渡す関数内で、その関数の再帰的な呼び出しを行った場合、内部呼び出しによって外部呼び出しの返す行型を上書きしてしまうため、エラーが発生しました。

（障害発生例 - 内部で int型列のレコードを返す再帰呼び出しがある）
db1=# CREATE FUNCTION f43(t text) RETURNS record LANGUAGE plpython3u AS $$
      if t == "text":
          plpy.execute("SELECT * FROM f43('int') AS (a int)");
          return { "a": "x" }
      elif t == "int":
          return { "a": 1 }
      $$;

db1=# SELECT * FROM f43('text') AS (a text);
ERROR:  invalid input syntax for type integer: "x"
CONTEXT:  while creating return value
PL/Python function "f43"
→ 修正後は列名a、値「x」を持つレコードが返る

PL/Python のトリガーによって別のトリガーが呼び出された場合、内側のトリガー用に作成された TD辞書によって外側のトリガーの TD辞書が上書きされてしまっていました。

TD辞書はトリガとして PL/Python 関数を使用した場合に、関連する値を格納するために使われます。

これにより、クラッシュが生じたり、以前の Tclエラーを指す誤ったコンテキスト情報が出力されたりする可能性がありました。

マルチスレッドアプリケーションにおいて、OpenSSL から返るエラーメッセージがおかしくなる可能性がありました。

（以下のようにメッセージがエラーコード表示になってしまうケースが報告された）
FATAL:  could not load root certificate file "root_ca.crl": SSL error code 2147483650

pg_dump で --binary-upgrade オプションを指定した場合に該当します。通常、このオプションを使用するのは pg_upgrade コマンドだけです。

pg_restore の「-l」が「-n」や「-N」などの選択的なリストアのオプションと共に指定された場合、コメントなど依存しているオブジェクトが、実際にはダンプに含まれていてリストアされるものであっても、TOC エントリ一覧から省かれていました。

SQL言語の関数のエグゼキュータは、ユーティリティ命令（SELECT/INSERT/UPDATE/DELETE/MERGE 以外）に対して計算したクエリID を伝えそこなっていました。

リモートサーバが PostgreSQL 15 以降であって、リモートの単純ではないビューに対して作った外部テーブルを参照する場合に、本エラーが発生します。

リモートサーバはこの構文を実装していないか、ローカルサーバとは異なる解釈をするかもしれないため、あえてリモートサーバでの実行を試みることはないと判断されました。

本構文がサポートされたのは PostgreSQL 13.x 以降です。

maxOS バージョン 15 以降でのコンパイル失敗が修正されます。

この修正は 9.2.x から 11.x のリポジトリでも修正適用されています。