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」 などのプランナエラーにつながる可能性があります。

この変更は、拡張に属さない既存オブジェクトがある場合に、拡張のスクリプトが CREATE OR REPLACE を行うことを防止します。また、同じ状況での CREATE IF NOT EXISTS も防止します。 これにより、敵対的なデータベースユーザが拡張のオブジェクトの所有者になって、それを変更して将来の他ユーザによるオブジェクト使用を危機にさらすという、トロイの木馬型の攻撃を防ぐことができます。 副次的な利点として、意図しないオブジェクトを誤って置換してしまうリスクも軽減されます。(CVE-2022-2625)

スタンバイサーバがデータベース作成の WALレコードをリプレイする時に、テーブルスペースのディレクトリが見つからないことがあります。 本パッチ適用前は、このような場合、スタンバイはリカバリに失敗していましたが、このようなディレクトリが合法的に欠落している可能性がありました。テーブルスペースを（通常のディレクトリとして）作成し、リプレイが一貫した状態に達したら、再び削除されていることを確認する動作に変更されました。

通常、PostgreSQL のテーブルスペースは、他のファイルシステム上のディレクトリへのシンボリックリンクですが、この変更により、データベースクラスタディレクトリ内の単なるディレクトリにすることができます。

これはテストには便利な仕組みです。さらに、CREATE DATABASE リプレイの修正（前項の修正）で、欠落しているテーブルスペースを構内テーブルスペースとして一時的に作成するために必要となります。

設定パラメータ allow_in_place_tablespaces が追加されています。以下のように使用できます。

（以下を実行すると pg_tblspc 以下にテーブルスペース用ディレクトリが作られる）
db1=# SET allow_in_place_tablespaces TO on;
db1=# CREATE TABLESPACE sp1 LOCATION '';
CREATE TABLESPACE

CVE-2022-1552 むけの修正により、CREATE INDEX が演算子クラスやその他のオブジェクトの検索を実行する際に、以前は呼び出しユーザのパーミッションを適用していたところで、テーブル所有者のパーミッションを適用するようになっていました。pg_dump はパーミッションを再度付与する前に CREATE INDEX を発行するため、これによりダンプ/リストアのシナリオが壊れていました。

本修正で問題を回避するように調整されました。

クライアントがそのようなコマンドの直後に Sync メッセージを送信せず、代わりに別のコマンドを送信した場合、そのコマンドで障害が発生すると、直前のコマンドがロールバックされ、通常ディスク上に矛盾した状態が残りました（欠落しているデータベースディレクトリや余分なデータベースディレクトリなど）。

そのような状況を防ぐためのメカニズムは、簡易問い合わせメッセージ内の複数コマンドに対しては機能しますが、拡張問い合わせの一連のメッセージに対しては機能しません。現在動作しているユースケースを壊さずに矛盾を防ぐため、そのようなコマンドの後に暗黙のコミットを強制するものとなりました。

内部実装関数 TransactionIdIsInProgress(xid) が、対象のトランザクションが可視とみなされる前に「false」を報告し、さまざまな誤動作を引き起こす可能性がありました。競合状態のウィンドウは通常、非常に狭いですが、同期レプリケーションを使用すると同期レプリカの待機がそのウィンドウ内で発生するため、より広くなります。

代表的な誤動作は以下のエラーが出ることです。

ERROR:  t_xmin is uncommitted in tuple to be updated

以下ような形状の問い合わせについて、予期せぬエラー「ERROR: set-valued function called in context that cannot accept a set」が生じるケースが報告されました。

SELECT unnest(ARRAY[]::integer[]) + 1 AS pathkey
  FROM ta JOIN tb ON ta.c1 = tb.c1 ORDER BY pathkey

ユーザが不十分な SELECT権限しか持たないテーブルに拡張統計情報がある場合、一部の問い合わせが「ERROR: permission denied ...」ではなく、「ERROR: unrecognized node type」で失敗していました。

統計収集は正常に動作しますが、WHERE にその式を含む問い合わせは、プラン作成時に「ERROR: unknown clause type ...」で失敗していました。

（エラー発生例）
db=# CREATE TABLE t9 (a int, b int);
db=# CREATE STATISTICS stat_ex1 ON
       (CASE a WHEN 1 THEN true ELSE false END), b FROM t9;
db=# INSERT INTO t9 SELECT g % 10, g FROM generate_series(1,10000) g;
db=# ANALYZE t9;
db=# SELECT * FROM t9 WHERE (CASE a WHEN 1 THEN true ELSE false END) AND b = 2;

ERROR:  unknown clause type: 134

