結合を伴う一部のケースで、問い合わせで読み込まれた全ての列をパーサが権限検査に使う使用列ビットマップに記録することに失敗していました。エグゼキュータは問い合わせ実行のためにいくつかの種類の SELECT権限を依然として要求するものの、これはテーブルの一列にのみ SELECT権限を持ったユーザが、工夫をこらした問い合わせを通して全ての列を読むことができることを意味します。

本問題に該当する問い合わせの格納されたビューは、不完全な使用列ビットマップを持ちます。そのため、アップデート後でもビューに適切なパーミッションが強制されません。セキュリティが列単位のアクセス制御に依存したインストレーションでは、全てのユーザ定義ビューに「CREATE OR REPLACE ...」を実行し直して、再パースさせることが推奨されます。(CVE-2021-20229)

UPDATEコマンドで異なるパーティションに行を移動しようとして、宛先パーティションでの何らか制約違反になって、かつ、そのパーティションの列が親テーブルと異なる物理位置である場合、エラーメッセージにユーザが SELECT権限を持たない列の内容が露出する可能性がありました。(CVE-2021-3393)

同時挿入により、誤ったページにエントリが配置されるインデックス破損が起きる可能性がありました。バージョンアップ後、同時挿入をしたかもしれない全ての GiSTインデックスを再作成をすることが推奨されます。

CREATE INDEX CONCURRENTLY が全ての同時実行トランザクションで挿入した行が可視になるようにそれらが完了するのを待機する箇所で、同じく全ての準備されたトランザクションが完了するのも待機しなければなりませんでした。これを行っていなかったことで、準備されたトランザクションにより挿入された行が新たなインデックスから無視されて、インデックスを使った問い合わせでそのような行が取りこぼされて、誤った問い合わせ結果が生じる可能性がありました。

プリペアドトランザクションを使っているインストレーション（max_prepared_transactions が 1以上）では、本障害が起きている場合に備えて、全ての同時作成したインデックスを REINDEX することが推奨されます。

（クラッシュが生じるプラン形状の例）
db=# CREATE TABLE t5 (i int, j int);
db=# INSERT INTO t5 SELECT g/10, g FROM generate_series(1,40) g;
db=# explain (costs off) SELECT * FROM (VALUES (1),(2)) v(a),
       LATERAL (SELECT v.a, i, j, count(*) FROM t5 GROUP BY cube(i,j)) s
       ORDER BY v.a, i, j;
                 QUERY PLAN
--------------------------------------------
 Sort
   Sort Key: "*VALUES*".column1, t5.i, t5.j
   ->  Nested Loop
         ->  Values Scan on "*VALUES*"
         ->  MixedAggregate
               Hash Key: t5.i, t5.j
               Hash Key: t5.i
               Hash Key: t5.j
               Group Key: ()
               ->  Seq Scan on t5
(10 行)

タプルが読み戻されたときに、集約のグルーピング値が NULL に置き換わる可能性があって、誤った問い合わせ結果につながりました。

ソートバッチの最後のタプルが偶然に既にソート済みの次グループの最初のタプルになった場合、これまでのコードは誤動作しました。これは「ERROR: retrieved too many tuples in a bounded sort」エラーか、エラー無しに誤った問い合わせ結果をもたらします。

PostgreSQL 13.x では、本ケースで確実に NULLポインタ参照が起きます。PostgreSQL 12.x、11.x では目に見える症状は現れないようですが、問題が決して起きないとは言えません。

以下を拡張問い合わせとして実行して、クラッシュする動作が報告されました。

 DO $$ BEGIN ROLLBACK; END $$;

行を変更した BEFORE UPDATE FOR EACH ROW トリガーは、何であれ、UPDATE が行を他パーティションに移動するのを妨げました。しかし、この制限をもうける必要がもはやありませんでした。

本状況でこれからは以下のエラーが発生しなくなります。

ERROR: moving row to another partition during a BEFORE trigger is not supported

ハッシュパーティションテーブルがサイズの異なるパーティション（即ち一様でない法の値）を持っている場合、あるいは、一部の残余の値に対してパーティションが欠けている場合、プランナの除外ロジックが除外可能なパーティションについて誤判断して、在るべき行が欠けた誤った問い合わせ結果が生じる可能性がありました。

このケースは本来サポートされません（一般に ORDER BY を使ったカーソルが必ず更新可能となることは保証されません）。しかしながら、これまでの実装では拒絶しておらず、エラー無しに誤った問い合わせ結果（誤った更新）が生じる可能性がありました。

これは特に外部結合の出力に対する LATERAL参照を含む副問い合わせで発生します。この誤りにより異常な形状のプランが生じるおそれがありました。報告されているケースでは「ERROR: failed to assign all NestLoopParams to plan nodes：...」が生じましたが、それ以外の症状になる可能性もあります。

以下の形状の SQL で上記エラーが生じる動作が報告されました。

