以下のような発生例が報告されました。c1列の追加がテーブル書き換えを要する変更で、デフォルト値無しの列追加が c2 です。

db=# CREATE TABLE t1 (id int);
db=# CREATE SEQUENCE seq1;
db=# ALTER TABLE t1
       ADD COLUMN c1 numeric(10,0) NOT NULL DEFAULT nextval('seq1'),
       ADD COLUMN c2 varchar(20);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

REINDEX CONCURRENTLY は新たな版のインデックスに対してセッションレベルのロックを取得しておらず、潜在的に他セッションによる早すぎる操作を許していました。また、悪いタイミングでの問い合わせキャンセルや割り込みによるセッション終了により、REINDEX CONCURRENTLY が持つセッションレベルロックが解放されない恐れがありました。

この障害により pg_depend の肥大化が生じますが、それ以外の害はありません。既存の重複エントリは pg_depend システムテーブルを操作するか、インデックスを一度削除することで除去できます。

この障害により、古い実行中のトランザクションが終了するまでの間、VACUUM が失敗していました。

VACUUM 実行で以下のようなエラーが出るケースが報告されました。

ERROR:  multixact ... from before cutoff ... found to be still running

CLUSTERコマンドで以下のような予期せぬメッセージが発生していました。

ERROR:  trying to store a heap tuple into wrong type of slot

トリガが無い、という不適切なエラーが生じていました。以下に発生例を示します。

db=# CREATE TABLE t7p (a int PRIMARY KEY) PARTITION BY LIST (a);
db=# CREATE TABLE t7p12 PARTITION OF t7p FOR VALUES IN (1, 2)
                        PARTITION BY LIST (a);
db=# CREATE TABLE t7p1 PARTITION OF t7p12 FOR VALUES IN (1);
db=# CREATE TABLE t7p2 PARTITION OF t7p12 FOR VALUES IN (2);
db=# CREATE TABLE t7p3 PARTITION OF t7p FOR VALUES IN (3);
db=# CREATE TABLE t7fk (a int REFERENCES t7p DEFERRABLE INITIALLY IMMEDIATE);
db=# BEGIN;
db=# SET CONSTRAINTS t7fk_a_fkey DEFERRED;
ERROR:  no triggers found for constraint with OID 24861

条件に該当するCREATE INDEXコマンドに対して以下のような予期せぬエラーが出るケースが報告されました。

ERROR:  unexpected varattno 4 in expression to be mapped

これまではインデックスの依存性に関するエラーを出して失敗していましたが、自動的にインデックスも削除されるべきでした。

このような場合に、インデックスの pg_class.relispartition フラグが誤った状態で残っていて、DROP INDEX の失敗をもたらしていました。DROP INDEX で、以下のようなエラーが出る動作が報告されました。

ERROR:  could not find tuple for parent of relation ...

この誤りで、本来可能なパーティション単位での結合プランを使えなくなるか、「could not find pathkey item to sort」というプランナのエラーになる可能性があります。

この誤りは、オフセットが自明でない式のときに様々なエラーをひき起こす可能性がありました。一例として、関数内の問い合わせが WINDOW句のオフセット式で関数パラメータを参照していて、関数がインライン化されている場合に以下のようなエラーを出すことがありました。

ERROR:  no value found for parameter 1

以下のエラーが発生するケースが報告されました。稀ですが本障害で postmaster のクラッシュをひき起こす可能性もあります。

FATAL:  no free slots in PMChildFlags array

本障害で更新SQL処理のバックエンドプロセスのクラッシュが生じます。EvalPlanQual再チェックは、READ COMMITTEDトランザクション隔離レベルでのSQL実行における内部的な処理です。

本来、権限が無いというエラーが出るべきところで、不適切なエラーが出ていました。

（本障害によるエラー例）
db=> REINDEX TABLE pg_toast.pg_toast_16388;
ERROR:  unexpected relkind: 116

（本来生じるべきエラーは以下）
ERROR:  must be owner of table pg_toast_16388

設定パラメータの誤りでパラレル問い合わせがエラーになったときに、エラーメッセージから誤っている個所が分かりにくいという問題がありました。

一部のコードパスではリードオンリーで開いたファイルにも fsync() を試みていました。これは一部プラットフォームではエラーをひき起こし、サービスダウンの原因となりました。

(Windowsプラットフォームで以下PANICの発生が報告されました)
PANIC:  could not fsync file "pg_replslot/xxx/state": Bad file descriptor

これまでは入力文字列で 0.25GB が上限でしたが、これからは変換後の出力が1GB を超えない限り処理できるようになります。