（障害発生例）
db=# CREATE TABLE t10 (c int, a int[]);
db=# CREATE STATISTICS stat_ex10 (mcv) ON c, a FROM t10;
db=# INSERT INTO t10 SELECT g, ARRAY[g] FROM generate_series(1, 10) g;
db=# ANALYZE t1
db=# SELECT * FROM t10 WHERE c = ANY (ARRAY[1,2,3]) AND 1 = ANY(a);

server closed the connection unexpectedly

場合によっては、コマンドがトリガを持たない子パーティションでトリガを調整しようとするため、「ERROR: trigger does not exist」が発生することがありました。

高コストな統計情報対象を伴うシナリオでは、キャンセルできないソート操作に何秒も費やす可能性がありました。

「ERROR: syntax error, unexpected IDENT_P at or near " " of jsonpath input」のような、パーサ実装のトークン名を伴うメッセージが出ていました。

これまで省略されていたため、セッションの後半でアサート失敗やクラッシュを引き起こす可能性がありました。

不正メモリアクセスにより、潜在的にクラッシュが生じる可能性がありました。

稀なケースでは、誤解を招くエラーが報告されることがありました。

「ERROR: FOR UPDATE cannot be applied to a join」とするべきところで、「ERROR: relation "..." in FOR UPDATE clause not found in FROM clause」が出力される動作が報告されました。

おおよそ 1600列を超えるケースはサポートされておらず、必ず実行に失敗します。しかしながら、32K を超える列を持った問い合わせによって、アサート失敗またはクラッシュが発生する以前のコードが一部ありました。これを避けるために構文解析するときに検査するようになりました。

ダンプされたビューはこの関数に対する過剰な列エイリアスを持っているため、ダンプ／リストアや pg_upgrade でのエラーを引き起こしました。

（障害動作例）
db=# CREATE TYPE typ18 AS (c1 int, c2 int, c3 int);
db=# CREATE VIEW v18 AS SELECT * FROM fn18();
db=# ALTER TYPE typ18 DROP ATTRIBUTE c2;
db=# SELECT pg_get_viewdef('v18', true); -- ダンプ時の出力を確認
          pg_get_viewdef
----------------------------------
  SELECT fn18.c1,                +
     fn18.c2,                    +
     fn18.c3                     +
    FROM fn18() fn18(c1, c2, c3);
(1 row)
db=# SELECT fn18.c1, fn18.c2, fn18.c3 FROM fn18() fn18(c1, c2, c3);
ERROR:  table "fn18" has 2 columns available but 3 columns specified

クラッシュやアサート失敗を起こす可能性がありました。

子パーティションについてのレプリカアイデンティティ列の検査が抜け落ちていました。

サブスクライバ側でアサート失敗を引き起こす動作が報告されました。

適切なクリーンアップには複雑で低レベルな機能を必要とします。従って、どの既知の呼び出し元もクリーンアップしないことがあり得ます。このために、手続き言語が COMMIT を発行したが（例えば遅延制約検査などで）エラーが起きてしまった場合に誤動作を招きます。

これを改善するために SPI_commit() を次のように再定義しました。即ち、前トランザクションの特性を保存せずに新しいデフォルトトランザクションの特性を取ること以外は、SPI_commit_and_chain() と等価な新しいトランザクションを開始するものとしました。この変更を透過的にするため、SPI_start_transaction() を no-op（何もしない動作）に再定義しました。全ての SPI_commit() の既知の呼び出し元は直後に SPI_start_transaction() を呼びます。これにより全ての呼び出し元は本変更の影響を受けません。同じ変更は SPI_rollback() にも行われています。

PL/Python の修正も行われました。PL/Python では、このようなエラー処理が完全に省略されていて、Python 3.11 ではクラッシュすると報告されており、古いバージョンでは何も問題ないように見えますがメモリリークが起きます。

時々「WARNING: message type 0x33 arrived from server while idle」が出る動作が報告されていました。また、PQgetResult() から問い合わせの最後の NULL の結果が失われる可能性がありました。

EXEC SQL PREPARE などの特定の操作をデータベース接続を確立する前に呼び出すと、エラーを報告するのではなくクラッシュしました。

クエリごとにロケールオブジェクトを作成して解放するのではなく、最初の接続時にプロセスごとに C ロケールオブジェクトを割り当てるように修正されました。これにより、AIX における libc の メモリリークが軽減され、また、どのプラットフォームでも性能向上が見込まれます。

これにより、libedit (およびおそらく libreadline) でカーソルがどの列にあるかについて混乱するのを防ぎます。

（動作例）
db=# SELECT 1;
 ?column?
----------
        1
(1 row)

db=# \watch
2022年08月16日 07時53分10秒 (every 2s)

 ?column?
