生成列が、テーブル内の他の列の単なるコピーで、かつ、リファレンス渡しのデータ型（文字列型など）である場合、テーブルに壊れたデータが投入されるかクラッシュを引き起こす可能性がありました。他の列を単に複製する GENERATED式という役に立たない使い方に限られればよいですが、時に入力そのものを返す関数を使っている式で本状況が生じる可能性があります。

本障害で以下のようなデータ投入時に巨大なメモリ要求によるエラーが出るケースも報告されました。

ERROR:  XX000: invalid memory alloc request size 18446744073709551613

CREATE TABLE ... INHERITS でテーブルの列が継承された場合、親の列が生成列（GENERATED）であるときに子の列で生成列であるという属性を変更することが禁止され、一方で、親の列が生成列でないときに子の列で GENERATED を指定して生成列にできるようになりました。

これらの規則が不明瞭であったことに起因して、生成列と継承の組み合わせを含むテーブル定義のダンプがリストアできない場合が報告されました。

物理的に後ろにある列を参照する GENERATED式をコピーしようとするときに CREATE TABLE ... LIKE が以下のようなエラーを起こしました。

（報告されたエラー発生例）
db=# CREATE TABLE t3 (
     funds float GENERATED ALWAYS AS (cast(funds_t AS double precision)) STORED,
     funds_t text,
     id bigserial not null);

db=# CREATE TABLE IF NOT EXISTS t3_temp (LIKE t3 INCLUDING GENERATED);
ERROR:  XX000: unexpected varattno 3 in expression to be mapped

式でないインデックス列は作成時には常に、そのテーブル列の attstorage属性をコピーしていました。整合性を維持するように、ALTER TABLE ... SET STORAGE ... が実行されたときにインデックスに対しても属性を変更するようになりました。

indisclustered は pg_indexシステムテーブルの列で、前回テーブルを当該インデックスを使って CLUSTERコマンドを実行した場合にtrue となります。これまで、当該列を対象に ALTER TABLE を実行すると、この情報が失われていました。

REPLICA IDENTITY属性は、論理レプリケーション用に使われ、ALTER TABLE ... REPLICA IDENTITY USING INDEX ... コマンドで指定されます。pg_indexシステムテーブルの列名としては indisreplident です。これまで、当該列を対象に ALTER TABLE を実行すると、この情報が失われていました。

これまで、このような場合に属性が失われ、REINDEX CONCURRENTLY後のCLUSTERコマンド実行が失敗する可能性がありました。

これにより、他セッションがいくつかの同オブジェクトを削除している場合の競合状態によるエラーを回避します。以下のエラーが出るケースが報告されました。

ERROR:  cache lookup failed for relation 41019

一部のエラーケースでは意図通りのメッセージの代わりに「unexpected node type」といったエラーメッセージが報告されていました。

これまで、パーティションをデタッチした際にトリガが残ってしまう動作があり、そのようなトリガは、旧親テーブルとの依存関係のために以下のようなエラーが出て、削除不能となっていました。

db=# ALTER TABLE t10p DETACH PARTITION t10c;
db=# DROP TRIGGER trig ON t10c;
ERROR:  cannot drop trigger trig on table t10c because trigger trig on table t10p requires it

（該当する例: 整数型に COLLATE を指定する式を与えている）
db=# CREATE TABLE t11p (i int) PARTITION BY LIST (i);
db=# CREATE TABLE t11c1 PARTITION OF t11p FOR VALUES IN ('1' COLLATE "POSIX");

これは独自の等価性演算子を持つインデックス演算子クラスだけの問題ですが、理論的には間違っていたので、確認するように修正されました。

pg_read_all_statsロールのメンバ は pg_stat_progress_* ビューを参照できるとドキュメントに記載されていましたが、実際には参照できませんでした。

この修正は、テーブル名を制約する外側の WHERE句がプッシュダウンされるようにビューを再定義し、計算がデータベース内の全トリガではなく、対象テーブルに属するトリガに対してのみ行われるようにします。多くのトリガを持つデータベースでは、この変更でかなりの速度差が出ます。