タプルストアとは、問い合わせの中間結果の表形式データを格納する領域です。一部の場合にタプルストアがソーステーブルの、問い合わせに必要な列だけではなく、全列を含むことがありました。

本修正は問い合わせで生じる不要に大きい一時ファイルを小さくします。

repalloc() は PostgreSQL のメモリマネージャモジュールが提供する標準ライブラリの realloc() に似た動作をする関数です。

これまで、アーカイブリカバリ後のオンラインWALディレクトリにRECOVERYHISTORYファイルが残る動作がありました。

recovery_min_apply_delay はアーカイブリカバリの際の設定では通常使われませんが、動作すべきでした。これまでは設定すると常にアーカイブリカバリに失敗し、アサート有効のビルドではアサート失敗が生じました。

これらは バージョン12 から postgresql.conf に記述するようになったため、クラッシュリカバリ時にも有効になっていることが有り得ますが、このときこれら設定に従うことは望ましくありません。クラッシュリカバリが完了するまで、これらの設定は無視されるようになります。

パブリッシャにその列が存在しないときに、サブスクライバで REPLICA IDENTITYの一部として列を宣言すると、下記のエラーをひき起こしました。

ERROR:  negative bitmapset member not allowed

これまでは場合によっては wal_sender_timeout の時間だけ停止が滞留することがあり、PostgreSQLサービス停止を遅らせました。

誤ったロジックがロジカルレプリケーションにおけるwal_receiver_timeout の働きを妨げていました。パブリッシャ側の walsender が終了したのにサブスクライバ側のlogical worker が待ち続けるという動作が報告されました。

この誤りで、例えば pg_stat_subscription.last_msg_send_time がたいてい NULL になりました。

この障害によりバックエンドプロセス終了が遅くなりました。

libpqベースのクライアントは一般的に、最初の接続試行が失敗するまでユーザにパスワード入力を促さないため、パスワードが必要な場合には二回接続を試みます。それゆえ、サーバはクライアントがパスワードを要する接続を閉じたときに無駄なログメッセージを出さないように書かれています。しかしながら、PAM認証ではそのようになっておらず、余計な認証失敗メッセージを複数出力していました。

bitshiftright() はビット列データ型（bit、bit varying）の右シフト演算子の実装関数です。ビット列の長さが 8 の倍数ではないときに、結果の最終バイトにあるシフトされた桁のゼロ埋めに失敗していました。

ほとんどの場合、異常になるのは不可視部分のデータです。しかし、ビット列比較では余分なビットも無視されず、常に 0 であると想定されるところに非ゼロビットが存在することで予期せぬ比較動作が生じます。

ビット列の右シフト結果をテーブルに格納している場合、不整合データを以下のような SQL で補正できます。

UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol);

歴史的に、また、SQL標準により、このような場合に結果は 1 であるべきですが、12.0 では 0 を返していました。

(以下の応答は 1 が正しい)
db=# SELECT strpos('ABCDE', '');
 strpos
--------
      0
(1 row)

（オーバーフローが検出されない例)
db1=# SELECT extract(epoch from '256 microseconds'::interval * (2^55)::float8);
     date_part
--------------------
 -9223372036854.775
(1 row)

(修正後は以下エラーがでるようになります)
ERROR: interval out of range

括弧を記載しない書き方も受け入れるようになりました。

バージョン12で整数パラメータの検査が厳しくなっていましたが、末尾の空白まで許容しないのは望ましくないと判断されました。

これまでは接続状態に CONNECTION_BAD がセットされませんでした。

ecpg_gettext() の定義をクライアントコードから見えない適切な位置に移すことで修正されています。

pg_dump がパーティションテーブルの外部キーについて完全な依存情報の出力に失敗していました。このため、pg_restore で早すぎるタイミングで外部キー制約を再作成しようとして、パラレルリストアが時々失敗することがありました。

これまでは、同じ名前を持ち異なるテーブルに付く二つのトリガは OID でソートされましたが、これからはテーブル名でソートされます。RLS（行単位セキュリティポリシー）についても同様です。

以前は、データ型がドメインや複合型の格納列が元となっている場合に誤判定をして、本来不要な pg_upgrade 失敗をひき起こしたり、pg_upgrade 実行後のクラスタを壊してしまったりすることがありました。

これは、それに続く pg_rewind の実行の失敗につながる可能性がありました。

継続WALレコードがページの境界で丁度終わるような特別なケースの場合、-sオプションによりそのWALレコードを指定した際に正常にレコードを処理できずアサーションエラーが発生していました。

