PostgreSQL 14.19 に関する技術情報

このリリースは 14.18 からの修正リリース（2025年 8月 14日リリース）です。
14.X からのアップデートではダンプ、リストアは不要です。

ただし、BRIN numeric_minmax_multi_opsインデックスを使用している場合には、インデックス再作成することを推奨します。下記の4番の項目を参照してください。

また、14.14 よりも前のバージョンからアップデートする場合には、14.14のリリース情報も参照してください。

PostgreSQL 14.18 から 14.19 への変更点

17.6, 16.10, 15.14, 14.19, 13.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。

プランナの見積もり関数におけるセキュリティチェックが強化されました。 (Dean Rasheed) (17.6)(16.10)(15.14)(14.19)(13.22)

CVE-2017-7484に対する修正およびその後の追加修正は、呼び出し元ユーザーに読み取り権限のない列の統計データに対して、情報漏洩の可能性がある関数が適用されるのを防ぐことを目的としていました。しかし、その対策には見落とされていた点が2つありました。

1つ目の見落としは、パーティションや継承階層に関するもので、テーブルに設定されたRLSポリシーが統計データへのアクセスを制限すべき状況で、実際には制限されていませんでした。

2つ目は、クエリがビューを介してテーブルにアクセスするケースです。この場合、ビューの所有者はビューの基になるテーブルの読み取り権限を持っていても、呼び出し元のユーザーがそのビューに対する権限を持っていないことがあります。これまでの実装では、ビューの所有者の権限がセキュリティチェックを通過させてしまい、その結果、呼び出し元ユーザーのビューに対する権限を確認する前に、基になるテーブルの統計情報に情報漏洩の可能性がある関数が適用されることがありました。この問題は、プランニングの開始時点でビューに対するセキュリティチェックを行うようにすることで修正されました。これにより、以前よりも早い段階で権限エラーが発生する可能性があります。(CVE-2025-8713)

§ § § § § §

pg_dumpスクリプトが、リストアを実行するユーザーへの攻撃に使われるのが防止されました。 (Nathan Bossart) (17.6)(16.10)(15.14)(14.19)(13.22)

ダンプ／リストア操作では通常、SQLコマンドがスーパーユーザーとして実行されるため、ターゲットのデータベース環境は、ソースサーバーを信頼している必要があります。しかしそれは、リストアを実行するためにpsqlを使うOS上のユーザーが、ソースサーバーを信頼しなければならないことを意味するわけではありません。ここでのリスクは、攻撃者がソースサーバー上でスーパーユーザー権限を得ていた場合に、psqlのメタコマンドとして解釈されるようなテキストを出力させることができる点です。これにより、ターゲットデータベースへのアクセスとは無関係に、リストアを実行しているユーザーのアカウントに対し、シェルレベルのアクセスが可能になる恐れがあります。

このような事態が発生しないことを確実にするため、psqlに\restrictコマンドを追加し、それ以降のメタコマンドの実行を禁止できるようにしました。また、pg_dumpがソースサーバーからのデータよりも前にこのコマンドを出力するようにしました。(CVE-2025-8714)

§ § § § § § § §

pg_dumpの出力にあるコメント内の名前に含まれる改行がスペースに変換されるようになりました。 (Noah Misch) (17.6)(16.10)(15.14)(14.19)(13.22)

改行文字を含むオブジェクト名があると、出力スクリプト内に任意のSQLコマンドを挿入することが可能になってしまう問題がありました。（CVE-2025-8714の修正がなければ、psqlのメタコマンドをこの方法で注入することも可能でした。）この種の問題は、CVE-2012-0868によって過去に修正されていましたが、その後の開発によって、いくつかのケースが再び入り込んでしまっていました。(CVE-2025-8715)

§ § § § § §

BRINの組み込み演算子クラスnumeric_minmax_multi_opsが誤った距離計算をしてしまう問題が修正されました。 (Peter Eisentraut, Tom Lane) (17.6)(16.10)(15.14)(14.19)

この関数の結果は、64ビット環境では時々誤りが生じ、32ビット環境では大きく誤った値を返すことがありました。ただし、このロジックはあくまで値をどのように範囲へ統合するかを決定するために使われているだけなので、明確なエラーとして現れることはありませんでした。最悪の場合でも、インデックスの効率が悪くなり、サイズが肥大化する程度です。それでも、numeric_minmax_multi_ops演算子クラスを使用しているBRINインデックスについては再インデックスを行うことが推奨されます。

§ § § § §

元々は存在しなかった受け入れ可能なXML入力サイズに関する上限がなくなりました。 (Michael Paquier, Erik Wienhold) (17.6)(16.10)(15.14)(14.19)(13.22)

