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

自動VACUUM、CLUSTER、CREATE INDEX、REINDEX、REFRESH MATERIALIZED VIEW、pg_amcheck では「セキュリティ限定された操作」による保護が有効化されるのが遅すぎたり、全く働かなかったりしていました。

データベース内に永続オブジェクトを作成する権限を持ったユーザは、スーパーユーザ権限で任意の SQLコードを実行するオブジェクトを定義できました。仕込まれた SQLコードは、次に自動VACUUM が行われるときに、あるいは、スーパーユーザがそのオブジェクトに作用するいずれかのコマンドを実行したときに、実行されます。

本脆弱性は CVE-2022-1552 として登録されています。

ltree拡張を演算子クラスパラメータをサポートするようにアップグレードするときに、ltree列に対する GiSTインデックスのデフォルトのシグネチャ長（ハッシュサイズ）が、意図せず変更されてしまいました。最初から ltree をバージョン 1.2 にアップグレードしている場合を除き、このようなインデックスに何らか操作が行われた場合、シグネチャ長が 8バイトではなく 28バイトと見做されて動作します。したがって、おそらくそのインデックスは壊れています。安全のためバージョンアップ後に全ての ltree の列に対する GiSTインデックスを再作成（REINDEX）することを推奨します。なお、ltree[] 配列の列に対する GiSTインデックスには影響しません。

選択リストの最上位以外での tbl.*などの行全体変数から作られたタプルの列名は、今後は、もしあるなら常に関連して名前付けされた複合型の要素名になります。これまでは FROM のエントリに適用された全ての列の別名を追跡させるように試みていました。しかし、これは意味がないと判断されました。

従来実装では、行全体をあらわす列を使用したテーブルを作った後、行全体の列の元となるテーブルの列名を付け直した場合に、そのようなテーブルのSELECT で予期せぬエラーが発生して、格納したデータが読めなくなってしまうことがありました。

（報告された障害発生ケース）
db=# CREATE TABLE t3 (data int);
db=# CREATE VIEW v3 AS SELECT t3 FROM t3;
db=# CREATE TABLE t3_log (ts timestamp, what v3);

（列名を付け直す操作）
db=# ALTER TABLE t3 ADD big_data bigint;
db=# UPDATE t3 SET big_data = data;
db=# UPDATE t3_log SET what.t3.big_data = (what).t3.data;
db=# ALTER TABLE t3 DROP data;
db=# ALTER TABLE t3 RENAME big_data TO data;
db=# INSERT INTO t3 VALUES (123456);
db=# INSERT INTO t3_log SELECT now(), v3 FROM v3;

（この時は正しく出力）
db=# SELECT * FROM t3_log;
             ts             |     what
----------------------------+--------------
 2022-05-16 13:49:54.862458 | ("(123456)")
(1 row)
db=# \c

（接続し直した後にはエラーになる）
db=# SELECT * FROM t3_log;
ERROR:  record type has not been registered

列名を付け直したい場合の本障害の回避策は、副問い合わせの階層を追加して、行全体の変数が副問い合わせの出力を参照して、素のテーブルを参照しないようにすることです。これは上記のエラー発生例で言えば「CREATE VIEW ...」を「CREATE VIEW v3 AS SELECT v::t3 AS t3 FROM (SELECT * FROM t3) v(d);」と記述することです。

numeric型を返すようになった新しい EXTRACT の実装コードで、誤って DAYS_PER_YEAR 定数を整数型に変換して切り捨てていたため、13.x バージョン以前の float型を返すコードと戻り値が異なっていました。

この関数はカタログデータで STRICT と定義されるべきでしたが、バージョン14 ではこれが指定されていなかったため、代替策として、関数実装に実行時のチェックが追加されました。

これらのデータ型に対する XMLスキーマ出力では文字列パターンの正規表現が壊れていました。

（報告された障害発生ケース）
db=# CREATE TEMP TABLE nocols();
db=# INSERT INTO nocols DEFAULT VALUES;
db=# SELECT * FROM nocols n, LATERAL (VALUES(n.*)) v;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

非同期リモートクエリをサポートするために最近追加されたコードは、このケースを処理できず、クラッシュや「ERROR: unrecognized node type ..」などの認識されないノードタイプに関するエラーが引き起こされました。

再帰的な WITH クエリの名前が自身の中で再利用されると、プランナがクラッシュしたり、奇妙なエラーを報告したりする可能性がありました。

（障害発生例）
db=# WITH RECURSIVE x(col) as (
       SELECT 1 UNION (
	     WITH x AS (SELECT * FROM x)
           SELECT * FROM x)
     ) SEARCH DEPTH FIRST BY col SET seq
     SELECT * FROM x;
ERROR:  could not find attribute 2 in subquery targetlist

奇妙なエラーやアサート失敗が報告されました。

（エラー発生例）
db=# SELECT (SELECT GROUPING(v1)) FROM (VALUES ((SELECT 1))) v(v1) GROUP BY v1;
ERROR:  plan should not reference subplan's variable

