同時リフレッシュのある一段階が弱いセキュリティ制限のもとで実行されていました。マテリアライズドビューの所有者が、何らか説きつけて、スーパーユーザや他の高権限ユーザにそのビューの同時リフレッシュをさせた場合、REFRESH を実行したユーザの権限でコードを実行させることができました。

全てのユーザ定義コードはマテビュー所有者として実行されるように修正されました。これが期待される動作でした。

この誤りを使った権限奪取は PostgreSQL 16.x では実施できないことが知られていて、おそらく 16.x では実際には脆弱性が無いと見られます。(CVE-2024-0985)

多数の JITコンパイルの後にバックエンドプロセスがメモリ不足状態になることが報告されていました。

LATERAL参照を伴うまれな状況で、不正な実行プランが作られる可能性がありました。影響を受ける場合には、誤った問い合わせ結果が返る、「ERROR: variable not found in subplan target list」などの奇妙なエラーになる、あるいは、エグゼキュータでプロセスがクラッシュする可能性がありました。

サブクエリが、外部結合の下にあって、外部結合のスコープ外にあるものを LATERAL参照する出力列を持っているとき、誤った問い合わせ結果が生じる可能性がありました。外部結合により生じるべき出力列の NULL が、異なる値になる可能性がありました。

PlaceHolderVar はプランナの実装コードにおいて別のプランノード結果から値が充当される変数を意味します。

本誤りにより予期せぬエラー「ERROR: WindowFunc not found in subplan target lists」が生じるおそれがありました。

この誤りにより「ERROR: cache entry already complete」が生じるおそれがありました。

「ERROR: wrong varnullingrels (b) (expected (b 3)) for Var 2/2」といった予期せぬエラーが発生することがありました。

varnullingrels はプランナの実装コードにおける変数ノードの修飾情報の一つです。

パーティションテーブルに対して MERGE UPDATE 動作をするときに、パーティションキーを変更するために UPDATE が DELETE と INSERT に置き換えられる場合に「AFTER UPDATE ROW」トリガを発効しないようになりました。RLS 検査などの他の UPDATE 後のアクションも同様に行われなくなります。

これらのアクションは一般的には失敗します。このことは通常の UPDATE で実行しない理由であり、MERGE でも実行すべきではありません。

このようなトリガが NULL を返すことで更新を妨げようとした場合、MERGE がエラーやアサート失敗を引き起こしていました。

「ERROR: could not open file "base/16384/16393.1" (target block 3081245700): previous segment is only 1 blocks」というエラーが出るケースが報告されました。

更新中タプルが別セッションによって更新されて別ページに移動されたばかりの場合、バッファへの PINなしに新しいタプルバージョンからデータを取得しようとするタイミングがありました。これにより原理的には、新タプルの未更新列にガベージデータが表示される可能性がありました。

実際に問題が生じる可能性は低いと見られます。

上限値が大きすぎたために、予想ハッシュテーブルサイズが大きい場合に「ERROR: invalid DSA memory alloc request size ..」エラーが発生することがありました。

ディスク不足時にエラーが生じた後、アサート失敗が生じるケースが報告されました。

この誤りにより、エグゼキュータで「ERROR: attribute 1 of type record has wrong type」などのエラーが生じる可能性がありました。

（エラー発生例）
db1=# SELECT
        string_agg(DISTINCT 'a', ','),
        sum((SELECT sum(1) FROM (VALUES(1)) b(id) WHERE a.id = b.id))
        FROM unnest(array[1]) a(id);
ERROR:  attribute 1 of type record has wrong type
DETAIL:  Table has type text, but query expects integer.

（正しい応答）
 string_agg | sum
------------+-----
 a          |   1
(1 row)

この誤りはアサートを無効にした実運用むけビルドでは、何ら影響はありません。

孫テーブルが複数の中間の親テーブルを通して新たな列を継承した場合、「ERROR: tuple already updated by self」エラーが生じました。

これまでは「ERROR: tuple already updated by self」が発生していました。