libxml2の2.13系の初期リリースに存在したバグへの回避策として、10MBを超えるテキストチャンクを拒否するコードパスを使用していましたが、以前のコードではそのような制限はありませんでした。これら初期リリースは現在では実環境で使用されている可能性は低いため、以前のコードに戻しました。

§ § § § § § § § § § § §

同時更新によるMERGEの不具合が修正されました。 (Dean Rasheed) (17.6)

MERGEがCTEの内部で実行され、かつ対象のテーブルにBEFORE ROWトリガが定義されている場合に、同時に別のUPDATEやDELETEによって対象行が変更されると、MERGEコマンドが失敗することがありました。具体的には、UPDATEの場合はクラッシュを引き起こし、DELETEの場合は誤ったアクションが実行される可能性がありました。

以下、DELETE実行で誤ったアクションが実行される実行例です。

db1=# SELECT * FROM mergetbl;
 id | num | val
----+-----+------
  1 |  50 | init
(1 row)

(セッション1で上記のデータをUPDATE) 
db1=# BEGIN;
db1=*# UPDATE mergetbl SET num = 150, val = 'updated1' WHERE id = 1;
NOTICE:  UPDATE: (1,50,init) -> (1,150,updated1)

(セッション2から、CTEの内部からMERGEを実行する)
db1=# BEGIN;
db1=*# WITH m AS (
  MERGE INTO mergetbl m
  USING (SELECT 1 as id) s
  ON s.id = m.id
  WHEN MATCHED AND num < 100 THEN
    DELETE
  WHEN MATCHED AND num < 200 THEN
    UPDATE SET val = 'updated2'
  RETURNING *
)
SELECT * FROM m;

(セッション1を閉じる)
db1=*# COMMIT;

(セッション2で以下が返る)
NOTICE:  DELETE: (1,150,updated1)
 id | id | num | val
----+----+-----+------
  1 |  1 |  50 | init
(1 row)
→セッション1でnum = 150にしているので、正しくはUPDATEアクションが実行されるべき

(17.6では正しいアクションが実行される)
NOTICE:  UPDATE: (1,150,updated1) (1,150,updated2)
 id | id | num |   val
----+----+-----+----------
  1 |  1 | 150 | updated2
(1 row)

§ §

継承の親テーブルへのMERGEが修正されました。 (Dean Rasheed) (17.6)(16.10)(15.14)

継承の親テーブルへの挿入は、WITH CHECK OPTIONおよびRETURNINGアクションの処理に失敗することで、クラッシュを引き起こしたり、不正確なクエリ結果を生成したりする可能性がありました。

db1=# CREATE TABLE merge_parent (
  id int, value int);
db1=# CREATE TABLE merge_child () INHERITS (merge_parent);
db1=# CREATE VIEW merge_view WITH (security_barrier) AS
SELECT * FROM merge_parent WHERE value >= 0
WITH CHECK OPTION;

(17.5以前は、以下のようにエラーは返ってこず0行として返ってくる)
MERGE INTO merge_view tgt
USING (VALUES (2, -5)) AS src(id, value)
ON tgt.id = src.id
WHEN NOT MATCHED THEN
  INSERT (id, value) VALUES (src.id, src.value)
  RETURNING *;
 id | value | id | value
----+-------+----+-------
(0 rows)

MERGE 0

(17.6では以下のエラーが返ってくる)
ERROR:  new row violates check option for view "merge_view"
DETAIL:  Failing row contains (2, -5).

§ § §

文レベルのトリガを持つテーブルが、パーティションまたは継承の子テーブルになれるように修正されました。 (Etsuro Fujita) (17.6)(16.10)(15.14)(14.19)(13.22)

遷移テーブルを伴う行レベルのトリガは、パーティションや継承の子テーブルでは許可されていません。なぜなら、継承ツリー全体に対する操作では、各子テーブルごとに個別の遷移テーブルを管理しなければならないためです。しかし、この問題は文レベルのトリガには当てはまりません。文レベルのトリガは親テーブルのものだけが実行されるからです。それにもかかわらず、既存のテーブルがパーティションや継承の子テーブルになれるかを判断するコードは、両方の種類のトリガを一律に拒否していました。

§ § § § § §

子テーブルである外部テーブルからの遷移タプルの収集を禁止するよう修正されました。 (Etsuro Fujita) (17.6)(16.10)(15.14)(14.19)(13.22)

