パブリッシャデータベースまたはサブスクライバデータベースの悪意のあるユーザが、レプリケーションを実行するロール（スーパーユーザであることが多い）によって任意のSQLコードの実行を引き起こす可能性がありました。このリスクのいくつかは CVE-2018-1058で説明されているものと同等で、本修正は、レプリケーションの送信者と受信者が空の search_path 設定で実行されるようにして、リスクを緩和します。CVE-2018-1058 の修正と同様に、この変更によりレプリケートされたテーブルの定義で使用されるスキーマ修飾されていないオブジェクト名で問題が生じるかもしれません。

信頼されていないロールに属するオブジェクトのレプリケートには他にも危険性があり、そのことについてドキュメント記載されました。(CVE-2020-14349)

攻撃者が拡張のターゲットスキーマまたは必須とされているスキーマにオブジェクトを作成できる場合、拡張のインストールスクリプトに対して CVE-2018-1058 と同様の攻撃が行われる可能性があります。拡張のインストールにはスーパーユーザ権限を必要とすることが多いため、これによりスーパーユーザ権限を取得するための道が開かれてしまいます。このリスクを軽減するために、スクリプトの実行で使用される search_path により注意を払う、check_function_bodies 設定を無効にしてインストール時のコード実行を回避する、一部の contrib モジュールで使用されているカタログ調整クエリを安全にする、ということが行われました。

ドキュメントに、サードパーティの拡張の作者がインストールスクリプトを安全にするための記述が追加されました。これは完全な解決策ではありません。不注意にインストールされた場合、他の拡張に依存する拡張は依然としてリスクがあります。(CVE-2020-14350)

パーティションキー列が複数あるとき、一部の列に値を限定する WHERE句が無かったり、限定を与える句が複数あったりする場合に、パーティション除外のための検査の生成が誤動作するおそれがありました。これはサーバプロセスのクラッシュ、不正なクエリ結果、アサート失敗をもたらす可能性がありました。

（クラッシュする例の一つ ／ この場合「b >= 2」が無ければクラッシュしない）
db=# CREATE TABLE pt3 (a int, b int, c int, d int) PARTITION BY RANGE (a, b, c, d);
db=# CREATE TABLE pt3_p1 PARTITION OF pt3 FOR VALUES FROM (1,1,1,0) TO (1,1,1,10);
db=# CREATE TABLE pt3_p2 PARTITION OF pt3 FOR VALUES FROM (2,2,2,0) TO (2,2,2,10);
db=# SELECT * FROM pt3 WHERE a >= 1 AND b >= 1 AND b >= 2 AND c >= 2 AND d >= 0;
server closed the connection unexpectedly

このようなスキャンで結合の外側から値を使用する必要がある実行計画は、通常、実行時にクラッシュします。

（実行するとクラッシュするプラン形状の例 ／ pt4a と pt4b はパーティションテーブル）

db=# EXPLAIN (costs off) SELECT * FROM pt4a WHERE NOT EXISTS (
       SELECT FROM pt4b WHERE pt4b.a = pt4a.a AND pt4b.b = pt4a.b + 1 AND pt4b.c = 123)
       AND a = 1 AND c = 120;
                          QUERY PLAN
---------------------------------------------------------------
 Nested Loop Anti Join
   ->  Seq Scan on pt4a_p1
         Filter: ((a = 1) AND (c = 120))
   ->  Bitmap Heap Scan on pt4b_p1
         Recheck Cond: ((c = 123) AND (b = (pt4a.b + 1)))
         Filter: ((a = 1) AND (a = pt4a_p1.a))
         ->  BitmapAnd
               ->  Bitmap Index Scan on pt4b_p1_c_idx
                     Index Cond: (c = 123)
               ->  Bitmap Index Scan on pt4b_p1_b_idx
                     Index Cond: (b = (pt4b.b + 1))
(11 rows)

本障害によりアサート失敗が報告されました。アサートを無効にしている場合、誤った結果やクラッシュがもたらされる可能性があります。また、発生を防ぐ修正に加えて、本ケースはアサートではなく問い合わせのエラーとして報告されるようになりました。

組み込みの論理レプリケーションを使用している場合は、組み込みの walreceiver が（誤った状態をクリアする）フィードバック返信をいずれにせよかなり頻繁に送信するため、これは比較的小さな問題です。しかし、pglogical のような他のレプリケーションシステムでは、重大な性能問題が発生していました。

これまでのコードでは、パブリッシャテーブルとサブスクライバテーブルで列番号が異なる可能性を考慮していませんでした。実際に列番号が異なっていた場合、どのトリガを実行するかについて誤った判断をする可能性がありました。

pg_replication_slot_advance() 関数は以前これができなかったため、レプリケーションスロットを手動で進めた後にリソースのクリーンアップ（不要になったWALセグメントの削除など）を妨げる可能性がありました。

以前の一連のマイナーリリースで追加されたフレーズ検索の修正により、長い文書に対して ts_headline() が不合理に時間を要する可能性がありました。さらに悪いことに時間を要することのあるループ内でキャンセルできませんでした。