SELECT t13u.znum, g.v
  FROM t13u
  LEFT JOIN t13b on t13b.txt ~ 'xxx'
  LEFT JOIN LATERAL (SELECT regexp_replace(t13b.txt, 'xxx', '')::int v)
    AS g ON true
  LEFT JOIN t13r WHERE t13r.bnum = g.v;

RESULT RTE とは問い合わせの結果出力で使うリレーションを意味します。

この誤りにより、「ERROR: no relation entry for relid N」（Nは数値）というエラーが生じる可能性がありました。

（本障害を発生させる SELECT文の例）
 SELECT z, a, b FROM (SELECT 0 AS z) AS t1
   LEFT JOIN (SELECT true AS a) AS t2 ON true,
   LATERAL (SELECT true AS b UNION ALL SELECT a AS b) AS t3 WHERE b;

この誤りにより「ERROR: failed to build any N-way joins」（Nは数値）というプランナのエラーが生じる可能性がありました。

結合に LATERAL参照を使っている場合に発生が報告されました。

明示的に Sortノードを加えることでこのようなパスの使用は可能で、一部のケースではより優れたプランを生み出します。

この場合、安全にワーカプロセスにプッシュすることはできませんが、インクリメンタルソート機能で誤ってこれらをプラン候補に含めてしまっていました。本障害でバックエンドプロセスのクラッシュが報告されています。

これは稀なケースでサポート関数が欠けていることによるエラーを防止します。

GiSTインデックスを使った Merge Join でエラー「ERROR: function ammarkpos is not defined for ...」が生じる動作が報告されました。

同コマンド内の重複したロール名やスキーマ名は、「ERROR: tuple already updated by self」エラーやユニーク制約違反をもたらす可能性がありました。

この変更により、ALTER ROLE ... [NO] INHERITの結果が迅速に反映されて権限判定が行われるようになります。

この不具合は、wal_level が minimal に設定された状態で、テーブルがALTER TABLE SET TABLESPACE で書き換えされていた場合でのみ発生します。 問い合わせで「ERROR: snapshot too old」が報告されない可能性がありました。

「ERROR: cannot access temporary or unlogged relations during recovery」や「ERROR: table ... cannot be replicated」が出る可能性がありました。この不具合は、wal_level が minimal に設定されている場合のみ発生します。 したがって、以下の警告が出るべきでした。「WARNING: wal_level is insufficient to publish logical changes」

CREATE TABLE ... LIKE ではテーブルを新しく作成した後、インデックスなどの取り込みを処理するために、LIKE句の再検査をします。この再検査で同じ名前の別のテーブルが見つかり、予期しない動作が発生する可能性がありました。一例として、新しく作成されるテーブルが、LIKE の対象と同じ名前の一時テーブルである場合が挙げられます。

（以下を実行すると主キーインデックスの無い s24.t24 が作られてしまいます）
db=# CREATE TABLE public.t24 (id int PRIMARY KEY);
db=# BEGIN;
db=# CREATE SCHEMA s24;
db=# SET LOCAL search_path TO s24, public;
db=# CREATE TABLE t24 (LIKE t24 INCLUDING ALL);
db=# COMMIT;

これにより、CREATE TABLE で宣言された自己参照外部キー制約が、LIKE句によるインデックスに依存するケースが修正されました。

以下のような SQL が以前は動作していたものが、直近のマイナーバージョンからエラーになることが報告されました。

db=# CREATE TABLE t25_base (id int PRIMARY KEY);
db=# CREATE TABLE t25_inherited (
       LIKE id_base INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES,
       self_ref_if INT,
       FOREIGN KEY (self_ref_if) REFERENCES t25_inherited (id)
   ) INHERITS (t25_base);
ERROR:  there is no unique constraint matching given keys for referenced table "t25_inherited"

ただし、allow_system_table_mods = on であれば引き続き作成可能です。

元々、ビューをテーブルの継承ツリーに加える操作は禁止されています。このような変換を含む継承ツリーに対する問い合わせでエラーやクラッシュが生じる可能性がありました。

db=# CREATE TABLE t27a (id int);
db=# CREATE TABLE t27b (id int);
db=# CREATE TABLE t27c () INHERITS (t27a);

(通常のテーブルは CREATE RULE でビューに変換できます)
db=# CREATE RULE "_RETURN" AS ON SELECT TO t27b DO INSTEAD SELECT id FROM t27a;

(継承の子テーブルはビューに変換できなくなります)
db=# CREATE RULE "_RETURN" AS ON SELECT TO t27c DO INSTEAD SELECT id FROM t27a;
ERROR:  could not convert table "t27c" to a view because it has child tables

これまでは、そのテーブルやインデックスが複数セグメントにわたっている場合に、先頭セグメントだけは即座にサイズゼロになりますが、残りのセグメントは単純にファイル削除を行っていたため、他のバックエンドがファイルオープンしている間はディスクスペースが解放されませんでした。

以前は削除できましたが、パーティション化されたリレーションに対して、その後に行われる操作が失敗しました。 クラッシュが生じるケースが報告されています。