これまでは「ERROR: tuple already updated by self」が発生していましたが、これからは重複した指定を無視してエラーを出さないようになります。

（これまでのエラー例）
db1=# CREATE ROLE u;
db1=# DROP ROLE u, u;
ERROR:  tuple already updated by self

ロック取得不足のため、DROP STATISTICS を ANALYZE と同時に実行した場合に、「ERROR: tuple concurrently deleted」が発生していました。

これらの場所では、関数のデフォルト引数に VOLATILE 関数が指定されているのを検出できなかったり、使われる具体的なデータ型について実際には IMMUTABLE であるのに多様関数を VOLATILE と判断したりする可能性がありました。

これにより GENERATED句を不適切に拒否または受け入れしたり、ALTER TABLE .. ADD COLUMN で定数デフォルト値の最適化を誤って適用したりする可能性がありました。

カタログタプルの行外フィールドは何であれ、カタログキャッシュに挿入する前に、TOAST展開されます。これはカタログキャッシュエントリを無効化するかもしれないデータベースアクセスと関わりますが、新たなエントリはまだキャッシュに存在していません。その結果、既に古くなったキャッシュエントリが作られて永続化するかもしれないという競合動作になります。これにより（例えば DDL の同時実行で稀に）予期せぬ振る舞いがもたらされました。

TOAST展開後にタプルの可視性を再チェックすることで修正されました。

「0 - INT64_MIN」の計算はオーバーフローエラーとなるべきで、大部分のプラットフォームではそうなっています。しかしながら、組み込みの整数オーバーフローが無く、128-bit整数も無いプラットフォームの場合、オーバーフローを検知できず、INT64_MIN の値を返していました。

timestamp型の範囲を越えていて「ERROR: timestamp out-of-range」を出すべき一部の場合で、ERROR ではなく誤った問い合わせ結果を返していました。

interval型の値の掛け算と割り算で、「ERROR: interval out of range」を出すべき一部ケースで、ERROR ではなく誤った問い合わせ結果を返していました。

大きな scram_iterations（イテレーション回数が多い）場合に、本関数は時間を要します。本関数は例えば password_encryption が scram-sha-256 であるときに ALTER ROLE ... PASSWORD '...' でパスワード変更するときに使われます。本修正により本関数実行中に問い合わせのキャンセルが可能になりました。

一部のコードパスで、古い統計情報が返される可能性がありました。本修正は以下のビューの応答に影響があります。

 pg_stat_archiver
 pg_stat_bgwriter
 pg_stat_checkpointer
 pg_stat_io
 pg_stat_slru
 pg_stat_wal

これまで、該当の設定パラメータについて無効な値であっても error列に何も出力されませんでした。

(16.x での該当設定パラメータ)
 ignore_system_indexes
 jit_debugging_support
 jit_profiling_support
 log_connections
 log_disconnections
 post_auth_delay

これまではパーティションキーの対応する要素から、異なる照合順序を持つインデックスも受け入れていて、誤動作を引き起こす可能性がありました。

予期せぬ「ERROR: could not open relation with OID」が発生していました。

バッファへの（排他ロックではなく）共有ロックでこれを行おうとしていましたが、二つのプロセスが同時にクリーンアップを行おうとするとインデックス破損が生じる可能性がありました。

インデックスのルートページの分割が自身の挿入と同時に生じると、「ERROR: buffer NNNN is not owned by resource owner」になる可能性がありました。

このようなインデックスを使用しようとして、「ERROR: could not open file "pg_tblspc/0/PG_16_202307071/0/0": No such file or directory」といったエラーが生じる可能性がありました。

所有者権限が必要なラージオブジェクト操作（例えば GRANT や COMMENT）で、所有者ユーザであってもスーパーユーザでない限り、「ERROR: unrecognized class ID: 2613」といったエラーが出て失敗しました。

何もしない ALTER LARGE OBJECT OWNER コマンド（元の所有者を指定するなど）が、誤った class ID を PostAlterHook に渡していました。本フックを使っている拡張に混乱をもたらしていたと考えられます。