この関数は、どのクライアントも使用しないであろうという理由で以前に削除されましたが、とても古いバージョンの psql（および、おそらく他のアプリケーション）と組み合わせて使用した際に正常に動作しなくなってしまいました。

以前では、ユーザがCFLAGSに -O0 を設定した場合に失敗する可能性がありました。

以前のスピンロックのコードでは、それが許容されないアセンブリ命令に対してレジスタ0 を選択できたため、ビルドの失敗を引き起こしてました。

このバグに一致する報告は今までに 1回のみでしたが、修正された PostgreSQL のコードや変則的なコンパイラオプションによるビルドを実行した際に問題を起こす可能性がありました。

これにより xlc v16.1.0 での内部的なコンパイルエラーが避けられます。この変更は、コンパイラのエラーメッセージ形式が変わること以外ほとんど影響はありません。

bloom_index専用のオプションなど、特殊なオプションを ALTER TABLE で変更した場合に失敗することがありました。

（報告されたエラー例）
ERROR:  XX000: unrecognized lock mode: 2139062143

無関係な複数の親テーブルを継承した子テーブルがあって、継承した列が重複している場合、親テーブルでその列の型の変更するとエラーが返されるようになりました。以前は実行可能でしたが、そうすると、同期が取れなくなった親への問い合わせが失敗していました。

（該当する操作の例）
db=# CREATE TABLE pt53_1 (f1 int, f2 int);
db=# CREATE TABLE pt53_2 (f1 int, f3 bigint);
db=# CREATE TABLE ct53 (f4 int) INHERITS (pt53_1, pt53_2);
NOTICE:  merging multiple inherited definitions of column "f1"
db=# ALTER TABLE pt53_1 ALTER COLUMN f1 TYPE bigint;
ERROR:  cannot alter inherited column "f1" of relation "ct53"

いったん ALTER TABLE .. NO INHERIT .. で継承関係を外して、各テーブルでデータ型を変更して、ALTER TABLE .. INHERIT .. で再び継承関係を付与するという手順で同様の操作を行うことができます。

これまでは以下のようなエラーが生じていました。

db=# CREATE TABLE t54 (id int);
db=# INSERT INTO t54 VALUES (1), (2);
db=# BEGIN;
db=# ANALYZE t54,t54;
ERROR:  duplicate key value violates unique constraint "pg_statistic_relid_att_inh_index"
DETAIL:  Key (starelid, staattnum, stainherit)=(16391, 1, f) already exists.

プランナは ICU照合が使われていた場合に、大文字小文字が区別できるかを適切に判定できていなかったため、多くのパターンで固定された接頭語として扱ってしまい、ILIKE句から派生したインデックススキャン時に見つけるべきエントリを見逃す可能性がありました。

（誤動作例）
db=# CREATE TABLE t55 (
       normal text UNIQUE, icu text COLLATE "de-x-icu" UNIQUE);
db=# INSERT INTO t55 VALUES ('ABC', 'ABC');
db=# SELECT * FROM t55 WHERE normal ILIKE 'abc';
 normal | icu 
--------+-----
 ABC    | ABC
(1 row)

db1=# SELECT * FROM t55 WHERE icu ILIKE 'abc';
 normal | icu 
--------+-----
(0 rows)

以前は、行セキュリティポリシーが設定されていた場合に、行タイプの不一致に関する偽のエラーが生じる可能性がありました。

（エラー発生例）
db=> CREATE TABLE t56 (a int, b int, c int);
db=> CREATE POLICY p56 ON t56 USING (t56 >= ROW(1,1,1));
db=> ALTER TABLE t56 ENABLE ROW LEVEL SECURITY;
db=> ALTER TABLE t56 FORCE ROW LEVEL SECURITY;
db=> INSERT INTO t56 SELECT 10, 20, 30;
db=> INSERT INTO t56 SELECT * FROM (SELECT b, c FROM t56 ORDER BY a) ss;
ERROR:  table row type and query-specified row type do not match
DETAIL:  Table row contains 2 attributes, but query expects 3.
（3番目の値を NULL として INSERT に成功する動作が正しい）

該当の場合にバックエンドプロセスがクラッシュする可能性がありました。

以下の形の SQL でクラッシュが報告されました。

SELECT * FROM t58 WHERE x = ANY(NULL::bigint[]);

可視の行バージョンが HOT更新された場合、デッドタプルとなった以前のバージョンでロックが取得されるかもしれず、直列化の保証に微妙に失敗する可能性がありました。