バージョン11より前には修正後と同様に動作していたので、これは潜在的なパフォーマンス劣化でした。

本修正は既存のデータベースクラスタには適用されませんが、明示的にビュー定義を置き換えることで修正することができます。information_schema.triggersビューを含む情報スキーマの定義はソースコードの以下パスにあります。

src/backend/catalog/information_schema.sql

以前のリファクタリングで、いくつかのホットなコードパスで isinf() を余分に呼び出すようになっていました。

これまで、GiST や GIN インデックス検索として実行されている場合、「!(foo <-> bar)」のようなクエリで、マッチする行が見つからない問題が発生していました。

以下のような場合が該当します。

（マッチすべきところでマッチしない障害動作例）
db=# SELECT 'wa:1D wb:2A'::tsvector @@ 'w:*D <-> w:*A'::tsquery as "true";
 true
------
 f
(1 行)

検索条件部分が適切に強調されない動作が報告されました。

gin_fuzzy_search_limit の値が小さいと、意図せずに同じインデックスページを何度も再スキャンしてしまい、予期せず遅くなる可能性がありました。別のコードパスでは、意図したフィルタリングの適用に失敗しており、多すぎる値を返す可能性がありました。

（修正前のエラー発生例）
db=# SELECT '( 1 , 1 ) , 5'::circle;
ERROR:  invalid input syntax for type circle: "( 1 , 1 ) , 5"

ビット数の引数が int4 のみなので、これらの関数を使用して長い bytea の最初の256MB を超えるビットにアクセスすることはできません。バージョン 13 では引数が int8 に拡張される予定ですが、それまでの間は、これらの関数が長い bytea の最初の部分文字列で動作します。

修正前は、このような場合に以下エラーが発生していました。

ERROR:  index 0 out of valid range, 0..-1

これは、ディレクトリエントリが参照されてからstat() を実行しようとするまでの間にファイルが削除された場合の競合状態による失敗を防ぎます。

そのような場合に以下のエラーが出るケースが報告されました。

db=# CREATE FUNCTION f24(x anyrange, out lu anyarray, out ul anyarray)
     LANGUAGE SQL
     AS 'SELECT array[lower(x),upper(x)], array[upper(x),lower(x)]';

db=# SELECT * FROM foo24(int4range(6,9));
ERROR:  cache lookup failed for type 0

これまで、以下の FATALメッセージで失敗していました。

FATAL:  unsupported frontend protocol 1234.5679: server supports 2.0 to 3.0

これまで、GSSAPI暗号化が使用されている場合、バックエンドと libpq の両方がセッション中に送信されたデータの総量に相当するメモリリークが発生していました。

これにより以下のような問い合わせのメモリ使用量が巨大になっていました。

db=# SELECT sum(f) FROM generate_series(1, 1000000) g(i),
                        generate_series(i, i+1) f;

この誤りは、ハッシュ化されたサブプランのクエリを十分な回数再実行した時に、深刻なメモリの肥大化を引き起こす可能性がありました。

何もしないドメインへの型変換が式から完全に取り除かれない場合があり、修正されました。旧メジャーバージョンと比べて動作が遅くなっていたことが報告されていました。

実際には上記の状況であっても本障害でのクラッシュ発生は稀です。

以下のような EXPLAIN出力（一部抜粋）が報告されていました。

->  Hash  (cost=0.11..0.11 rows=10 width=12) (actual time=0.002..0.002 rows=1 loops=8)
      Buckets: 2139062143  Batches: 2139062143  Memory Usage: 8971876904722400kB
      ->  Function Scan on unnest init_1  (cost=0.01..0.11 rows=10 width=12) (actual time=0.001..0.001 rows=1 loops=8)

これまで不正確な経過時間が報告されていました。

これによって、VACUUM がインデックスのクリーンアップスキャンをスキップできる場合について、微妙に間違った判断をする可能性がありました。

（誤った psコマンドの出力行の例）
46510   ??  Ss     0:00.05 postgres: startup   recovering 000000010000000000000003 waiting waiting