「shared/local」ラベルの数は実際には共有バッファだけを参照していました。本修正で、このラベルは「shared」に変更されました。

これまで、CREATE DATABASE の実行中や直後に OSクラッシュが生じた場合、リカバリに失敗したり、起動後にそのデータベースへの接続に失敗する可能性がありました。同様のタイミングでベースバックアップを取得した場合にも、そのバックアップを使用する時に似た問題が起きる可能性がありました。症状としては、データベースディレクトリや PG_VERSIONファイル、pg_filenode.mapファイルが欠損するか空になります。

リカバリの問題を診断するのに役立つ追加情報がマスタプロセスのログとして提供されます。具体的には以下のメッセージです。

LOG:  starting backup recovery with redo LSN XX/XXXXXXXX, checkpoint LSN XX/XXXXXXXX, on timeline ID NN
LOG:  restarting backup recovery with redo LSN XX/XXXXXXXX
LOG:  completed backup recovery with redo LSN XX/XXXXXXXX and end LSN XX/XXXXXXXX

実装においてサブトランザクションで startedInRecoveryフラグが正しく設定されていませんでした。これはデッドインデックスタプルの処理にのみ影響があります。この誤りにより、サブトランザクション中の問い合わせが返すべき（プライマリではデッドだがスタンバイでは未だ有効な）インデックスエントリを無視してしまう可能性があり、誤った問い合わせ結果が生じます。あるいは、未だプライマリではデッドになっていないインデックスエントリにデッドと早すぎる印付けをしてしまう可能性がありました。後者は深刻な結果になるか明らかではありませんが、想定された動作ではありません。

レプリケーション接続確立まで待つ間、walreceiver を SIGTERM に応答しないようにした変更を、旧に戻しました。以前の変更内容では、スタンバイ昇格が妨げられることがありました。

このバグは 64-bitプラットフォーム上で 32-bit ビルドした PostgreSQL を稼働させる場合を除き、顕在化しないと考えられます。

このデッドロックの一端はロック待ちと無関係であるため、デッドロックに陥ると自動では検出できず、（コマンドキャンセルやプロセス停止など）手動で介入しない限り永続的に止まってしまいます。

tablesync worker はロジカルレプリケーションのテーブル初期同期を行うものです。apply worker は変更差分の適用を行います。

新しい列にデフォルトの定数値を持つ ALTER TABLE ... ADD COLUMN ... は、既存のタプルの書き換えをせず、代わりにタプルの読み取りコードが正しいデフォルト値を挿入することを期待していました。

その後、そのテーブルでレプリケーションが開始された場合、pgoutput は正しいデフォルト値の代わりに NULL を送信し、サブスクライバで不正なレプリケーションを引き起こしていました。

このケースでは、不適切な形式の COPY コマンドが生成されていました。

これは、password_required=true のサブスクリプションがスーパーユーザを所有者として接続文字列にパスワードなしで作成されたけれども、その後に所有者が非スーパーユーザに変更されたケースを検出することを目的としています。

これまではパスワードファイルや PGPASSWORD環境変数でパスワードが供給されれば、接続文字列にパスワードの無いサブスクリプションを一般ユーザで利用可能でした。

CheckPWChallengeAuth は PostgreSQL実装内部の関数です。これまで一部ケースでこの場合をログ出力されるエラーとして扱っていました。これは意図したものではなく、psql のような一般的なクライアントで頻繁にある動作であるため、ログスパムの生成につながっていました。

また、この誤りは ClientAuthentication_hook を使用する拡張を混乱させたかもしれません。

「data」フィールドの使用に代えて BIO「app_data」フィールドを使用するようになりました。以前のバージョンでは問題ありませんでしたが、3.2 ではクラッシュや二重解放のエラーを引き起こしていました。

「LOG: could not accept SSL connection: Socket operation on non-socket」というエラーが出てSSL接続に失敗するケースが報告されました。

以前の実装では、errno が設定されていない場合、報告されたエラーの原因は EOF の読み込みだと決めつけていました。 これにより「could not accept SSL connection: Success」のような奇妙なエラー報告が稀に発生していました。