以前のコーディングでは、返却可能な列に加え、返却不可能な列も読み取ろうとする可能性がありました。 これは実際には無効な値に対して何も行わなかったためおよそ無害でしたが、最近追加されたエラーチェックでそのようなプランを拒否して、下記のエラーメッセージを出していました。

ERROR:  XX000: variable not found in subplan target list

EvalPlanQual は READ COMMITTED 隔離レベルの問い合わせにおける内部的な処理です。

従来コードはピンを解放した後、さらに数回バッファにアクセスしていました。理論的には別プロセスがピンがなくなった時点ですぐにバッファを再利用し（あるいは、より可能性が高いのは、その空き領域をデフラグしようとし）、タプルの新しいバージョンを見つけるのに失敗する可能性があります。

一つの ALTER FUNCTION コマンドで関数の「SET」句も更新した場合、並列性属性の変更が失われていました。

（誤動作例／「PARALLEL safe」を指定したので proparallel は 「s」が正しい）
db=# CREATE FUNCTION public.f14() RETURNS int LANGUAGE sql AS 'SELECT 1';
db=# ALTER FUNCTION public.f14() SET timezone TO 'UTC' PARALLEL safe;
db=# SELECT proname, proparallel, proconfig FROM pg_proc WHERE proname = 'f14';
 proname | proparallel |   proconfig
---------+-------------+----------------
 f14     | u           | {TimeZone=UTC}
(1 row)

一部のコードパスで、外部キー制約が依存しているインデックスを、ユニーク制約または主キー制約によって所有されているインデックスと取り違えていました。その結果、外部キー制約を持つテーブルに対する特定の ALTER TABLE 操作に際して、下記のような奇妙なエラーが発生していました。

 ERROR:  relation 145678 has multiple clustered indexes 
または
 ERROR:  "t15_pkey" is not an index for table "t15" 

システムは「ERROR: cannot alter system column "cmax"」などと、それができないことを通知するべきですが、代わりに「ERROR: no owned sequence found」を報告する場合がありました。

テーブルは正しいデータで再構築されますが、インデックスの順序とはほとんど関係のない順序になりました。

ソートを使用して GiSTインデックスを構築するコードパスは、完了時にファイルの fsync を怠っていました。このため、その後すぐにオペレーティングシステムがクラッシュした場合、インデックスが破損する可能性がありました。

必要なテーブルとインデックスのロックが確実に標準的な順序（子の前に親、インデックスの前にテーブル）で取られるようになりました。DROP INDEX の以前のコーディングでは、これとは異なる方法でロックを取っていたため、標準的な順序でこれらのロックを取る同時実行の問い合わせに対してデッドロックが発生する可能性がありました。

DROP TABLESPACE によって強制されるチェックポイントが、テーブルスペースのディレクトリからすべてのデッドファイルを削除することに失敗して、以下のような偽のエラーが発生する場合がありました。

ERROR:  tablespace "tblspc20" is not empty

チェックポイントが完了できるようになる前に、テーブルのディスクファイルが全削除されることをTRUNCATE は保証しなければなりません。そうでないと、そのチェックポイントから開始したリプレイが、削除されているはずのページの予期せぬデータを見つけて、リプレイ失敗を引き起こすおそれがありました。

サーバプロセス終了時に「FATAL: cannot fetch toast data without an active snapshot」のエラーを出して、一時オブジェクトの削除に失敗することがありました。次に一時スキーマを使う際に正常にクリーンアップされるため、通常は無害です。

バージョン14 ではそのような名前が意図せず使えなくなってしまっていました。

これはリグレッションテストを容易にすることを目的としており、クエリID が計算されるけれども EXPLAIN の出力には表示されません。

RegisterSyncRequest は局所的にストレージ同期の要求を受け付けたり、要求を checkpointerプロセスに転送したりする、内部実装関数です。

その中で checkpointer への同期要求キューが溢れた場合（shared_buffers が小さい場合に起こりえます）、その待ち行列が減るのを待つ動作をします。このときの待機を示す待機イベント「RegisterSyncRequest」が追加されました。

これは同期リクエストを送信するバックエンドの反応性を改善します。更にこの待機に対応した待機イベント「CheckpointerWriteDelay」も追加されました。

不運なタイミングのとき、WAL を適用するプロセスが他プロセスのバッファロックの解放を待って、動作が止まってしまう可能性がありました。

publish_via_partition_root オプションが true に指定されていて、更新するリレーションに対する異なる先祖で指定された複数のパブリケーションがある場合（即ち親子関係にあるリレーション各々にパブリケーションを作っている場合）、サブスクリプションへの変更の報告に際して間違った先祖リレーションを選択することがありました。

本設定に対する上限検査コードの欠陥により、これまでは再起動されたワーカを直ぐに終了してしまっていて、ほとんどのワーカが存続できませんでした。

この対処をしないと、サブスクライバはその値を見ることができないので、更新を正しく複製できないことになります。