このタイミングでログに記録されないインデックスの検査をする必要はありませんでした。この検査はいくつかのワークロードでかなりのパフォーマンスの問題を引き起こしていました。また、理論的にはデッドロックを引き起こす可能性もありました。

この誤りはアサート失敗をもたらします。アサートを無効にした本番ビルドに悪影響があるかどうかは不明です。

ALTER SYSTEM自体ではそのような状態は発生しませんが、postgresql.auto.conf を変更する外部ツールでは発生する可能性があります。対象パラメータの重複したエントリが削除され、新しい設定が (ある場合) 最後に追加されるようになります。

これまでは ALTER SYSTEMコマンドは重複エントリに対して、実際に適用されるのは末尾エントリであるにもかかわらず、先頭のエントリだけを書き換えしていました。

以下にメッセージの違いを示します。

(変更前: include = '')
LOG:  input in flex scanner failed at file "/var/lib/pgsql/11/data" line 1
FATAL:  configuration file "/var/lib/pgsql/11/data/postgresql.conf" contains errors

(変更前: include = '/var/lib/pgsql/11/data/postgresql.conf')
LOG:  could not open configuration file "postgresql.conf": maximum nesting depth exceeded
FATAL:  configuration file "/var/lib/pgsql/11/data/postgresql.conf" contains errors

(変更後: include = '')
LOG:  empty configuration file name: ""
FATAL:  configuration file "/var/lib/pgsql/11/data/postgresql.conf" contains errors

(変更後: include = '/var/lib/pgsql/11/data/postgresql.conf')
LOG:  configuration file recursion in "/var/lib/pgsql/11/data/postgresql.conf"
FATAL:  configuration file "/var/lib/pgsql/11/data/postgresql.conf" contains errors

時期によって変化する UTCオフセットを持つ時間帯が指定されている場合、オフセットを解決できるように日付も必要です。使用される構文によっては、この検査が強制されず、誤った出力が生成される場合がありました。

(誤動作の例)
=# SELECT '12:53:57 m11'::timetz;
      timetz
-------------------
 12:53:57+09:18:59
(1 row)

(エラーになるのが修正後の正しい動作です)
ERROR:  invalid input syntax for type time with time zone: "12:53:57 m11"

レコード引数が NULL であり、複合型が宣言されていない場合は、代わりに AS句を使用してみてください。これは推奨される使用法ではありませんが、バージョン11 より前は機能しており、今では再び使用できます。AS句を使用するなら、json[b]_to_record() 関数を使用すべきです。

(変更前)
=# SELECT * FROM json_populate_record(null::record, '{"a":1,"b":2}')
     AS x(a int, b int);
ERROR:  record type has not been registered

(変更後)
=# SELECT * FROM json_populate_record(null::record, '{"a":1,"b":2}')
     AS x(a int, b int);
 a | b
---+---
 1 | 2
(1 row)

(推奨される方法)
=# SELECT * FROM json_to_record('{"a":1,"b":2}') AS x(a int, b int);
 a | b
---+---
 1 | 2
(1 row)

(クラッシュの再現例)
=# SELECT * FROM xmltable('.' PASSING '<foo/>'
                          COLUMNS a text PATH 'foo/namespace::node()');
server closed the connection unexpectedly

GIN ポスティングリストの項目は、隣接するインデックス付き TID間の距離が16TB を超える場合、7 バイトを必要とします。ロジックの 1 つのステップがそれと同期していなかったため、6バイトのバッファに値を書き込もうとする可能性がありました。原則としてこれはスタックオーバーランを引き起こす可能性がありますが、ほとんどのアーキテクチャでは、次のバイトが未使用のアライメントパディングである可能性が高く、バグは無害です。いずれにせよバグに遭遇することは稀です。

NULL 以外の列値に対して計算された距離の一部が Infinity または NaN である場合、問い合わせの出力順序が誤っている（通常の並び替えの結果とは異なる）可能性があります。

以下に順序が異常である例を示します。

(変更前)
=# SELECT * FROM point_tbl ORDER BY f1 <-> '0,1';
        f1
-------------------
 (10,10)
 (NaN,NaN)
 (0,0)
 (1e-300,-1e-300)
 (-3,4)
 (-10,0)
 (-5,-12)
 (5.1,34.5)

 (1e+300,Infinity)
(10 rows)

(修正後)
=# SELECT * FROM point_tbl ORDER BY f1 <-> '0,1';
        f1