外部テーブルから構成されたパーティションテーブルへの問い合わせなどで、非同期実行が使われたときに ERROR を出す場合に、該当している可能性があります。

以前は、関数本体にセミコロンが含まれているため、構文エラーとなっていました。

（本マイナーバージョンから実行可能になった PL/pgSQL の例）
db1=# DO LANGUAGE plpgsql $$
      BEGIN
        CREATE FUNCTION f1() RETURNS int
          BEGIN ATOMIC
            SELECT 1;
          END;
        END $$;

（以前は以下のようなエラーになった）
ERROR:  syntax error at end of input
LINE 5:             SELECT 1;

クエリの問題以外の理由 (接続が失われた場合など) でエラーが返された場合、パイプラインの状態が同期しなくなる可能性があります。これにより、呼び出し側のアプリケーションでビジーループが発生する可能性がありました。

パイプラインモードでも、引き続き PQflush() を呼び出す必要がある場合がありますが、この変更により一部の不整合が解消されます。

ノンブロッキングモードで GSSAPI 暗号化を使用すると、libpq が「GSSAPI caller failed to retransmit all data needing to be retried」というエラーを出して、サーバへのデータ送出に失敗することがありました。

initdb は V16以前は postgresql.conf の「lc_...」パラメータのコメントを常に解除していて、本マイナーバージョンアップで再び元の動作に戻されました。16.0 の変更により、initdb の --no-locale オプションがlc_messages に意図した効果を及ぼさなくなっていました。

以前は、コマンドがこれらのプロパティを設定するためダンプに含まれていましたが、これらのプロパティは拡張機能の内部事項として考慮される必要があるため、全く誤った動作でした。さらに、復元するユーザにはそれらを設定するための十分な権限がない可能性があり、（RLSポリシーをダンプするにはテーブルのロックを取得する必要があるため）ダンプするユーザにもそれらをダンプするための十分な権限がない可能性がありました。

典型的には「--exclude-table」などの指定で一部テーブルを除外したときに、除外したテーブルの拡張統計オブジェクトも除外するということです。これはインデックスなどの他の依存オブジェクトの動作に準拠します。

以前は、\startpipeline コマンドに一致する\endpipeline がない場合、pgbench は奇妙な動作をしていました。これは、pgbench が適切に処理する必要があるケースというよりは、スクリプトのミスのように見えるため、エラーを投げるようになりました。

false_positive_rate パラメータに最大値を指定したときに、アサート失敗が生じる動作が報告されました。

「ERROR: could not open file "....": No such file or directory」といったエラーが生じる動作が報告されました。

「ERROR: could not open file "....": No such file or directory」といったエラーが生じる動作が報告されました。

cmd.exe 経由で子プロセスを起動するときは、/D フラグを渡して、レジストリで指定された自動実行コマンドが実行されないようになりました。これにより予想外の副作用が回避できます。

この変更により、pg_wchar.h で「include 」を行う必要がなくなりました。一部のサードパーティコードで問題が発生していました。

PostgreSQL のビルドで選択されるコンパイラオプションは、Python のヘッダファイルの最新バージョンに含まれる構造体に関する警告を引き起こしました。gcc を使用する場合、プラグマを使用してこれらの警告を抑制するようになります。

グリーンランド、カザフスタン、パレスチナの夏時間法の変更、南極観測点のケーシーとボストークの修正、ベトナム、トロント、ミクロン島の歴史的修正が含まれます。

これにより、待ちリストが長い場合の O(N^2) の動作が修正されました。一部のユースケースでは、これによりスループットが大幅に向上します。

システムカタログを変更するトランザクションの途中でデコーディングが開始されると、デコーダがそれを認識できず、そのトランザクションをカタログ検索の進行中として扱うことができない場合がありました。

この修正は、トップレベルのトランザクションにはすでにカタログ変更が含まれているとマークされているけれども、そのサブトランザクションにはマークがついていない場合に対処します。