PostgreSQLでは、外部テーブルに対して遷移テーブル付きのトリガはサポートされていません。しかし、パーティションや継承の子テーブルが外部テーブルである場合については、これまで見落とされていました。親テーブルに遷移テーブル付きのトリガがあると、外部テーブルである子テーブルから誤った遷移タプルが収集されてしまうことがありました。このようなケースはサポートされていないため、明示的に禁止するようにしました。この修正により、このような場合は、エラー「ERROR: cannot collect transition tuplesfrom child foreign tables」が発生するようになりました。

以下に再現例を示します。

(パーティションの子テーブルが外部テーブルである場合)
db1=# \d
                  List of relations
 Schema |     Name     |       Type        |  Owner
--------+--------------+-------------------+----------
 public | foreigntable | foreign table     | postgres
 public | parenttable  | partitioned table | postgres
(2 rows)

db1=# ALTER TABLE parenttable ATTACH PARTITION foreigntable FOR VALUES IN ('AAA');

(parenttable に対してAFTER INSERT 文レベルトリガ作成)
db1=# CREATE FUNCTION trigger_func() RETURNS trigger AS $$
BEGIN
  RAISE NOTICE 'trigger fired';
  RETURN NULL;
END;
$$ LANGUAGE plpgsql;

db1=# CREATE TRIGGER parenttable_insert_trig
  AFTER INSERT ON parenttable
  REFERENCING NEW TABLE AS new_table
  FOR EACH STATEMENT
  EXECUTE PROCEDURE trigger_func();

db1=# INSERT INTO parenttable VALUES ('AAA', 100);
ERROR:  cannot collect transition tuples from child foreign tables

(17.5 で実行するとエラーは発生しない)
db1=# INSERT INTO parenttable VALUES ('AAA', 100);
NOTICE:  trigger fired
INSERT 0 1

§ § § § § §

予約済みプレフィックス付きの不明なカスタムパラメータのリセットを許可するようになりました。 (Nathan Bossart) (17.6)(16.10)(15.14)

以前は、ALTER DATABASEやALTER ROLE、ALTER SYSTEMを使って保存されたパラメータ設定について、そのパラメータが不明なパラメータであっても、予約済みのプレフィックスを持っていた場合、その設定を削除することができませんでした。このようなケースは、拡張がかつて使用していたパラメータが、拡張のアップグレードで削除された場合などに発生する可能性がありました。

§ § § §

ALTER SUBSCRIPTION ... DROP PUBLICATION実行時に発生しうるデッドロックが修正されました。 (Ajin Cherian) (17.6)(16.10)(15.14)(14.19)

レプリケーションのオリジンを削除する時に、サーバープロセスがカタログロックを一貫した順序で取得するようにして、デッドロックの可能性を防ぐようになりました。

§ § § § §

競合する名前を持つインデックスを作成する際に、競合状態となる時間が短縮されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

インデックスの自動生成名を決定する際、すでに有効なエントリとの競合と同様に、未コミットのエントリとの競合も回避するようになりました。これにより、他のトランザクションで並行してCREATE INDEXが実行されている場合に、まだインデックスの作成中であったり、作成は完了していてもトランザクションがコミットされていない場合に、同じインデックス名を誤って選んでしまう可能性を防げるようになりました。依然として競合が発生する可能性はありますが、これは新しいインデックスのパラメータを検証し、pg_classへの行挿入が完了するまでの短時間だけです。

§ § § § §

1つのコマンドで複数のテーブルをVACUUMする場合に、VACUUMオプションが間違って適用されてしまう問題が修正されました。 (Nathan Bossart, Michael Paquier) (17.6)(16.10)(15.14)(14.19)(13.22)

あるテーブルに対して指定されたTRUNCATE、INDEX_CLEANUPオプションが、他のテーブルにも誤って適用されてしまうことがありました。

§ § § § §

インデックスのないテーブルをVACUUMする際に、そのテーブルの空き領域マップが適切なタイミングで更新されるようになりました。 (Masahiko Sawada) (17.6)

以前の最適化により、そインデックスのないテーブルでは空き領域マップのVACUUM処理がスキップされてしまうことがありました。

§ §

SIMILAR TO正規表現内の文字クラスの処理が修正されました。 (Laurenz Albe) (17.6)(16.10)(15.14)(14.19)(13.22)

SIMILAR TOパターンマッチング式をPOSIX形式の正規表現に変換するコードは、角括弧 [] がネストされ得ることを考慮していませんでした。例として、[[:alpha:]%_]というパターンでは、%と_の文字がリテラルとして扱われるべきですが、コードはそれらをメタ文字として扱っていました。

(17.6では[[:digit:]%]で t が返る)
db=# SELECT '%' SIMILAR TO '[[:digit:]%]',
            '%' SIMILAR TO '[%[:digit:]]';
 ?column? | ?column?
