自動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」のような誤解を招くエラーメッセージを表示していましたが、より的確なメッセージを表示するように修正されました。

REINDEX CONCURRENTLY を TOASTテーブルまたは TOASTテーブルのインデックスに 適用した場合、破損したインデックスを生成することがよくありました。これは TOASTエントリを更新するセッションが、他の更新の動作と同様にトランザクションがコミットされるまで ROW EXCLUSIVE ロックを保持するのではなく、ROW EXCLUSIVE ロックをすぐに解放したために発生しました。今回 TOAST 更新が通常のルールに従ってテーブルロックを保持するよう修正されました。既存の破損したインデックスは、再度 REINDEX を実行することで修復できます。

VACUUM では、それを指すリダイレクトアイテムが残っている状態で RECENTLY_DEAD のタプルを削除することがありえました。そのようなタプルのアイテムスロットが後に新しいタプルで再利用されると、既存の HOTチェーンの一部とみなされ、インデックス破損が形成されます。

発生した場合はテーブルのインデックス再作成で修復できます。しかし、これは非常に確率の低いシナリオであるため、発生したかもしれないという可能性だけでインデックスを再作成することは推奨されません。

EvalPlanQual再チェックは READ COMMITTED 隔離レベルの問い合わせで使われる処理です。

この見落としにより、COPY でエラーが発生した後、誤ったエラーメッセージやクラッシュが発生することがありました。

この誤りは可変長データ型のマルチ範囲を処理する際にクラッシュを引き起こす可能性がありました。

これにより、「ERROR: could not identify a hash function for type record」（型レコードのハッシュ関数を識別できない）のエラーが防止されます。

場合によっては、Append が単純化されるべきではない時に単純化され、誤った問い合わせ結果（重複した行）が発生することがありました。

単一の子ノードを持つ Appendノードは、例えば「SELECT id, c FROM t1 UNION ALL SELECT id, c FROM t2 WHERE false」といった形を持つ問い合わせのプランで出現する可能性がありました。

インデックスの列にはインデックスオンリースキャンで返すことができるか（返却可能列か返却不能列か）を示す、returnable属性があります。

インデックスが返却可能列と返却不能列の両方を持ち、返却不能列の 1つが返却可能列にあらわれるテーブル列を使用した式である場合、その式を使用した問い合わせは、返却可能列から式を再計算するのではなく、返却不能列を読もうとするインデックスオンリースキャンプランとなる可能性がありました。返却不能列は NULL として読み込まれるため、誤った問い合わせ結果が発生しました。

（障害動作例／ここでの lower(c) は返却不能列）
db=# CREATE TABLE t9 (c text);
db=# INSERT INTO t9 VALUES (md5('A')), (md5('B'));
db=# CREATE INDEX ON t9 USING gist(lower(c) gist_trgm_ops) INCLUDE (c);
db=# SET enable_seqscan TO off;
db=# \pset null *NULL*
db=# SELECT lower(c), c FROM t9;
 lower  |                c
--------+----------------------------------
 *NULL* | 7fc56270e7a70fa81a5935b72eacbe29
 *NULL* | 9d5ed678fe57bcca610140957afab571
(2 rows)

この障害により誤った問い合わせ結果が生じるケースが報告されました。

結合条件に不等号を使っている場合や浮動小数点データ型で 0.0 と -0.0 がある場合などで問題が生じました。この障害により、クラッシュや誤った問い合わせ結果が生じる可能性があります。

強制関数は正しい動作（何もしないこと）を実行しますが、この変換は非効率で望ましくありません。

character(N) 型を bpchar 型にキャストする場合が該当します。

anicompatible* 型の多相パラメータを持つ関数や演算子が、実際には本当は一致しないはずの引数の集合に一致したと、パーサが誤判断することがありました。

報告されたケースでは、一つの呼び出しに複数の演算子を一致させることになり、「ERROR: operator is not unique: ...」「HINT: Could not choose a best candidate operator. You might need to add explicit type casts.」などのあいまいな演算子だというエラーを引き起こしました。一方、より後の処理段階でエラーを起こすこともあり得ました。

修正されませんが、これは 9.6.x でも該当します。

プライマリ上のアクティブなトランザクションのセットが周回境界を越えている間にスタンバイサーバが起動すると（古いトランザクションよりも小さい XID を持つ新しいトランザクションがいくつか存在するため）、「ERROR: out-of-order XID insertion in KnownAssignedXids」エラーが生じました。再試行されますがこのエラーを乗り越えることはできません。

パブリケーションに子テーブルと親テーブルの両方が含まれ、publish_via_partition_root オプションが設定されている場合、サブスクライバは子テーブルと親テーブルの両方で無駄な同期を開始していました。このような場合は親テーブルのみが同期されるようになりました。

これまでは、引用符で囲まれていないセミコロンを含む SQLコマンド、奇数の一重引用符または二重引用符を含むドル引用符で囲まれたリテラル、または SQLコマンドがコメントで始まる場合、walsenderプロセスがエラーを起こしました。

さらに、不完全なエラーからの回復処理により以降のコマンドでも予期せぬエラーが発生する可能性がありました。

一部のファイルシステムでは、この見落としによりシステムクラッシュ後に論理書き換えの状態ファイルが失われる可能性がありました。

