この変更は、拡張に属さない既存オブジェクトがある場合に、拡張のスクリプトが 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」というエラーが発生するリスクがありました。

バージョン14 で追加された最適化のため、CREATE INDEX ... CONCURRENTLY と REINDEX ... CONCURRENTLY が時々インデックスエントリ作成に失敗していました。その結果、誤った問い合わせ結果が生じる可能性があります。本修正でこの最適化が取り消されました。

CONCURRENTLYオプションを付与して作成された全てのインデックスをバージョンアップ後に再作成することが推奨されています。

データ型の等価関数またはハッシュ関数が各呼び出しで一貫性に欠ける結果を返す場合に、Memorize がクラッシュを起こす可能性がありました。これからは、そのような場合にエラー「ERROR: could not find memoization table entry」が出るようになります。

この誤りにより、それが最善でない場合でも Memorize が使われたり、Memorizeノードにおける巨大なハッシュ表の初期化のためにエグゼキュータの起動時間が非常に長くなったりしました。

（修正前のエラー動作例）
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 ビューから使われます。

このバグにより、正しいデータに対しても「ERROR: invalid byte sequence for encoding "UTF8": 0xe5」などの入力データが不正であるという偽性のエラーが生じる可能性がありました。

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

（修正後の動作、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

（14.3 でのエラーメッセージ）
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)」と出力されていました。また、古いリリースではクラッシュする可能性がありました（本修正は 10.x 以降に適用されています、次リリース 13.8、12.12、11.17、10.22 に含まれます）。

接続が失われた場合などに、libpq で生成されたエラー結果を誤って処理していたため、クラッシュが生じていました。