----------+----------
 t        | t
(1 row)

(17.5では f が返る)
db=# SELECT '%' SIMILAR TO '[[:digit:]%]',
            '%' SIMILAR TO '[%[:digit:]]';
 ?column? | ?column?
----------+----------
 f        | t
(1 row)

[%_[:alpha:]]のように前に%_を記述した場合は、修正以前も期待どおりの結果が返ってきていました。

§ § § § § § § § § § § § § § § § §

pg_dumpなどでビューや関数の定義を取得するため、問い合わせを逆解析する際、「FETCH FIRST 式 ROWS WITH TIES」句の式部分を常に括弧で囲むように修正されました。 (Heikki Linnakangas) (17.6)(16.10)(15.14)(14.19)(13.22)

単純でない式は括弧で囲む必要がありますが、型キャスト付きの値などを誤って単純な式と見なし、括弧で囲まず、構文として誤ったSQLを生成する可能性がありました。

(エラー発生例)
$ psql -c "CREATE VIEW v1 AS SELECT * FROM generate_series(1, 10) AS c1 ORDER BY c1 FETCH FIRST (5::bigint) ROWS WITH TIES;" db1
$ createdb db2
$ pg_dump db1 | psql db2
(省略)
ERROR:  syntax error at or near "::"
行 5:  FETCH FIRST (5)::bigint ROWS WITH TIES;
                      ^

checkpointerプロセスのfsyncリクエストキューのサイズを制限するように修正されました。 (Alexander Korotkov, Xuneng Zhou) (17.6)(16.10)(15.14)(14.19)(13.22)

shared_buffersの設定が非常に大きい場合、checkpointerプロセスがfsyncリクエストキューに1GBを越える領域を割り当てようとし、「invalid memory alloc request size」エラーが発生し、リトライを繰り返し、無限ループが発生していました。

§ § § § § § § § § § § §

ロジカルデコーディングで不完全なWALレコードの読み取り時に無限に待機し続けないように修正されました。 (Vignesh C) (17.6)(16.10)(15.14)(14.19)(13.22)

複数ページにまたがるWALレコードの最初の部分を書き込んだ後にサーバがクラッシュした場合、ロジカルデコーティングではWALストリームから次ページのデータが到着するのを待機します。しかし、データが到着することはなく、無限に待機し続けていました。

§ § § § § §

「MultiXactOffsetSLRU」と「MultiXactMemberSLRU」のLWLock待機イベント名の表記ゆれが修正されました。 (Bertrand Drouvot) (17.6)

pg_wait_eventsとpg_stat_activityで待機イベント名が異なっており、これらのビューを結合する監視問い合わせが機能しない可能性がありました。

§ §

pg_classのrelaclなど、データベースオブジェクトのアクセス権限を表す、ACL文字列内のロール名の引用符付けの一貫性のなさが修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

引用符の付け方はロケールに依存していたため、異なる環境に移行する際に移植性の問題が発生する可能性がありました。(pg_dumpではこの問題の影響はありませんが、他のツールでは影響する可能性があります。)一貫性を確保するため、出力時に非ASCII文字を常に引用符で囲むようになりました。ただし、下位互換性を維持するため、入力時に非ASCII文字を引用符で囲む必要はありません。

§ § § § § §

テーブルと外部テーブルのオプション名に等号 (=) を使用できないように修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

このようなオプション名に明確な使用例はなく、許容すると「name=value」という内部形式で格納する際に曖昧さが発生するため、使用できないように修正されました。

§ § § § §

LZ4圧縮されたアーカイブデータの解凍が特定の条件下で失敗する問題が修正されました。 (Mikhail Gribkov) (17.6)(16.10)(15.14)

この問題は圧縮率の低い入力データのみで発生するようで、これまで検出されなかった可能性があります。

§ § § §

btreeインデックスのスキャン処理で稀にインデックスエントリを誤って削除済みとして扱ってしまう問題が修正されました。 (Peter Geoghegan) (17.6)(16.10)(15.14)(14.19)(13.22)

この問題は、マージ結合に伴うスキャンで、同じページに同時に挿入・削除されたエントリがある場合に発生する可能性があり、正しい行が取得できないことや不要なリソースが保持されることがありました。

§ § § § §

論理レプリケーションで他プロセスからのキャッシュ無効化メッセージを再送信しないように修正されました。 (vignesh C) (17.6)(16.10)(15.14)(14.19)(13.22)

以前のマイナーリリースでプロセス間のキャッシュ無効化メッセージに正しく応答するように修正され、更新適用中に古いカタログを参照しないようになりました。しかし、その際に意図せずメッセージを再送信してしまい、メッセージ数が急増し、メモリ割り当てエラーが発生する可能性がありました。