-------------------
 (0,0)
 (1e-300,-1e-300)
 (-3,4)
 (-10,0)
 (10,10)
 (-5,-12)
 (5.1,34.5)
 (1e+300,Infinity)

 (NaN,NaN)
(10 rows)

NULL をインデックスのサポート関数まで廻さないようにして、クラッシュの可能性を回避します。

通常は内部状態は変わらないため再同期は不要です。しかし、接続がいくつかのサーバの内の 1つにつながる場合など、稀なケースでは問題になる可能性がありました。

この変更により、psql は、たとえば SSL が使用されているかどうかなど、起動時に発行される対話型メッセージを再発行します。

（問題の再現例）
$ psql
psql (11.5)
Type "help" for help.

postgres=#

（ここでPostgreSQL11サーバを停止して、PostgreSQL12サーバを起動する）

postgres=# SELECT 1; 
FATAL:  terminating connection due to administrator command
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: Succeeded.

postgres=# df
ERROR:  column p.prokind does not exist
LINE 5:  CASE p.prokind
              ^
HINT:  Perhaps you meant to reference the column "p.probin".

（サーバが変わったことを認識していないためエラーが生じました）

「psql -f」など、引数のあるオプションを引数無しで渡したときに、musl の libc ライブラリでクラッシュしました。

以前の修正により、pg_dump は常に pg_opfamily を参照するようになりましたが、そのカタログはバージョン 8.3 より前には存在しませんでした。

これにより、pg_restore の動作が他のいくつかのアプリケーションと統一されます。特に、12 より前のバージョンは 12 の pg_restore と同様に動作し、複数の PostgreSQL バージョン間で動作するダンプ/リストアスクリプトの作成が簡単になります。この変更の前、pg_restore はそのようなオプションを - という名前のファイルへの出力を意味すると解釈していましたが、それを望む人はほとんどいませんでした。

これまではファイル読み取りエラーを、読み取り中のファイル内容削除と見做して、無視していました。今後はそれ以外のケースについてエラーを出すようになります。

fsync が遅い場合、以前のコーディングではタイムアウトエラーが発生する可能性がありました。

ジョブ数が多すぎるエラーを出すかどうかの判断を、より正確にファイル記述子の数を調べて行うように変更されました。

複合型が完全に削除され、PL/pgSQL 関数の実行の間に同じ名前の新しい型が作成される場合が対象となります。複合型の変数は、新しい定義に一致するように更新されます。

ログ取得なしインデックスには、この状況で有効なデータが含まれているとは限らないため、チェックしなくなりました。

array_column <@ constant_array のような句はインデックス可能と見なされますが、インデックス検索では空の配列値が見つからない場合があります。

このための唯一の実用的なバックパッチ可能な修正では、<@ のインデックス検索でインデックス全体をスキャンする必要があります。つまり、単純なシーケンシャルスキャンよりも問い合わせの性能が低下する可能性が高いことを意味します。

この変更によって性能に悪影響が及ぶアプリケーションには、いくつかの選択肢があります。このバグのない GIN インデックスに切り替えるか、array_column <@ constant_array をarray_column <@ constant_array AND array_column && constant_array に置き換えることができます。これにより、以前とほぼ同じ性能が得られ、指定された定数配列の空ではないすべてのサブセットが検索されます。

xlc 13 以降では、この関数を PostgreSQL での使用方法と互換性のない方法で解釈するため、使用できない PostgreSQL のビルドが発生しました。代わりにカスタムアセンブリコードを使用して修正されました。

フィジーおよびノーフォーク島の夏時間法の変更に加えて、アルバータ、オーストリア、ベルギー、ブリティッシュコロンビア、カンボジア、香港、インディアナ（ペリー郡）、カリーニングラード、ケンタッキー、ミシガン、ノーフォーク島、韓国およびトルコの歴史的な修正が含まれます。

場合によっては、ビューは、pg_dump がビューよりも後にダンプする必要があるオブジェクトに依存する場合があります。最も一般的な例は、主キー列で GROUP BY を使用する問い合わせが、主キーなしでは意味的に無効である可能性があることです。これは、ビューの列名と型を確定するだけのダミーの CREATE VIEW コマンドを発行し、その後、完全なビュー定義で CREATE OR REPLACE VIEW を発行することで処理されます。以前は、ダミー定義は実際には CREATE TABLE コマンドであり、これは後の CREATE RULE コマンドによって自動的にビューに変換されました。新しいアプローチは、PostgreSQL バージョン 10 以降で正常に使用されています。以前の方法ではビューのレプリカアイデンティティの状態に関して誤ったエラーメッセージが発生するという報告のため、古いリリースにパッチが適用されました。また、この変更により、このようなビューを含むリストア中に --clean オプションを使用しようとする際の問題も回避されます。