VACUUM FULL などの操作が同時に行われた場合に、ANALYZE が間違ったタプルを置換してしまう可能性がありました。

これにより、自動バキュームが何度もトライしては同じバキュームジョブをスキップすることを繰り返すというまれなケースが回避されます。

この誤りはまれにスペースを無駄にしましたが、それ以外は無害です。

REINDEX CONCURRENTLY に失敗した後に REINDEX TABLE を行った場合に、使用できず、削除もできない重複したインデックスが作成されてしまう問題が生じていました。

以前は pg_depend のリンクがまったくない古いインデックスを残すことがありえたため、例えば親テーブルが削除されてもインデックスは削除されずに残ってしまいました。

この障害はスーパーユーザが一時スキーマを手動で削除した場合にのみ発生します。これは一般的な状況ではありませんが、この場合も動作すべきでした。

クラッシュリカバリの間にアーカイブされる準備が整った WALセグメントがアーカイブされずにリサイクルされる可能性がありました。

これにより、アーカイブストレージから存在しない WAL ファイルをフェッチしようとする多くの試みを排除することが可能となり、アーカイブへのアクセスが遅い場合に役立ちます。

この条件は様々なシナリオで正当に到達可能なため取り除かれました。

WALデータが適切に取りおかれず、早くに削除されてしまう可能性がありました。

本障害のため walsender が後でロックを待機したまま動けなくなる可能性がありました。

これまで、このような場合に生成列が更新されませんでした。

synchronous_standby_names の設定を変更している間、同期コミットを待っているトランザクションをリリースしてもよいかどうかについて、誤った判断を下す可能性がありました。 また、walsenderプロセスが終了してすぐにプロセスが再起動された場合にも、同様に誤った判断を下す危険性がありました。

そのような関数実行でクラッシュが発生していました。

接続開始時の証明書の検証は、いくらかのメモリリークの可能性があり、クライアントプロセスの起動中にデータベース接続を多数オープンした場合に問題となる可能性がありました。

AIX で動作しないケースが報告されていました。

\gx コマンドは直前の SQL 実行結果を拡張出力モードで引数に指定したファイルへ書き込みます。

以前の pg_dump はこの依存関係を無視してしまい、ダンプ/リストアや pg_upgrade時にそれらが反映されませんでした。

これにより、イベントトリガが他のオブジェクトの復元に干渉するリスクを最小限に抑えることができます。

ファイルの末尾にゼロ埋めされたブロックが追加されることがありました。これは一般的なバージョンの tar では問題ないようですが、POSIXファイル形式の仕様としては問題がありました。

このようなサブディレクトリは実際にはデータベースクラスタには属していないので、処理してはいけませんでした。

以下の通り、正しくクォートされた文字列を認識できるようになりました。

（PostgreSQL 12.2 の createdb コマンド）
$ createdb --lc-collate "foo'; SELECT '1" 'foobar2'
createdb: error: database creation failed: ERROR:  CREATE DATABASE cannot run inside a transaction block

（PostgreSQL 12.3 の createdb コマンド）
$ createdb --lc-collate "foo'; SELECT '1" 'foobar2'
createdb: error: database creation failed: ERROR:  invalid locale name: "foo'; SELECT '1"

これまではフィールド長が 65535 を超えると 0 になっていましたが、本修正によって ERROR が返るようになりました。

（修正前の動作）
db=# SELECT nlevel(('1' || repeat('.1', 65534))::ltree);
 nlevel
--------
  65535
(1 row)

db=# SELECT nlevel(('1' || repeat('.1', 65535))::ltree);
 nlevel
--------
      0
(1 row)


（修正後の動作）
db=# SELECT nlevel(('1' || repeat('.1', 65535))::ltree);
ERROR:  number of ltree levels (65536) exceeds the maximum allowed (65535)

このような XID は負の整数として報告されるようになりました。これはワークアラウンドですが、エラーを投げるよりは良いと判断されました。これまで、以下のようなエラーが発生していました。

db=# SELECT * FROM bt_metap('index');
ERROR: value "2180413846" is out of range for type integer