§ § § § § §

レプリケーションスロットの同期設定が誤っていても、サーバが予期せず停止しないように修正されました。 (Fujii Masao) (17.6)

sync_replication_slotsがtrue、かつ、wal_levelがlogical未満の場合、postmasterプロセスはエラーを報告し、停止していました。本来の意図は単にスロット同期を無効にするだけのため、エラーメッセージのレベルを下げ、postmasterプロセスが停止しないようになりました。

§ §

チェックポイント処理中の早過ぎる古いWALファイル削除が回避されました。 (Vitaly Davydov) (17.6)(16.10)(15.14)(14.19)(13.22)

チェックポイント処理中にレプリケーションスロットのリスタートポイントが進行すると、不要になったWALセグメントの早まった削除がなされ、その後すぐにデータベースがクラッシュした場合、リカバリに失敗する可能性がありました。 WALセグメントをチェックポイント1サイクル分、追加で保持するよう修正されました。

§ § § § §

レプリケーションスロットの確定済みフラッシュ位置を後方に移動しないようになりました。 (Shveta Malik) (17.6)(16.10)(15.14)(14.19)(13.22)

場合によっては、レプリケーションクライアントが永続的に保存したLSNよりも過去のLSNを確認し、再起動後に古いLSNを送信する可能性がありました。クライアントが2つのポイント間のWALに対して何もする必要がないなら、これはバグとは言えません。ただし、データ重複を避けるため、そのWALを再送信すべきではありません。そのため、作成されたスロットに対しては常に最新の確認済みLSNを信頼するようになりました。

論理レプリケーションで予期せぬデータ重複コンフリクトが出る障害例が報告されました。

§ § § § §

新しい論理レプリケーションワーカを起動する前に過剰な遅延が発生しないようになりました。 (Tom Lane) (17.6)(16.10)

場合によっては、論理レプリケーションランチャーが新しいワーカを起動する前に、設定されたwal_retrieve_retry_intervalよりもかなり長い時間スリープすることがありました。

§ §

INSERT ... ON CONFLICTの論理レプリケーション中のメモリ解放後使用（use-after-free）が修正されました。 (Ethan Mertz, Michael Paquier) (17.6)(16.10)

これにより、進捗状況の報告が不正確になる可能性があり、非常に運が悪ければ、wal senderプロセスがクラッシュする可能性がありました。

§ § §

スタンバイサーバでのトランザクション待機を中断できるようになりました。 (Kevin K Biju) (17.6)(16.10)(15.14)(14.19)(13.22)

スタンバイサーバでのレプリケーションスロットの作成には、プライマリサーバでのアクティブなトランザクションが終了し、その後スタンバイサーバでリプレイされるまで待機する必要がある場合がありました。これは無期限の待機となる可能性があるため、操作をキャンセルできるようにすることが望ましいのですが、ループ内でクエリのキャンセルがチェックされていませんでした。

§ § § § §

物理レプリケーションのスタンバイサーバで動作する論理wal senderが、スタンバイサーバでリプレイ済のデータのみ送信するようになりました。 (Alexey Makhmutov) (17.6)(16.10)

以前は未リプレイでもフラッシュ済のデータを送信しようとしていました。そのためにスタンバイサーバのシャットダウンに際して、startupプロセスが停止してWALリプレイがそれ以上進まないために、論理wal senderが無限に待機することがありました。

§ §

自動VACUUMにおけるリレーションごとのメモリリークが修正されました。 (Tom Lane) (17.6)(16.10)(15.14)

§ § §

XMLSERIALIZE(... INDENT) でのセッション存続期間のメモリリークが修正されました。 (Dmitry Kovalenko, Tom Lane) (17.6)(16.10)

§ § § § §

「バンプ」アロケータを使用して大きなメモリブロックを割り当てる際、メモリ不足となった後に発生する可能性のあるクラッシュが修正されました。 (Tom Lane) (17.6)

スナップショットなしでシステムカタログのTOASTされたフィールドを取得しようとする箇所が修正されました。 (Nathan Bossart) (17.6)(16.10)(15.14)(14.19)(13.22)

これにより、アサート失敗が発生したり、エラー「ERROR: cannot fetch toast data without an active snapshot」が発生する可能性がありました。

§ § § § §

複数のテーブルまたがる制約がある場合に、制約を更新するとアサート失敗する問題が修正されました。 (Tom Lane, Jian He) (17.6)(16.10)(15.14)(14.19)(13.22)

例えば、アサートを有効にした環境では以下のクエリを実行するとアサート失敗が発生していました。