----------
        1
(1 row)

（修正前の動作）
^Cdb=#

（修正後の動作）
^C
db=#

バージョン 14 では、いくつかの組み込み関数が、anyarray ではなく anycompatiblearray 型を取るように変更されました。これはほとんど透過的ですが、これらの関数の上に構築されたユーザ定義の集約関数と演算子は、正確に一致する型で宣言する必要があります。古いシグネチャを参照するオブジェクトが存在すると、pg_upgrade が失敗する原因となるため、アップグレードを開始する前に、そのようなケースを検出して報告するように変更されました。

(修正後の動作)
$ pg_upgrade -b /usr/local/pgsql-13.8/bin -B /usr/local/pgsql-14.5/bin \
    -d /usr/local/pgsql-13.8/data -D /usr/local/pgsql-14.5/data
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for user-defined encoding conversions              ok
Checking for user-defined postfix operators                 ok
Checking for incompatible polymorphic functions             fatal

Your installation contains user-defined objects that refer to internal
polymorphic functions with arguments of type "anyarray" or "anyelement".
These user-defined objects must be dropped before upgrading and restored
afterwards, changing them to refer to the new corresponding functions with
arguments of type "anycompatiblearray" and "anycompatible".
A list of the problematic objects is in the file:
    incompatible_polymorphics.txt

Failure, exiting
$ cat incompatible_polymorphics.txt
In database: postgres
  aggregate: public.array_accum(anyelement)

これに伴って、pg_stat_statements.max の最大値が 2147483647 から 1073741823 に変更されました。

外部テーブルのビューが WITH CHECK OPTION 制約を持つ場合、リモートで挿入されるデータを取得し、制約をチェックしますが、一度に複数の行が挿入されると、最初の 1行しかリモートのデータを取得できず、残りの行はローカルのデータで制約をチェックしていました。そのため、リモートのテーブルが行単位 BEFORE INSERT トリガをもち、リモートでデータが変更される場合、制約を適切にチェックできませんでした。

db=# CREATE SERVER loopback
       FOREIGN DATA WRAPPER postgres_fdw OPTIONS (dbname 'db');
db=# CREATE USER MAPPING FOR CURRENT_USER SERVER loopback;
db=# CREATE FUNCTION row_before_insupd_trigfunc()
       RETURNS trigger LANGUAGE plpgsql AS $$
         BEGIN NEW.a := NEW.a + 10; RETURN NEW; END; $$;
db=# CREATE TABLE base_tbl (a int, b int);
db=# CREATE TRIGGER row_before_insupd_trigger
       BEFORE INSERT OR UPDATE ON base_tbl FOR EACH ROW
       EXECUTE PROCEDURE row_before_insupd_trigfunc();
db=# CREATE FOREIGN TABLE foreign_tbl (a int, b int)
       SERVER loopback OPTIONS (table_name 'base_tbl');
db=# CREATE VIEW rw_view AS
       SELECT * FROM foreign_tbl WHERE a < b WITH CHECK OPTION;
db=# ALTER SERVER loopback OPTIONS (ADD batch_size '10');

（修正前の動作: Batch Size が 10 のまま、
  2行目の挿入が変更前データでチェックされ、制約違反のデータが格納される）
db=# EXPLAIN (VERBOSE, COSTS OFF) INSERT INTO rw_view VALUES (0, 15), (0, 5);
                                   QUERY PLAN
--------------------------------------------------------------------------------
 Insert on public.foreign_tbl
   Remote SQL: INSERT INTO public.base_tbl(a, b) VALUES ($1, $2) RETURNING a, b
   Batch Size: 10
   ->  Values Scan on "*VALUES*"
         Output: "*VALUES*".column1, "*VALUES*".column2
 Query Identifier: -8082510435137086002
(6 rows)

db=# INSERT INTO rw_view VALUES (0, 15), (0, 5);
INSERT 0 2

（修正後の動作: Batch Size が 1 になり、
  2行目の挿入が変更後のデータでチェックされ、制約違反でエラーになる）
db=# EXPLAIN (VERBOSE, COSTS OFF) INSERT INTO rw_view VALUES (0, 15), (0, 5);
                                   QUERY PLAN
--------------------------------------------------------------------------------
 Insert on public.foreign_tbl
   Remote SQL: INSERT INTO public.base_tbl(a, b) VALUES ($1, $2) RETURNING a, b
   Batch Size: 1
   ->  Values Scan on "*VALUES*"
         Output: "*VALUES*".column1, "*VALUES*".column2
 Query Identifier: 9094516644014608466
(6 rows)