（変更前のダンプ出力）
$ pg_dump

CREATE TABLE public.v (
    c1 integer,
    c2 text
);

COPY public.t (c1, c2) FROM stdin;
.

ALTER TABLE ONLY public.t
    ADD CONSTRAINT t_pkey PRIMARY KEY (c1);

CREATE RULE "_RETURN" AS
    ON SELECT TO public.v DO INSTEAD  SELECT t.c1,
    t.c2
   FROM public.t
  GROUP BY t.c1;

（変更後のダンプ出力）
$ pg_dump

CREATE VIEW public.v AS
SELECT
    NULL::integer AS c1,
    NULL::text AS c2;

COPY public.t (c1, c2) FROM stdin;
.

ALTER TABLE ONLY public.t
    ADD CONSTRAINT t_pkey PRIMARY KEY (c1);

CREATE OR REPLACE VIEW public.v AS
 SELECT t.c1,
    t.c2
   FROM public.t
  GROUP BY t.c1;

python、python3、python2 の順番で検索し、configure が、単なる python という名前の実行ファイルが存在しないという、ごく一般的な状況で成功するようになりました。PYTHON 環境変数を設定することにより、この選択をオーバライドすることも可能です。

一時関数の発効には長らく、pg_temp.func_name(args) という明示的な一時スキーマの指定が必要でした。これは、pg_temp.type_name(arg) と関数風の構文を使って一時データ型にキャストする場合も同様に必要です。そうでないと一時オブジェクトを使って関数呼び出しを横取りすることができて、8.2.4バージョンで防止された CVE-2007-2138 の脆弱性と同様の方法で、権限拡大を狙うことが可能でした。

一時スキーマとは一時オブジェクトのためのスキーマです。pg_temp_1 など番号を伴う名前が自動付与されますが、指定する場合には pg_temp という名前で代表させることができます。また、search_path に明示的な pg_temp の指定が無いと一時スキーマは優先して選択されます。

本修正後は、以下例の最初の型キャストは使用できず、型キャストのための処理に進む前にエラーになります（後者の 2つもエラーですが、これらは型キャスト処理が働いた結果のエラーです）。

db=# CREATE DOMAIN pg_temp.nonempty AS text CHECK (VALUE <> '');

db=# SELECT nonempty('');
ERROR:  function nonempty(unknown) does not exist
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

db=# SELECT pg_temp.nonempty('');
ERROR:  value for domain nonempty violates check constraint "nonempty_check"

db=# SELECT ''::nonempty;
ERROR:  value for domain nonempty violates check constraint "nonempty_check"

ハッシュ化された副プランは、ハッシュ要素を比較するために外側の問い合わせの元の比較演算子を使用していました。その演算子が型を跨る場合は、全てのハッシュ要素が副問い合わせの出力型になるので、これは誤りでした。PostgreSQL本体に含まれるハッシュ可能な型を跨る演算子に対して、64bitマシンでは、この誤りはほぼ無害です。しかし、32bitマシンでは、クラッシュやサーバメモリの不当なデータ露出になる可能性があります。

以下の問い合わせは = 演算子が text型と副問い合わせからの name型（外側と異なるデータ型）との間で適用され、副問い合わせ結果が「hashed SubPlan 1」として扱われるので、問い合わせの形状としては本問題に該当します。

explain (verbose)
  SELECT 'foo'::text IN (SELECT 'bar'::name UNION ALL SELECT 'bar'::name);

拡張モジュールが、より大きなリスクをもたらすハッシュ可能な型を跨る演算子を提供しているかもしれません。

これは一つ前のマイナーリリースで混入した障害です。変更された列のインデックスが適切に処理されていませんでした。

インデックスを持つ列をいくつかデータ型変更する ALTER TABLE に対して、以下のエラーになる動作が報告されました。

ERROR:  relation "《インデックス名》" already exists

特にトリガで実現されている外部キー制約で該当します。

本修正前には、トランザクションのコミット時に処理すべきトリガが削除されてしまったことで COMMIT時にエラーが生じる可能性がありました。

（例）
db=# CREATE TABLE t4_1(f1 int primary key);
db=# CREATE TABLE t4_2(f1 int REFERENCES t4_1 DEFERRABLE INITIALLY DEFERRED)
       PARTITION BY RANGE (f1);