Windows の pg_ctl で、-l で指定したログファイルがまだ存在せず、pg_ctl が Administrator権限で実行されている場合、postmaster から書き込みできないパーミッションでログファイルが作成されて、権限不足のエラーが生じる可能性がありました。

Unixスタイルのロケール文字列（たとえば "et_EE.UTF-8"）の場合、ドットの後にあるのはエンコーディング名です。これを Windows のコードページ番号として扱って、以下のエラーが生じていました。

> initdb.exe --locale et_EE.UTF-8 -D C:\data
initdb: ERROR:  invalid locale name "et_EE.UTF-8"

そのため、ドットの後の文字がすべて数字であるかどうかを確認し、そうでない場合はコードページ番号ではなくエンコーディング名として扱うようになりました。

これを設定していないと、カラー化オプションが実際には動作しませんでした。

これはソースコード内のインターフェースに関連する修正です。

pkg-config が存在しないか、libxml2 に関する情報がない場合は、これまで通りxml2-config に問い合わせます。

この変更により、PostgreSQL がデフォルトではないバージョンの libxml2 を使用する場合、そのバージョンの xml2-config を PATH に設定すると、ビルドプロセスが中断される可能性があります。代わりに、XML2_CONFIG にデフォルトではない xml2-config を設定してください。この方法は、古いバージョンの PostgreSQL でも新しいバージョンの PostgreSQL でも動作します。

America/Godthabゾーンは、現在の英語の使用法を反映するために America/Nuuk に名称変更されました。変更前の名前も互換性のために利用可能なままです。

また、initdb の既知の Windowsタイムゾーン名のリストが最近追加されたものを含むように更新され、そのプラットフォーム上のシステムのタイムゾーン設定が正しく翻訳される可能性が高まりました。

この競合状態により、誤ったホットスタンバイフィードバックメッセージがプライマリサーバに送り返される可能性があり、VACUUM がプライマリ上ですぐに実行されてしまう可能性がありました。

これにより、必要に応じて "-fPIC" を追加するなど、C++ のソースファイルが正しくコンパイルされるようになります。11.x以降バージョンでは既にそのようになっています。

関数、プロシージャ、トリガ、マテリアライズドビュー、インデックスに対する本SQL文について修正が行われました。本SQL文はデータベースオブジェクトが拡張に依存していると印付けするものです。依存関係があると、拡張を DROPする際にそのデータベースオブジェクトも削除されます。

本SQLの実行際して何ら権限チェックが行われていませんでした。そのため、拡張を削除できるユーザは権限の無いオブジェクトを削除可能でした。また、管理者が拡張を削除する際に権限の無いオブジェクトを削除させるように仕組むことができました。

本SQLの実行には対象オブジェクトの所有者であることが要求されるように修正されました。

パーティションテーブルのパーティションが CASCADEオプション付きでTRUNCATEされた場合で、かつ、パーティションテーブルが他テーブルからの外部キー参照を持っていた場合、参照しているテーブルも空にされるべきです（通常のテーブルもそのように動作します）。参照しているテーブルがパーティションテーブルである場合に検査に取りこぼしがあり、外部キー制約違反の行が残る可能性がありました。

このため、データベースにパーティションテーブル間の外部キー制約があり、これまでに被参照テーブルにパーティション単位で TRUNCATE を行っていたなら、外部キー違反が無いかを確認することを推奨します。

最も簡単な確認方法は新たに同定義の外部キー制約を加えることです（確認用なので追加に成功したら、削除します）。ロック取得の観点から、これが実施しにくい場合には、SELECT文で制約違反の行を探してください。

複数階層パーティションテーブルの第二階層以下にパーティションをアタッチするとき、そのパーティションテーブルを参照する外部キー制約が新たなパーティションに複製されず、その結果、後で制約違反を引き起こす可能性がありました。

簡単な修復方法は、そのパーティションをデタッチしてアタッチすることです。修復すべきパーティションが大量にある場合には、新たに同定義の外部キー制約を追加する方法が良いでしょう。