pg_stat_progress_cluster の heap_blks_scanned列の値が誤っていました。

これまではバックスラッシュとそれに続くマルチバイト文字は正しく処理されませんでした。一部のクライアント文字エンコーディングでは、この影響によりマルチバイト文字の一部がフィールドセパレータまたはコピーデータの終わりを表すマーカーとして、誤って解釈される可能性がありました。

実際の問い合わせ実行はしないので不要な動作でした。

新しく LISTEN しているバックエンドが、切り捨てられている途中の SLRU ページを読み取ろうとして、エラーが発生する可能性がありました。

「WARNING: NOTIFY queue is NN% full」（NNは数値）や、「ERROR: too many notifications in the NOTIFY queue」が生じます。

2つの JSONオブジェクト、または 2つの JSON配列を連結できるようになりました。配列以外のオブジェクトを 1要素の JSON配列でラップした後、JSON配列の連結を実行することにより、すべての組み合わせを処理できるようになりました。

修正以前は、オブジェクト結合のいくつかの組み合わせは、この方式で結合されていましたが、その他の組み合わせはエラーになりました。

この不具合により、「*」数量詞が完全な正規表現(ARE)で実行された最短マッチの動作、すなわち「*?」のように動作する可能性があります。

「^」演算子も同様に該当します。

(報告された誤動作例、2行目の pow は正しくは 0.7678656556403084 )
db=# SELECT n, 1.000000000123^n AS pow FROM (VALUES (-2147483647), (-2147483648), (-2147483649)) AS v(n);
      n      |        pow
-------------+--------------------
 -2147483647 | 0.7678656557347558
 -2147483648 | 1.0000000000000000
 -2147483649 | 0.7678656555458609
(3 rows)

引数に指定された開始インデックスと長さを加算して、整数のオーバーフローが発生した場合、誤動作を引き起こしていました。「ERROR: negative substring length not allowed」が生じるか、あるいは、エラーは出ずに単に文字列全体が返されました（大部分のケースはこちらです）。

通常、周回点にはページの半ばで到達し、これをページの境界に丸める必要がありましたが、正しく行われていませんでした。データベースクラスタが SLRUオーバーフローまでの 1ページ以内に到達しない限り、この問題は発生せず、適切に機能しているシステムで起こる可能性は低いです。

この問題が発生した場合、後の「apparent wraparound」を含むログメッセージや「ERROR: could not access status of transaction」のエラーで顕在化します。「LOG: could not truncate directory "pg_xact": apparent wraparound」が出るケースが報告されました。

以前は、WALアーカイブが有効になっていると、スタンバイが新しいタイムラインで実行されているプライマリを追跡できず「ERROR: requested WAL segment ... has already been removed」などのエラーが発生する可能性がありました。

pg_basebackup 実行時にアサート失敗が生じる問題が報告されました。

startupプロセスはデッドロックの検出処理を行っていないため、startupプロセスが最後に循環待機に参加した場合は、デッドロックが検出されない可能性がありました。

以前は HOTチェインを辿るのに失敗して古すぎるトランザクションID限界を計算してしまい、ホットスタンバイでリカバリ競合を誤って処理する可能性がありました。ほとんどの場合、正しいトランザクションID限界は HOTチェインを調べなくとも取得できるため、このバグによる影響は限定的です。

以前は、どちらの設定が優先されるかはクライアントが GSS暗号化を要求するかによって異っていました。

hostgssenc または hostnogssenc のエントリが存在する場合は関連データがログメッセージに含まれます。

GSS暗号化接続では GSS認証しか使用できないという無意味な制限が解除されました。GSS暗号化情報が接続認証時のログメッセージに追加されました。

共有メモリの必要サイズを計算するときに GSS暗号化関連の領域を含めるようになりました。以前は max_connectionsパラメータの値を非常に大きくした場合に問題が発生する可能性がありました。

復旧不能な GSS暗号化エラーを報告するときの無限再帰が回避されました。

以前は、停止直前にバックグラウンドワーカを要求したプロセスが無限に待機し、停止が完了しなくなる競合状態が発生していました。

指定されるトランザクションID はエポックを含めて 64ビット幅になりえますが、strtoul() 関数で解析されていたため、long型が 32ビットのプラットフォーム（Windows など）で不正な値としてエラーが発生していました。

backend> SET log_min_messages TO debug5;
backend> CREATE INDEX ON t (c);

(修正前)
DEBUG:  building index "t_c_idx" on table "t" with request for 2 parallel workers

(修正後)
DEBUG:  building index "t_c_idx" on table "t" serially

FIPSモードの OpenSSLを使用する場合、SHA256ハッシュは拒否され、エラーが発生します。エラーを解消するには EVPハッシュへの書き換えが必要ですが、マイナーリリースでは互換性を維持するためにできません。この修正により、--no-manifest オプションを指定すれば、そのような場合でもベースバックアップを取得できます。