以前は読み込むデータの長さが指定されていない場合、これらの関数は stat() によって報告されたファイルの長さで停止していました。これはパイプやその他の種類の仮想ファイルには不適切な動作です。

SQL にも JSON にも 「NaN」(not-a-number) という概念はありませんが、jsonpath のコードはそのような値を許可しようとしていました。これは必然的に非標準の動作につながるため、最初からそのような値を拒否する方が良いと判断されました。

影響を受ける集約は以下です。

      corr()
      covar_pop()
      regr_intercept()
      regr_r2()
      regr_slope()
      regr_sxx()
      regr_sxy()
      regr_syy()
      stddev_pop()
      var_pop()

このような場合の集約された値として「NaN」を返すべきですが、PostgreSQL v12 で導入されたアルゴリズム変更のために 0 を返すようになっていました。

一部の部分集計ワーカーが「NaN」のみを検出し、他のワーカーが「NaN」以外のもののみを検出した場合、結果は誤って結合され全体的に誤った結果（つまり「NaN」であるべき時に「NaN」ではない）になる可能性がありました。

日付時刻入力の仕様は、"24:00:00" またはそれに相当する "23:59:60" を許容しますが、それ以上の値は許容しません。しかし、非ゼロの少数秒を伴う "23:59:60.nnn" を受け入れるように範囲チェックが誤って実装されていました。

タイムスタンプ値では翌日の1秒目に折り返される結果になりました。time や timetz の値では、保存された値は実際には 24時間より大きくなり、ダンプ/リストアの失敗やその他の誤動作を引き起こす可能性がありました。

ALTER TABLE が（例えば、列のデータ型の変更により）テーブル内容を完全に書き換える必要がある場合で、外部キーや CHECK制約を再検証するためにテーブルをスキャンする必要がある場合に、これらが時々間違った順序で行われ、以下のような奇妙なエラーを引き起こしていました。

 ERROR:  could not read block 0 in file "base/16543/17654": read only 0 of 8192 bytes

以前は、テーブルのレプリカID のインデックスをインデックス再構築すると設定が失われ、将来の論理デコード出力に古いタプル値が含まれなくなる原因となっていました。

初期化時のカタログデータは、これら 2つのカタログ列を常に非NULLであると誤って印付けしていました。その印付けが正しいかどうかに依存している主な場所は、JIT有効時のタプル分解です。本修正では影響が出る箇所でこれらの誤った印付けを無視するようにしています。初期化時のカタログデータはバージョン13以降で修正されます。

また、これらの項目の NULL確認を行うコードが追加されました。ただし、NULL確認が無いためにクラッシュする可能性はほとんど無いと考えられます。

アサート失敗や、クエリ実行時のクラッシュにつながる可能性がありました。

（クラッシュを引き起こす問い合わせ例）
db=# CREATE TABLE t22 (a int);
db=# INSERT INTO t22 VALUES (0), (1), (2);
db=# SELECT * FROM t22, LATERAL (
       SELECT t22.a > 1 AS b, 1 AS c FROM (SELECT random() ORDER BY 1) AS v
       UNION ALL
       SELECT true AS b, 2 AS c
     ) AS vt22 WHERE b AND a >= 0;
server closed the connection unexpectedly

以前は、データベースの列の照合順序を使用していましたが、正しくクエリの照合順序を使用するようになりました。

現在は非決定的な照合順序があるので、修正前は非決定的な照合順序が与えられた場合に演算子が完全に失敗するケースがありました。クエリ自体が動作するようなケースでプラン作成が失敗することは望ましくないため、推定の目的で演算子を呼び出す際には、クエリの照合順序を使用しなければなりませんでした。

これは主に、GROUP BY で得られるグループ数のプランナ推定に影響を与えていました。

本ケースはキャンセルされたバキュームの後に合法的に発生する可能性があるので、それに関する警告は過度なものでした。

temp_tablespaces が空か、データベースのテーブルスペースを明示的に指定している場合に、（パラレルハッシュ結合などで用いられる）共有ファイルセットの一時ファイルが期待通りデータベースのテーブルスペースに配置されるのではなく、pg_defaultテーブルスペースに配置されていました。

これにより、wal_consistency_checking設定が有効な場合に偽のエラー報告をする可能性がありました。

（報告されたエラー例）
FATAL:  inconsistent page found, rel 1663/16385/22133, forknum 0, blkno 15
CONTEXT:  WAL redo at 0/739CEDE8 for SPGist/VACUUM_REDIRECT: newest XID 4619

I/O エラーが EOF に到達したことと区別がつかなかったり、全く報告されなかったりするいくつかのケースが修正されました。また、ブロック番号やバイト数などの詳細が追加されました。

buffileモジュールは内部的な一時ファイルの読み書きに使われるものです。