「ERROR: could not map filenode "..." to relation OID」という奇妙なエラーメッセージが出るケースが報告されました。

本障害により、実行時にテキスト型の値が不明なデータ型の値（即ち 0x00 で終わる文字列）として解釈されて、テキスト値に続くサーバメモリの露出をもたらす可能性がありました。(CVE-2023-5868)

現在の配列範囲の外側にある配列の添え字に新たな要素を割り当てるとき、境界値ケースで検知されない整数オーバーフローが生じる可能性がありました。潜在的に任意コード実行の攻撃が可能なメモリ上書きや、サーバメモリ暴露が可能でした。(CVE-2023-5869)

ドキュメントでは pg_signal_backend はスーパーユーザ所有のプロセスにはシグナルを投げれないとされていますが、これらプロセスには送信可能でした。紐づくロールの ID が ゼロになっていたため、スーパーユーザ所有でないと見做されていました。これらをスーパーユーザ所有として扱うように修正されました。

PostgreSQL本体コードの範囲ではセキュリティ影響は軽微です。しかし、バックグラウンドワーカを使う拡張が脆弱になるかもしれません。(CVE-2023-5870)

ページのダウンリンク位置が不正確に追跡される場合について修正されて、そのような状態から復旧できるロジックが導入されました。この誤りはその後のインデックス検索で誤った問い合わせ結果をもたらします。マイナーバージョンアップ後に GiSTインデックスを再作成することを推奨します。

interval型には「24:00:00」と「1 day」のように、区別できるけれども比較すると等しい値があります。これは Btree 重複排除における前提を破ります。そのため、interval型の列は重複排除の対象外とする必要がありました。この見落としにより index only スキャンで誤った問い合わせ結果が返る可能性がありました。さらに、amcheck がほぼ全てのこのようなインデックスをエラー報告するように改定されました。

マイナーバージョンアップ後に interval型列の btreeインデックスは再作成すべきです。

日付の距離計算が逆方向であったため、マージするエントリを適切に決定できませんでした。このようなインデックスは正しい結果を返すものの、本来よりも大幅に非効率でした。該当する BRIN インデックスは再作成することを推奨します。

無限（infinity、-infinity）が、他の値から大きな距離ではなく、距離ゼロと誤って処理されていて、マージするエントリを適切に決定できませんでした。また、無限ではないけれども巨大な値（タイムスタンプとして表現できる上限に近い値）では、内部オーバーフローを起こして、やはり、マージするエントリを適切に決定できませんでした。このようなインデックスは正しい結果を返すものの、本来よりも大幅に非効率でした。該当する BRIN インデックスは再作成することを推奨します。

このバグは大きな interval型の値を該当するインデックスに挿入するときに、予期せぬエラー「ERROR: interval out of range」をもたらします。

プルーニングとはパーティションテーブルへの問い合わせで一部パーティションの走査を省略することを意味し、ここでのステップとはそのための情報が格納されたデータ構造を意味します。

複数あるパーティションキーの 1つに IS NULL条件がある一部の場合にクラッシュする可能性がありました。

READ COMMITTED モードでは UPDATEは、対象行が同時実行トランザクションから更新されたことを検知したなら、対象行に関する問い合わせの WHERE句を再チェックします。MERGE において、この再チェック処理が適切に動作しておらず、新たに更新された行を再度更新すべきかの判断を誤る可能性がありました。

本障害により、READ COMMITTEDモードでの同時実行で、MERGE が誤った問い合わせ結果（誤った更新結果）となる可能性がありました。

コマンドで指定したテーブルが制約により処理対象から除外されているけれども、その子孫テーブルは除外されていない場合、最初の除外されていない子孫テーブルを主対象テーブルとみなしていました。

この誤りにより、文レベルのトリガが子テーブルに対して発火する誤動作が生じました。加えて、バージョン16 では予期せぬエラーも発生しました。