そのような集約関数は PostgreSQL本体には存在しませんが、PostGIS などの一部の拡張では提供されています。いずれにしてもアサートを有効にしたビルドでなければ影響はありません。

pg_get_functiondef() は psql で関数定義を出力するときなどに使われます。

（他に以下のようなフォーマットの乱れも生じました）
db=# CREATE FUNCTION f(bool) RETURNS void AS $$
   $$ LANGUAGE plperl TRANSFORM FOR TYPE bool;

（修正前）
db=# \sf f
CREATE OR REPLACE FUNCTION public.f(boolean)
 RETURNS void

 TRANSFORM FOR TYPE boolean LANGUAGE plperl
AS $function$
$function$

（修正後）
=# \sf f
CREATE OR REPLACE FUNCTION public.f(boolean)
 RETURNS void
 TRANSFORM FOR TYPE boolean
 LANGUAGE plperl
AS $function$
   $function$

以前はプロシージャ内で INOUT引数を持つ別のプロシージャを呼び出すと、呼び出し先で COMMIT または ROLLBACK 文を実行した場合にエラーになりました。

（障害動作例）
db=# CREATE PROCEDURE p1(INOUT a int) LANGUAGE plpgsql AS $$
       BEGIN COMMIT; a := 1; END; $$;
db=# CREATE PROCEDURE p2() LANGUAGE plpgsql AS $$
       DECLARE a int := 2;
       BEGIN CALL p1(a); END; $$;
db=# CALL p2();
ERROR:  unsupported target type: 0
CONTEXT:  PL/pgSQL function p2() line 5 at CALL

以前は GSS暗号化接続を確立した後、認証中に失敗した場合、SSL暗号化接続を試すことなく、非暗号化接続にフォールバックしていました。これにより、予期しない接続エラーが発生したり、暗号化が期待される場所で黙って暗号化されていなかったりする可能性がありました。

以前は NULL を返していました。

以前は機能していましたが、最近のバグ修正でパスワード指定が無視され、パスワード入力が求められるようになっていました。

以前は、128 文字で勝手に切り捨てられていました。

=# CREATE TABLE t (c text DEFAULT '1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890');
CREATE TABLE

(修正前)
=# \d t
                                                                            Table "public.t"
 Column | Type | Collation | Nullable |                                                             Default
--------+------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------
 c      | text |           |          | '1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567

(修正後)
=# \d t
                                                                                 Table "public.t"
 Column | Type | Collation | Nullable |                                                                  Default
--------+------+-----------+----------+--------------------------------------------------------------------------------------------------------------------------------------------
 c      | text |           |          | '1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890'::text

以前は引数が複数の単語からなる場合に最初の単語を使ってヘルプが見つけられませんでした。例えば、\help RESET ALL で RESET文のヘルプを表示できませんでした。また、必要な場合にページャを呼び出せないことがよくあり、メモリリークも発生していました。

(修正前)
db=# \help RESET ALL
No help available for "RESET ALL".
Try \h with no arguments to see available help.

(修正後)
db=# \help RESET ALL
Command:     RESET
Description: restore the value of a run-time parameter to the default value
Syntax:
RESET configuration_parameter
RESET ALL

URL: https://www.postgresql.org/docs/13/sql-reset.html

以前の動作ではリストア時に無害ですが余計なエラーが発生していました。

（該当するテーブル定義例）
CREATE TABLE t61p (c1 int, c2 int GENERATED ALWAYS AS (c1 * 2) STORED);
CREATE TABLE t61c () INHERITS (t61p);

（リストア時のエラー例）
pg_restore: from TOC entry 3432; 2604 33854 DEFAULT t61c c2 postgres
pg_restore: error: could not execute query: ERROR:  column "c2" of relation "t61c" is a generated column
Command was: ALTER TABLE ONLY public.t61c ALTER COLUMN c2 SET DEFAULT (c1 * 2);

（11.x 以降バージョンでは）同様に ALTER INDEX ATTACH PARTITION コマンドもパーティションインデックスの所有者として実行するようになりました。

以前は、これらのコマンドはリストアスクリプトを開始したロールによって実行されていました。これらは通常動作しますが、場合によってはそのロールが十分な権限を持っていない可能性がありました。

拡張のスクリプトがオブジェクトを作成し、そのオブジェクトに GRANT OPTIONで権限を付与した場合、後にユーザがそのような権限を取り消すとpg_dump はその状況を再現するために誤ったSQLを生成してしまいます。

ただし、この誤動作に該当する拡張は今日ほとんどありません。

巻き戻しが必要であるときに、巻き戻し不要と判断するケースがありました。

これにより、変数を「12:34」のような文字列を含むタイムスタンプのリテラル値に代入しようとする動作を防ぎます。

データベース名がコマンドラインで指定されるのではなくデフォルトで設定されていた場合、pg_dumpall、pgbench、oid2name、vacuulo は、接続失敗後に誤解を招くエラーメッセージを出力していました。