（外部キー制約やユニーク制約のトリガではなく）ユーザ定義トリガについて、パーティションの作成やアタッチをするときに取りこぼしが生じるおそれがありました。

このようなトリガが実行されないことがありました。

ファイル識別子を使いすぎて、以下のようなエラーが出るケースが報告されていました。

ERROR:  exceeded maxAllocatedDescs (492) while trying to open file "pg_replslot/logical/xid-2362-lsn-0-24000000.spill"

本障害は、サブスクライバのテーブルがパブリッシャからコピーされていないリファレンス渡しのデータ型の列を含む場合に限って、顕在化した問題を発生させます。

text や numeric など格納サイズが大きいデータ型はリファレンス渡しです。ビルドオプションによっては int8 や float8 もリファレンス渡しになります。

更新や削除の操作に際して、既存タプルを探すときに最初に一致したタプルを返すようになりました。これまでは全てを調べる動作になっていました。

大きい OID値を持つデータベースがあるときに、以下のようなエラーが報告されていました。

pg_basebackup: error: could not get write-ahead log end position from server: ERROR:  value "3000000000" is out of range for type integer

この障害は、複数バッチの（即ち、件数が多くてメモリに載らない場合の）パラレルハッシュ結合の際に、以下のような予期せぬ警告を発生させました。

WARNING:  temporary file leak: File 15 still referenced

これにより、入れ子ループの内側にある等、このようなプランノードを複数回スキャンする必要がある場合の障害を回避します。本障害でクラッシュする動作が報告されました。

無駄な処理を削って、それによる CPUキャッシュ間の同期処理の発生を回避します。

そのような場合には非パラレルのインデックス作成が行われるようになります。

以下のエラーが発生する場合にリークが発生しました。

ERROR: too many dynamic shared memory segments

これにより一時テーブルが ON COMMITアクションを持っていた場合の奇妙なエラーを回避します。以下のような発生ケースが報告されました。

=# CREATE TEMP TABLE t0(c1 INT PRIMARY KEY) ON COMMIT DELETE ROWS;
=# REINDEX TABLE CONCURRENTLY t0;
ERROR:  index "t0_pkey_ccnew" already contains data

他のセッションは一時テーブルにアクセスできないため、一時テーブルに対するインデックス作成で CONCURRENTLY を使う利点はありません。

本障害ではデッドロックや、削除済みページの誤った状態更新、最近に削除されたページを辿る動作の失敗、を起こす可能性があり、これらが回避されました。

一例として、以下のような形状の問い合わせが該当します。

SELECT * FROM (
 SELECT * FROM (
  VALUES ('A'::text NOT IN (
   SELECT 'E'::text AS col_1 FROM (
    VALUES (NULL), (NULL), (NULL), (NULL)) AS tab_1 (col_2)
     WHERE false),
   NULL, 'B'::text, 3::int),
  (false, 4::int, 'B'::text, 0::int)) AS tab_3 (col_4, col_5, col_6, col_7)
 WHERE tab_3.col_4) AS tab_8 ORDER BY 1, 2, 3, 4;

例えば以下のような操作でエラーが発生していました。

db=# CREATE TABLE t25 (a int, b int, c int, x int);
db=# INSERT INTO t25 VALUES (1, 1, 1, 1), (2, 2, 2, 2);
db=# ALTER TABLE t25
       DROP COLUMN x,
       ALTER COLUMN a TYPE bigint,
       ALTER COLUMN b TYPE bigint,
       ADD COLUMN x bigint GENERATED ALWAYS AS ((a + b) * 2) STORED;
ERROR:  attribute 1 of type t25 has wrong type
DETAIL:  Table has type integer, but query expects bigint.

この障害で、定数デフォルトを伴う ALTER TABLE .. ADD COLUMN で追加された列の値が誤って NULL と読み取られる可能性がありました。

タプル変換とは行データをレコード型に代入するときなどに必要となる内部処理です。

この問題は data_sync_retry = on の場合のみ該当します。off の場合には FileClose() 失敗は（仕様通りに）PANIC になるはずです。