db=# CREATE TABLE t4_2_p1 PARTITION OF t4_2 FOR VALUES FROM (0) TO (10);
db=# INSERT INTO t4_1 VALUES (1);
db=# BEGIN;
db=# INSERT INTO t4_2 VALUES (1);
db=# ALTER TABLE t4_2 DROP CONSTRAINT t4_2_f1_fkey;
（修正後はここで以下のようなエラーが生じる）
ERROR:  cannot ALTER TABLE "t4_2" because it has pending trigger events
db=# COMMIT;
（修正前はここで以下のようなエラーが生じる）
ERROR:  relation 16123 has no triggers

本修正前は「CREATE TRIGGER ... EXECUTE FUNCTION my_trigger_func('my params', 123);」などとして付与した引数が欠落してコピーされていました。

ALTER TABLE ... DROP COLUMN はパーティションキーである列の削除を拒絶します。しかしながら、間接的な削除（キー列のデータ型をカスケード削除する場合など）では、このようなチェックが働かず、キー列の削除を許していました。この結果、パーティションテーブルが壊れて、アクセスも削除もできなくなるおそれがありました。

本修正は、キー列の削除を要するカスケード削除の際にはパーティションテーブル全体を削除するという要素を pg_depend に追加します。これはパーティションテーブルが作られるときに追加されます。したがって、バージョンアップ前に作られた既存パーティションテーブルでは、キー列のみ削除されてしまうリスクが残ります。

この問題は組み込みのデータ型のパーティションキー列では発生しません。したがって、大部分のユーザには無害であると考えられます。

デフォルトパーティションでのみ一部の列を削除してあるなど、列が1対1対応でない場合に誤動作することがありました。

その後の有効なパーティションテーブルに対する操作（パーティション追加など）で、以下のようなエラーが生じる可能性がありました。

ERROR:  attribute 4 of type t7_partition_1 has been dropped

これまではインデックスを作成しようとしたり、インデックスのあるパーティションテーブルに外部テーブルをアタッチするときに、以下のようなエラーが発生していました。

ERROR: cannot create index on foreign table "t8_parted"

これからは外部テーブルのパーティションについては単にインデックスが作られない動作になります。ただし、ユニークインデックスである場合には例えば以下のようなエラーになります。

ERROR: cannot create unique index on partitioned table "t8_parted"

通常、テーブルの主キー列が GROUP BY に含まれる場合は他のグループ化列を安全に除去することができます。主キー列でグループを特定できるからです。しかし、継承テーブルを読む場合には、親子テーブル間、子テーブル間をまたがるユニーク性は保証されないため、この最適化は使えません。

以下の誤動作が報告されました。最後の SELECT は 2行が返るのが正しい動作です。実行プランで c1列がグループ化対象から外れてしまっていました。

db1=# CREATE TABLE t11  (c0 INT PRIMARY KEY, c1 INT);
db1=# CREATE TABLE t11c (c0 INT) INHERITS (t11);
db1=# INSERT INTO t11  (c0, c1) VALUES (0, 0);
db1=# INSERT INTO t11c (c0, c1) VALUES (0, 1);
db1=# SELECT c0, c1 FROM t11 GROUP BY c0, c1;
 c0 | c1
----+----
  0 |  0
(1 row)

この障害により、一部の EXISTS問い合わせからの結果行が重複し、誤った結果が返ります。

修正前も、処理が非効率にはなりますが、問い合わせ結果は正しいです。

PostgreSQLのプランナはインデックスを使って値の最大値、最小値を調べる動作をすることがあります。

プランナが列の最小値や最大値を知るために最近に作られたインデックスを使うとき、最近に無効になった実際には端点値を含まないタプルを誤って選択してしまう可能性がありました。

誤選択したタプルには NULL が入っているかもしれず、最悪の場合は、以下のエラーになります。

ERROR: found unexpected null value in index ...

本障害でよくある挙動は、誤った値が使われてプラン作成におけるデータ推測の品質が劣化することです。

遷移テーブルを使った処理で以下のエラーが出るケースが報告されました。

ERROR:  executor could not find named tuplestore "《NEW遷移テーブル》"

EvalPlanQual処理は、READ COMMITTEDトランザクション隔離モードでの行の更新で使われる内部的な仕組みです。

外部キーの全列が同じデータ型でない場合に、ALTER TABLEが外部キーの再検証が必要かどうかの判断を誤る可能性がありました。この判断の誤りは常に保守的な方向で、再検証が不要なものを必要と判断すると見られます。したがって、不要な処理による性能上のバグと言えます。

これにより、ANALYZE の際に以下のエラーが出るのを回避します。

ERROR:  tuple already updated by self