(修正前のアサート失敗発生例)

=# CREATE TABLE t1(a int);
=# CREATE TABLE t2(b t1 CHECK ((b).a IS NOT NULL));
=# ALTER TABLE t1 ALTER COLUMN a TYPE numeric;

§ § § § § § § § § § §

内部実装関数PortalRunMulti() の終了時点で必ずコマンドタグが決定されているとする誤ったアサートが削除されました。 (Álvaro Herrera) (17.6)(16.10)(15.14)(14.19)(13.22)

このアサートは、空のプリペアドステートメントの実行などの特殊なケースで失敗していました。

§ § § § § §

XMLTABLEのパース処理でアサート失敗する問題が修正されました。 (Richard Guo) (17.6)(16.10)(15.14)

XMLTABLE式では、列にNOT NULLを指定することが可能であり、これを表現するために、パーサーは内部的に「is_not_null」というオプション名を生成していました。しかし、パーサーはユーザーが任意のオプション名を指定できるようにもしているため、ユーザーが同名の「is_not_null」を明示的に使い、真偽値以外の値を割り当てた場合、内部の前提が崩れてアサートが失敗してしまう問題が発生していました。

今回の修正では、ユーザーが指定したオプション名が内部の予約名と衝突していないかをチェックし、衝突していた場合はエラーを出すようになりました。さらに、内部で使うオプション名を「__pg__is_not_null」に変更することで、ユーザー定義名との衝突リスクも低減されています。

§ § §

PL/pgSQLで式を並列実行できる機能が復元されました。 (Dipesh Dhameliya) (17.6)(16.10)(15.14)(14.19)(13.22)

この機能は以前は利用可能でしたが、過去のバグ修正によって意図せず無効化されてしまっていました。

§ § § § § §

PL/Pythonにおけるエラー報告処理で発生する特殊なケースのメモリリークが修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

Pythonからのエラーを報告する際にメモリ不足が発生すると、Python オブジェクトの参照カウントを適切に減らす処理が失敗する可能性がありました。その結果、セッション全体にわたってメモリが解放されずに残存してしまう問題が起こることがありました。

§ § § § § § § § § §

hostaddrを使ってサーバのアドレスを指定した場合に、libpqのPQcancelCreate()関数が正しく動作するよう修正されました。 (Sergei Kornilov) (17.6)

これまではPQcancelCreate()が生成したキャンセル用のオブジェクトを実際に使用するとlibpq がセグメンテーション違反によりクラッシュする問題がありました。

§ §

libpqのPQport()関数が修正され、引数として渡された接続がNULL でない限りこの関数はNULLを返さないようになりました。 (Daniele Varrazzo) (17.6)(16.10)(15.14)(14.19)(13.22)

これは仕様として文書化されていますが、バージョン10以降のlibpq ではユーザーがポートを指定しなかった場合にNULL を返すケースがありました。この挙動が仕様どおりに戻され、NULLを渡された場合には空文字列""を返すようになりました。ただし、バージョン18以降では、コンパイル時に設定されたデフォルトのポート番号として、通常は5432が返されるようになります。

§ § § § § §