トリガを駆動されたときにアサートエラーが生じる動作が報告されました。

PL/pgSQL関数を使ってユーザ定義した集約関数を実行したときにアサートエラーが生じるケースが報告されました。

入力文字列中の誤った月や曜日に関するエラー報告が、誤った部分を示すときマルチバイト文字の途中で切り出すことがあり、続くエラーの元になる不適切なエンコードのエラーメッセージをもたらしました。

これを回避するため、次の空白文字までを切り出し範囲とするようになりました。

（障害動作例: B.C. 7年について -7 を返すのが正しい動作）
db=# SELECT EXTRACT(ISOYEAR FROM 'Feb 03 04:05:06 0007 PST BC'::timestamp);
 date_part
-----------
        -6
(1 row)

以下のように、どの照合順序を使って処理すべきか判別できない場合に、予期せぬエラーメッセージや、アサートエラーが出ていました。

db=# CREATE TABLE t33 (c0 char(2) COLLATE "C", c1 char(2) COLLATE "POSIX");
db=# INSERT INTO t33 VALUES ('', '');

db=# SELECT * FROM t33 WHERE c1 <> c0;
ERROR:  cache lookup failed for collation 0
（予期せぬエラー出力）

db=# SELECT * FROM t33 WHERE c1 = c0;
ERROR:  could not determine which collation to use for string comparison
HINT:  Use the COLLATE clause to set the collation explicitly.
（こちらは望ましいエラー出力）

リファクタリングの誤りで、TIDスキャン（ctid列による選択）が実行時統計情報ビューでシーケンシャルスキャンとして数えられており、さらに、シーケンシャルスキャンのようにテーブル全体の術部ロックを取りました。後者の動作は SERIALIZABLE トランザクションモードで不要な直列化失敗エラーを引き起こす可能性がありました。

リレーションが更新可能かを調べる内部実装関数が、自己参照ビューに対して無限再帰を起こすため、そのような場合に処理を打ち切るように修正されました。

これまでは xact_start 列にプロセス開始時刻があらわれることがありました。

テキスト以外の出力形式では、このフィールドは Plans 副グループの内側に出力されて、構文的に不正な出力になっていました。

JSON形式であれば以下のような形の不正な出力があり得ました。

    "Plans": [
        { ..サブプラン.. },
        "Subplans Removed": 5,
        { ..サブプラン.. }
    ]

"Subplans Removed" は親の Append や MergeAppend プランノードに付けるように修正されました。

この変更はテキスト形式にも反映されます。これまで InitPlan の下にあった Subplans Removed は、InitPlan よりも手前に現れるようになります。

非テキストの出力フォーマットでは、たとえ値が空やゼロであっても、各フィールドが存在することが期待されます。

この変更は、CVE-2017-7484 セキュリティ障害の修正で生じた、パーティションテーブルの性能問題を修正します。先のセキュリティ修正では、現在ユーザが直接には読むことのが許可されない列の統計情報に、漏洩のある演算子を適用できないようにしました。

一方で、親のパーティションテーブルのみに参照権限があって、個々のパーティションには権限が無いというのは、ごく一般的な状態です。ユーザは親のパーティションテーブルを通して、子パーティションの列を参照できます。このような場合に、先のセキュリティ修正のためにプランナの見積もりが必要以上に劣化していました。

この誤りは、以下のような予期せぬエラーをもたらしました。また、アサートエラーになる可能性もありました。

（本エラーを発生させる問い合わせ例）
db=# SELECT FROM (
      SELECT FROM pg_stat_bgwriter AS r0
       LEFT JOIN pg_stat_bgwriter AS r1 ON (true), LATERAL (
        SELECT FROM pg_publication AS r2, LATERAL (
         SELECT FROM pg_class WHERE r1.buffers_alloc IS NOT NULL
         ) AS sq0 LIMIT 1) AS sq1) AS sq2;
ERROR:  failed to construct the join relation

LIKE や正規表現のパターンマッチ演算子をバイナリ互換のインデックス演算子クラスでマッチさせようとするときに発生しました。