以前のバグ修正により、古い形式の継承ツリーに対する拡張統計の構築が無効になりましたが、パーティションテーブルに対する構築も無効になっており、不要な制限となっていました。今回の変更により、ANALYZE はパーティションテーブルの統計オブジェクトの値を計算できるようになりました。（しかし、autovacuum はパーティションテーブルを自動処理しないので、パーティションテーブルの統計情報を維持したい場合は、パーティションテーブルに対して定期的に手動 ANALYZE を実行する必要があることに注意してください。）

現在、拡張統計情報の値は継承ツリー全体ではなく各テーブルに対してローカルでのみ計算されます。しかし、この値が継承ツリーをまたがる問い合わせを計画する際に誤って参照されたため、デフォルトよりも悪い推定値になる可能性がありました。

この制限は通常のテーブルでは長い間存在していましたが、見落としによりパーティションテーブルではチェックされていませんでした。

同じ禁止事項はすでに主キーインデックスに存在していました。

同時実行中のセッションが、テーブルに主キーがあるかどうかに関する判定を更新できなかったため、不正なロジカルレプリケーションの動作が発生する可能性がありました。

パブリケーションしているテーブルの UPDATE で、テーブルに ALTER TABLE で主キーを設定した後であっても、以下エラーが発生する動作が報告されました。

ERROR:  cannot update table ... because it does not have a replica identity and publishes updates

同時実行中のセッションが、どのインデックスが REPLICA IDENTITY であるかの判定を更新できなかったため、不正なロジカルレプリケーションの動作が発生する可能性がありました。

このような場合は動作すべきでしたが以下のエラーが発生していました。

ERROR:  compress method must be defined when leaf type is different from input type

並列化されていない処理では既に無視されていましたが、並列化されたロジックでは機能していませんでした。その結果、xmin の限界値の前進が抑えられることで、バキュームのクリーンアップが遅れるなどの望ましくない影響がありました。

式インデックスを持つテーブルの多くの行を更新する UPDATE 文は、大量のメモリを消費する可能性がありました。

認証方式が cert の場合、clientcert=verify-full が暗黙的に指定されますが、pg_hba_file_rules ビューは誤って clientcert=verify-ca と報告していました。

以前は、client_min_messages のレベルを高く設定すると、接続しているクライアントにもログメッセージが送信される可能性がありました。これはクライアントが要求していない動作です（そしておそらくワイヤープロトコル違反でした）。

行全体の変数は、var.* として出力されますが、ルールが再ロードされたときに個々の列に展開されるため、異なるセマンティクスとなっていました。これを防ぐために他の場所と同様に明示的なキャストが行われるようになりました。

これまでは、パラメータに名前が付いていても $n と出力されていました。

これによる実際の影響は、アライメントを考慮すれば限定的なものですが、デバッグビルドでは警告が発生していました。

これらの誤りは、製品ビルドではなく、デバッグビルドのみ影響を受けました。

エラーメッセージのローカライズに失敗する可能性がありました。

PQcancel はシグナルハンドラから安全に呼び出すことができるはずですが、strerror は安全ではありません。誤った使用法は、サーバへのキャンセルメッセージ送信に失敗した場合にのみ発生しますので、そのためおそらくこれまで報告がありませんでした。

これはドキュメントの動作と一致し、セッション開始後の SET ROLE または SET SESSION AUTHORIZATION を実行した場合に発生し得るパーミッションエラーを避けます。また、混乱を防ぐために操作対象のロール名がパスワードプロンプトに含まれるようになりました。

パーティションにトリガがあり、親テーブルにも同じ名前の無関係な文レベルトリガが存在した場合、以前のコードでは「ERROR: more than one row returned by a subquery used as an expression」というエラーが発生していました。

これは、psql の \copy コマンド、または pg_recvlogical で「-f -」を付けた場合に影響がありました。「could not stat file」エラーが発生しました。

この誤りに起因する障害報告は確認されていませんが、gettext() は非同期シグナル安全な関数ではなく、安全とは言えません。

以前は、パスワード入力を求められている間、Ctrl+C でこれらのプログラムを終了することができませんでした。

まれに、出力スクリプトがユーザ定義キャストを作成する前に参照してしまう場合がありました。

以前のコードでは、一部のカーネル呼び出しからのエラーをチェックできず、他のケースでは誤った errno 値を報告する可能性がありました。

インデックスオンリースキャンでは末尾の空白が削除された列値が返されましたが、これはインデックス格納方法に起因したもので、想定の動作ではありませんでした。末尾空白の違いだけですが誤った問い合わせ結果です。

空白埋めをした char(N) 値を格納するようにコードが修正されました。インデックスの動作は REINDEX をしない限りすぐには反映されません。 REINDEX（インデックス再作成）をしない場合、空白が削除された値は、更新を行っていくなかで徐々に置き換えられていきます。インデックスオンリースキャン実行計画を使用しない問い合わせは、どの場合でも影響を受けません。

これらのエラーは、外部テーブルのスキャンを並列化しようとすると、クラッシュまたは誤った問い合わせ結果を引き起こす可能性がありました。

これにより Python 3.10 では distutils が非推奨になり Python 3.12 での削除が予定されている configure-time の警告が回避されます。 おそらく、Python 3.12 以降では configure --with-python は完全に失敗します。

sysconfig が Python 2.7 より前、また、Python 3.2 より前にも存在しなかったため、古くなった Python バージョンでの PL/Python のビルドはもはやできなくなります。

configure ではターゲットシステムで /dev/urandom が使用可能であるはずと想定すべきでしたが、代わりに configure が失敗していました。