並行して挿入されたタプルが別の並行トランザクションによって更新され、どちらのタプルのバージョンも現在のトランザクションのスナップショットには見えなかった場合、シリアライズ競合チェックは、タプルが現在のトランザクションの結果に関連しているかどうかについて誤った結論を導き出す可能性がありました。 これにより、直列化失敗でエラーにすべき SERIALIZABLEトランザクションのコミットを許容してしまう可能性がありました。

機能的には無害ですが、チェックサムが有効な場合や wal_log_hints = on の場合、無駄な WAL量増大を引き起こしていました。デッド状態とは無効なエントリであることを示すフラグの付いた状態を意味します。

そのようなリクエストは fsync が無効の場合には無視されますが、保留中の処理を保持するハッシュテーブルから削除する対応が漏れていました。この問題によりハッシュテーブルが肥大化し、再度 fsync を有効化した場合に、アサート失敗が発生する可能性がありました。

偽性の警告「WARNING: aborting backup due to backend exiting beforepg_stop_backup was called」や、アサート失敗が報告されました。

この問題により、一貫性のないチェックサムで pg_control が書き込まれる可能性があり、次に書き込む前にクラッシュした場合、データベースを再起動できないなど、あとで問題が発生する可能性がありました。

これらの関数（文書化されておらず、ODBC ドライバの古いバージョンのみで使用）には、クラッシュを発生させたり、パーティションテーブルなど、ストレージのないテーブルに対して呼び出すと、「could not open file」などの混乱を招くエラーメッセージを表示する問題が含まれていました。

レプリケーションスロット関連の処理の一部では、このコーディング規則に違反していました。そのため、関数の呼び出し中にエラーが発生すると、ごくまれにスピンロックがスタックする可能性がありました。

この問題は、アサートが誤っていただけで、通常の製品ビルドには影響ありません。

この修正は、停止しかけのサーバプロセスから最後のエラーメッセージを確実に取得するためだけでなく、読み取りエラーが発生するまで接続が失われたことを考慮せず済ますためにも重要です。これまで、COPY データの転送中に接続が失なわれた場合に、アプリケーションにエラーを報告することなく、永遠に送信し続ける可能性がありました。

GSS暗号化を使用した接続では、サーバの再起動後にリセットしようとしたとき、または候補サーバのリストの次に移動しようとしたとき、フリーズしてしまう可能性がありました。

一部のコードパスでは「could not write file: Success」などのおかしな報告が生成される可能性がありました。

pg_dump では、出力をシークできない（例えば、出力が何かにパイプされている）場合に、そのようなダンプファイルを生成します。この修正により、そのようなダンプファイルでも並列リストアができるようになります。

アクセス権限はテーブル単位を先に付与する必要がありますが、並列リストアではそれを確実に順序づけできていませんでした。この問題により、「tuple concurrently updated」のエラーが発生したり、列単位のアクセス権限が付与されない可能性がありました。この問題はアクセス権限間の依存関係をダンプファイルに含めることで修正しています。そのため、問題が再発しないようにするには、修正された pg_dump でダンプを取得しなおす必要があります。

これまで、対象クラスタで vacuum_defer_cleanup_age が 0 以外に設定されている場合、システムカタログの凍結処理が正しく動作せず、混乱を招くメッセージとともにアップグレードが失敗していました。アップグレード中は設定が上書きされることに注意してください。

この修正がないと、レプリケーションの senderプロセスが送信障害を検出した場合に、レプリケーションスロットの LSN 位置に対して予期した最後の更新をせずに終了する可能性があります。この問題により、再接続時にデータが再送信されたり、pg_recvlogical が受信しようとした最後のデータの後に送信されたエラーメッセージを見逃す可能性がありました。

オンラインのソースクラスタを使用する場合、ファイルを同時に削除できますが、これまで、ファイルのディレクトリエントリを確認してから、stat() でそれを調査するまでの間に削除されると、pg_rewind の動作に混乱が生じていました。

これまで、テキストモードでテストファイルに書き込んでいましたが、これはPostgreSQL での実際の使用方法を正しく反映したものではありませんでした。

この状態は WAL の再生中は正常です。

状況の組み合わせによっては、この問題は dblink_close() が予期しないリモート COMMIT を発行する可能性がありました。

これまで、pgp_sym_encrypt 関数では、zlib の API 要件を正しく処理していなかったため、誤った圧縮データを生成する可能性がありました。標準的なzlib でこのエラーが発生したとの報告はありませんが、IBM の zlibNX 実装を使用した場合に問題が確認されました。

圧縮されたストリームは空のパケットで正常に終了する可能性がありますが、解凍処理はこれに対応しておらず、データが破損しているとのエラーが発生していました。

この問題により、ソースツリーのトップレベルを識別するために、configureを検索する処理に混乱が発生していました。

この修正により、最新バージョンの glibc でもビルドエラーが発生しなくなります。

生成列が、テーブル内の他の列の単なるコピーで、かつ、リファレンス渡しのデータ型（文字列型など）である場合、テーブルに壊れたデータが投入されるかクラッシュを引き起こす可能性がありました。他の列を単に複製する 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以降バージョンでは既にそのようになっています。