（データベース名が空欄のエラーメッセージ例）
[user1@host1 ~]$ pgbench
pgbench: error: connection to database "" failed: FATAL:  role "user1" does not exist

EXPLAIN 出力を生成中に消費されたメモリは、現在のトランザクションが終了するまで(最上位の文の場合)、または周囲の文が終了するまで(入れ子になった文の場合)解放されませんでした。これは log_nested_statements が有効な場合に特に問題でした。

これからは削除されたユーザーマッピングや外部サーバに依存する接続は切断されて参照できなくなります。以前はローカルセッションの間は何であれ維持されていました。

実際にはここでエラーは発生しないと考えられますが、この変更により静的分析ツールからの警告が表示されなくなりました。

以前は、autoprewarm はこれまでにロードできたブロック番号のみでステータスファイルに書き換えていました。そのため、次回の起動時にプレウォーム機能が大幅に無効化されてしまう可能性がありました。本修正により、最初のロードパスが完了するまでステータスファイルの更新を抑制するようになりました。

contrib/pg_prewarm の autoprewarm 親プロセスのメインループは、望ましいスリープ時間を 1000分の 1 に過小評価しており、意図したよりもはるかに多くの CPUを消費していました。リモートサーバからの結果を待つ場合、contrib/postgres_fdw は、希望するタイムアウト時間を 1000倍に過大評価していました。（ただしこの誤りは 60秒の上限を設けていたことで軽減されていました）

これらのエラーはどちらも、秒とマイクロ秒をミリ秒に誤って変換することに起因していました。新しい API TimestampDifferenceMilliseconds() を導入して、将来的にこれをより簡単に正しく取得できるようにしました。

この新しい方式により、Xcode が基盤となるオペレーティングシステムよりも新しい場合に、望ましい結果が得られる可能性が高くなります。OS のバージョンと一致しない sysroot を選択すると、実行可能ファイルが機能しなくなるかもしれません。

これにより、Xcode がオペレーティングシステムと同期していない場合の結果も同様に改善されます。

これに起因する障害報告は確認されていませんが、一部のアーキテクチャでは問題が発生する可能性がありました。

このような呼び出し自体が問題を引き起こすことは知られていませんが、一部のコンパイラは memcpy() の引数が決して NULL ではないと仮定しているため、近くのコードが正しく最適化されない可能性があります。

ロシア（ボルゴグラードゾーン）と南スーダンでの夏時間法の変更に加えて、オーストラリア、バハマ、ベリーズ、バミューダ、ガーナ、イスラエル、ケニア、ナイジェリア、パレスチナ、セーシェル、バヌアツの歴史的修正が含まれます。

特に、Australia/Currie は、Australia/Hobart と同じになるように修正されました。

ソースコード内の定数値が変更されました。

新たに LISTEN しているバックエンドが、切り捨てられている途中のSLRUページを読み取ろうとして、エラーが発生する可能性がありました。

キューの末尾ポインタがバックエンドのキュー位置と等しくない値に設定される可能性があり、その結果、キュー切り捨てロジックが実際には無効になります。その後 NOTIFY の継続的な使用は、キューがいっぱいの警告を発生させ、最終的にはサーバが再起動されるまで NOTIFY を送ることができなくなりました。

これらはアクセス制限の仕組みの抜け穴となっていて、テンポラリでない SQLオブジェクトを作る権限を持った攻撃者はスーパーユーザとして任意の SQL実行が可能でした。(CVE-2020-25695)

これからは該当する操作について、それぞれ以下のエラーが生じます。

ERROR:  cannot create a cursor WITH HOLD within security-restricted operation

ERROR:  cannot fire deferred trigger within security-restricted operation

pg_dump と pg_restore の -d パラメータや他コマンドの --maintenance-db パラメータには、単一のデータベース名ではなく、複合的な接続パラメータを含む接続文字列を与えることもできます。

これらのコマンドが、並列処理や複数データベース処理などで、追加的な接続を開始する必要がある場合、指定した接続文字列が無視されて、通常の接続パラメータ（データベース名、ホスト、ポート、ユーザ名）が使われていました。

デフォルトと異なる SSL や GSS のパラメータなど、接続文字列に何らか重要な情報が含まれている場合、この振る舞いのために接続失敗が生じる可能性がありました。さらに悪いことに、接続は成功するけれども意図通りに暗号化されていないというセキュリティ上の危険を伴う動作もあり得ました。(CVE-2020-25694)

（以下コマンドで --jobs 指定があるとき失敗するという発生例が報告されました）
$ pg_dump --dbname="sslmode=verify-ca sslrootcert=server-ca.pem \
   sslcert=client-cert.pem sslkey=client-key.pem \
   hostaddr=1.2.3.4 user=postgres dbname=app" \
   --format=directory --file=dump.dat --jobs=3 

これまでは、デフォルトでない SSL や GSS のオプションなどのパラメータが無視されて再接続に失敗することがありました。さらに悪いことに、再接続は成功するけれども意図通り暗号化されず、セキュリティ上の危険を伴う動作もあり得ました。(CVE-2020-25694)