（発生例: text型とバイナリ互換の char型に対応した bpchar_ops を使用しています）
db=# CREATE TABLE t43 (c text);
db=# CREATE INDEX i43 ON t43 (c bpchar_ops);
db=# SELECT * FROM t43 WHERE t43.c LIKE '';
ERROR:  no = operator for opfamily 426

列のプランナ統計情報と比較条件の値とが特定条件に合致する場合に問題が発生します。

拡張統計情報が a と b の間に作られているところで、以下のような問い合わせを実行するとき、アサートエラーが出る動作が報告されました。アサート無効のときにはプランナの見積もりが不正確になります。

SELECT * FROM t45 WHERE (a = 1) OR (b = 1) OR (c = 1)

これにより以下のように、システム列を参照する問い合わせで予期せぬエラーが発生するのを防止します。

db=# CREATE TABLE t46 (id int, c1 int, c2 int);
db=# INSERT INTO t46 SELECT g, g, g FROM generate_series(1, 1000) as g;
db=# CREATE STATISTICS s46 ON id, c1 FROM t46 ;
db=# ANALYZE t46;
db=# SELECT (ctid::text::point)[0] blkno, count(*) cn FROM t46
       GROUP BY blkno ORDER BY cn DESC LIMIT 10;
ERROR:  negative bitmapset member not allowed

これまでは、何らかインデックスアドバイザ拡張が仮定の BRINインデックスを伴うプランを生成させようとすると、BRINコスト見積もりコードが常にインデックスのメタページに物理的にアクセスしようするため、失敗しました。

これはサポートされていないものですが、これまでは、そのことを示すエラーがエグゼキュータによる実行時にしか出ませんでした。そのため、不明瞭なプランナのエラーで原因が隠されてしまうおそれがありました。

リライタの段階で以下のようなエラーメッセージが出るようになりました。

db=# CREATE TABLE t48 (a int PRIMARY KEY, b text);
db=# INSERT INTO t48 VALUES (2, '2');
db=# CREATE VIEW v48 AS SELECT a, b, a AS aa FROM t48;
db=# CREATE RULE v48_upd_rule AS ON UPDATE TO v48
       WHERE OLD.a > 0 DO INSTEAD UPDATE t48 SET b=NEW.b WHERE a=OLD.a;
db=# UPDATE v48 SET b = 'ROW 2' WHERE a = 2;
ERROR:  cannot update view "v48"
DETAIL:  Views with conditional DO INSTEAD rules are not automatically updatable.
HINT:  To enable updating the view, provide an INSTEAD OF UPDATE trigger or an unconditional ON UPDATE DO INSTEAD rule.

（以下は修正前バージョン 12.1 でのエラーメッセージ）
ERROR:  no relation entry for relid 2

元々自分自身を含む複合型は作成できない仕様でした。本修正で以下の操作がエラーになります。

db=# CREATE TYPE two_ints AS (a int, b int);
db=# CREATE TYPE two_ints_range AS RANGE (subtype = two_ints);
db=# ALTER TYPE two_ints ADD ATTRIBUTE c two_ints_range;
ERROR:  composite type two_ints cannot be made a member of itself drop type two_ints cascade;
NOTICE:  drop cascades to type two_ints_range
（上記は修正後の動作、修正前はエラーにならない）

そのようなパーティションテーブルに対する問い合わせで、何らかエラーやスタックオーバーフロー（ERROR: stack depth limit exceeded）が起きる動作が報告されました。定義時点でエラーが出るようになります。

空の列名でなく自動生成した列名が出力されるようになります。

(修正前)
=# CREATE INDEX ON t ((ROW(c)));
ERROR:  column "" has pseudo-type record

(修正後)
=# CREATE INDEX ON t ((ROW(c)));
ERROR:  column "row" has pseudo-type record

=# CREATE MATERIALIZED VIEW mv (c) AS VALUES (1);
CREATE MATERIALIZED VIEW

(修正前のpg_dump出力)
CREATE MATERIALIZED VIEW public.mv AS
 VALUES (1)
  WITH NO DATA;