（16.0 でのエラー発生例）
db1=# CREATE TABLE t8p (f1 int, f2 int, f3 int, check (f1 < 10) NO INHERIT);
db1=# CREATE TABLE t8c () INHERITS (t8p);
db1=# INSERT INTO t8c SELECT i, i+1, 0 FROM generate_series(1,1000) i;
db1=# CREATE INDEX ON t8c (f1, f2);
db1=# UPDATE t8p SET f3 = 11 WHERE f1 = 12 and f2 = 13;
ERROR:  invalid perminfoindex 0 in RTE with relid 16648

ScalarArrayOpExpr は「indexcol = ANY(ARRAY[...])」や「indexcol IN (...)」といった検索条件で使われるエグゼキュータノードです。マーク/リストア処理とは、処理位置を覚えておいて再開する btreeインデックス検索の内部処理です。

本障害により、誤った問い合わせ結果が生じて、結果に含まれるべき行が失われる可能性がありました。

行数の多いテーブルに対する jsonb_array_elements() 関数実行で引数でjsonb型の列の存在しないキーを指定したときにメモリリークが発生する現象が報告されました。

この関数の 1つの呼び出しで設定されたオリジン条件が、オリジン引数を指定しなかった後の呼び出しで再使用されていました。これは意図された動作ではありません。

以前は「ERROR: only heap AM is supported」という的外れなエラーが発生していました。「ERROR: ".." is a partitioned table」が本来出るべきエラーです。

pgstatindex()、pgstatginindex()、pgstathashindex()、または pgstattuple() が無効なインデックスに適用された場合、エラーを報告するようになりました。brin_desummarize_range()、brin_summarize_new_values()、brin_summarize_range()、または gin_clean_pending_list() が無効なインデックスに適用された場合は、デバッグ・レベルのメッセージを報告する以外は何もしない動作になります。

以前は、これらの関数はインデックスを処理しようとして、失敗した CREATE INDEX の残骸の内容によっては奇妙なエラーを出すことがありました。「ERROR: could not read block 0 in file」が出るケースが報告されました。

実際には処理可能な場合でも、「ERROR: invalid memory alloc request size .....」が発生することがありました。

受信ベクトルに位置データが含まれている場合、バイナリ受信関数は、完成した tsvector に無駄なスペース（位置データのサイズにほぼ等しい）を残していました。極端な場合、これにより出力時に長さ制限を下回っていたベクトルに対して「ERROR: lexeme length exceeded maximum total lexeme length」が発生する可能性がありました。いずれの場合もディスクスペースが無駄になる可能性がありました。

以前はクラッシュ（セグメンテーション違反）が発生していました。

これまでは ALTER SUBSCRIPTION ... SET (run_as_owner = ...) を実行しても効いていませんでした。

パーティション間での挿入状態の不適切な共有により、COPY FROM 中に失敗する可能性があり、典型的には「ERROR: could not read block NNNN in file XXXX: read only 0 of 8192 bytes」が発生していました。

これにより、デフォルト値が実際にはその列で有効でない場合や、デフォルトの式が現在の実行コンテキストで失敗する場合に発生するエラーが回避されます。このような特殊なケースは、ダンプのリストア時に発生することがありました。15.x 以前のリリースではこのような状況にならなかったため、16.x 以降について修正されました。

最近のリファクタリングで、意図していたエラーチェックが誤って削除され、有用なエラーメッセージの代わりに「ERROR: cache lookup failed for function 0」が出力されていました。

PostgreSQL本体には、これに適合する組み込みパラメータはありませんが、拡張機能でそのようなパラメータを定義することができます。

これにより、一時テーブルのカタログエントリが（非常に複雑な「CHECK」条件などで）TOAST を必要とするほど大きい幅のフィールドを持つ場合の誤動作が防止されます。

CREATE TEMP TABLE でアサート失敗が発生する動作が報告されました。

Cライブラリ関数の system() は archive_command 設定などでPostgreSQL が外部コマンドを呼ぶ動作で使用されています。system() によってフォークされたものの、目的の子プログラムをまだ実行していない子プロセスが、親サーバープロセス向けのシグナルを受信して動作するおそれがありました。これにより、終了時にクリーンアップ処理が重複して実行されてしまいます。