PROMPT1 などのプロンプトの変数にはコマンド実行結果を含めることができるため、安全でないサーバから意図せぬ SQL実行結果が返ることで、クライアント側で任意のシェルコマンドが実行されてしまう危険がありました。(CVE-2020-25696)

（特別に扱われる変数を上書きしてしまう動作例）
db1=# SELECT 'off' as "AUTOCOMMIT", '%`hostname`> ' as "PROMPT1"; \gset
 AUTOCOMMIT |    PROMPT1
------------+---------------
 off        | %`hostname`>
(1 row)

host1> \echo :AUTOCOMMIT
off
host1>

13.0 以降で wal sender は START_REPLICATION に対してコマンド完了イベントを二つ報告します。これはドキュメントに記載されておらず、明らかに意図されたものではありません。しかしながら、wal receiver が一部のコードパスで余分なイベントを必要とすることが判明したため、二つのコマンド完了イベントが返る動作を正として修正され、そのようにドキュメント記載されました。

これは OS のクラッシュによるデータ損失を防止します。SLRUディレクトリとして、トランザクション制御に使われる pg_xact (pg_clog)、pg_commit_ts、pg_subtrans、共有行ロック制御に使われる pg_multixact などが該当します。

BYPASSRLS属性の変更はスーパーユーザによってのみ行えます。しかし、パスワード変更など、他の ALTER ROLE操作は、通常のパーミッション検査によって許可されるべきです。これまでは誤って、BYPASSRLS属性を持ったユーザに対するすべての変更にスーパーユーザ権限が必要となっていました。

（修正前の動作例： BYPASSRLS属性があると自身のパスワード変更に失敗）
db1=# ALTER ROLE foo BYPASSRLS;
ALTER ROLE
db1=# \c db1 foo
You are now connected to database "db1" as user "foo".
db1=> ALTER ROLE foo PASSWORD 'newpass';
ERROR:  must be superuser to change bypassrls attribute

これは生成列を通常の列にするコマンドですが、現在の実装では子テーブルに対して正しく処理できないため、当面は単にこれを禁止することになりました。

これまで ONLYフラグが無視されていました。

これまでは無限再帰を理由としたエラー(ERROR: infinite recursion detected ...)が出ていましたが、禁止する実装上の理由はありませんでした。定義可能な自己参照ビューの pg_dump に失敗する問題が報告されていました。

これは CONCURRENTLY ではない通常の REINDEX と同じ動作です。

pg_stat_progress_create_index ビューに異なるテーブルやインデックスのOID が現れる動作が報告されました。

以下のような定義のテーブルとビューに対して、

CREATE TABLE t13 (id serial, idplus1 int GENERATED ALWAYS AS (id + 1) STORED);
CREATE VIEW v13 AS SELECT * FROM t13;

以下のような更新に失敗する場合が報告されました。

UPDATE v13 SET id = 1000 WHERE id = 1;

更新可能ビューを通した更新による列指定トリガの駆動に失敗する可能性もあり、本修正はこちらにも対応しています。

以下のように照合順序（COLLATE）によって結果が変わる式を指定すると、これまではエラーになっていました。これからは、定義時点のデフォルト照合順序で境界条件の式が評価されるようになります。

（従来の動作例）
db1=# CREATE TABLE pt14 (b boolean, v text) PARTITION BY LIST (b);
db1=# CREATE TABLE pt14_1 PARTITION OF pt14 FOR VALUES IN ('foo' < 'bar');
ERROR:  could not determine which collation to use for string comparison
HINT:  Use the COLLATE clause to set the collation explicitly.

配列要素が照合順序に影響を受ける場合に配列のハッシュ作成が失敗していました。特に、テキスト配列の列をキーとしたハッシュパーティショニングの利用を妨げていました。

これまでは以下のように行を挿入した時点でエラーが発生していました。これからはデフォルトの照合順序が適用されてエラーが回避されます。

db1=# CREATE TABLE pt15 (ta text[], v text) PARTITION BY HASH (ta);
db1=# CREATE TABLE pt15_0 PARTITION OF pt15 FOR VALUES
        WITH (MODULUS 2, REMAINDER 0);
db1=# CREATE TABLE pt15_1 PARTITION OF pt15 FOR VALUES
        WITH (MODULUS 2, REMAINDER 1);
db1=# INSERT INTO pt15 VALUES (ARRAY['abc'], 'val1');
ERROR:  could not determine which collation to use for string hashing
HINT:  Use the COLLATE clause to set the collation explicitly.

date型と timestamp型の比較で、date型の値が timestamp の有効範囲を超える場合にエラーが生じていました。また、timestamp型 と timestamptz型の比較で、タイムゾーンを適用すると有効範囲を超える場合にもエラーが生じていました。

型キャストできない場合でも正しく比較ができるように修正されました。