GSSAPI認証で16kBを超えるパケットが必要な場合に、認証処理が失敗しないよう修正されました。 (Jacob Champion, Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

Active Directoryのグループに多数所属しているユーザーでは、より大きな認証パケットが必要ですが、16kBをパケットサイズの上限としていました。この制限により、エラー「GSSAPI context establishment error:The routine must be called again to complete its function: Unknownerror」などが発生し、接続が失敗するケースがありました。

§ § § § §

SSLおよびGSSAPIによるデータ送信におけるタイミング依存の失敗が修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

SSLまたはGSSAPIでの暗号化をノンブロッキングモードで使用している場合、エラー「SSL error: bad length」または、エラー「GSSAPI callerfailed to retransmit all data needing to be retried」というメッセージを出力し、処理が失敗することがありました。

§ § § § §

ECPGアプリケーションにおける接続の検索時に、NULLポインタ参照が発生しないよう修正されました。 (Aleksander Alekseev) (17.6)(16.10)(15.14)(14.19)(13.22)

この問題は、接続名がNULLの接続と非NULL接続少なくとも2つの接続が存在する状況で発生する可能性がありました。

§ § § § § §

psqlのタブ補完がCOPYおよび\copy のオプションについて改善されました。 (Atsushi Torikoshi) (17.6)(16.10)(15.14)(14.19)

COPY FROM とCOPY TOで同じオプションが提示されていましたが、これからは FROMかTO かを区別して、適したオプションだけ提示するようになります。

§ § § § §

pgbench で、複数のパイプライン同期メッセージを受けたときのアサート失敗が回避されました。 (Fujii Masao) (17.6)(16.10)(15.14)

これはパイプラインモードを使用する場合の問題です。

§ § § §

pg_createsubscriberコマンドでサブスクリプションを初期化するときの、トランザクションリプレイの重複が修正されました。 (Shlok Kyal) (17.6)

サブスクライバのリカバリ中に処理された最後のトランザクションが、通常のレプリケーションが開始されたときに再送されてしまう可能性がありました。

§ §

pg_dumpがドメイン型におけるNOT NULL制約のコメントを確実にダンプするようになりました。 (Jian He, Alvaro Herrera) (17.6)

§ §

pg_dumpがドメイン型の制約のコメントを有効な順序で出力するようになりました。 (Jian He) (17.6)(16.10)(15.14)(14.19)(13.22)

これまで、制約を作成する前にそのコメントを付与するコマンドがあらわれる場合がありました。

§ § § § § §

全ての種類のデータベースオブジェクトについて、pg_dumpで安定したソート順を保つようになりました。 (Noah Misch, Andreas Karlsson) (17.6)(16.10)(15.14)(14.19)(13.22)

pg_dumpは依存性に基づく並び替えをする前に、オブジェクトをその論理名でソートしますが、ルールや制約などいくつかのオブジェクト種別については、OIDでのソートが行なわれており、論理的に同じデータベースで異なる出力順になる可能性がありました。このため、ダンプ出力を比較してオブジェクト差異を調べることが難しくなっていました。

§ § § § § § § § § § § § § § § § §

pg_dumpのフィルタファイルでオブジェクトタイプの誤った解析が修正されました。 (Fujii Masao) (17.6)

キーワードとして次の空白文字までを解釈すべきところ、次にアルファベット、数字、アンダースコア以外の文字が現れるところまでを解釈していました。このため、「table_data」を誤って「table-data」と書いた場合にエラーにならずに「table」と解釈される、といった動作が生じていました。

§ §

pg_restoreが、PostgreSQL 12より前のバージョンの pg_dumpで作られたディレクトリ形式のダンプからのラージオブジェクトのリストアにできない障害が修正されました。 (Pavel Stehule) (17.6)

（修正前のエラー発生例）
$ pg_restore -d db1 db1.d
pg_restore: error: could not open large object TOC file "db1.d/3210.dat" for input: No such file or directory

pg_upgradeで一貫しない継承されたNOT NULL制約を検査するようになりました。 (Ali Akbar) (17.6)(16.10)(15.14)(14.19)(13.22)

PostgreSQL 18 より前のバージョンでは、継承された列のNOT NULL制約を除去できました。しかしながら、これはリストア不能な定義をもたらし、pg_upgradeが失敗しました。このような場合をpg_upgradeが事前検査で検出できるようになりました。

§ § § § § § § § § § § § § § § § § § § § § § § § § § § §

pg_upgrade でターゲットデータベースクラスタの postgresql.conf の max_slot_wal_keep_size に設定があるときエラーが発生していたものが、修正されました。 (Dilip Kumar) (17.6)

これまではデフォルトの -1 であることが必要でした。

§ §

initdb実行時に（すなわち-cで指定して）、track_commit_timestampが有効であるときのアサート失敗が回避されました。 (Hayato Kuroda, Andy Fan) (17.6)(16.10)(15.14)(14.19)(13.22)

§ § § § § §

pg_waldumpが「PREPARE TRANSACTION」のWALレコードで、不正な情報（削除された統計）を表示していたものが、修正されました。 (Daniil Davydov) (17.6)(16.10)(15.14)

§ § §

contrib/dblink の接続確立のときに接続リークの可能性があり、回避されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

新たな接続オブジェクトを作るときにout of memoryエラーを起こした場合に、オープンされたリモートサーバへの接続がローカルサーバへのセッションが終了するまでの間、リークして、リモートサーバ上でアイドルセッションが残りました。

§ § § § §

contrib/pg_prewarmで巨大なshared_buffers設定に対処できるようになりました。 (Daria Shanina) (17.6)(16.10)(15.14)(14.19)(13.22)

これまではshared_buffersがおよそ5000万ページ（400GB）を超えるとき、自動プレウォームでメモリ割り当てエラーが発生して動作しませんでした。

§ § § § §

contrib/pg_prewarm において、アサート失敗が発生しないよう修正されました。 (Masahiro Ikeda) (17.6)

ストレージを持たないビューなどのリレーションに対してpg_prewarm()を実行すると、アサート付きビルドでは失敗していました。非アサートビルド時では実害はありませんでしたが、このようなケースをエラーとして拒否するよう修正されました。

contrib/pg_stat_statementsで、正規化されたクエリの$1、$2などのパラメータ番号に欠番が生じないよう修正されました。 (Sami Imseih) (17.6)(16.10)(15.14)(14.19)(13.22)

(欠番が発生する例)
=# SELECT WHERE '1' IN ('2'::int, '3'::int::text);
=# SELECT query from pg_stat_statements WHERE query LIKE '%SELECT WHERE%';
                            query
--------------------------------------------------------------
 SELECT WHERE $1 IN ($3::int, $4::int::text)
(1 row)

§ § § § §

contrib/postgres_fdwのメモリリークが修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

DirectModifyメソッドの呼び出しの途中でクエリが失敗した場合に、リモート側の更新コマンドの結果を保持するPGresultがセッション終了まで解放されないメモリリークが発生していました。これはRETURNING句でデータを処理する際に起こる可能性がありました。

なお、DirectModifyメソッドとは外部テーブルにUPDATE等のDMLコマンドを実行できるようにする内部実装コードです。

§ § § § §

configureの--with-includesおよび--with-librariesオプションで指定されたディレクトリが、システム標準ディレクトリよりも先に検索されるようになりました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

これらのオプションを利用する一般的な理由は、ユーザがビルドしたライブラリをシステムが提供するライブラリより優先して使えるようにするためです。しかし、makefileが発行するコマンドのオプション順序が不適切だったため、一部の環境ではこの目的のために使えませんでした。

§ § § § § §

configureでの__cpuid()および__cpuidex()のチェックが修正されました。 (Lukas Fittl, Michael Paquier) (17.6)(16.10)(15.14)(14.19)(13.22)

これらのWindows固有の関数をconfigureが正しく検出できなかったために利用されず、ハードウェア命令の利用可否を確認できずにCRC計算が本来より遅くなる問題がありました。ただし、Windowsでの商用環境向けのビルドでは、通常はAutoconfツールチェーンを使用しないため、この不具合の影響は限定的です。

§ § § § § §

Solaris系プラットフォームで--with-pamオプションを指定した場合ビルドが失敗する問題が修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

Solarisでは、PAM認証のAPIが他のUNIX系プラットフォームと異なっており、その結果inconsistent pointerというコンパイラ警告が出力されていました。これまでは警告であるため対応されていませんでしたが、GCC 14以降では警告ではなくデフォルトでエラー扱いとなるため、修正されました。

§ § § § § §

GNU Hurdへ移植できるようコードが修正されました。 (Michael Banck, Christoph Berg, Samuel Thibault) (17.6)(16.10)(15.14)(14.19)(13.22)

GNU Hurdでは、他のUnix系OSで一般的に定義されているIOV_MAXやO_RDONLYが存在しない点が考慮されていませんでした。IOV_MAXが未定義の場合には16とみなす旧来の処理を復活させるなど、GNU Hurd環境に対応する修正が行われました。

§ § § § § § § § §

memset_s()の使用をC11標準に厳密に準拠するよう修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

これにより一部のプラットフォームでのコンパイル失敗が回避されました。

§ § § § § §

MSVCでMesonを利用してビルドする際に、互換性に関する警告が出力されていたものが修正されました。 (Peter Eisentraut) (17.6)(16.10)

§ §

JSONBの比較を行う内部実装関数compareJsonbContainers()で、未初期化値に関するコンパイラ警告が出力されないよう修正されました。 (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)

§ § § § § §

libxml2 2.14以上を利用してビルドした際に、deprecatedである旨の警告が出力されていたものが、修正されました。 (Michael Paquier) (17.6)(16.10)(15.14)(14.19)(13.22)

§ § § § § §

pg_locale.hをC++ でコンパイルする際の問題が修正されました。 (John Naylor) (17.6)(16.10)(15.14)(14.19)(13.22)

PostgreSQLのヘッダファイルは、C++で書かれた拡張からインクルードできるように、通常は「extern "C" { ... }」で囲む必要がありますが、pg_locale.hではlibicuのヘッダを使用しているためにこれが失敗していました。libicuヘッダ内のC++専用の宣言を利用しないようにすることで修正されました。

C++で書かれた拡張でlibicuのC++ API を利用したい場合は、pg_locale.hより前にlibicuのヘッダをインクルードする必要があります。

§ § § § § §

SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

PostgreSQL 14.19 に関する技術情報

PostgreSQL 14.18 から 14.19 への変更点

最近の投稿

カテゴリー

PostgreSQL 14.18 から 14.19 への変更点

関連記事:

最近の投稿

カテゴリー

タグ