fastシャットダウンに対してアサート失敗する動作が報告されました。

ファイルシステムによっては、サーバがそのファイルに同時に書き込むときに、pg_control の読み込みがアトミックな動作にならないことがあります。これは不正な CRC によって検出できます。エラーを報告する前に、数回再試行してファイルが有効になるかどうかを確認するようになりました。

ファイルの一貫したビューを確実に取得できるように、pg_control を読み取る前に適切なロックを取得するようになりました。関数 pg_control_system()、pg_control_checkpoint()、pg_control_recovery()、pg_control_init() で修正が行われました。

64ビットマシンでは、track_activity_query_size 設定値は、許可される接続数を乗算したときに 32ビットのオーバーフローを引き起こすのに十分大きな数となります。

該当する処理が実行される代表的な操作は pg_stat_activityビューの参照です。max_connections が 3000 以上、track_activity_query_size = 1MB のとき、「SELECT * FROM pg_stat_get_activity(NULL)」に対して、「ERROR: invalid memory alloc request size 18446744072590721024」が発生するケースが報告されました。

current_child_table_relidフィールドの更新と同時に、ブロックレベルのカウンタをゼロにリセットする必要がありました。

background writerプロセスからの WAL書き込みがこれまでpg_stat_walビューで参照できる統計情報に反映されませんでした。

本障害により、WAL と I/O に関する一部の統計情報が PostgreSQLサービス停止で失われてしまうおそれがありました。

以前は、一時テーブルの書き込みが通常テーブルの書き込みとしてカウントされていました。

CALL文の引数でインライン化されている関数を置き換えする DDLコマンドでは、PL/pgSQL によるキャッシュを捨てる必要がありました。これが行われなかったため、誤動作や「ERROR: cache lookup failed」などの奇妙なエラーが発生していました。

（誤動作例）
db1=# CREATE FUNCTION f(int) RETURNS int LANGUAGE sql AS $$ SELECT $1 + 1 $$;
db1=# CREATE PROCEDURE p1(p int) LANGUAGE plpgsql
        AS $$ BEGIN CALL p2(f(p)); END $$;
db1=# CREATE PROCEDURE p2(p int) LANGUAGE plpgsql
        AS $$ BEGIN RAISE NOTICE '%', p; END $$;
db1=# CALL p1(10);
NOTICE:  11
db1=# DROP FUNCTION f(int);
db1=# CREATE FUNCTION f(int) RETURNS int LANGUAGE sql AS $$ SELECT $1 + 2 $$;
db1=# CALL p1(10);
ERROR:  cache lookup failed for function 16699
CONTEXT:  SQL statement "CALL p2(f(f1))"
PL/pgSQL function p1(integer) line 1 at CALL

この見落としにより、アサート失敗やクラッシュ、または「ERROR: bogos varno: ..」エラーが引き起こされる可能性がありました。レコード型を出力する共通テーブル式（WITH句）を使った問い合わせで現象の発生が報告されました。

これらの関数はノードの元の演算子が存在している間は消えないと考えられるためこれはほとんどの場合に無害です。

誤った個所でちょうどメモリ不足エラーが起きると、無限ループをもたらす一貫しない状態が生じる可能性がありました。

以前はでたらめなデータ状態として扱っており、WAL の終わりに到達したものと解釈していましたが、それは間違っていて一貫しない WAL再生が引き起こされる可能性がありました。

プライマリ停止後にスタンバイが「FATAL: invalid memory alloc request size ....」を出して止まる現象が報告されました。

このコードは、変更されたバッファをダーティとしてマークする前に WAL を書き込むことで、クラッシュ安全性に必要な条件に違反していました。この関数を使用する　PostgreSQL本体コードはありませんが、拡張機能（例えば contrib/bloom）は使用します。

この見落としにより、サブスクリプションは run_as_owner を意図して true に設定していたとしても、常に false として復元されていました。これはバージョン16 より前のリリースの動作とは同等ではありません。

以前は両方のタイプとも存在する場合にテーブルレベルの ACL のみが復元されていました。