（修正前の動作: 修正後はいずれも true が返ります）
db1=# SELECT '2202020-10-05'::date > '2020-10-05'::timestamp;
ERROR:  date out of range for timestamp
db1=# SET TimeZone = 'UTC-2';
db1=# SELECT '4714-11-24 BC'::date < '2020-10-05'::timestamptz;
ERROR:  date out of range for timestamp
db1=# SELECT '4714-11-24 BC'::timestamp < '2020-10-05'::timestamptz;
ERROR:  timestamp out of range

また、マイナス年と明示的な BC指定は打ち消し合って、紀元後の年になります。このことがドキュメントにも明記されました。

（誤動作例: 正しくは「0001-01-01 BC」）
db1=# SELECT to_date('-1-01-01','yyyy-mm-dd');
    to_date
---------------
 0002-01-01 BC
(1 row)

（誤動作例: 修正後はマイナス年と BC が打ち消し合って紀元後の年になる）
db1=# SELECT to_timestamp('-44-02-01 11:12:13 BC', 'YYYY-MM-DD HH24:MI:SS BC');
          to_timestamp
---------------------------------
 0045-02-01 11:12:13+09:18:59 BC
(1 row)

これは SQL標準では必須ではありませんが、to_json() 関数は Javascript互換のtimestamp書式を生成するため、対応するのが適切と判断されました。

ISO 8601 書式は「T」を使った「2017-03-10T12:34:56+3:10」といったものです。

これまではプライマリサーバからストリーミングレプリケーションで取得した本ファイルをアーカイブしませんでした。その結果、スタンバイサーバの PITRリカバリに失敗する可能性がありました。

postmasterダウン後の動作が適切ではありませんでした。

本障害により、SQL実行時に以下のエラーが出ることがありました。

ERROR:  ORDER/GROUP BY expression not found in targetlist

結果として、プランナ統計情報の pg_class.reltuples が誤って 0 となる可能性がありました。

インデックスエントリは 行外の TOASTポインタを含むことができませんが、BRIN では考慮されていませんでした。この結果、「ERROR: missing chunk number 0 for toast value NNN」といったエラーが発生する可能性がありました。

既存のインデックスでこのようなエラーに遭遇した場合には、REINDEX で修正できます。

CREATE INDEX で格納オプションに buffering=on を指定していたり、インデックスサイズが effective_cache_size 設定値に達した場合に、バッファ付きインデックス構築が行われます。

本障害でクラッシュを引き起こす可能性がありました。

FreeBSD 11、そしておそらく他のプラットフォームでは、このエラーのためにビューのアドレスとネットマスクの列が常に null になっていました。

上記の debug_query_string は PostgreSQL実装内のグローバル変数名です。

OLD を返す BEFORE ROW UPDATEトリガは更新を抑止するために使われます。このようなトリガが、削除されていたり見つからない列を持つテーブルについてOLD を返した場合、これらの列が NULL として読み取られてしまうため、クラッシュ、予期しない CHECK制約の失敗、または正しくない RETURNING の出力が発生する可能性がありました。

トリガ作成後に列を削除したり、非NULLのデフォルト値を持つ列を追加したりした場合にこれらの問題が報告されました。

開始タグと終了タグが一致しない不正なXMLが出力されていました。

以下のエラーが発生して失敗する可能性がありました。

ERROR:  invalid memory alloc request size .....

修正により、真に失敗する必要がある場合には、メッセージ送出におけるサイズ超過の問題と分かるエラーメッセージが出るようになっています。

関わるデータ型によっては、誤った結果やクラッシュにつながる可能性がありました。

（障害動作例: 関数内で型を明示していない場合に戻り値が壊れています）
db1=# CREATE TYPE typ33 AS (a float, b float);
db1=# CREATE FUNCTION f33() RETURNS SETOF typ33 AS $$
        SELECT 1, 2 UNION SELECT 3, 4 ORDER BY 1;
      $$ language sql immutable;

db1=# SELECT f33();
        f33
-------------------
 (5e-324,1e-323)
 (1.5e-323,2e-323)
(2 rows)

以前は関数の属性だけをコピーして、パラメータの属性はコピーしていませんでしたが、これが s390x でクラッシュの原因となることが示されており、他のプラットフォームでもその他の問題がある可能性がありました。

以前の libpq は、接続開始時に WSAStartup() を呼び出し、接続のクリーンアップ時に WSACleanup() を呼び出していました。しかし、 WSACleanup() を呼び出すと、他のプログラム操作に干渉する可能性があるようです。特に、期待された出力を標準出力に出力する際にまれに失敗することが観測されています。WSACleanup() の呼び出しを省略しても悪影響はなさそうなので、呼び出さなくなりました。

これにより、プログラムが一連のデータベース接続を実行する際にDLL のロードとアンロードが繰り返されることによるパフォーマンスの問題も解消されます。

マルチスレッドの ecpg アプリケーションでは、不適切なロックが原因でまれに誤動作が発生する可能性がありました。

これにより、改行を適切に扱えるようになりました。