複数のトランザクションがトランザクションT1 が行ロックを解放するのを待っていて、T1 がそのロックレベルを格上げするとき、T1終了時に待っているトランザクションの間で偽性の（実際にはデッドロックではない）デッドロックが報告されました。

ここでのロックレベルの格上げとは、「SELECT ... FOR KEY SHARE」 の行ロックを取得している行に対して、次に「UPDATE ...」を行う場合などを指します。

本障害に該当した場合、デッドロック状態がデッドロックエラーにならず、問い合わせがキャンセルされるまで処理がブロックされてしまいます。

本障害が人工的な問い合わせ以外で発生するのかは明らかではありません。通常パラレルワーカがリーダプロセスで取得済みのロック以外を必要とすることは無いため、実際には問題はほぼ起きないと考えられます。

範囲データ型は、ある値以上である値より小さいという半開区間になるように境界値を標準化させます。これを誤って無限値（infinity、-infinity）に対しても同様に試みていました。無限値の場合には干渉しないようになりました。

修正前は以下のような奇妙な振る舞いが生じていました。

db1=# SELECT '[-infinity,infinity]'::daterange @> '-infinity'::date "include?";
 include?
----------
 t
(1 row)

db1=# SELECT '[-infinity,infinity]'::daterange @> 'infinity'::date "include?";
 include?
----------
 f
(1 row)

db1=# SELECT '[-infinity,infinity]'::daterange;
      daterange
----------------------
 [-infinity,infinity)
(1 row)

money型の最大値（あるいは負の最小値）に近い値で以下のように不正確な変換が生じる可能性がありました。

db=# select '-92233720368547758.07'::money, '-92233720368547758.07'::money::numeric(30,2);
           money            |       numeric
----------------------------+----------------------
 $92,233,720,368,547,758.07 | 92233720368547758.00
(1 row)

これは pg_waldump のクラッシュをひき起こしました。

10以前のバージョンで作った Btreeインデックスがあって、それを pg_upgrade でバージョンアップした後のアクセスで問題が生じました。11 でも修正されていますが、実際にアサート失敗が起きるのは 12 の betaバージョンです。

これによって結果がテーブルに直接格納された場合の問題が回避されます。これまでは以下の処理でエラーが発生していました。

db=# CREATE TYPE two_int8s AS (q1 int8, q2 int8);
db=# CREATE FUNCTION compresult(int8) RETURNS two_int8s LANGUAGE plpgsql AS
       $$ DECLARE r record; BEGIN r := ROW($1,$1); RETURN r; END $$;
db=# CREATE TABLE two_int8s_tab (f1 two_int8s);
db=# INSERT INTO two_int8s_tab VALUES (compresult(42));
db=# SELECT f1 FROM two_int8s_tab;
   f1
---------
 (42,42)
(1 row)

(再接続後に実行)
db=# SELECT f1 FROM two_int8s_tab;
ERROR:  record type has not been registered

ごくまれな場合に、Windows形式の改行コードを含むサービスファイルが誤って解析され、接続エラーになっていました。

ユーザ定義 opclass がユーザ定義範囲型のサブタイプ opclass である場合、関連するオブジェクトが誤った順序でダンプされ、リストアできないダンプが生成されていました。

opclass の依存関係を処理する潜在的なエラーはほかのケースでも発生する可能性がありますが、これは唯一知られているケースです。

NULL を Perl の undef値として扱わせて、それを jsonb に変換する場合に以下エラーが出るケースが報告されました。

ERROR:  cannot transform this Perl type to jsonb

これにより、VS 2017 と SDK v10 の組み合わせでビルドする際にSDK v8.1 が無いとビルドに失敗する問題が回避されます。

場合によっては initdbコマンドは実際のゾーン名より優先して、これらの人工的なゾーン名のいずれかを選択していました。

これらの 2 つよりも C ライブラリのタイムゾーンの動作に一致するほうが優先されるようになります。

歴史的に IANA では、この人工的なゾーンに「Local time zone must be set--see zic manual page」のような省略形を設定します。tzdbデータベースの最新バージョンでは代わりに -00 が表示されますが、一部のプラットフォームでは何らか歴史的なフレーズを表示するためにデータを変更します。

最新の省略形が使用される場合に限ってこのタイムゾーンを表示することで、非常に長い文字列が abbrev列に出力されるのが防止されました。

これによって zicコマンドに新しい -b slim オプションが追加され、インストールされたゾーンファイルのサイズを削減できます。現在は使用されていませんが、将来的には有効になる可能性があります。