これらのデータ型は PostgreSQLバージョン12 で廃止されたため、アップグレード可能と主張する前に古いデータベースに存在しないことを確認します。

複数の -N オプションは、複数スキーマについてスキーマ内テーブルを除外すべきですが、クエリ生成の誤りで、実際には何も除外されていませんでした。

この修正で以下のような誤った報告が防止されます。

ERRPR:  the first child of leftmost target page is not leftmost of its level ...
ERROR:  block NNNN is not leftmost ...
ERROR:  left link/right link pair in index XXXX not in agreement

リカバリを終えたデータベースクラスタで、btree インデックスぺージを削除するWALレコードが中途であって、VACUUM がそれらをクリーンアップする前に、amcheck を実行するとこれらのエラーが発生していました。

このようなインデックススキャンは本来返すべきすべての値を返せず、誤った問い合わせ結果が生じました。

Xcode 15 (macOS Sonoma とともにリリース) では、PostgreSQL のビルド中にライブラリの重複に関する警告が多数発生するようにリンカの動作が変更されました。これらは無害ですが目障りなため、同じライブラリを複数回引用することは避けるようになりました。

また、-multiply_define の使用も削除されました。これは明らかに無効なものでした。

最近の Debian および Ubuntuリリースでは、基礎となる tzdbエントリがデフォルトでインストールされなくなったため、デフォルトリストにこの略語が存在すると、エラーが発生する可能性があります。必要であれば、カスタム略語ファイルを介して元に戻すことができます。

これまでは本関数でリセットしても共有カタログには効果がありませんでした。

tsvector列の GiSTインデックスでのページ分割の決定が適切に行われない可能性がありました。

この障害により不正メモリ読み取りが生じるケースが報告されました。

競合で削除されたデータベースの統計エントリが残り、そのためにどのデータベースを処理するかの選択が混乱する可能性がありました。

Linux などの long が int よりも大きいプラットフォーム（Windows なら同サイズ）において、数テラバイトの一時ファイルを必要とする巨大なソート処理について、整数オーバーフローで誤動作を引き起こす可能性がありました。

これにより CPUサイクルが節約されるだけでなく、スナップショットを設定してはならないトランザクション制御コマンドでのキャッシュ無効化後のエラーが防止されます。

プロシージャ内で COMMIT の次に SET TRANSACTION ISOLATION LEVEL を実行して、「ERROR: SET TRANSACTION ISOLATION LEVEL must be called before any query」が発生する障害ケースが報告されました。

これにより、タプルスロットの寿命がその値を構築したタプル記述子よりも長くなった場合に、不正なポインタが使用される可能性が回避されます。

予期せぬエラー「ERROR: unsupported byval length: 32639」が生じて、その後にアサート失敗やクラッシュが生じるケースが報告されました。

これにより、ロール名を変更後に特別な文字列「$user」の意味が再決定されます。

サーバー接続が pgbouncer を介して実行されている場合でのみ発生が確認されています。

現在のトランザクションのプロパティを新しいトランザクションに伝播する代わりに、以前のトランザクションのプロパティをいくつか伝播していました。

以下のように実行したときに「SHOW transaction_isolation」に対して不適切な出力が得られるケースが報告されました。

db1=# START TRANSACTION ISOLATION LEVEL SERIALIZABLE; COMMIT;
      START TRANSACTION ISOLATION LEVEL REPEATABLE READ;
      SAVEPOINT s; COMMIT AND CHAIN;
      SHOW transaction_isolation; 
      COMMIT;

これまでは無効なページヘッダに対するエラー出力なしにページ読み込みのリトライが行われていました。

SEARCH/CYCLE を含む再帰問い合わせの EXPLAIN 出力でエラーが発生するケースが報告されました。

PostgreSQL 13 以降では、下記例のように f1、f2、… というフィールド名でレコード型から要素を参照することができます。本機能が PostgreSQL 11.x、12.x にもバックポートされました。

db1=# SELECT (ROW(1,2,3)).f3;
 f3
----
  3
(1 row)