db=# INSERT INTO rw_view VALUES (0, 15), (0, 5);
ERROR:  new row violates check option for view "rw_view"
DETAIL:  Failing row contains (10, 5).

これにより、シグナルが posix_fallocate() に割り込むときのバスエラー (SIGBUS) が回避されます。

これにより、Solaris で発生する可能性のあるクラッシュが回避されます。

これにより、ハングアップやカーネルパニックが発生するように見えるため、修正が利用可能になるまでこの機能は使用されません。

（修正前のエラー動作例）
db=# CREATE TYPE ctyp4 AS (c1 boolean, c2 boolean);
db=# CREATE DOMAIN dom4 AS ctyp4 NOT NULL;
db=# CREATE FUNCTION f_ctyp4() RETURNS ctyp4 LANGUAGE sql
     AS $$ SELECT (true, true) $$;
db=# CREATE FUNCTION f_dom4() RETURNS dom4 LANGUAGE sql
     AS $$ SELECT (true, true) $$;

（複合型を返す場合は動作する）
db=# SELECT f_ctyp4 FROM f_ctyp4();
 f_ctyp4
------------------------
 (t,t)
(1 row)

（複合型のドメインを返す場合にエラーになっていた - 修正後は動作する）
db1=# SELECT f_dom4 FROM f_dom4();
ERROR:  type dom4 is not composite

（修正前バージョンでのエラー発生例）
db=# CREATE TABLE t5 AS SELECT generate_series(1, 100)::int i ;
db=# SELECT GROUPING(ss.x) FROM t5 CROSS JOIN LATERAL (
       SELECT (SELECT t5.i) as x) ss GROUP BY ss.x;
ERROR:  variable not found in subplan target list

pg_stat_get_subscription() 関数は pg_stat_subscription ビューから使われます。

そのような問い合わせに適切なエラーを返すようになりました。これまでは奇妙なエラーが出たり、クラッシュしたりしていました。

（修正後の動作、f(v1,v2) で実際の列数より多く別名が指定されている）
db=# SELECT * FROM XMLTABLE (ROW () PASSING null COLUMNS v1 timestamp)
     AS f (v1, v2);
ERROR:  XMLTABLE function has 1 columns available but 2 columns specified

（修正前のエラーメッセージ）
ERROR:  no relation entry for relid 0

これまでは、自動生成されたこの別名は常に隠されていましたが、結果としてビューやルールがリストア不能になる稀なケースがありました。

以前は、CREATE OPERATOR CLASS によって演算子族が暗黙的に作成された場合、イベントトリガに通知されませんでした。

以前は、リスタートポイント完了時にコントロールファイルの最終チェックポイントのフィールドが誤って更新される可能性があり、次の通常チェックポイント完了前にサーバがクラッシュした場合、PANIC が発生して再起動に失敗する可能性がありました。

以前は、プライマリサーバ上の大規模トランザクションが（おそらく変更されたテーブルがパブリッシュされていないために）スタンバイにデータを送信しない場合、スタンバイがタイムアウトする可能性がありました。キープアライブメッセージを定期的に送信することで修正されました。

このような場合には無害な警告メッセージが生じることがありました。

短い説明は SHOW ALL の description などに表示されるもので、以前は、拡張でここに NULL を指定していると表示処理がクラッシュしていました。

以前のマイナーリリースで、サーバでの SSL 秘密鍵のアクセス権チェック方式を libpq にも適用しましたが、所有者チェックまで同様に行うべきではありませんでした。鍵ファイルにアクセス可能であるけれども所有者と異なるユーザでクライアントを実行するときに、予期せぬエラーが生じることがありました。

(エラー例: root で root 以外のユーザが所有者の鍵ファイルを指定して psql を実行）
$ su -
# PGSSLCERT=/ssl/cert.pem PGSSLKEY=/ssl/key.pem PGSSLROOTCERT=/ssl/rcert.pem \
  PGSSLMODE=verify-ca psql -h localhost -U postgres -d postgres
psql: error: private key file "key.pem" must be owned by the current user or root

接続が失われた場合などに、libpq で生成されたエラー結果を誤って処理していたため、有用なエラーメッセージではなく「(null)」と出力されていました。また、古いリリースではクラッシュする可能性がありました

「FOR ALL TABLES」指定のパブリケーションは、個別にテーブルを指定せず、全テーブルが複製対象となり、一時テーブルを複製しようとします。DDL 中のヒープ書き換え一時テーブルは除外されますが、マテリアライズドビューの書き換え中に作成された内部一時テーブルをカバーできませんでした。これにより、REFRESH MATERIALIZED VIEW 中に「logical replication target relation ... does not exist」というエラーが発生するリスクがありました。