このようなプラットフォームはほとんどありません。そのため、これまでリファクタリングが潜在的なメモリ破壊をもたらすことに気づかれませんでした。サポートされているプラットフォームで該当する唯一のものは Cygwin で、バックエンドプロセスのクラッシュが報告されました。

バージョン14 で追加された最適化は、なんらかの理由でサーバプロセスがタイマ割り込みを逃してしまった場合は他についてもカーネルに要求を繰り返さないというもので、セッションの以降においてタイムアウト検出に失敗することになりました。

これでは脆弱すぎると判断され、リカバリパスが追加されました。

PL/Perl関数のコンパイル時には Perl はユーザ定義コードを実行すると考えられます。しかしながら、SPI 経由の SQL操作を行うコードは望ましくなく、クラッシュかセキュリティ障害を起こす可能性がありました。関数の検証に際して本当にコード実行をしたいわけではありません。そこで、代わりに親切なエラーメッセージを出す検査が加えられました。

この変更により、libpq の SSL鍵ファイルの所有者とアクセス許可の安全チェックが、バージョン9.6 以降のサーバと統一されます。すなわち、現在のルールに加え、鍵ファイルの所有者が root であって、パーミッションが 0640 以下の場合を許容するようになりました。これは、鍵ファイルのシステム全体での管理に役立ちます。

書き込みエラーを検出した場合、PQisBusy() は常に真を返しましたが、これは誤りでした。サーバから何か読み取れるまで、通常は入力処理を継続したいところでした。

この障害の実際の影響は、libpq の非同期クエリAPI を使用するアプリケーションが、PQconsumeInput() が致命的なエラーを返した場合にしか接続断を検出しないことです。この修正により、接続断が順当にエラーの PGresult オブジェクトを介して報告されるようになりました。これはほとんどのアプリケーションにとって相応しい動作です。

14 より前のバージョンは、2つ以上の「.」を含むパターンにおけるスキーマとテーブル以外の全ての修飾名を黙って無視していました。バージョン14 でのリファクタリングの誤りで、そのユースケースがエラーになるようになってしまいました。本バージョンで復活しましたが、先頭の修飾名がカレントデータベースの名前と一致しない場合にはエラーが発生します。

（バージョン 14.2 で以下エラー／13.x 以前と 14.3 以降では実行可能）
db1=# \d db1.public.t1
Did not find any relation named "db1.public.t1".

（バージョン14.3 で以下エラー／13.x 以前では実行可能）
db1=# \d foo.bar.public.t1
improper qualified name (too many dotted names): foo.bar.public.t1

pg_ctl は、stop または promote シグナルを送信する一方で postmasterプロセスが動作していること（PID が有効であるか）を 1回確認しますが、その後は単純に PIDファイルが削除されるまで待機していました。postmaster が PIDファイルを削除したり、制御ファイルを更新したりせず、非正常に終了した場合、pg_ctl はタイムアウトになるまで待機していました。

これに替えて postmasterプロセスがまだ存在しているかをときどき再チェックするようになりました。

WALセグメントサイズを知るために WALファイルを読み取ったとき、ファイルサイズが XLOG_BLCKSZ よりも小さい場合（例えば 0バイト）、pg_waldump は誤ったエラー報告をしていました。また、このエラーメッセージおよび関連するエラーメッセージで報告されるファイル名は無効である可能性がありました。

（報告された誤ったメッセージ／正しくないファイル名や要因が示される）
pg_waldump: fatal: could not read file ".....": .....

これは正当な境界条件的ケースでしたが、このモジュールではほぼ想定されていませんでした。必要に応じて、NULL を返すか、行を返さないように変更されました。これは、エラーを発生させるよりも有効です。

これらの変更により、モジュールが不良データでクラッシュする可能性が低くなりました。

このようなトリガはテーブルを照会する際、手前で挿入した行を参照するかもしれません。バッチ挿入では、これらの行がまだ可視となってない可能性があるため、予期せぬ動作を回避するため、無効にされました。

この修正はリモートサーバが意図と異なる順序で並べ替えるケースを防止します。これは見た目だけの場合もありますが、リモートデータがローカルで実行されるマージ結合の入力として使用されると、完全に間違った結果が生じる可能性がありました。

これらの変更のほとんどは、C および POSIX 標準の文書に型通りに準拠するためのものであり、本番ビルドに影響を与える可能性はほとんどありません。

mingw の gcc によるビルドで問題が報告されました。

これにより、ビルドプロセスが最新の MSys ツールチェーンで機能するように調整されました。

何らかの理由で、MinGW によって提供される Cライブラリは、デフォルトでプログラムのコマンドライン引数のシェルワイルドカード文字を展開してしまいます。MSVC では特に発生しないため、これは混乱を招くのでパターン展開が無効化されました。

バージョン13 以降のサーバは、パーティションテーブルのパブリッシュがサポートされるようになりました。バージョン13 より古いバージョンのサーバは、パーティションテーブルのサブスクライブを処理できず、「table ... not found on publisher」のような誤解を招くエラーメッセージを表示していましたが、より的確なメッセージを表示するように修正されました。