(修正後のpg_dump出力)
CREATE MATERIALIZED VIEW public.mv AS
 SELECT "*VALUES*".column1 AS c
   FROM (VALUES (1)) "*VALUES*"
  WITH NO DATA;

修正前は、xmltable関数で参照されているデータ型や照合順序を削除することで、ビューやルールを壊すことができました。この修正は新たに作成したビューとルールに適用され、既存のものには適用されません。

=# CREATE EXTENSION seg;
=# CREATE TABLE t53 AS SELECT '<s>1 .. 2</s>'::xml AS c;
=# CREATE VIEW v53 AS SELECT s::text FROM t53, xmltable('//s' PASSING c COLUMNS s seg);

(修正前)
=# DROP EXTENSION seg;
DROP EXTENSION
=# SELECT * FROM v53;
ERROR:  cache lookup failed for type 16499

(修正後)
=# DROP EXTENSION seg;
ERROR:  cannot drop extension seg because other objects depend on it
DETAIL:  view xmlview depends on type seg
HINT:  Use DROP ... CASCADE to drop the dependent objects too.

修正前はパラメータ値を誤って SQL識別子として処理していました。

この修正により、libpq のようなクライアントライブラリでは、トランザクション内で受信した通知をクライアントがトランザクション完了と判断するまで受信可能になります。実際には通知を非同期で受信する必要があるため、動作の違いはおそらくありません。ただ、セッションをまたがる通知のテストケースを作成するのに便利です。

この誤りにより、データが損失したり、それに伴って接続が切断したり、データを残して送信が完了したと判断してスリープ状態となったりする可能性があります。さらに、libpq では接続ごとに暗号化状態を管理できなかったため、複数の暗号化接続を使用する場合にエラーが発生する可能性があります。

この修正により、SSL と同様に機能が無効の場合でも、関連するすべてのパラメータを常に受けつけるようになります。

%b、%B は月の略称、名称に置換されますが、修正前は、1 始まりの月数を 0始まりの月名の配列の添字に使用しており、11月までは翌月の月名に置換され、12月はクラッシュする可能性がありました。

複合型やドメインには対応していましたが、これらについて見逃されていました。

PL/pgSQL の変数によって参照される複合型やテーブルを削除して再作成したとき、以下のようなエラーが生じることがありました。

ERROR:  could not open relation with OID 34567

これにより、そのパラメータの無意味な設定によるクラッシュを防止します。

このケースは役に立たず、一部のプラットフォームではクラッシュしました。

この問題により、PostgreSQL が古いバージョンの OpenSSL で構築されている場合、SSL圧縮オプションを必要に応じて設定できなくなる可能性がありました。

これは、idle_in_transaction_session_timeout、lock_timeout、statement_timeout、track_activities、track_counts、およびtrack_functions に適用されます。

プロダクションビルドでは通常、メモリコンテキストチェックが有効にならないため、これは問題ではありません。ただし、デバッグビルド（--enable-cassert や-DUSE_VALGRIND）ではリークが非常に深刻になる可能性があります。

LWLock 統計情報のコード (デフォルトではビルドされません。-DLWLOCK_STATSを使用してコンパイルする必要があります) は、ハッシュテーブルキーの作成が失敗した結果、同じ LWLock およびバックエンドプロセスの複数のエントリを報告する可能性がありました。

これは、NOTIFY で目に見えるタイミングの異常を引き起こし、おそらく他の誤動作も引き起こしました。

知られている限り、この見落としは、実際のクエリの誤動作ではなく、不要な情報を含む以下のようなログメッセージをもたらしました。

LOG:  unrecognized win32 error code: ...

これは、対象ファイルに削除のフラグが設定されているが、実際には削除されていないためにファイルを開くことができない場合の対処に役立ちます。例えば、pg_ctl は、postmaster がすでに停止しているかどうかを調べるときに、以下ようなエラーでしばしば失敗しました。

pg_ctl: could not open PID file "c:/pgsql/data/postmaster.pid": Permission denied