これに失敗すると --inserts を指定したときにクラッシュしたり、COPY を使用してテーブルのデータを再ロードする際に（通常は正しいのですが）列指定の無い COPYコマンドとなる場合がありました。

フィジー、モロッコ、パレスチナ、カナダのユーコン準州、マッコーリー島、南極のケーシー基地の夏時間法の変更に加えて、フランス、ハンガリー、モナコ、パレスチナの歴史的修正が含まれます。

この変更は、アップストリームで zicコマンドのデフォルトの出力オプションがfat から slim へ変更されたことへの対応です。v13 より前のブランチでは引き続き fatモードを選択しているため、これは単なる見た目を整えるための修正です。この変更により、strftime() が失敗しない限り errno が変更されないことも保証されます。

これはごく稀に発生する障害で、後の xid の周回で明らかになるか、または「ERROR: could not access status of transaction」エラーを引き起こしていました。

これにより、並列実行された pg_restore での潜在的なデッドロックが回避されるようになりました。

CREATE TABLE が LIKE と従来の継承の両方を使用する場合、CHECK制約の列参照と LIKE の親テーブルからの式インデックスに誤った番号が付けられることがよくあり、間違った結果や奇妙なエラーメッセージが出力されていました。 同じことが、その機能を備えたブランチの 生成列(GENERATED) の式でも発生する可能性がありました。

本障害の結果、間違った列のマージが行われ、データ挿入時に以下のような列の型が違うというエラーが生じました。CREATE TABLE時のアサート失敗も報告されています。

ERROR:  attribute 1 of type record has wrong type

この処理は必ず失敗していて、以下のような紛らわしいエラーメッセージが出力されていました。

ERROR:  DROP INDEX CONCURRENTLY must be first action in transaction

エラーメッセージは以下のように変更されました。

ERROR:  cannot drop partitioned index "《インデックス名》" concurrently

これにより、挿入と同時にパーティションが追加された場合に競合が発生する問題が修正されました。

この障害が発生する可能性は低いため、実際の影響は小さく、発生した場合もワーカプロセスが再起動されるだけです。

この変更前は、postmaster が既存の並列ワーカーを終了し、新しい（並列）ワーカーの起動を拒否するため、並列クエリ処理は中断されていました。また、自動バキュームが機能しなくなり、存続しているクライアントセッションが大量のデータ変更を行うと、長期的に深刻な影響を与える可能性がありました。

この変更前には、並列処理を多用すると、並列ワーカープロセスの作成を要求する同時シグナルが多すぎるため、postmaster がクラッシュすることが確認されています。

ほとんどのサーバプロセスはすでにこの慣行に従っていましたが、アーカイバプロセスは見落とされていました。クライアントの起動パケットをまだ待っている状態のバックエンドも、同様にこの慣行に従っていませんでした。

定数サブクエリ出力列は、一部のグループ化セットにのみ表示されるグループ化列である場合、実際には一定ではありませんでした。

これにより、グループ化セットを含む問い合わせで誤った結果が返ることがありました。

問い合わせの実行でクラッシュする動作が報告されていました。

この修正前は、HOT のエラーのために親タプルを見つけられない可能性がありました。その結果、インデックス作成に対して以下のエラーがもたらされました。

ERROR:  failed to find parent tuple for heap-only tuple at (XX,YY) in table "tbl"

インデックス列に対する INリストと別の条件とを与える、以下の障害再現手順が確認されています。最後の SELECT結果が変動してしまいます。

db1=# CREATE TABLE t63 AS SELECT generate_series(1,999999) i;
db1=# ALTER TABLE t63 SET (parallel_workers=2, autovacuum_enabled=off);
db1=# CREATE INDEX ON t63 (i);
db1=# SET parallel_leader_participation=off;
db1=# SET min_parallel_table_scan_size=0;
db1=# SET enable_bitmapscan=off;
db1=# SET enable_indexonlyscan=off;
db1=# SET enable_seqscan=off;
db1=# SELECT COUNT(1) FROM t63 WHERE i > 555 AND i IN (
        333,334,335, …中略… ,664,665,666) ORDER BY 1;

これまではインデックスのスキャンでインデックス破損と誤認した以下のようなエラーが生じるおそれがありました。

ERROR: corrupted BRIN index: inconsistent range map

不必要なエラー発生が防止されたのに加えて、メッセージ文面も「ERROR: failed to re-find tuple within index 《インデックス名》」に変更されました。

これによりクラッシュを引き起こす可能性があります。

CREATE AGGREGATE に指定する関数のデータ型が一致していない場合に以下のようなメッセージが出ますが、そこで示すデータ型が誤っていました。

ERROR:  moving-aggregate implementation returns type 《データ型》, but plain implementation returns type 《データ型》.

これは主に、非常に長いセキュリティトークンをパスワードとして使用できるようにする場合に役立ちます。

以前は、必要なインデックスがすべて配置される前に外部キー制約を復元しようとして、エラーが発生する可能性がありました。

これにより一部の開発環境における configure の失敗を回避しました。