PostgreSQL – SRA OSS Tech Blog

pgsql-hackersウォッチ（2026年9月）

長田悠吾 (Yugo Nagata) — Tue, 06 Oct 2026 02:38:59 +0000

今回は、PostgreSQL の開発者向けメーリングリストである pgsql-hackers で、2026年9月に行われた議論の中から、筆者が注目した話題を紹介します。網羅的なまとめではなく、筆者が追跡した範囲での内容となります。

PostgreSQL 19 で相次いだ機能の差し戻し

PostgreSQL 19 のリリースを目前に控えた9月は、複数の新機能が差し戻し（revert）されるという異例の月となりました。

まず、SQL標準のプロパティグラフ問い合わせ機能である SQL Property Graph Queries (SQL/PGQ) が差し戻されています。この機能では、グラフを構成する頂点や辺、ラベル、プロパティなどをシステムカタログで管理していました。しかし、それに伴って依存関係が複雑化し、グラフ削除後に不要なメタデータが残る問題や、ダンプ・リストア時の問題などが報告されていました。議論では、既存の依存関係管理の仕組みそのものを見直す必要があるのではないかという意見も出て差し戻しとなりました。

また、Temporal Table 機能の一部である UPDATE/DELETE FOR PORTION OF も差し戻されました。この機能はレコードが持つ期間情報の一部分のみを更新または削除するものですが、それによって残りの期間を表す新しい行が発生します。この新しく生成された行が、READ COMMITTED 分離レベルで並行実行される更新処理から適切に認識されず、その結果として更新結果が失われる Lost Update 発生の可能性が受け入れがたい問題として捉えられました。

さらに、外部キー参照整合性チェック高速化機能のうち、複数行をまとめて確認するバッチ処理部分が差し戻されています。外部キー参照整合性チェックの高速化は、チェックを SQL 実行ではなく直接インデックス検索で行うことによる性能改善ですが、複数行をまとめて処理する際のスナップショット取得タイミングや、他の機能との相互作用によって不整合が生じる可能性が指摘されていました。そのためバッチ処理部分が差し戻されましたが、1行単位で実行する高速化部分は維持されています。

このほか、オンラインでデータチェックサムを有効化・無効化する機能についても、コミット後に多数の修正が必要となったことから差し戻しが行われました。

グラフ処理や Temporal Table 機能など、データベースとしての可能性を広げる機能が差し戻しとなったのは残念ではありますが、これら新しい機能実装と、既存機能との相互作用や依存関係管理、並行実行制御といった PostgreSQL の深い部分との関わりが表面化した例として興味深く感じました。

TOAST の改善

一方で、PostgreSQL 20 に向けた開発として、TOAST 関連の改善が進展しています。

TOAST とは PostgreSQL で大きなデータをテーブルに格納するための基盤で、データを圧縮・分割して専用の TOAST テーブルへ格納します。その管理に利用する OID（Object ID）を従来の 4 バイトから 8 バイトへ拡張する機能がコミットされました。

従来の 4 バイトの TOAST OID では、大量のデータを扱うシステムでは枯渇する可能性があり、データ行の挿入時に未使用 OID を探索する必要があり、そのオーバーヘッドによる性能低下も課題となっていました。新しい方式ではテーブル単位のオプションによって 8 バイト OID を利用できるようになり、未使用 OID を探索する必要がなくなることから性能改善も期待されています。

また、TOAST の圧縮方式拡張も議論されています。現在利用できる圧縮方式は pglz と lz4 の2種類のみですが、将来的により多くの圧縮方式を追加できるようにするための基盤整備が提案されています。最初の追加候補としては ZSTD が予定されています。

圧縮プロトコル

通信性能改善に関する提案として、プロトコル圧縮にも進展がありました。

これは、バックエンドからフロントエンドへ送られるデータを圧縮する提案です。過去の議論でカバーする機能を広げすぎて合意に至らなかった反省から、今回は機能を絞る方向で議論が進められています。対象となるのはSELECT や COPY 文で送られる行データで、圧縮方式としては ZSTD のみをサポートする方向で検討されています。また、コネクションプーラとの互換性を維持するため、トランザクション境界で圧縮フレームをリセットする仕組みも議論されています。

UNDO ログエンジン

リカバリ関連では、新しい UNDO ログエンジンの提案がありました。

PostgreSQL は REDO ログ（WAL）を中心とした設計を採用しており、トランザクションの変更を取り消すための UNDO ログは持っていません。そのため、更新・アボートの繰り返しでテーブルやインデックスが膨張したり、クラッシュ時に作成途中のファイルがディスク上に残る（孤立ファイル問題）が課題となっていました。過去にも zheap など UNDO ログベースのテーブルアクセスメソッドの提案がありましたが、今回の提案は新しいテーブルアクセスメソッドから出発するのではなく、まず汎用的な UNDO 基盤を用意しようというアプローチです。

提案では、共通の UNDO 情報は通常の WAL に記録し、アクセスメソッド固有の UNDO 情報は別領域で管理します。また、アボートされたトランザクションや UNDO の進捗を一元管理し、実際の UNDO 処理はバックグラウンドで実行することで、高速なリカバリの実現を目指しています。

まずは UNDO ログを用いた孤立ファイルの削除やアボート済みデータの回収を対象とした機能を先行して実装し、その後に新しいテーブルアクセスメソッドへの応用を検討する構想となっています。新しいテーブルアクセスメソッドから作るのではなく、UNDOログのための新基盤の整備から始めるという方向性は興味深いものに感じました。

ブルームフィルタによるハッシュ結合改善

以前にも紹介した、ブルームフィルタ（Bloom Filter）を利用したハッシュ結合の改善についても引き続き議論が続いています。

これは、ブルームフィルタを利用することで、結合先に存在しない行をスキャン段階で除外できるため、大幅な性能向上が期待できるという提案ですが、9月には、プランナにおけるブルームフィルタ適用後の行数の見積もりについて議論されていました

提案の一つでは、ブルームフィルタを近似的な semi-join （結合先に存在する行だけを残す結合）とみなしてコストベース最適化へ組み込む方法が示されています。これは、SIGMOD 2025 で発表された論文（Including Bloom Filters in Bottom-up Optimization）を参考にしたものです。一方で、コストベースの最適化では正確な行数推定は難しくプラン処理も複雑になるという意見も出されています。その回避策の実例として、実行時に実際のデータを見て振る舞いを動的に調整する SQL Server の実装について紹介した論文（I Can’t Believe It’s Not Yannakakis: Pragmatic Bitmap Filters in Microsoft SQL Server, CIDR 2026）が引き合いに出されていました。そうした懸念から、プランナではブルームフィルタの存在は考慮せず実行時に可能ならば適用する方式を推す声も上がっています。

PostgreSQL のプラン処理にブルームフィルタの存在をどのように組み込むかという議論は、理論と実装をどう結びつけるかという観点からも興味深いと感じており、今後も注目していきたいと思います。

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

PostgreSQLのデータ型を「なんとなく」で選ばない

正野裕大 (Yuta Masano) — Thu, 01 Oct 2026 05:25:11 +0000

PostgreSQLでテーブルを作るとき、保存する値が決まっていても、データ型の選択に迷うことがあります。注文コードには、長さを指定できるvarchar(n)を使うのか、textでよいのか。金額にはnumericを使うのか、円単位なら整数型でよいのか。日時や外部APIのレスポンスにも、複数の保存方法があります。

テストデータを少し入れるだけなら、どの型でも問題なく動くように見えるかもしれません。しかし、注文コードの形式が変わったり、金額を集計したり、海外拠点の時刻を扱ったり、決済レスポンスを検索したりすると、型の違いが表面化します。型を選ぶときは、値を保存できるかだけでなく、保存後にどう使うかまで考えます。

この記事は、SQLの基本を理解し、これからテーブルを設計する方に向けた入門向け記事です。架空の注文管理テーブルordersを例に、文字列、数値、日付時刻、JSONの型を用途別に検討します。型選びに関わる性質と判断理由に絞って説明します。

例では、注文コード、単価、数量、注文日時などを保存します。まずテーブルを定義し、各列の型を用途に照らして確認します。

この最初の定義には、後で見直す候補としてdouble precisionとjsonをあえて含めています。以降の章で、金額の正確さやJSON検索の必要性に応じて、型を変更する条件を確認します。

CREATE TABLE orders (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY -- 注文を一意に識別するID。値はPostgreSQLが自動で採番する。
  , order_code varchar(16) NOT NULL                  -- 注文コード。最大16文字の文字列を必ず入れる。
  , customer_memo text                               -- 顧客からのメモ。業務上の長さ制限を設けず、入力は任意。
  , unit_price numeric(12, 2) NOT NULL               -- 商品1個あたりの単価。全体で12桁、小数点以下2桁。
  , quantity integer NOT NULL                        -- 注文数量。整数値を必ず入れる。
  , total_amount double precision NOT NULL           -- 注文金額の合計。必ず入れる。
  , ordered_at timestamp without time zone NOT NULL  -- 注文日時。必ず入れる。
  , payment_payload json                             -- 決済サービスなどから返されたJSON形式のデータ。
);

1. 文字列型は上限と条件の表し方で選ぶ

1.1. `char(n)`を選ぶ場面は限られる

注文コードのように形式が決まった文字列には、固定長のchar(n)も候補に見えます。ただし、char(n)は入力が指定した長さに満たない場合、末尾に空白を補います。また、char同士の比較では末尾の空白を無視します。そのため、末尾の空白を値の一部として区別したい列には向きません。

CREATE TEMP TABLE order_code_char (
  code char(5) NOT NULL
);

INSERT INTO order_code_char VALUES ('hi');

SELECT code, char_length(code), octet_length(code), code = 'hi   ', code = 'hi'
FROM order_code_char;
 code  | char_length | octet_length | ?column? | ?column?
-------+-------------+--------------+----------+----------
 hi    |           2 |            5 | t        | t
(1 row)

この例では、'hi'の末尾に3つの空白を補ってchar(5)の幅で保存しています。char_length(code)は末尾の空白を数えないため2を返しますが、octet_length(code)は、このASCII文字列では5を返します。空白を含む'hi 'との比較も、含まない'hi'との比較もtrueです。固定長を指定しても、入力された文字列をそのまま区別して保存できるわけではありません。

性能面でも、char(n)を選ぶ利点はありません。公式文書の「8.3. 文字型」によると、PostgreSQLのchar(n)には固有の性能上の利点がありません。空白埋めで保存領域が増えるため、char(n)、varchar(n)、textの中では通常最も遅い型です。新規設計ではchar(n)を避け、最大長を制限するならvarchar(n)やCHECK制約を検討します。

1.2. `varchar(n)`は文字数の上限を型に記せる

orders.order_codeには、最大16文字を保存できるvarchar(16)を指定しています。varchar(16)は、char(n)のように後ろに空白文字を補わず、指定した文字列をそのまま保存します。初期の注文コードが次の形式なら15文字なので、後ろに空白文字が付くことなく保存できます。

CREATE TEMP TABLE orders_code_varchar (
  order_code varchar(16) NOT NULL
);

INSERT INTO orders_code_varchar VALUES ('OD-000000000001');

発番側の仕様変更で注文コードに日付が加わると、上限を超える場合があります。次の値は18文字なので、同じ列には保存できません。

INSERT INTO orders_code_varchar VALUES ('OD-20260801-000001');
ERROR:  value too long for type character varying(16)

これはvarchar(n)の長さ制限によるエラーです。公式文書の「8.3. 文字型」では、character varying(n)、つまりvarchar(n)は最大n文字を保存できる型と説明されています。通常の挿入では、超過分がすべて空白の場合を除き、上限を超える入力はエラーになります。ここでいうnはバイト数ではなく文字数です。

varchar(n)を使うときは、現在のデータが収まるかに加えて、上限の根拠を確認します。注文コードの仕様が変わったら、発番側の変更に合わせてデータベース側の上限も見直します。

1.3. 長さの上限は型か制約で表す

注文コードの上限が業務仕様として「最大18文字」と決まっているなら、varchar(18)を使えます。型定義から最大長が分かり、上限を超える入力はデータベースが拒否します。上限を変える場合は、列の型定義を変更します。

文字列型と業務上の条件を分けて定義するなら、textとCHECK制約を組み合わせる方法もあります。CHECK制約は、条件式がFALSEになる値を拒否します。条件式がNULLになる値は通過するため、NULLも拒否する場合はNOT NULL制約を併用します。次の定義では、text型の注文コードをOD-で始まる18文字以下の値に制限しています。

CREATE TEMP TABLE orders_code_text (
  order_code text NOT NULL,
  CONSTRAINT orders_code_format_check CHECK (
    order_code LIKE 'OD-%'
    AND char_length(order_code) <= 18
  )
);

CHECK制約では、長さと接頭辞の条件を同時に定義できます。上限を変えるときは、列の型を維持して制約を変更します。長さだけを型に記すならvarchar(n)、長さを含む業務条件をまとめて管理するならtextとCHECK制約、というように条件の表し方で選べます（CHECK制約）。

この使い分けは、短い文字列にはvarchar(n)、長い文字列にはtextという性能上の区別ではありません。公式文書の「8.3. 文字型」によると、長さ制限の検査や空白埋めの負担を除けば、文字列型の間に性能差はありません。orders.customer_memoのように業務上の長さ制限がない列には、textを使えます。

1.4. 保存できる文字列でもB-treeインデックスに入らない場合がある

長い文字列を保存できることと、その値全体をインデックスのキーにできることは別です。たとえばorders.customer_memoをtextで保存できても、その列にB-treeインデックスを作成できるとは限りません。B-treeは等価比較や範囲検索などに使うインデックスですが、1件のインデックスエントリにはサイズ上限があります。

PostgreSQLは、テーブルやインデックスをページ（データを格納する単位）に分けて管理します。標準的なページサイズは8 KiBです。公式文書の「B-treeインデックス」によると、1つのインデックスエントリは、1ページのおよそ3分の1（8 KiBのページでは約2.7 KiB）を超えられません。TOASTによる圧縮が適用される場合は、圧縮後のサイズが制限の対象です。そのため、テーブルには保存できても、値全体をキーにするとINSERTやCREATE INDEXがエラーで失敗します。値を切り詰めて登録することはありません。

たとえば、圧縮されにくい文字列を保存してからB-treeインデックスを作成すると、次のようなエラーが発生します。エラーメッセージのbuffer pageは、上述のページを指しています。

CREATE TEMP TABLE long_memo (
  memo text
);

INSERT INTO long_memo
SELECT string_agg(md5(random()::text), '')
FROM generate_series(1, 200);

CREATE INDEX ON long_memo (memo);
ERROR:  index row size 6416 exceeds btree version 4 maximum 2704 for index "long_memo_memo_idx"
DETAIL:  Index row references tuple (0,1) in relation "long_memo".
HINT:  Values larger than 1/3 of a buffer page cannot be indexed.
Consider a function index of an MD5 hash of the value, or use full text indexing.

この例では、文字列自体はtext列に保存できますが、値全体をB-treeのキーにできないため、CREATE INDEXが失敗しています。既にインデックスがある場合は、同じ値をINSERTした時点でインデックスへの追加に失敗します。INSERT文はエラーで取り消されるため、テーブルに行だけが残ることもありません。この単一列のtextインデックスでは、サイズ制限を回避するために値を途中で切り詰めて登録することはありません。切り詰めた部分だけを使って、異なる値を同一視する動作もありません。

この制限はtextだけでなく、大きなvarchar(n)にも当てはまります。長い文字列を検索するときは、検索方法に合ったインデックスを選びます。単語単位の検索には全文検索とGINインデックス、完全一致検索にはハッシュ値を使った式インデックスなどが候補です。ハッシュ値には衝突の可能性があるため、利用者はハッシュ値の条件に加えて元の値との比較条件も検索に含めます。PostgreSQLは、指定された元の値との比較条件を評価し、ハッシュ値が一致した候補から検索対象を絞り込みます。

2. 数値型は必要な正確さと値の範囲で選ぶ

2.1. `double precision`は2進数で表せる値しか正確に扱えない

金額の計算や比較を10進数の規則どおりに行うなら、double precisionは使いません。冒頭のorders.total_amountは、必要な桁数を指定したnumericに変更します。一方、測定値や統計計算のように近似値を許容し、計算速度や表現できる値の範囲を優先する用途では、double precisionを使えます。

double precisionは小数を扱えますが、2進数で有限桁に表せない値は近似値になります。税率や割引率を使って金額を計算し、小数点以下まで正確に扱う場合には、この性質が問題になります。

numericとdouble precisionの違いは、次の計算で確認できます。どちらも0.1 + 0.2が0.3と等しいかを比較しています。

SELECT 0.1::numeric + 0.2::numeric = 0.3::numeric AS numeric_equal;
 numeric_equal
---------------
 t
(1 row)

SELECT 0.1::double precision
     + 0.2::double precision = 0.3::double precision AS double_equal;
 double_equal
--------------
 f
(1 row)

numericではtrue、double precisionではfalseになります。0.1は2進数で有限桁に表せないため、double precisionでは近似値として扱われます。一方、numericは10進数の値を正確に扱うため、この計算では期待どおりの比較結果になります（浮動小数点数データ型）。

整数だけなら、double precisionでも−2の53乗から2の53乗までの整数をすべて正確に保存できます。正数の上限は約9,000兆です。この範囲の金額を1円単位で保存するだけなら、浮動小数点表現による誤差は生じません。また、0.5のように2進数で正確に表せる小数もあります。ただし、税率や割引率を使った計算には、0.1のように近似値になる小数が含まれることがあります。整数を正確に保存できても、その後の計算まで正確とは限りません。

0.1のように2進数で有限桁に表せない小数が計算に含まれると、その値は近似になります。そのため、金額を10進数の規則で計算・比較し、丸めを管理したい要件にはdouble precisionは向きません。orders.total_amountにはnumericを使います。

2.2. 金額には`numeric`、個数には整数型を使う

10進数として正確に扱う金額には、必要な桁数を決めてnumericを使います。numeric(precision, scale)のprecisionは全体の桁数、scaleは小数点以下の桁数です。orders.unit_priceのnumeric(12, 2)は、全体で12桁、小数点以下2桁を指定しています。指定より多い小数桁の入力は、まず2桁に丸められます。丸めた後の整数部が10桁を超える値は保存できません。orders.total_amountにも同じ考え方を使えますが、合計額に必要な桁数は単価とは分けて確認します。

金額を常に円単位の整数として扱うなら、integerやbigintに保存する設計も選べます。この場合も、税率や割引率の計算で小数が出たとき、どの時点で丸めるかを決めます。orders.quantityのような個数や回数には整数型を使い、想定する値の範囲に応じてintegerかbigintを選びます。

近似値を許容できる値には、double precisionを検討します。測定値や統計計算の結果など、10進数としての厳密な一致より計算速度や表現できる値の範囲を優先する用途です。小数を含むかどうかだけでなく、どの程度の正確さが要るかでnumericと使い分けます。

2.3. 新規設計では`money`型より`numeric`を優先する

金額を保存する型にはmoneyもありますが、新規設計ではnumericを優先します。moneyの表示形式や小数部の精度は、データベースのlc_monetary設定に依存します。設定が異なるデータベースへダンプをリストアすると、ダンプに含まれるmoneyの文字列表現をリストア先のlc_monetaryで解釈できず、読み込みに失敗することがあります。読み込みに成功しても、表示形式や小数部の扱いが変わる可能性があります。また、moneyを整数で割った結果は、表現できない小数部を0方向へ切り捨てます。負数の場合も、絶対値が小さくなる方向です。そのため、moneyはデータベースの設定と、演算に組み合わせる型の規則を意識して使う必要があります（通貨型）。

moneyは既存スキーマとの互換性など、明確な理由がある場合に検討します。通貨記号を含む表示が必要なら、numericの値をto_charで整形できます（データ型書式設定関数）。たとえば、to_char(unit_price, 'L999G999G999G990D00')で通貨記号、桁区切り、小数点以下の表示形式を指定できます。ordersの金額列では、保存したnumericの値を計算や比較に使い、画面に表示するときだけto_charで表示用の文字列に変換します。

3. 日付時刻型は保存したい時刻の意味で選ぶ

orders.ordered_atの型を選ぶには、注文日時として何を記録するのかを決めます。受信した表記をそのまま残すのか、特定の地域の日付と時刻を記録するのか、注文が起きた一瞬を記録するのかで選択が変わります。ここでは文字列型、timestamp without time zone、timestamp with time zoneを比較します。

3.1. 受信した表記を残すなら文字列型を選べる

受信した表記をそのまま残す必要があるなら、文字列型を選べます。UTCとの時差を表すオフセットやタイムゾーン名、部分的な日時、仕様外の値も、監査記録として保存できます。PostgreSQLや、JDBCやODBCなどのデータベースドライバに日時として解釈・変換させず、アプリケーション側だけで解釈する方針にも合います。

ただし、文字列型では日時としての妥当性は保証されません。データベースで日時の範囲検索や演算をするなら、日付時刻型を使います。検索と受信原文の保存の両方が必要なら、検索用の日付時刻型列と原文用の文字列列を分けます。

文字列の並び順を日時順として使うには、入力形式と照合順序（文字列比較の規則）を統一します。たとえば日付をYYYY-MM-DDにそろえ、桁数、精度、表記規則を固定すれば、文字列の順序を日付順として利用できます。ただし、異なるタイムゾーンの日時を同じ列に保存すると、表記上の順序と実際の時系列が一致しない場合があります。形式と照合順序を統一するだけで目的を満たせるか確認が必要です。

3.2. `timestamp without time zone`は時差を変換しない

orders.ordered_atに指定したtimestamp without time zoneは、日付と時刻を保存しますが、タイムゾーン情報は持ちません。タイムゾーン付きの文字列を入力しても、時差の部分は無視されます。次の例では、同じ入力をtimestamp with time zoneにも保存し、セッションのタイムゾーンを変えて表示を比較します。

SET TIME ZONE 'Asia/Tokyo';

CREATE TEMP TABLE orders_time (
  ts_without timestamp without time zone,
  ts_with timestamp with time zone
);

INSERT INTO orders_time VALUES
('2026-07-01 09:00:00+09', '2026-07-01 09:00:00+09');

SELECT ts_without, ts_with FROM orders_time;
     ts_without      |        ts_with
---------------------+------------------------
 2026-07-01 09:00:00 | 2026-07-01 09:00:00+09
(1 row)

SET TIME ZONE 'UTC';

SELECT ts_without, ts_with FROM orders_time;
     ts_without      |        ts_with
---------------------+------------------------
 2026-07-01 09:00:00 | 2026-07-01 00:00:00+00
(1 row)

ts_withは、Asia/Tokyoでは09:00:00+09、UTCでは00:00:00+00と表示されます。一方、ts_withoutはどちらでも09:00:00です。timestamp without time zoneでは、入力に含まれる+09を使った変換も、表示先のタイムゾーンに合わせた変換も行われません。

timestamp without time zoneが適するのは、特定の地域の日付と時刻そのものを扱う場合です。たとえば、店舗の営業開始日時やシフト開始日時なら、timestamp without time zoneを検討できます。その場合は、どの地域の日時かを店舗や拠点の情報と一緒に管理します。注文が実際に起きた時点を複数の地域から比較する用途には、次のtimestamp with time zoneが適しています。

3.3. `timestamp with time zone`は同じ一瞬を保存する

timestamp with time zoneは、タイムゾーンを考慮して日時を扱います。明示的なタイムゾーンを含む入力はUTCに変換して保存し、出力時にはセッションのTimeZoneに合わせて表示します。入力時のタイムゾーン名や+09という指定自体は保存しません。

注文受付時刻、決済完了時刻、ログ発生時刻のように、同じ一瞬を複数の地域から比較するなら、timestamp with time zoneが適しています。orders.ordered_atをこの用途に使うなら、timestamp without time zoneから変更する候補になります。前節の例で表示が変わったのは、保存した一瞬はそのままに、表示先のタイムゾーンに合わせて変換したためです。

ただし、タイムゾーンのない入力をtimestamp with time zoneに渡すと、セッションのTimeZoneで解釈されます。アプリケーションの接続設定、データベースドライバによる日付時刻型への変換、取得後の表示設定が一致しないと、意図しない時刻として扱われる可能性があります。入力にタイムゾーンを含めるか、セッションのTimeZoneを固定するかを決め、取得後の表示先も明確にします。

保存したい値ごとの選択肢をまとめます。日付時刻型の仕様は、公式文書の「日付/時刻データ型」と「日付/時刻の入力」を参照してください。

表したいもの	選択肢
注文受付、決済完了、ログ発生のような同じ一瞬	`timestamp with time zone`
特定の地域における、ある日の営業開始日時やシフト開始日時	`timestamp without time zone`
受信した表記、部分的な日時、仕様外の日時をそのまま保存	`text`または`varchar`
日付時刻型の値と受信原文の両方が必要	日付時刻型列と原文用文字列列を分ける

4. JSON型は原文の保持と検索の必要性で選ぶ

4.1. `text`、`json`、`jsonb`は保存後の用途が異なる

orders.payment_payloadには、決済サービスから返されたJSON形式のデータを保存します。保存先にはtext、json、jsonbがあり、受信内容をどこまでそのまま残すか、保存後にどう検索するかで選びます。

textはJSONとして検証しないため、JSONとして不正な文字列も保存できます。NUL文字だけは保存できません。これは、PostgreSQLのtext型自体がNUL文字を保存できないためです。実装上のサイズ上限は約1GBです。JSONとしての妥当性を検証せず、受信内容を残すことが目的なら候補です。

jsonは入力がJSONとして正しいことを検証し、入力されたテキストを保存します。空白、キーの順序、重複キーも保持します。冒頭の定義のようにpayment_payloadをjsonにすると、JSONとして検証しながら受信時の表記を残せます。

jsonbは入力を解析し、分解した形式で保存します。そのため、保存後の検索や比較に向いています。入力時に変換が必要ですが、GINインデックスも利用できます。一方、空白やキーの順序は保持されず、重複キーは最後の値だけが残ります。次のSQLで、重複キーの扱いを比較できます。

SELECT '{"a": 1, "a": 2, "active": false}'::json;
               json
-----------------------------------
 {"a": 1, "a": 2, "active": false}
(1 row)

SELECT '{"a": 1, "a": 2, "active": false}'::jsonb;
            jsonb
---------------------------
 {"a": 2, "active": false}
(1 row)

jsonでは2つのaが入力どおりに残りますが、jsonbでは最後の値である2だけが残ります。受信時の表記を保持するならjson、JSONとしての検証もせず文字列を残すならtext、JSONの内容を検索・比較するならjsonbを選びます。

4.2. JSONのキーや値を検索するなら`jsonb`を使う

決済レスポンスのトップレベルにerror_codeキーがある注文を調べるなら、orders.payment_payloadをjsonbにする方法があります。冒頭のテーブル定義どおり列がjson型の場合、次の検索を実行するとエラーが発生します。?演算子はjsonb型に対して定義されているためです。

SELECT id
FROM orders
WHERE payment_payload ? 'error_code';
ERROR:  operator does not exist: json ? unknown
LINE 3: WHERE payment_payload ? 'error_code';
                              ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.

列をjsonbに変更すると、同じ条件でキーの有無を調べられます。

ALTER TABLE orders
  ALTER COLUMN payment_payload TYPE jsonb
  USING payment_payload::jsonb;

SELECT id
FROM orders
WHERE payment_payload ? 'error_code';
 id
----
(0 rows)

jsonやtextで保存し、検索のたびにjsonbへ変換する方法もあります。ただし、変換が必要になり、インデックスも検索式に合わせて定義しなければなりません。

検索量が増えたら、jsonb列へのGINインデックスも検討します。GINは、JSONのキーや値などを使った検索に利用できるインデックスです。標準のGIN演算子クラスでは、キーの存在、包含、JSONPathによる検索などを扱えます。詳しくは公式文書の「JSONデータ型」と「jsonbインデックス」を参照してください。

5. まとめ: 列の用途から型を決める

ordersの各列を見直すと、値の形式だけでは型を決められないことが分かります。注文コードには長さの上限、金額には計算の正確さ、注文日時にはタイムゾーンの扱い、決済レスポンスには原文の保持と検索方法を考える必要があります。

文字列では、最大長を型に記すならvarchar(n)、業務条件を制約で管理するならtextとCHECK制約を検討します。char(n)は空白埋めと比較規則に注意が必要で、性能上の利点もないため、新規設計で選ぶ場面は限られます。また、長い文字列を保存できても、値全体をB-treeインデックスのキーにできるとは限りません。

数値では、10進数の正確さが必要ならnumeric、整数で足りるなら値の範囲に応じてintegerかbigintを選びます。double precisionは近似値を許容できる用途に使い、金額では丸める時点と規則も決めます。moneyは設定や演算規則に依存するため、新規設計で使う場合は注意が必要です。

日付時刻では、同じ一瞬を扱うならtimestamp with time zone、特定の地域の日付と時刻を扱うならtimestamp without time zoneを検討します。受信した表記を残すために文字列型を選ぶこともできますが、その場合は日時としての妥当性や比較方法を別途管理します。

JSONでは、受信文字列を検証せずに残すならtext、JSONとして検証して入力テキストを保持するならjson、内容を検索・比較するならjsonbが候補です。決済レスポンスを記録として残すのか、内容を使って注文を検索するのかで、適する型が変わります。

テーブルを設計するときは、列ごとに保存する値と用途を確かめます。拒否する入力、必要な計算、検索条件が明確になれば、型を選ぶ理由も定まります。

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

pgsql-hackersウォッチ（2026年8月）

長田悠吾 (Yugo Nagata) — Fri, 04 Sep 2026 00:00:31 +0000

今回は、PostgreSQL の開発者向けメーリングリストである pgsql-hackers で、2026年8月に行われた議論の中から、筆者が注目した話題を紹介します。網羅的なまとめではなく、筆者が追跡した範囲での内容となります。

PostgreSQL 19 リリースにむけて

PostgreSQL 19 のリリースに向けた準備が進められています。PostgreSQL のメジャーリリースのリリースノートには、開発だけではなくレビューや開発報告など何らかの形での貢献者の名前リストが掲載されます。これらの名前について、表記揺れや重複、姓と名の順序などを確認する作業が行われました。なお、SRA OSS からも6名（８月時点）の貢献者の名前が含まれています。

一方で、リリース予定機能についてはやや緊迫した状況となっています。きっかけとなったのは、主要開発者の Robert Haas が AI（Claude）を利用して最近の不具合報告を整理し、多数の問題報告が集まっている機能を洗い出したことでした。対象となったのは、外部キー制約の高速化、REPACK / REPACK CONCURRENTLY コマンド、オンライン・データチェックサム有効化、SQL Property Graph Queries（SQL/PGQ）など、PostgreSQL 19 の主要機能です。議論では、それぞれについてリスクを評価し、機能全体または一部を差し戻すべきかどうかが検討されています。

興味深かったのは、こうした状況の背景として、「AI の普及によって従来よりも不具合が発見されやすくなった可能性がある」という意見も出ていたことです。PostgreSQL に限らず、OSS 開発のあり方が変化しつつあることを感じさせる議論でした。

SSIで相次いで報告された不具合

新機能ではなく、長年存在する機能に関する議論として、SERIALIZABLE 分離レベルを実現するための仕組みである、シリアライザブルスナップショット分離（SSI）に関する不具合が多数報告されました。ここ最近で SSI に関係する不具合が合計7件報告され、それぞれについて修正案が議論されています。報告された問題には、一意性制約をすり抜けて主キー重複が発生する可能性があるものや、SAVEPOINT の ROLLBACK 時に直列化異常の情報が失われる可能性があるものなどが含まれています。

SSI は PostgreSQL のトランザクション制御機構の中でも特に複雑な部分の一つです。これらの問題はもともと別々のスレッドで報告されたものですが、開発者の Andrey Borodin によって一つのスレッドへ整理されており、SSI の内部動作や課題を理解するための良い手がかりとなっています。

INSERT SELECT のパラレル化

性能改善に関する議論では、INSERT SELECT のパラレル化に進展がありました。

INSERT SELECT は、SELECT 文の結果をテーブルに挿入するための構文ですが、この SELECT の実行部分をパラレル化することで、大量データのロードを高速化しようという提案です。しかし、テーブルへの挿入時には、トリガや制約、デフォルト値、生成列などの処理が実行される可能性があり、それらを並列実行しても安全かどうかを確認する必要があります。この確認処理自体がオーバヘッドとなり、巨大なパーティションテーブルなどでは特にそれが顕著となります。

この問題に対し、ユーザ自身が事前にテーブルを「並列安全」と宣言する方式も提案されていましたが、その場合はユーザに全ての責任を負わせることになるため、好ましくありません。これに対して8月には、並列安全性を初回アクセス時に自動計算し、その結果をキャッシュする方法が提案されました。さらに、適切なキャッシュの無効化や、SELECTを並列実行した結果を一旦全て一時ファイルに保存してからテーブルに挿入する方式とのハイブリッドなど、さらなる改善の議論が続いています。

リカバリのパイプライン化

もう一つ注目した性能改善提案が、リカバリ処理のパイプライン化です。これは、PostgreSQL のリカバリ（クラッシュリカバリ、アーカイブリカバリ）時に WAL の適用を高速化するための提案です。

現在の PostgreSQL では、リカバリを担当する「startup プロセス」が、WAL の読み込み、デコード、適用をすべて担当しています。提案では、WAL のデコードを専用のバックグラウンドプロセスへ分離し、startup プロセスは WAL の適用に専念する構成となっています。つまり、WAL レコードの生成と消費を異なるプロセスで担当するパイプライン構造であり、これによって、リカバリ処理を20〜42%程度高速化できることが報告されています。

8月には、ロック競合によるオーバーヘッドの削減や、プロセス間シグナル通信の最適化、不正な WAL を検出した場合の責任分担などについて議論が行われました。リカバリアーキテクチャそのものを見直す提案として興味深く感じています。

VACUUMを妨げる要因を可視化する pg_xmin_horizon

運用に関する提案としては、新しいシステムビュー pg_xmin_horizon の議論に進展がありました。

PostgreSQL を運用していると、不要データを削除する VACUUM が期待通りに進まないことがあります。その原因としては、長時間実行中のトランザクションやレプリケーションスロット、プリペアドトランザクションなどが考えられます。現在も既存のシステムビューを組み合わせることで調査は可能ですが、それぞれの情報取得タイミングが異なるため、必ずしも正確な状況を把握できるとは限りません。

pg_xmin_horizon は、そのような要因を単一のビューで確認できるようにする提案です。このビューには、VACUUMを妨げている要因（バックエンドプロセス、レプリケーションスロット、プリペアドトランザクション、など）や、その要因によって VACUUMがどこで止められているか、要因となっているトランザクションのIDはなにか、などの情報が含まれています。8月には、表示情報の追加やテスト強化、ドキュメント整備などが進められていました。運用時のトラブルシューティングに役立つ機能として期待できそうです。

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

PostgreSQL 18.6 に関する技術情報

データベース技術グループ — Tue, 01 Sep 2026 04:35:29 +0000

このリリースは 18.4 からの修正リリース（2026年 8月 13日リリース）です。
バージョン 18.5 は欠番となります。
18.X からのアップデートではダンプ、リストアは不要です。

しかしながら、最初の 3項目のセキュリティ修正は、設定の修正やデータのクリーンアップが必要となるかもしれません。また、修正項目に該当する GINインデックスや GiSTインデックスがある場合には、インデックス再構築が必要となります。

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

PostgreSQL 18.4 から 18.6 への変更点

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

ロジカルデコーディングの出力プラグインが厳格化されました。新たな設定パラメータoutput_plugin_librariesでの指定が必要となりました。(CVE-2026-6471) (Jacob Champion) (18)(17)(16)(15)(14)

これまでは、レプリケーションユーザがロジカルデコーディングむけに任意のライブラリを選ぶことができて（プラグイン名になどフルパス指定も可能）、さまざまな攻撃が可能でした。仕組みを変えずにこれを防げるようにするため、許可された出力プラグインのホワイトリストが導入されました。

PostgreSQL本体同梱のpgoutput（ロジカルレプリケーション用）とtest_decoding（単純なテキスト書き出し用）がデフォルトでoutput_plugin_librariesに含まれます。

加えて、pg_upgrade --checkで、新クラスタのoutput_plugin_librariesが旧クラスタ（バージョン 17.x 以降）のレプリケーションスロットで使っているプラグインライブラリを許可していない場合、失敗するようになりました。

§ § § § § § § § §

contrib/pgcryptoのPGP暗号化がサポートされない暗号化方式を検出するように、修正されました。(CVE-2026-14663) (Daniel Gustafsson) (18)(17)(16)(15)(14)

これまでは、OpenSSLが要求された暗号化方式を（例えば、FIPSモードであるため、あるいは、古いプロバイダがロードされていないために）拒否した場合に、pgcryptoはその失敗を知らせず、プレーンテキストを含む暗号化されないブロックに単にXORを適用していて、その「暗号化」は容易に解読可能でした。これは典型的には非推奨や非FIPSの暗号化アルゴリズム（cipher-algoオプション指定が blowfish/bf, twofish, cast5, 3des などの場合）で発生します。

これからはデフォルトでは、OpenSSLでサポートされない方式でのPGP暗号化がエラーになり、これまでの動作により不適切に暗号化されたメッセージの復号もエラーになります。pgp_pub_decrypt()関数、pgp_sym_decrypt()関数などのオプション引数の新たなオプションignore_cipher_failureに1を指定して実行すると、従来通りの振る舞いに戻ります。

前述の理由で不適切に暗号化されたメッセージを、'ignore-cipher-failure=1'オプションを指定して復号する場合には、OpenSSLの動作がそのメッセージを作成したときと同じでなければなりません。サポートされない暗号化方式が異なっている場合にはうまくいきません。

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

psqlがスクリプト化された「COPY ... FROM STDIN」コマンドに続くインラインデータを、COPY開始時のエラーであっても、読み飛ばすように修正されました。(CVE-2026-6464) (Tom Lane) (18)(17)(16)(15)(14)

これまでは「COPY」コマンドが行の読み込みを始める前に（例えば、対象のテーブルが無い、などで）エラーを起こした場合、psqlはこのことを認識できず、続くインラインデータを読んでSQLとして処理しました。これは良くて誤りであり、悪くするとSQLインジェクションを起こします。

これまでも、COPY開始処理が完了してサーバが「PGRES_COPY_IN」を返した後であれば、途中の行読み込みでエラーを起こしても、残りを読み飛ばすように動作していました。

本修正が実運用SQLスクリプトに影響を及ぼすことは無いと考えられますが、テスト用スクリプトでは意図的に「COPY ... FROM STDIN」コマンドが失敗するように作られている場合があります。そのような場合には各コマンドの後に「\.」というデータ区切り行を追加する必要があります。さもないと、読み飛ばす行が多すぎる結果になるかもしれません。

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

EXECUTEやFETCHを実行するポータルの出力行型についてクロスチェックを行うようになりました。(CVE-2026-16239) (Robert Haas) (18)(17)(16)(15)(14)

EXECUTEとFETCHは2つのポータルを使います。外側の1つはそのステートメント自身のためで、内側の1つはクエリを代わって実行します。これまで、宣言された2つのポータルの行型を異なるものにできて、これを利用してサーバメモリ暴露や任意コード実行を引き起こせました。

§ § § § § §

to_char()で、長いタイムゾーン省略形によるバッファオーバーランが修正されました。(CVE-2026-14669) (Tom Lane) (18)(17)(16)(15)(14)

これは容易にバックエンドプロセスのクラッシュができて、任意コード実行をもたらす攻撃も報告されました。

§ § § § § §

正規表現によるマッチ、分割の関数で、バッファオーバーランが修正されました。(CVE-2026-14664) (Masahiko Sawada) (18)(17)(16)(15)(14)

不正な文字エンコーディングのデータを渡すと、変換バッファの終端を過ぎた位置に書き込みが行なわれる可能性がありました。regexp_match()、regexp_matches()、regexp_split_to_table()、regexp_split_to_array()の各関数の動作が修正されました。

§ § § § § §

ascii()関数が不正な入力に対して頑健になりました。(CVE-2026-18024) (Michael Paquier) (18)(17)(16)(15)(14)

不正な文字エンコーディングのデータが入力されることで、騙されて読むべきでない何バイトかを読んで返す可能性がありました。アサートが有効なビルドでは、アサート失敗も発生します。

§ § § § § §

pg_restore_attribute_stats()関数でのマルチ範囲型の処理が修正されました。(CVE-2026-16238) (OpenAI Security Research Team) (18)(17)(16)(15)(14)

pg_restore_attribute_stats()はプランナ統計情報のダンプ、リストアで使われる関数です。

pg_restore_attribute_stats()はマルチ範囲型を元となる範囲型と単純に同様に扱っていました。これは境界ヒストグラムについては有効でしたが、他の種類の統計情報に対しては誤っていました。

誤った統計情報のリストアにより、不適切なプラン選択による問合せ実行の遅延や潜在的なプランナ誤動作の可能性が考えられます。

§ § §

scalarineqsel()が、tid型と想定される定数を実際にそうであるか検査するようになりました。(CVE-2026-14668) (Tom Lane) (18)(17)(16)(15)(14)

この想定は組み込みの演算子については成り立ちますが、悪意で作られた演算子には通用せず、クラッシュやサーバメモリ暴露を引き起こします。

scalarineqsel()は選択率の見積を返すプランナの内部実装関数の1つです。

§ § § § § §

tsvector型とtsquery型の実装コードが（個々の要素、全体の長さの両面で）きわめて長い値に対して頑健になりました。(CVE-2026-14662) (Tom Lane) (18)(17)(16)(15)(14)

ドキュメントに記載されていた上限が、全てのコードパスで必ずしも強制されていませんでした。

本マイナーバージョンアップで、これまで許容されていたデータについて、以下のようなエラーが出るようになる可能性があり、仕様通りであるものの非互換変更ともいえます。

ERROR:  lexeme is too long for tsvector ...
ERROR:  string is too long for tsvector ...
ERROR:  word is too long to be indexed ...
ERROR:  tsquery is too large

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

「FUNC_MAX_ARGS」を超える関数引数を処理する必要がない、と誤って想定していた様々な箇所が修正されました。(CVE-2026-14679) (Tom Lane) (18)(17)(16)(15)(14)

特に集約関数について、実際の引数の数の上限は「FUNC_MAX_ARGS - 1」ですが、パーサ段階では制限しておらず、後の処理で問題を引き起こしました。潜在的にバッファオーバーランの可能性がありました。

「FUNC_MAX_ARGS」はビルド時指定の定数でデフォルト100です。

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

internal型を引数や戻り値とする関数のSQLからの呼び出しを拒否するようになりました。(CVE-2026-14680) (Tom Lane) (18)(17)(16)(15)(14)

拒否するための既存の仕組みはありましたが、不十分であったため、明示的な検査が追加されました。

また、いくつかの集約関数のcombine処理で入力がNULLである場合に正しくSQLとしてのNULLを返すように修正されました。

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

ALTER TABLEコマンドで再構築されたとき、拡張統計オブジェクトの所有者が保たれるようになりました。(CVE-2026-6469) (Masahiko Sawada) (18)(17)(16)(15)(14)

これまでは拡張統計情報の対象テーブルに、列の型を変えるなどのALTER TABLEコマンドを実行したロールが、拡張統計オブジェクトの所有者になっていましたが、これは不適切な動作と判断されました。

§ § § § § §

EXTRACT()関数呼び出しを逆パースするときに、必要であればフィールド名をクォートするようになりました。(CVE-2026-15741) (Nathan Bossart) (18)(17)(16)(15)(14)

パーサはEXTRACT()のフィールド名としてどのような文字列リテラルも受け付け、検証は実行時まで先送りされます。関数呼び出しを格納して、解析する場合（例えばpg_dumpのとき）、文字列本体が逐語的に吐き戻されて、SQLインジェクションが可能でした。

逆パースはダンプ出力やpsqlでの定義表示で行なわれる処理です。

§ § § § § §

これまで検査ができていなかった個所について、データ型に対する「USAGE」権限を検査するようになりました。(CVE-2026-6470) (Nathan Bossart) (18)(17)(16)(15)(14)

「CREATE TYPE AS RANGE」、「ALTER TABLE OF」、および、格納される式を作成するコマンド（式を伴うビューやチェック制約の定義など）で、検査が行なわれていませんでした。これらの欠落により、「USAGE」権限を持たないロールでもデータ型に依存するオブジェクトを作成できて、データ型の所有者が後でデータ型を変更できなくなる可能性がありました。

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

行単位セキュリティ(RLS)に対して、ロールに依存したキャッシュされたプランを、ロール変更後に無効化するようになりました。(CVE-2026-14666) (Ilya Staroverov, Shinya Kato, Nathan Bossart) (18)(17)(16)(15)(14)

ロールのメンバーシップや属性、データベース所有者の変更は、行単位セキュリティポリシーの振る舞いに影響がありますが、これまでは、キャッシュされた古い状態に基づくプランがそのまま使われていました。

§ § § § § §

直接のSSL接続の後のGSSEncRequestメッセージを拒否するようになりました。(CVE-2026-14681) (Michael Paquier) (18)(17)(16)(15)(14)

これまでサーバは、TLS暗号化接続が確立した後にもGSSAPI暗号化の要求を受け付けていました。これに成功すると、接続はTLS暗号化(SSL)を使っているけれども、pg_hba.confのルールとしてはGSS接続のように見えました。その結果、pg_hba.confでSSLを無効としていても、それを正しく強制できませんでした。

§ § §

モックのSCRAM認証シークレットがより本物らしくなりました。(CVE-2026-14672) (Nathan Bossart) (18)(17)(16)(15)(14)

存在しないロールやSCRAMシークレットを持たないロールに対して、SCRAMログインが試みられた場合、PostgreSQLはモックのシークレットを生成して認証のハンドシェイクをとにかく行ない、攻撃者にそのことが分からないようにします。しかしながら、モックが固定のイテレーションカウントで作られていたため、観測可能な応答の差異がありました。

本修正で、モックにもscram_iterations設定パラメータの値を使って、より実際に使われているシークレットに似せるようになりました。

§ § § §

ecpgアプリケーションでの範囲外書き込みが修正されました。サーバから不正なbytea型データを受け取ることで引き起こされます。(CVE-2026-16241) (Michael Paquier) (18)(17)(16)(15)(14)

ecpgはbytea型の値は「\x」で始まることを検査せずに想定していました。壊れているか悪意のサーバは2バイトよりも短い文字列を送ってくるかもしれず、そのためにアプリケーションでのメモリ上書きが発生しました。

§ § § § § §

psqlの「\unrestrict」コマンドの引数でバッククォート展開をしないようになりました。(CVE-2026-18408) (Nathan Bossart) (18)(17)(16)(15)(14)

\restrict と \unrestrict は 17.6、16.10、15.14、14.19バージョンでのCVE-2025-8714の修正で導入されましたが、その中で見落としがありました。悪意のサーバからの応答で出力されたダンプにより、リストアを実行するユーザに意図せぬシェルコマンド実行をさせること（シェルコマンドインジェクション）ができました。

§ § § § § §

pg_dumpにおいてpg_proc.protrftypesのエントリ数がFUNC_MAX_ARGSを超えないという前提が取り除かれました。(CVE-2026-19385) (Tom Lane) (18)(17)(16)(15)(14)

入力引数と出力引数の両方のエントリが存在する可能性があるため、この配列の長さがFUNC_MAX_ARGS（これは入力引数のみに制限するものです）を超えることは十分にあり得ます。仮にそうでは無いとしても、pg_dumpはサーバがpg_dumpと同じFUNC_MAX_ARGSの値でビルドされたと仮定することはできません。オーバーランが発生すると、pg_dump内部でのメモリ破壊を引き起こす可能性がありました。

pg_procシステムテーブルに関数定義が格納されて、protrftypes列にTRANSFORM句による変換のためのデータ型の配列が格納されます。FUNC_MAX_ARGSは実装内部の定数で、通常100です。

§ § § § § §

tieされたPerlの配列やハッシュに対して、PL/Perlが堅牢化されました。(CVE-2026-14670) (Tom Lane) (18)(17)(16)(15)(14)

通常のオブジェクトとは異なる挙動をするtieされたオブジェクトは、メモリの上書きや、破損した結果配列の生成につながる可能性があり、その結果、後で問題が発生する可能性が高い状況でした。

tieは、配列やハッシュなどの変数に対して操作用のメソッド群を実装したオブジェクトに結びつける Perl の機能です。

§ § § § § §

PL/PerlおよびPL/Tclにおけるメモリ割り当て計算時の整数オーバーフローが修正されました。(CVE-2026-14677) (Heikki Linnakangas) (18)(17)(16)(15)(14)

これはコードの異なる個所で発生していたCVE-2026-6473と同様の問題で、同じ方法で修正されました。

§ § § § § §

contrib/amcheckの関数がインデックス式を実行する前にsearch_pathを制限するようになりました。(CVE-2026-14673) (Noah Misch) (18)(17)(16)(15)(14)

amcheckはそれらのインデックス式をテーブル所有者の権限で実行するため、呼び出し元がsearch_pathに依存する関数を乗っ取り、テーブル所有者の権限で任意のコードを実行できてしまう恐れがありました。デフォルトでは、amcheck関数の呼び出しはスーパーユーザーにのみ許可されているため、これは脆弱性には当たりません。しかし、もしその権限が他のユーザに付与されていた場合、ドキュメントで示されているよりも大きな危険が生じることになります。

§ § § § § §

contrib/fuzzystrmatchのlevenshtein()およびlevenshtein_less_equal()関数における整数オーバーフローが修正されました。(CVE-2026-15742) (Nathan Bossart) (18)(17)(16)(15)(14)

これらの関数に大きなコスト値を渡すと整数オーバーフローが発生し、無意味な結果が生じたり、場合によっては境界外書き込みを引き起こしたりする可能性がありました。

§ § § § § §

contrib/pg_stat_statementsにおけるバッファオーバーランが修正されました。(CVE-2026-14676) (Alvaro Herrera) (18)(17)(16)(15)(14)

クエリの正規化処理において、正規化後の文字列が必要とするサイズが正確に考慮されていませんでした。

§ §

contrib/pg_trgmのGiST picksplit関数におけるデータ型エラーが修正されました。(CVE-2026-14678) (Heikki Linnakangas) (18)(17)(16)(15)(14)

このエラーによりバッファの末尾を超えた読み取りを引き起こし、通常は不適切な分割判断の原因となっており、運が悪ければクラッシュに至る可能性もありました。

§ § § § § §

contrib/refintのプランキャッシュが削除されるようになりました。(CVE-2026-14671) (Ayush Tiwari) (18)(17)(16)(15)(14)

このキャッシュの挙動にはいくつかの深刻なバグがありました。特に、check_foreign_key()がカスケードUPDATEクエリに新しいキー値を埋め込んでしまうため、キャッシュされたプランでは、本来使用すべきキー値ではなく、最初に必要とされたキー値が再利用されてしまう問題がありました。最も簡単な解決策は、これを削除することです。

§ § § § §

並列GINインデックスの構築時に、テーブルのpg_class.reltuples値が正しく更新されるようになりました。 (Jan Nidzwetzki, Tomas Vondra) (18)

並列ワーカーが処理した行数として初期化されていない値を報告する場合があり、その結果、reltuplesがInfinityやNaNといった不正な値になる可能性がありました。このような値が設定されると、その後のautovacuumやautoanalyze操作において、そのテーブルの処理が必要であると判断されなくなる可能性がありました。そうなると、この状態は自動的には解消されません。

reltuplesを正しい値にリセットするには、手動でANALYZEコマンドを実行するか、別のインデックスを作成する必要があります。 GINインデックスを持つテーブルがある場合は、reltuplesの値が妥当かどうかを確認することをお勧めします。以下のようなクエリが役立ちます。

SELECT DISTINCT t.oid::regclass, t.reltuples
FROM pg_class t
  JOIN pg_index i ON t.oid = i.indrelid
  JOIN pg_class ic ON i.indexrelid = ic.oid
WHERE t.relhasindex AND ic.relam = 2742;

§ §

非同期のAppendプランノードを再スキャンする際の、非同期読み取りの不適切な処理が修正されました。 (Alexander Korotkov, Gleb Kashkin, Etsuro Fujita) (18)(17)(16)(15)(14)

上位のプランノードがAppendの出力をすべて読み取る前にAppendを再スキャンする場合、外部サーバー（例えばpostgres_fdwなど）に対して送信済の未完了リクエストをすべて破棄する必要があります。サブプランのパラメータが変更された場合や、次回のスキャンでパーティションプルーニングによってサブプランが破棄される場合、この処理が正しく行われていませんでした。その結果、クエリ結果が不正になったり、無限ループに陥ったり、アサート失敗が発生したりする可能性がありました。

§ § § § § §

RANGEパーティションテーブルにおけるパーティションプルーニングの不具合が修正されました。 (David Rowley) (18)(17)(16)(15)(14)

特定のケースにおいて、本来対象とすべきDEFAULTパーティションがスキップされ、その結果、クエリの結果から行が欠落して、誤った問い合わせ結果となる恐れがありました。

§ § § § § §

結果リレーションのプルーニング後に、ModifyTableプランノード内の外部データラッパーの状態を正しく更新するようになりました。 (Ayush Tiwari, Rafia Sabih) (18)

以前は、実行時のパーティションプルーニングによって、対象のパーティションテーブルの一部のパーティションをスキャンする必要がないと判断された場合、そのテーブルに外部テーブルのパーティションが含まれていると、クラッシュや誤動作が発生する可能性がありました。

§ §

「BEFORE UPDATE」トリガーを持つテーブルに対して、「RETURNING OLD」を指定したUPDATE文で発生していた並行更新の処理漏れが修正されました。 (Dean Rasheed) (18)

対象行が並行して更新された場合、「READ COMMITTED」分離レベルでは、RETURNING句で返される「OLD」値はすべて、更新後の行の値を反映している必要があります。しかし、トリガーが存在する場合、トリガー自体や最終的な出力行では正しい値が参照されていたにもかかわらず、古い値が返されてしまっていました。結果として、誤った問い合わせ結果が生じる可能性があります。

§ §

複数の結合キーと多数のNULL値が存在する場合のハッシュ結合の性能問題が修正されました。 (David Rowley) (18)

NULL値を持つタプルは他のどのタプルとも一致することはないため、ハッシュテーブルに挿入されるべきではありません。これまでのコードでは、最後の結合列以外の列にNULL値が含まれる場合にこの処理が適切に行われていなかったため、NULL値を含む入力が多数あるとハッシュテーブルが著しく肥大化していました。

§ §

RETURNING句の式における括弧で囲まれた「OLD」や「NEW」の解析処理が修正されました。 (Marko Grujic) (18)

「(old).colname」や「(old).*」といった式が誤って処理され、実質的に「NEW」への参照に変換されていました。結果として、誤った問い合わせ結果が生じる可能性がありました。

value IN (array)式に対するプランナのNULL許容性および厳密性チェックが修正されました。 (Ayush Tiwari) (18)(17)(16)(15)(14)

これらのチェックは、配列オペランドが空でないことが既知である場合にのみ成功すべきですが、その点が考慮されておらず、本来適用されるべきではない最適化が適用されてしまう問題がありました。これにより、実際の配列が空であった場合、誤った問い合わせ結果が生じる可能性がありました。

§ § § § § §

不適切な結合削除のロジックが修正されました。 (Matheus Alcantara, Richard Guo) (18)(17)(16)

一部の特殊なケースにおいて、外部結合のNULL許容側由来の定数出力値が、本来NULLに置換されるべき場面でNULLに置換されない問題が発生し、誤った問い合わせ結果が生じる可能性がありました。

§ § § § § § § §

結合の削除処理において、PlaceHolderVarsのクリーンアップがより徹底されるようになりました。 (Richard Guo, Arne Roland) (18)

この修正により、アサート失敗や誤った実行計画の生成（とそれに伴う誤った問い合わせ結果や予期せぬエラー）を招く可能性のあった様々なエッジケースが解消されます。

§ § §

コンテナデータ型（配列、複合型、範囲型）の等価比較におけるハッシュ可能性に関する漏れていたチェックが追加されました。 (Andrei Lepikhov, Tom Lane) (18)(17)(16)(15)(14)

プランナは、ハッシュベースの実行計画を採用する前に、コンテナの構成要素の型のハッシュ化可能かどうかを検証する必要がありました。一部の箇所でこの手順が漏れていたため、実行時に「ERROR: could not identify a hash function for type ...」という予期せぬエラーが発生していました。

§ § § § §

プランナが、異なる等価性ルールを持つグループ化ステップより下位へ、WHERE句をプッシュダウンすることを避けるようになりました。 (Richard Guo) (18)

非決定的照合順序でグループ化される列に対するテストは、その同じ照合順序を使用した比較である場合にのみ、安全にプッシュダウンできます。そうでない場合、グループ化によって統合されるはずだった行がフィルタリングされて、誤った問い合わせ結果が生じる可能性がありました。

§ §

「EXCLUDE」句を指定している、または「ORDER BY」を指定していない、COUNTウィンドウ関数の誤った最適化が修正されました。 (Chengpeng Yan, David Rowley) (18)(17)(16)(15)

これまで、このウィンドウ関数は該当しない場合でも単調増加するものとして扱われていました。そのため、誤った問い合わせ結果が生じる可能性がありました。

（報告された誤動作例）
db1=# CREATE TABLE t41 (id int PRIMARY KEY, k int NOT NULL, v int);
db1=# INSERT INTO t41(id, k, v) VALUES
        (1, 1, 1), (2, 1, NULL), (3, 1, 1), (4, 2, 1);

db1=# SELECT id, count(v) OVER (
        ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        EXCLUDE CURRENT ROW) AS c FROM t41;
 id | c
----+---
  1 | 1
  2 | 2
  3 | 1
  4 | 2
(4 rows)

db1=# SELECT * FROM (
        SELECT id, count(v) OVER (
          ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
          EXCLUDE CURRENT ROW) AS c FROM t41) s WHERE c < 2;
 id | c
----+---
  1 | 1
(1 row)
→ 正しくは id=3 の行も出力されないといけない

§ § § § §

プランナが"char"型の列の統計情報を参照する際に、予期せぬエラー「ERROR: cache lookup failed for collation 0」が発生する障害が修正されました。 (Feng Wu) (18)

"char"型は、一般的に使われるchar(n)型とは別の、主として内部的なシステムカタログで使用されるものです。

複数階層のパーティションが存在する場合でも、ALTER TABLEのALTER COLUMN ... DROP EXPRESSIONが正常に動作するよう修正されました。 (Alberto Piai) (18)(17)(16)(15)(14)

ALTER TABLE ... ALTER COLUMN ... DROP EXPRESSIONは、格納生成列を基本列に変換する構文です。複数階層の子パーティション／子テーブルを持つパーティションテーブルや継承ツリーの親テーブルに対して実行すると、「ERROR: ALTER TABLE / DROP EXPRESSION must be applied to child tables too」というエラーが発生していました。

§ § § § § §

排他制約であるインデックスのパーティションをアタッチする処理の不具合が修正されました。 (Japin Li) (18)(17)

この誤りにより、排他制約を持つパーティションテーブルのダンプ/リストアが正常に動作しなくなっていました。

リストア時に以下のようなエラーが発生します。

ERROR:  cannot attach index "..." as a partition of index "..."
DETAIL:  The index definitions do not match.

§ § §

ALTER CONSTRAINTを使用して、パーティションテーブルのNOT NULL制約にNO INHERITを設定することができないように修正されました。 (Andreas Karlsson) (18)

本来、パーティションテーブルのNOT NULL制約は、すべてのパーティションに継承される仕様であるため、NO INHERITを指定することはできません。これまでは、この仕様は制約を新規作成する際には正しく適用されていましたが、「ALTER TABLE ... ALTER CONSTRAINT」では適用されておらず、NO NULL制約の有無がパーティションごとに異なるようにできました。

ルールの名前を「_RETURN」に変更できないように修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

「_RETURN」という名前は、ビューの「ON SELECT」ルール用に予約されています。これまでは「ON SELECT」以外のルールをALTER RULEで「_RETURN」に名前変更できてしまい、その後の処理で問題を引き起こしていました。

具体的には、ダンプ/リストアで「ERROR: non-view rule for "..." must not be named "_RETURN"」というエラーを起こすことが報告されました。

§ § § § § §

DROP OWNED BYにおいて、ロールメンバーシップへのロックの解放漏れが修正されました。 (Jeff Davis) (18)(17)(16)

この不具合により、トランザクションが終了するまで、ロールメンバーシップ（pg_auth_membersシステムテーブルの対応するエントリであらわされる暗黙的なオブジェクト）へのロックが保持され続けていました。その結果、並行するDDL実行で警告メッセージが出ることがありました。

§ § § §

EXPLAINがSQL/JSONの集約関数をデパースするときに予期せぬエラーを出すことがあり、修正されました。 (Richard Guo) (18)(17)(16)

実行プランの構造によっては、「ERROR: invalid JsonConstructorExpr underlying node type」というエラーが発生していました。

§ § § §

遅延一意性制約のインデックスに対してREINDEX CONCURRENTLYを使用した場合の不具合が修正されました。 (Nitin Motiani) (18)(17)(16)(15)(14)

REINDEX CONCURRENTLYの実行中に一時的に作成されるインデックスのコピーが、誤って即時一意性制約として扱われていました。そのため、実際には制約違反ではない場合でも、制約違反が発生したと誤って報告することがありました。

§ § § § § §

非決定論的照合順序でバックスラッシュ（\）を使用したLIKE句のマッチングの不具合が修正されました。 (Nitin Motiani, Tom Lane) (18)

非決定論的照合順序において、LIKEがエスケープされたバックスラッシュ（\\）を誤って処理し、実質的にバックスラッシュが存在しないものとして扱っていました。

また、通常の文字の前にバックスラッシュが付いている場合も誤った処理をしていました。この場合、バックスラッシュは実質的に無視されるべきですが、実際には後続の通常の文字を完全一致として扱ってしまい、非決定論的照合順序にマッチするかを判断していませんでした。

§ § § §

LIKE句や正規表現の完全一致パターンのインデックススキャン最適化の不具合が修正されました。 (Jelte Fennema-Nio) (18)

非決定論的な照合順序におけるLIKEのリファクタリングによって、LIKE句や正規表現の完全一致パターンを、等価比較のインデックス条件に変換する最適化が誤って壊れていました。これはインデックスの照合順序と式の照合順序が一致しない場合に発生していました。この影響で、psql の「\d tablename」コマンドが大幅に遅くなっていました。

§ §

to_date() におけるローカライズされた月名、曜日名のマッチング処理が修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

大文字・小文字の変換によって文字列のバイト長が変化する場合に、マッチング処理が誤動作していました。月名、曜日名が認識されずに予期せぬエラーが発生する可能性が考えられます。

§ § § § § § §

ギリシャ文字の語末形のシグマに対する大文字小文字の変換のルールが修正されました。 (Jeff Davis) (18)

文字列の直前が大文字小文字を区別しない文字だけで構成されている場合、そのシグマを語末形のシグマとはみなさないようにしました。

§ §

ハングルU+11A7（TBASE）のNFC再合成における誤りが修正されました。 (Diego Frias, Michael Paquier) (18)(17)(16)(15)(14)

この文字は有効なT音節として扱われていましたが、実際にはT音節ではないため、正規化処理中にこの文字が消えてしまっていました。

§ § § § §

大文字小文字を区別しない類義語の辞書において、出力する語彙素が切り捨てられる不具合が修正されました。 (Jeff Davis) (18)(17)(16)(15)(14)

小文字への変換によって語彙素のバイト長が増加した場合、出力時に元のバイト長に誤って切り捨てられていました。

§ § § § §

大文字小文字変換処理において、途中で途切れたUTF-8文字への対処が修正されました。 (Jeff Davis) (18)(17)

§ § §

hash_record_extended()のバグが修正されました。 (Man Zeng) (18)(17)(16)(15)(14)

FunctionCallInvoke()に渡される2番目のisnull引数が初期化されていませんでした。既存の組み込み拡張ハッシュサポート関数では、この値を参照しないため問題はありません。しかし、拡張機能が提供するハッシュ関数が「PG_ARGISNULL(1)」を調べる場合、その影響を受ける可能性がありました。

§ § § § §

公開可能なテーブルが並行して削除された場合に、pg_get_publication_tables()が失敗する不具合が修正されました。 (Bharath Rupireddy) (18)(17)(16)

§ § § §

VARIADIC NULL を指定した場合に、satisfies_hash_partition() がクラッシュする不具合が修正されました。 (Robert Haas) (18)(17)(16)(15)(14)

§ § § § § §

tsvector_filter() および関連する関数で、不正な重みに関するエラーを、より明確かつ一貫した形で報告するよう修正されました。 (Ewan Young) (18)(17)(16)(15)(14)

具体的には、表示可能なASCII文字ではない重み文字については、charout()と同様に8進数形式（"\nnn"）で報告します。これにより、無効なエンコーディングを含むエラーメッセージが生成されるのを防ぎます。

§ § § § §

uundv7()関数で範囲外のタイムスタンプとなるシフト値を拒絶するようになりました。 (Baji Shaik) (18)

v7 UUIDで表現可能な範囲を超えたタイムスタンプになるシフト値は「ERROR: timestamp out of range for UUID version 7」というエラーを出すようになります。有効なタイムスタンプ範囲は、1970-01-01 00:00から10889年くらいまでです。これまでは壊れたUUID値が作られていました。

§ §

xpath()関数でnamestapeノードの処理が修正されました。 (Michael Paquier) (18)(17)(16)(15)(14)

予期せぬ「ERROR: could not copy node」エラーが出ていたものが修正されました。

§ § § § § § § § § §

jsonpathの「.decimal」メソッドが、精度やスケールの指定が正しくない場合でもERRORを出さないように、修正されました。 (Ewan Young) (18)(17)

サイレントモード（json_path_*関数のsilent引数がtrue）では、エラーを抑止すべきですが、そのようになっていませんでした。

§ § § § §

「IS JSON」や「JSON()」等の構文が、text型へのキャストを持たない文字列型の引数を与えられたときの、NULLポインタによるクラッシュが修正されました。 (Ayush Tiwari) (18)(17)(16)

PostgreSQL本体コードには該当するデータ型はありませんが、一部の拡張のデータ型で問題を引き起こす可能性がありました。

§ § §

「SQL/JSON」の「ON EMPTY / ON ERROR DEFAULT」の値に正しい型修飾が確実に適用されるようになりました。 (Ewan Young) (18)(17)

例えば、対象numeric型列の宣言された精度とスケールがデフォルト値に適用されませんでした。

（誤動作例）
db1=# SELECT JSON_VALUE(jsonb '{"b":"1234.5"}', '$.a' 
        RETURNING numeric(4,1) DEFAULT 99999.9 ON EMPTY);
 json_value
------------
    99999.9
(1 row)

（以下エラーが出るのが正しい動作）
ERROR:  numeric field overflow

§ § §

money型の最小値（64bit整数最小値）を-1で割ったときの、マシン依存の振る舞いが回避されました。 (Andrey Rachitskiy) (18)(17)(16)(15)(14)

x86_64アーキテクチャでエラーになるものが、aarch64アーキテクチャではエラーになりませんでした。オーバーフローを起こした場合には必ず「ERROR: money out of range」が出るようになりました。

§ § § § § §

全文検索の辞書に対するキャッシュエントリの作成途中でメモリ不足が生じた後にクラッシュする障害が修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

§ § § § § §

誤ったispell/hunspell辞書ファイルに対する処理でメモリ安全性に問題があり、修正されました。 (Andrey Rachitskiy) (18)(17)(16)(15)(14)

§ § § § § §

他セッションの一時テーブルへのアクセスが防止されました。 (Jim Jones, Daniil Davydov, Alexander Korotkov) (18)(17)(16)

基本的にそのようなアクセスは禁止されていますが、一部のコードパスで防止しきれておらず、干渉されたセッションで誤った問合せ結果が生じるおそれがありました。

§ § § § § §

一時テーブルにアクセスするときの「ERROR: no empty local buffer available」エラーが防止されました。 (Melanie Plageman) (18)

本修正でストリーミング読み取りの仕組みが使用可能なローカルバッファの数が制限されました。これまでは、effective_io_concurrency設定が大きな値の場合に単一のストリームで全バッファを利用可能であったため、本エラーが発生しました。

autovacuumがデータベースを処理する順番が修正されました。 (Rustam Khamidullin) (18)(17)

最高スコアから最低スコアに向かう順で処理されるべきところで、意図せず逆順になっていました。

§ § §

VACUUMのXID周回フェールセーフモードで、共有バッファプールを全使用するように動作が復旧されました。 (Melanie Plageman) (18)

通常のVACUUMは、他の処理に大きな影響を与えないように、共有バッファを少しだけ使うように制限されています。しかしながら、フェールセーフモードではできるだけ早くトランザクションIDを回収する必要があるので、この制限は放棄されることになっていました。この振る舞いがv18のリファクタリングで壊れていて、復旧されました。

§ § § §

パラレルVACUUMワーカーの処理でのメモリリークが修正されました。 (Baji Shaik) (18)(17)

パラレルワーカーからの報告過程で報告ごとに1kB程度のリークがあり、これはワーカープロセスが生きている間は蓄積されていきました。

§ §

問合せのキャンセルとVACUUM遅延が、GINインデックスのポスティングツリーのクリーンアップ中であっても、すぐに行なわれるようになりました。 (Paul Kim, Alexander Korotkov) (18)(17)(16)(15)(14)

よくある値に対するポスティングツリーは大きくなることがあり、ここに割り込みの検査が欠けていたため、処理が長く継続してしまいました。

§ § § § § §

GiSTおよびSP-GiSTのインデックスに対するIndex Only Scanで、インデックスタプルのデコーディングを誤る可能性があり、修正されました。 (Peter Geoghegan) (18)(17)(16)(15)(14)

この障害で壊れたデータが出力されて、誤った問い合わせ結果や予期せぬエラーが発生する可能性がありました。本体コードで影響があるのは、GiSTの演算子クラスrange_opsのみで、その範囲列が最初のインデックス列でない場合にのみ、誤動作が発生します。

（誤動作例）
db1=# CREATE TABLE t75 (a inet, r numrange);
db1=# INSERT INTO t75 VALUES 
      ('::1', numrange(repeat('1', 100)::numeric, repeat('2', 200)::numeric)));
db1=# CREATE INDEX ON t75 USING gist (a inet_ops, r range_ops);
db1=# VACUUM ANALYZE t75;
db1=# SET enable_seqscan TO off;
db1=# SELECT lower(r) = repeat('1', 100)::numeric,
             upper(r) = repeat('2', 200)::numeric FROM t75;
ERROR:  type with OID 860 does not exist

§ § § § § §

バルク拡張されたテーブルの新たな最終ブロックがフリースペースマップに即座に追加されるようになりました。 (Jingtang Zhang) (18)(17)(16)

off-by-one（1つ足りない）誤りで、複数ブロックが追加されたときの最後のブロックがフリースペースマップに登録されませんでした。VACUUMによってやがては正しく登録されますが、それまでの間、最終ブロックが使われませんでした。

§ § § §

トランザクションのアボート時のリソース解放処理で、メモリの二重解放（クラッシュをひきおこします）、または、エラーの再帰的な無限ループが起きる可能性があり、修正されました。 (Tom Lane) (18)(17)

巨大な入力値を伴うSQLがエラーになって、トランザクションアボートが行なわれたケースで問題が報告されました。

§ §

PostgreSQLの処理内でディレクトリを作成するとき、同じディレクトリの同時作成を許容するようになりました。 (Andrew Dunstan, Tom Lane) (18)(17)(16)(15)(14)

他プロセスが同じディレクトリを作っているのであれば、ディレクトリ作成に成功した扱いとすることで、これまで同時実行で発生する可能性のあった「ERROR: could not create directory "...": File exists」といったエラーを回避できます。

§ § § § §

JITコンパイルされたタプルデフォームを行うコードが、仮想生成列を正しく考慮するように修正されました。 (David Rowley) (18)

NOT NULL制約のある仮想生成列を含むテーブルへの問合せで、誤った問い合わせ結果が生じる例が報告されました。

依存されている全てのオブジェクトに共有ロックを取得することにより、宙に浮いたオブジェクト依存関係の生成が防止されました。 (Bertrand Drouvot) (18)(17)(16)(15)(14)

共有ロックは依存されているオブジェクトの削除と衝突しますので、これまであった競合状態を排除することができます。

例えば、これまでは、空スキーマの削除とスキーマ内へのオブジェクト作成の同時実行が両方成功して、無効なオブジェクト定義が残ることがありましたが、これからはどちらかのトランザクションが失敗します。

§ § § § § § § § § §

SERIALIZABLE分離モードに対する衝突の検出での競合状態が修正されました。 (Peter Geoghegan) (18)(17)(16)(15)(14)

初期の空のbtreeインデックスを検査するときに衝突が見過ごされる可能性があり、競合しているトランザクションのコミットを許してしまっていました。

§ § § § § §

バリアイベントの処理で競合状態が修正されました。 (Masahiko Sawada) (18)(17)(16)(15)

この誤りにより、プロセスがハングアップする可能性がありました。典型的には、その際に以下ログメッセージが出力されます。待機イベントとしてはIPC型のProcSignalBarrierの待機となります。

LOG:  still waiting for backend with PID %d to accept ProcSignalBarrier

近年追加されたオンラインWALレベル変更などの機能によって、この問題がより目立つようになっています。

§ § § §

同じロックグループに属するプロセス集合が同時に終了したときの競合状態が修正されました。 (Vlad Lesin) (18)(17)(16)(15)(14)

この誤りは「PANIC: latch already owned by PID ..」によるサービスのPANIC終了を引き起こす可能性があります。PostgreSQL本体の通常のパラレル問合せでは、リーダープロセスがワーカープロセスの終了を待たずに終了することが無いため、この問題は起きませんが、何らかの拡張で該当する可能性がありました。

§ § § § § § § § § §

テーブルのビジビリティマップ(VM)でビットをクリアする操作のWAL出力が修正されました。 (Melanie Plageman, Andres Freund) (18)(17)

このようなVM変更がWALサマライズ処理で見落とされていて、誤ったインクリメンタルバックアップをもたらす可能性がありました。また、このようなVMページの必要時のフルページイメージWAL出力も行なわれておらず、壊れたページ書き込みが修正されないままとなる可能性がありました。これは後にIndex Only Scanでの誤った問い合わせ結果が生じるなどの、誤動作を引き起こすおそれがあります。

既存のバックアップやアーカイブWALに潜在的にデータ破損が含まれていることに留意してください。

§ § § § § § § § §

WALサマライズ処理でのタイムライン変更時のハングアップが防止されました。 (Robert Haas) (18)(17)

スタンバイサーバで、以下のログメッセージがwalsummarizerプロセスから継続的に出力される動作が報告されました。

ERROR:  could not read WAL from timeline .. at ...: invalid record length ...

§ § § § § §

スタンバイ昇格のときのロジカルデコーディングのタイムライン選択で、競合状態が修正されました。 (Bertrand Drouvot) (18)(17)(16)

スタンバイ側で実行中のロジカルデコーディングが「ERROR: requested WAL segment has already been removed」で失敗する可能性がありました。再試行すれば成功するため恒久的な問題はありませんが、可用性としては有害でした。

§ § § § § § §

タイムラインを切替するときのwalreceiverの接続文字列の露出が回避されました。 (Chao Li) (18)(17)(16)(15)(14)

pg_stat_wal_receiverビューは機微なデータを除いてサニタイズされた接続文字列を見せるべきです。しかし、タイムライン切替に際して既存のwalreceiverプロセスを再利用するときに、一時的に完全な接続文字列を見せてしまっていました。

§ § § § §

ロジカルレプリケーションで受け取ったタプルの列数が正しいかの検証を、アサートではなく実行時チェックで行うようになりました。 (Varik Matevosyan) (18)(17)(16)(15)(14)

悪意の、または、壊れたパブリッシャは一貫性のない列数を送出するかもしれません。これによる深刻な悪影響をおよぼすシナリオは見つからなかったものの、より注意を払うべきと判断されました。

§ § § § §

レプリケーションコマンド内の文字列パラメータへのクォート付加について、実装がクリーンアップされました。 (Tom Lane) (18)(17)(16)(15)(14)

レプリケーションコマンドを生成する様々な個所で、コマンドに挿入されるレプリケーションスロット名や他のパラメータのクォート付加について、十分な注意が払われていませんでした。そのため、レプリケーションコマンドで予期せぬエラーが発生するおそれがありました。

原理的には作りこまれたレプリケーションスロット名でSQLインジェクションも可能でした。ただし、ほとんどの場合、元からSQL実行が可能な管理者が行う操作であるため、実用的な害はないと考えられます。

§ § § § §

空のプリペアドトランザクションのロジカルデコーディングについて修正されました。 (Masahiko Sawada) (18)(17)(16)(15)(14)

デコード可能な変更を起こさないプリペアドトランザクションは、先立つ「PREPARE」無しに、「COMMIT PREPARED」や「ROLLBACK PREPARED」を出力プラグインに送出していました。組み込みのサブスクライバでは、これはレプリケーションを壊します。他のプラグインでも同様に問題となると考えられます。

§ § § § § §

スタンバイ昇格後のUNLOGGEDシーケンスのデータ破損が修正されました。 (Fujii Masao) (18)(17)(16)(15)

これまでは、プライマリで作られてスタンバイにレプリケートされたUNLOGGEDシーケンスに、スタンバイ昇格後にアクセスすると、「ERROR: bad magic number in sequence」などのエラーや、アサート失敗が発生する可能性がありました。

§ § § § §

カスケードスタンバイでのWALアーカイブによるリカバリからストリーミングに復帰するときの再接続失敗が、修正されました。 (Marco Nenciarini) (18)(17)(16)(15)(14)

このとき「ERROR: requested starting point ... is ahead of the WAL flush position」が発生する可能性がありました。

§ § § § § §

WALリプレイが一貫性のあるデータベース状態に達する前にホットスタンバイ接続を受け付ける動作が防止されました。 (Nikhil Sontakke) (18)

§ §

スタンバイサーバで、ローカルにpg_database.dathasloginevtのクリアを試みないようになりました。 (Ayush Tiwari) (18)(17)

スタンバイで実行が試みられていましたが、これは機能しておらず、また、プライマリでの変化がすぐに反映されて上書きされるので不要な動作でした。

loginのイベントトリガを削除した後にスタンバイに接続したときに、「FATAL: cannot acquire lock mode AccessExclusiveLock on database objects while recovery is in progress」が出て接続できない動作が報告されました。

§ §

使われなくなったレプリケーションスロットを削除するときの競合状態が回避されました。 (Xuneng Zhou) (18)(17)

削除直後のスロットの共有メモリエントリを他セッションが再利用した場合、誤ったロック解放と誤ったログメッセージ（異なるスロット名やデータベースOIDが使われる）が生じる可能性がありました。

§ §

一時的なレプリケーションスロット（初期化途中の論理レプリケーションスロット）を削除するときの競合状態が回避されました。 (Zhijie Hou) (18)(17)(16)(15)(14)

これまでの実装では、スロットを解放した後にスロットの共有メモリエントリにいくらか追加的な更新を実行していました。これは他セッションが直ちに再利用するかもしれないため、安全ではありません。本修正で、一時スロットには、この更新を行なわないようになりました。

§ § § § §

ロジカルレプリケーションのテーブル初期同期で、進捗報告が古い内容となっていた問題が修正されました。 (Shinya Kato) (18)(17)(16)(15)(14)

これまでは、サブスクライバのpg_stat_progress_copyビューは、データコピーが終わった後でも、初期COPY操作をアクティブとして表示していました。同期がパブリッシャに追いつくまで、古いエントリが表示されたままでした。

§ § § § §

バックアップに失敗したなら、ベースバックアップの進捗がクリアされるようになりました。 (Chao Li) (18)(17)(16)(15)

これまで、pg_stat_progress_basebackupビューは、レプリケーションクライアントが切断するまで、古い進捗情報を表示し続けていました。標準付属のpg_basebackupであれば、失敗した後に即座に切断しますが、他のバックアップを取得するクライアントはそうであるとは限りません。

§ § § § § § § § §

設定track_functionsが有効であるとき、実行時統計情報(pgstats)のエントリの同時削除のためにPANICが生じる可能性があり、修正されました。 (Sami Imseih, Michael Paquier) (18)(17)(16)(15)

「PANIC: cannot abort transaction .., it was already committed」が出るケースが報告されました。

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

対応する共有ハッシュテーブルのエントリに対するメモリ領域取得に失敗した後、壊れた実行時統計情報(pgstats)のローカルエントリをクリーンアップするようになりました。 (Niall Newman) (18)(17)(16)(15)

これを行なっていなかったため、次にローカルエントリが使われたときに、NULLポインタ参照によるクラッシュが発生しました。

§ § § § §

読み込みや書き込みの失敗後に誤ったI/O操作統計が記録されないように、修正されました。 (Bertrand Drouvot) (18)

各種のWAL読み書きに処理に失敗したときにエラーを意味する負の値がそのまま統計値のカウントに使われていて、pg_stat_ioビューなどで参照されるWALのI/O統計に誤った値が混入する可能性がありました。

PL/Perlで、不正なPostgreSQL::InServer::ARRAYオブジェクトを扱うときのNULLポインタ参照によるクラッシュが回避されるようになりました。 (Xing Guo) (18)(17)(16)(15)(14)

PostgreSQL::InServer::ARRAYはPL/Perl関数に引数でPostgreSQLの配列を渡すときに使われるperlのオブジェクト型です。PL/Perl関数からPostgreSQLの配列を返すときにも使用できます。検査が不足していて、引数に由来せず適切な内部構造を持たないPostgreSQL::InServer::ARRAYオブジェクトを返すとクラッシュを引き起こせました。

（クラッシュ発生例）
=# CREATE FUNCTION f102() RETURNS integer[] AS $$
     return bless {}, "PostgreSQL::InServer::ARRAY"; $$ LANGUAGE plperl;
=# SELECT f102();
server closed the connection unexpectedly

§ § § § §

PL/Pythonで、Pythonのシーケンスオブジェクトとマッピングオブジェクトを扱うときにエラーを正しく検査するようになりました。 (Richard Guo) (18)(17)(16)(15)(14)

hstore_plpython拡張やjsonb_plpython拡張を使って、PL/Python関数の戻り値をhsotre型やjsonb型に変換している場合に該当する問題です。これまでは、壊れたオブジェクトやハンドルされない例外によって、NULLポインタ参照によるクラッシュが発生する可能性がありました。

§ § § § § §

libpqで、pqReadData()の実行中にSSLまたはGSSの復号バッファに残っている未処理バイトを常にすべて取り出すようになりました。 (Jacob Champion) (18)(17)(16)(15)(14)

例外的なケースですが、大きなメッセージのサーバからの届き方によっては、バッファがいっぱいになることでlibpqがソケット到着を誤って待ち続けて、APIを呼び出すクライアントアプリケーションがハングアップしてしまう可能性がありました。

pqReadData()はサーバ側からデータを読むlibpqの内部実装関数です。

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

libpqのメモリ不足状態の処理が改善されました。 (Anthonin Bonnefoy) (18)

COPYデータ読み込みや関数呼び出しの途中に、非同期メッセージ処理でメモリ不足になった場合にも、直ちにエラーを出すようになりました。これまでは、セッション切断された状態で処理が継続されていて、エラー発生が遅れたり、不適切なエラーが出る可能性がありました。

§ §

libpqのトレース機能が、新しい形式のBackendKeyDataメッセージとCancelRequestメッセージを正しく出力するようになりました。 (Anthonin Bonnefoy) (18)

これらのプロトコルメッセージは固定長から可変長に仕様変更されましたが、トレース機能では固定長を想定したままとなっていたため、「mismatched message length」という警告が出力されていました。

§ §

libpqが30000バイトを超えるParameterDescriptionメッセージを受け付けられるようになりました。 (Ning Sun) (18)(17)(16)(15)(14)

libpqは受信メッセージの妥当性検査として、「長くなりうるメッセージ型」以外について長すぎるメッセージを弾きます。ParameterDescriptionは「長くなりうるメッセージ型」として扱われていなかったため、メッセージ長が30000バイトを超えるとエラーになっていました。この制限により、7498個を超えるパラメータを持つプリペアドステートメントに対するPQdescribePrepared()が失敗していました。この数のパラメータはまれな用法ですが仕様の範囲内です。

§ § § § §

ecpgコンパイラのNULLポインタ参照によるクラッシュが修正されました。 (Jehan-Guillaume de Rorthais) (18)

構造体の内側に入れ子になった共用体を含むDECLAREセクションをもつ.pgcコードを変換しようとすると、ecpgコマンド実行がクラッシュしました。

（ecpgコマンドがクラッシュするコード例）
EXEC SQL BEGIN DECLARE SECTION;
    struct s1
    {
        char STR1[10];
        union u1
        {
             int NUM1;
             int NUM2;
        } U1;
    } S1;
EXEC SQL END DECLARE SECTION;

ecpgのGET DESCRIPTOR文とSET DESCRIPTOR文で、記述子ヘッダ項目を複数指定する構文が拒否されるようになりました。 (Masashi Kamura) (18)(17)(16)(15)(14)

これまでも文法上はこの構文が許されていましたが、実装は実際には複数のヘッダ項目に対応できておらず、指定すると壊れたCコードが生成されていました。

本修正で構文解析処理でもドキュメント上でもヘッダ項目は1つだけに変更されました。これは非互換性を含む変更です。

§ § § § §

psqlのパイプラインモードにおける遅延エラーの問題が修正されました。 (Michael Paquier) (18)

Syncメッセージへの応答としてサーバがエラーを報告する場面（遅延制約の違反など）で、psqlがハングアップしたり、アサート失敗したりする可能性がありました。

psqlの拡張表示（expanded）の整形出力で、行の幅が揃うようになりました。 (Pavel Stehule) (18)(17)(16)(15)(14)

テーブルのデータ行がレコードヘッダ行より狭い場合、データ行の幅がレコードヘッダ行に合わせられず、次のように桁のずれた出力になっていました。

（ずれた出力の例）

+-[ RECORD 1 ]-+
| a | 10 |
| b | 20 |
+---+----+

（修正後の出力例）

+-[ RECORD 1 ]-+
| a | 10       |
| b | 20       |
+---+----------+

§ § § § §

psqlの特別変数WATCH_INTERVALについて、既定の上限が強制されるようになりました。 (Sven Klemm, Daniel Gustafsson) (18)

大きすぎる値(1000000超)を設定しようとすると、psqlはエラーを報告するものの、その値を適用してしまっていました。修正後は、上限を超える値は拒否され、変数の値は変更されません。

psqlの「\l+」でデータベースサイズを表示する権限検査が修正されました。 (Christoph Berg) (18)(17)(16)(15)(14)

サーバ側のpg_database_size()は、pg_read_all_statsロールの権限を持つ利用者に対して、対象データベースへのCONNECT権限がなくてもすべてのデータベースのサイズの参照を許します。しかしpsqlはこの仕組みを考慮せず、CONNECT権限を持つ利用者以外に対してはこの関数を呼び出していませんでした。

修正後は、「\l+」の権限検査にpg_read_all_statsロールの権限（USAGE）の確認が加わり、pg_database_size()の権限規則と一致するようになりました。

§ § § § § §

psqlの「\df」のタブ補完で、プロシージャも候補に含めるようになりました。 (Erik Wienhold) (18)(17)(16)(15)(14)

「\df」コマンド自体はプロシージャも表示対象に含めるよう拡張されていましたが、タブ補完の候補は関数だけを表示し続けていました。

§ § § § § §

pgbenchのスレッド安全性のバグが修正されました。 (Fujii Masao) (18)(17)(16)(15)

pgbenchを複数スレッドで実行し、かつ「--verbose-errors」オプションを指定した場合、異なるスレッドが同じバッファを使ってエラーメッセージを組み立てようとし、ログ出力が壊れる可能性がありました。

§ § § §

pg_combinebackupで、コピー元ファイルが想定より小さい場合に無限ループが発生することがあり、防止されました。 (Peter Eisentraut) (18)(17)

「--copy-file-range」を指定して合成フルバックアップを再構築する過程で、ファイルが0バイトしかコピーできなかった場合をエラーとしていなかったため、試行が繰り返されてしまっていました。

§ §

pg_createsubscriberで、エラー発生後にパブリッシャ側オブジェクトのクリーンアップが行なわれない場合があり、修正されました。 (Nisha Moond) (18)(17)

pg_createsubscriberは、論理レプリケーションオブジェクトを作成した後にエラーを起こした場合、パブリッシャ上に作成したパブリケーションとレプリケーションスロットを削除する必要があります。一部のエラーケースでは削除が行われず、pg_createsubscriberの再実行のために手動での削除が必要でした。

§ §

pg_recvlogicalの出力ファイルが、ソースクラスタのグループ読み取り権限に従って作成されるようになりました。 (Fujii Masao) (18)(17)(16)(15)(14)

pg_recvlogicalはこの挙動についてドキュメントに記載されていたにもかかわらず、実際にはソースクラスタのグループ読み取り権限を反映した書き出しが行なわれず、常にファイル所有者の読み書きのみを許すモードが使われていました。

§ § § § §

pg_restoreの「--statistics」および「--statistics-only」オプションの一貫しない挙動が修正されました。 (Chao Li, Michael Paquier) (18)

「--schema」「--table」などの選択的リストアオプションと組み合わせた場合に意図通りの要素がリストアされませんでした。pg_dumpで対象選択オプションを組み合わせた場合と同様に動作するように修正されました。

（誤動作例）
$ psql -d db1 <
 § §
vacuumdbの「--missing-stats-only」が、パーティションテーブルに対する式インデックスを処理対象から除外するようになりました。  (Baji Shaik) (18)

これまで、本オプションのvacuumdb実行では、パーティションテーブルに式インデックスがあると、常にそのパーティションテーブルにANALYZEを実行しようとしていました。しかし、統計情報は子パーティションのインデックスに作成されても、パーティションテーブルのインデックスには作成されないため、意味がありませんでした。

 §
contrib/amcheckで、btreeインデックスのメタページの「allequalimage」フラグの破損が報告されない問題が修正されました。  (Chao Li) (18)

btreeインデックスを検査する関数は、これまでインデックスキー列のいずれかにinterval_ops演算子クラスを含む場合のみ正しく動作していて、そうでないインデックスでこの破損が見逃される可能性がありました。

 §
contrib/amcheckの GINインデックス検証関数でメモリリークが修正されました。問い合わせが終わるまで未開放メモリが蓄積します。  (Kirill Reshke) (18)

大きなGINインデックスの検証でメモリ使用量が増大するおそれがありました。

 § §
contrib/amcheckで、ショートヘッダのvarlenaデータムが正しく扱われるように修正されました。  (Andrey Borodin) (18)(17)(16)(15)(14)

この誤りで、btreeインデックス検証で無駄な処理が生じる可能性がありますが、それ以上の悪影響は無いと考えられます。


varlenaデータムとはPostgreSQL実装内で使われる長さとデータ本体からなるデータ構造です。ショートヘッダは長さをあらわすのに1バイトだけ使う形式です。

 § § § § §
contrib/btree_gistで、float4とfloat8の演算子クラスにおける「NaN」の扱いが修正されました。  (Bill Kim, Tom Lane) (18)(17)(16)(15)(14)

各種の比較関数と、GiSTのpenalty関数、distance関数が「NaN」を考慮しておらず、「NaN」を渡されたときに誤った結果を返していました。


本修正の適用後、float列のbtree_gistインデックスに「NaN」のエントリが含まれる可能性がある場合は、それらのインデックスの再構築を推奨します。

 § § § § § §
contrib/btree_gistで、GiSTインデックス構築時のbit型とvarbit型の値のソートが修正されました。  (Tom Lane) (18)

これまでbit型の値がbytea型であるかのようにソートされていました。これは明白な誤動作を引き起こすことはありませんでしたが、型本来のソート順に一致しない並びで構築されるため、非効率なインデックスになりました。


本修正の適用後、bit列上のbtree_gistインデックスの再構築を推奨します。

 § §
contrib/btree_gistで、非等価（<>）演算子を使った検索が修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

可変長データ型の場合、非リーフインデックスページを走査するコードが誤った比較関数を適用していました。これは誤った問い合わせ結果、および場合によってはクラッシュにつながる可能性がありました。

 § § § § § §
contrib/dblinkとcontrib/postgres_fdwで、use_scram_passthroughオプションについて、ユーザマッピングの設定が外部サーバの設定より優先されるよう修正されました。  (Matheus Alcantara) (18)

これまでは外部サーバ側の設定が優先されていましたが、これは他の外部テーブルオプションの挙動と一貫していませんでした。他の接続オプション（sslcertやsslkeyなど）と同様に、外部サーバのオプションは共通のデフォルト値を提供し、ユーザマッピングのオプションがそれを上書きする扱いに統一されました。


これは非互換性を含む変更と言えます。

 § §
contrib/dblinkの外部データラッパのuse_scram_passthroughオプションが拒否されるようになりました。  (Matheus Alcantara) (18)

このオプションは外部サーバとユーザマッピングに対してのみ意味を持ちますが、dblinkは外部データラッパ（dblink_fdw）レベルでもこのオプションを受け付けていました（そして受け付けた設定を無視していました）。

 §
contrib/hstore_plperl、contrib/jsonb_plperl、contrib/jsonb_plpythonで保護されていない再帰とループがあり、修正されました。  (Aleksander Alekseev) (18)(17)(16)(15)(14)

深くネストしたjsonb値を扱うときのスタックオーバーフロー（によるクラッシュ）が防止されました。また、Perlのオブジェクト参照の循環チェーンをたどるときに生じる無限ループが割り込み可能になりました。

 § § § § § § § § § §
contrib/intarrayでプランナ統計情報のカタログキャッシュエントリの解放漏れが修正されました。  (Man Zeng) (18)(17)(16)(15)(14)

この解放漏れにより、「WARNING:  resource was not closed: cache pg_statistic ..」のような警告が発生していました。

 § § § § §
contrib/ltreeで比較関数における整数オーバーフローが修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

約14,653個を超えるラベルを含むltree値は、オーバーフローによって誤った比較結果を返していました。btreeインデックスにそのような値が含まれている場合、破損している可能性があるため、本修正の適用後に再構築することを推奨します。

 § § § § §
contrib/pgcryptoで、OSSLCipherオブジェクトの使用中にエラーが発生した後の二重解放によるクラッシュが回避されました。  (Yuelin Wang) (18)(17)
 § §
contrib/pg_prewarmのautoprewarmワーカの範囲外アクセスが修正されました。  (Matheus Alcantara) (18)

このコードは、配列の末尾の1つ先から値を取り出そうとしており、セグメンテーション違反によるクラッシュを引き起こす可能性がありました。

 §
contrib/pg_surgeryのheap_force_kill関数とheap_force_freeze関数で、配列の範囲外書き込みが修正されました。  (Michael Paquier) (18)(17)(16)(15)(14)

オフセット番号がMaxHeapTuplesPerPage（ページあたりの最大タプル数、291など）に等しいTIDを変更しようとすると、確保された配列の末尾の1バイト先に書き込み、サーバをクラッシュさせる可能性がありました。

 § § § § §
contrib/pg_surgeryで、64K要素を超えるTID配列による無限ループが回避されるようになりました。  (Andrey Rachitskiy) (18)(17)(16)(15)(14)
 § § § § § §
contrib/spiのrefint拡張で、check_foreign_key()関数のNULLポインタ参照が回避されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

ON UPDATE CASCADEの場合、参照列の新しいキー値がNULLであると、クラッシュが発生していました。これはCVE-2026-6637の修正の見落しですが、その前からあったコードも正しいものではありませんでした。

 § § § § §
contrib/segで、確実性指示子「~」を持つセグメントの値が正しく出力されるように修正されました。  (Ewan Young) (18)(17)(16)(15)(14)

seg型の出力関数seg_out()はセグメントの上限に付いた「~」を出力していませんでした。さらに悪いことに、下限に「~」があり上限に指示子がない場合、上限がまったく出力されませんでした。なお、文字列としての出力が不正であるだけで、演算結果に影響はありません。

（誤動作例：2番目と3番目が誤動作）
db1=# SELECT '~1 .. ~5'::seg, '1 .. ~5'::seg, '~1 .. 5'::seg;
   seg    |  seg   |  seg
----------+--------+--------
 ~1 .. ~5 | 1 .. 5 | ~1 ..
(1 row)

 § § § § §
contrib/xml2のxpath_nodeset()関数で名前空間ノードを問合せたときのクラッシュが修正されました。  (Andrey Chernyy, Michael Paquier) (18)(17)(16)(15)(14)

以下のように、query引数に「//namespace::」を指定した場合にクラッシュするケースが報告されました。

db1=# SELECT xpath_nodeset(
        '',
        '//namespace::*');

 § § § § §
OpenSSL 4を使ったPostgreSQLのビルドに対応しました。  (Daniel Gustafsson) (18)(17)(16)(15)(14)
 § § § § §
タイムゾーンデータファイルをtzdataリリース2026cに更新しました。  (Tom Lane) (18)(17)(16)(15)(14)

アルバータ州（America/Edmonton）は、2026年11月から年間を通したUTC-06（実質的に、恒久的なサマータイム）になります。このリリースでは、それ以降のタイムゾーン省略形は「CST」と仮定しています。この仮定は将来変更される可能性が高いのですが、新しい省略形に何が使われるかは明らかになっていません。


モロッコ（Africa/Casablanca）は、2026-09-20に、サマータイムの切り替えなしの恒久的なUTC+00に移行します。

 § § § § § §
古いマイナーバージョンが生成したWALのリプレイ時の自己デッドロックが修正されました。  (Andrey Borodin) (16)(15)(14)

この不具合は前回のマイナーリリース(16.14、15.18、14.23)で導入されました。より古いマイナーバージョンのプライマリに追従するスタンバイサーバで、startupプロセスがハングアップしてレプリケーションが先に進まなくなりました。


共有行ロックで使われるマルチトランザクションに関するWALレコードのリプレイで問題が発生しました。

 § § §
変数が1つも渡されていない場合でも、未定義のjsonpath変数をエラーとして扱うようになりました。  (Andrey Rachitskiy) (16)(15)(14)

jsonbの「@?」演算子と「@@」演算子がjsonpath式の中で使う変数を渡せない、という場合のコードパスでは、未知のjsonpath変数が、本来の期待であるエラーの発生ではなく、JSONのnullとして誤って扱われていました。期待される動作でないことに加えて、この誤りは無制限のメモリ消費を引き起こす可能性がありました。

（誤動作例）
db1=# select '{"A":1}'::jsonb @@ '$"no_such_var" == 1';
 ?column?
----------
 f
(1 row)

db1=# SELECT '{"A":1}'::jsonb @? '$"no_such_var"';
 ?column?
----------
 t
(1 row)

（修正後は以下のエラーが出る）
ERROR:  could not find jsonpath variable "no_such_var"

 § § §
Visual Studio 2026を使ったPostgreSQLのビルドに対応しました。  (Andrew Dunstan) (16)(15)(14)
 § § §

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

PostgreSQL 17.11 に関する技術情報

データベース技術グループ — Tue, 01 Sep 2026 04:34:01 +0000

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

しかしながら、最初の 3項目のセキュリティ修正は、設定の修正やデータのクリーンアップが必要となるかもしれません。また、以下に記載の修正項目に該当する GiSTインデックスがある場合には、インデックス再構築が必要となります。

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

PostgreSQL 17.10 から 17.11 への変更点

ロジカルデコーディングの出力プラグインが厳格化されました。新たな設定パラメータoutput_plugin_librariesでの指定が必要となりました。(CVE-2026-6471) (Jacob Champion) (18)(17)(16)(15)(14)

§ § § § § § § § §

contrib/pgcryptoのPGP暗号化がサポートされない暗号化方式を検出するように、修正されました。(CVE-2026-14663) (Daniel Gustafsson) (18)(17)(16)(15)(14)

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

psqlがスクリプト化された「COPY ... FROM STDIN」コマンドに続くインラインデータを、COPY開始時のエラーであっても、読み飛ばすように修正されました。(CVE-2026-6464) (Tom Lane) (18)(17)(16)(15)(14)

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

EXECUTEやFETCHを実行するポータルの出力行型についてクロスチェックを行うようになりました。(CVE-2026-16239) (Robert Haas) (18)(17)(16)(15)(14)

§ § § § § §

to_char()で、長いタイムゾーン省略形によるバッファオーバーランが修正されました。(CVE-2026-14669) (Tom Lane) (18)(17)(16)(15)(14)

これは容易にバックエンドプロセスのクラッシュができて、任意コード実行をもたらす攻撃も報告されました。

§ § § § § §

正規表現によるマッチ、分割の関数で、バッファオーバーランが修正されました。(CVE-2026-14664) (Masahiko Sawada) (18)(17)(16)(15)(14)

§ § § § § §

ascii()関数が不正な入力に対して頑健になりました。(CVE-2026-18024) (Michael Paquier) (18)(17)(16)(15)(14)

§ § § § § §

pg_restore_attribute_stats()関数でのマルチ範囲型の処理が修正されました。(CVE-2026-16238) (OpenAI Security Research Team) (18)(17)(16)(15)(14)

pg_restore_attribute_stats()はプランナ統計情報のダンプ、リストアで使われる関数です。

誤った統計情報のリストアにより、不適切なプラン選択による問合せ実行の遅延や潜在的なプランナ誤動作の可能性が考えられます。

§ § §

scalarineqsel()が、tid型と想定される定数を実際にそうであるか検査するようになりました。(CVE-2026-14668) (Tom Lane) (18)(17)(16)(15)(14)

この想定は組み込みの演算子については成り立ちますが、悪意で作られた演算子には通用せず、クラッシュやサーバメモリ暴露を引き起こします。

scalarineqsel()は選択率の見積を返すプランナの内部実装関数の1つです。

§ § § § § §

tsvector型とtsquery型の実装コードが（個々の要素、全体の長さの両面で）きわめて長い値に対して頑健になりました。(CVE-2026-14662) (Tom Lane) (18)(17)(16)(15)(14)

ドキュメントに記載されていた上限が、全てのコードパスで必ずしも強制されていませんでした。

ERROR:  lexeme is too long for tsvector ...
ERROR:  string is too long for tsvector ...
ERROR:  word is too long to be indexed ...
ERROR:  tsquery is too large

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

「FUNC_MAX_ARGS」を超える関数引数を処理する必要がない、と誤って想定していた様々な箇所が修正されました。(CVE-2026-14679) (Tom Lane) (18)(17)(16)(15)(14)

「FUNC_MAX_ARGS」はビルド時指定の定数でデフォルト100です。

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

internal型を引数や戻り値とする関数のSQLからの呼び出しを拒否するようになりました。(CVE-2026-14680) (Tom Lane) (18)(17)(16)(15)(14)

拒否するための既存の仕組みはありましたが、不十分であったため、明示的な検査が追加されました。

また、いくつかの集約関数のcombine処理で入力がNULLである場合に正しくSQLとしてのNULLを返すように修正されました。

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

ALTER TABLEコマンドで再構築されたとき、拡張統計オブジェクトの所有者が保たれるようになりました。(CVE-2026-6469) (Masahiko Sawada) (18)(17)(16)(15)(14)

§ § § § § §

EXTRACT()関数呼び出しを逆パースするときに、必要であればフィールド名をクォートするようになりました。(CVE-2026-15741) (Nathan Bossart) (18)(17)(16)(15)(14)

逆パースはダンプ出力やpsqlでの定義表示で行なわれる処理です。

§ § § § § §

これまで検査ができていなかった個所について、データ型に対する「USAGE」権限を検査するようになりました。(CVE-2026-6470) (Nathan Bossart) (18)(17)(16)(15)(14)

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

行単位セキュリティ(RLS)に対して、ロールに依存したキャッシュされたプランを、ロール変更後に無効化するようになりました。(CVE-2026-14666) (Ilya Staroverov, Shinya Kato, Nathan Bossart) (18)(17)(16)(15)(14)

§ § § § § §

直接のSSL接続の後のGSSEncRequestメッセージを拒否するようになりました。(CVE-2026-14681) (Michael Paquier) (18)(17)(16)(15)(14)

§ § §

モックのSCRAM認証シークレットがより本物らしくなりました。(CVE-2026-14672) (Nathan Bossart) (18)(17)(16)(15)(14)

本修正で、モックにもscram_iterations設定パラメータの値を使って、より実際に使われているシークレットに似せるようになりました。

§ § § §

ecpgアプリケーションでの範囲外書き込みが修正されました。サーバから不正なbytea型データを受け取ることで引き起こされます。(CVE-2026-16241) (Michael Paquier) (18)(17)(16)(15)(14)

§ § § § § §

psqlの「\unrestrict」コマンドの引数でバッククォート展開をしないようになりました。(CVE-2026-18408) (Nathan Bossart) (18)(17)(16)(15)(14)

§ § § § § §

pg_dumpにおいてpg_proc.protrftypesのエントリ数がFUNC_MAX_ARGSを超えないという前提が取り除かれました。(CVE-2026-19385) (Tom Lane) (18)(17)(16)(15)(14)

§ § § § § §

tieされたPerlの配列やハッシュに対して、PL/Perlが堅牢化されました。(CVE-2026-14670) (Tom Lane) (18)(17)(16)(15)(14)

tieは、配列やハッシュなどの変数に対して操作用のメソッド群を実装したオブジェクトに結びつける Perl の機能です。

§ § § § § §

PL/PerlおよびPL/Tclにおけるメモリ割り当て計算時の整数オーバーフローが修正されました。(CVE-2026-14677) (Heikki Linnakangas) (18)(17)(16)(15)(14)

これはコードの異なる個所で発生していたCVE-2026-6473と同様の問題で、同じ方法で修正されました。

§ § § § § §

contrib/amcheckの関数がインデックス式を実行する前にsearch_pathを制限するようになりました。(CVE-2026-14673) (Noah Misch) (18)(17)(16)(15)(14)

§ § § § § §

contrib/fuzzystrmatchのlevenshtein()およびlevenshtein_less_equal()関数における整数オーバーフローが修正されました。(CVE-2026-15742) (Nathan Bossart) (18)(17)(16)(15)(14)

§ § § § § §

contrib/pg_stat_statementsにおけるバッファオーバーランが修正されました。(CVE-2026-14676) (Alvaro Herrera) (18)(17)(16)(15)(14)

クエリの正規化処理において、正規化後の文字列が必要とするサイズが正確に考慮されていませんでした。

§ §

contrib/pg_trgmのGiST picksplit関数におけるデータ型エラーが修正されました。(CVE-2026-14678) (Heikki Linnakangas) (18)(17)(16)(15)(14)

§ § § § § §

contrib/refintのプランキャッシュが削除されるようになりました。(CVE-2026-14671) (Ayush Tiwari) (18)(17)(16)(15)(14)

§ § § § §

並列GINインデックスの構築時に、テーブルのpg_class.reltuples値が正しく更新されるようになりました。 (Jan Nidzwetzki, Tomas Vondra) (18)

SELECT DISTINCT t.oid::regclass, t.reltuples
FROM pg_class t
  JOIN pg_index i ON t.oid = i.indrelid
  JOIN pg_class ic ON i.indexrelid = ic.oid
WHERE t.relhasindex AND ic.relam = 2742;

§ §

非同期のAppendプランノードを再スキャンする際の、非同期読み取りの不適切な処理が修正されました。 (Alexander Korotkov, Gleb Kashkin, Etsuro Fujita) (18)(17)(16)(15)(14)

§ § § § § §

RANGEパーティションテーブルにおけるパーティションプルーニングの不具合が修正されました。 (David Rowley) (18)(17)(16)(15)(14)

§ § § § § §

結果リレーションのプルーニング後に、ModifyTableプランノード内の外部データラッパーの状態を正しく更新するようになりました。 (Ayush Tiwari, Rafia Sabih) (18)

§ §

「BEFORE UPDATE」トリガーを持つテーブルに対して、「RETURNING OLD」を指定したUPDATE文で発生していた並行更新の処理漏れが修正されました。 (Dean Rasheed) (18)

§ §

複数の結合キーと多数のNULL値が存在する場合のハッシュ結合の性能問題が修正されました。 (David Rowley) (18)

§ §

RETURNING句の式における括弧で囲まれた「OLD」や「NEW」の解析処理が修正されました。 (Marko Grujic) (18)

value IN (array)式に対するプランナのNULL許容性および厳密性チェックが修正されました。 (Ayush Tiwari) (18)(17)(16)(15)(14)

§ § § § § §

不適切な結合削除のロジックが修正されました。 (Matheus Alcantara, Richard Guo) (18)(17)(16)

§ § § § § § § §

結合の削除処理において、PlaceHolderVarsのクリーンアップがより徹底されるようになりました。 (Richard Guo, Arne Roland) (18)

§ § §

コンテナデータ型（配列、複合型、範囲型）の等価比較におけるハッシュ可能性に関する漏れていたチェックが追加されました。 (Andrei Lepikhov, Tom Lane) (18)(17)(16)(15)(14)

§ § § § §

プランナが、異なる等価性ルールを持つグループ化ステップより下位へ、WHERE句をプッシュダウンすることを避けるようになりました。 (Richard Guo) (18)

§ §

「EXCLUDE」句を指定している、または「ORDER BY」を指定していない、COUNTウィンドウ関数の誤った最適化が修正されました。 (Chengpeng Yan, David Rowley) (18)(17)(16)(15)

（報告された誤動作例）
db1=# CREATE TABLE t41 (id int PRIMARY KEY, k int NOT NULL, v int);
db1=# INSERT INTO t41(id, k, v) VALUES
        (1, 1, 1), (2, 1, NULL), (3, 1, 1), (4, 2, 1);

db1=# SELECT id, count(v) OVER (
        ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        EXCLUDE CURRENT ROW) AS c FROM t41;
 id | c
----+---
  1 | 1
  2 | 2
  3 | 1
  4 | 2
(4 rows)

db1=# SELECT * FROM (
        SELECT id, count(v) OVER (
          ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
          EXCLUDE CURRENT ROW) AS c FROM t41) s WHERE c < 2;
 id | c
----+---
  1 | 1
(1 row)
→ 正しくは id=3 の行も出力されないといけない

§ § § § §

プランナが"char"型の列の統計情報を参照する際に、予期せぬエラー「ERROR: cache lookup failed for collation 0」が発生する障害が修正されました。 (Feng Wu) (18)

"char"型は、一般的に使われるchar(n)型とは別の、主として内部的なシステムカタログで使用されるものです。

複数階層のパーティションが存在する場合でも、ALTER TABLEのALTER COLUMN ... DROP EXPRESSIONが正常に動作するよう修正されました。 (Alberto Piai) (18)(17)(16)(15)(14)

§ § § § § §

排他制約であるインデックスのパーティションをアタッチする処理の不具合が修正されました。 (Japin Li) (18)(17)

この誤りにより、排他制約を持つパーティションテーブルのダンプ/リストアが正常に動作しなくなっていました。

リストア時に以下のようなエラーが発生します。

ERROR:  cannot attach index "..." as a partition of index "..."
DETAIL:  The index definitions do not match.

§ § §

ALTER CONSTRAINTを使用して、パーティションテーブルのNOT NULL制約にNO INHERITを設定することができないように修正されました。 (Andreas Karlsson) (18)

ルールの名前を「_RETURN」に変更できないように修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

具体的には、ダンプ/リストアで「ERROR: non-view rule for "..." must not be named "_RETURN"」というエラーを起こすことが報告されました。

§ § § § § §

DROP OWNED BYにおいて、ロールメンバーシップへのロックの解放漏れが修正されました。 (Jeff Davis) (18)(17)(16)

§ § § §

EXPLAINがSQL/JSONの集約関数をデパースするときに予期せぬエラーを出すことがあり、修正されました。 (Richard Guo) (18)(17)(16)

実行プランの構造によっては、「ERROR: invalid JsonConstructorExpr underlying node type」というエラーが発生していました。

§ § § §

遅延一意性制約のインデックスに対してREINDEX CONCURRENTLYを使用した場合の不具合が修正されました。 (Nitin Motiani) (18)(17)(16)(15)(14)

§ § § § § §

非決定論的照合順序でバックスラッシュ（\）を使用したLIKE句のマッチングの不具合が修正されました。 (Nitin Motiani, Tom Lane) (18)

§ § § §

LIKE句や正規表現の完全一致パターンのインデックススキャン最適化の不具合が修正されました。 (Jelte Fennema-Nio) (18)

§ §

to_date() におけるローカライズされた月名、曜日名のマッチング処理が修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

§ § § § § § §

ギリシャ文字の語末形のシグマに対する大文字小文字の変換のルールが修正されました。 (Jeff Davis) (18)

文字列の直前が大文字小文字を区別しない文字だけで構成されている場合、そのシグマを語末形のシグマとはみなさないようにしました。

§ §

ハングルU+11A7（TBASE）のNFC再合成における誤りが修正されました。 (Diego Frias, Michael Paquier) (18)(17)(16)(15)(14)

この文字は有効なT音節として扱われていましたが、実際にはT音節ではないため、正規化処理中にこの文字が消えてしまっていました。

§ § § § §

大文字小文字を区別しない類義語の辞書において、出力する語彙素が切り捨てられる不具合が修正されました。 (Jeff Davis) (18)(17)(16)(15)(14)

小文字への変換によって語彙素のバイト長が増加した場合、出力時に元のバイト長に誤って切り捨てられていました。

§ § § § §

大文字小文字変換処理において、途中で途切れたUTF-8文字への対処が修正されました。 (Jeff Davis) (18)(17)

§ § §

hash_record_extended()のバグが修正されました。 (Man Zeng) (18)(17)(16)(15)(14)

§ § § § §

公開可能なテーブルが並行して削除された場合に、pg_get_publication_tables()が失敗する不具合が修正されました。 (Bharath Rupireddy) (18)(17)(16)

§ § § §

VARIADIC NULL を指定した場合に、satisfies_hash_partition() がクラッシュする不具合が修正されました。 (Robert Haas) (18)(17)(16)(15)(14)

§ § § § § §

tsvector_filter() および関連する関数で、不正な重みに関するエラーを、より明確かつ一貫した形で報告するよう修正されました。 (Ewan Young) (18)(17)(16)(15)(14)

§ § § § §

uundv7()関数で範囲外のタイムスタンプとなるシフト値を拒絶するようになりました。 (Baji Shaik) (18)

§ §

xpath()関数でnamestapeノードの処理が修正されました。 (Michael Paquier) (18)(17)(16)(15)(14)

予期せぬ「ERROR: could not copy node」エラーが出ていたものが修正されました。

§ § § § § § § § § §

jsonpathの「.decimal」メソッドが、精度やスケールの指定が正しくない場合でもERRORを出さないように、修正されました。 (Ewan Young) (18)(17)

サイレントモード（json_path_*関数のsilent引数がtrue）では、エラーを抑止すべきですが、そのようになっていませんでした。

§ § § § §

「IS JSON」や「JSON()」等の構文が、text型へのキャストを持たない文字列型の引数を与えられたときの、NULLポインタによるクラッシュが修正されました。 (Ayush Tiwari) (18)(17)(16)

PostgreSQL本体コードには該当するデータ型はありませんが、一部の拡張のデータ型で問題を引き起こす可能性がありました。

§ § §

「SQL/JSON」の「ON EMPTY / ON ERROR DEFAULT」の値に正しい型修飾が確実に適用されるようになりました。 (Ewan Young) (18)(17)

例えば、対象numeric型列の宣言された精度とスケールがデフォルト値に適用されませんでした。

（誤動作例）
db1=# SELECT JSON_VALUE(jsonb '{"b":"1234.5"}', '$.a' 
        RETURNING numeric(4,1) DEFAULT 99999.9 ON EMPTY);
 json_value
------------
    99999.9
(1 row)

（以下エラーが出るのが正しい動作）
ERROR:  numeric field overflow

§ § §

money型の最小値（64bit整数最小値）を-1で割ったときの、マシン依存の振る舞いが回避されました。 (Andrey Rachitskiy) (18)(17)(16)(15)(14)

§ § § § § §

全文検索の辞書に対するキャッシュエントリの作成途中でメモリ不足が生じた後にクラッシュする障害が修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

§ § § § § §

誤ったispell/hunspell辞書ファイルに対する処理でメモリ安全性に問題があり、修正されました。 (Andrey Rachitskiy) (18)(17)(16)(15)(14)

§ § § § § §

他セッションの一時テーブルへのアクセスが防止されました。 (Jim Jones, Daniil Davydov, Alexander Korotkov) (18)(17)(16)

§ § § § § §

一時テーブルにアクセスするときの「ERROR: no empty local buffer available」エラーが防止されました。 (Melanie Plageman) (18)

autovacuumがデータベースを処理する順番が修正されました。 (Rustam Khamidullin) (18)(17)

最高スコアから最低スコアに向かう順で処理されるべきところで、意図せず逆順になっていました。

§ § §

VACUUMのXID周回フェールセーフモードで、共有バッファプールを全使用するように動作が復旧されました。 (Melanie Plageman) (18)

§ § § §

パラレルVACUUMワーカーの処理でのメモリリークが修正されました。 (Baji Shaik) (18)(17)

パラレルワーカーからの報告過程で報告ごとに1kB程度のリークがあり、これはワーカープロセスが生きている間は蓄積されていきました。

§ §

問合せのキャンセルとVACUUM遅延が、GINインデックスのポスティングツリーのクリーンアップ中であっても、すぐに行なわれるようになりました。 (Paul Kim, Alexander Korotkov) (18)(17)(16)(15)(14)

よくある値に対するポスティングツリーは大きくなることがあり、ここに割り込みの検査が欠けていたため、処理が長く継続してしまいました。

§ § § § § §

GiSTおよびSP-GiSTのインデックスに対するIndex Only Scanで、インデックスタプルのデコーディングを誤る可能性があり、修正されました。 (Peter Geoghegan) (18)(17)(16)(15)(14)

（誤動作例）
db1=# CREATE TABLE t75 (a inet, r numrange);
db1=# INSERT INTO t75 VALUES 
      ('::1', numrange(repeat('1', 100)::numeric, repeat('2', 200)::numeric)));
db1=# CREATE INDEX ON t75 USING gist (a inet_ops, r range_ops);
db1=# VACUUM ANALYZE t75;
db1=# SET enable_seqscan TO off;
db1=# SELECT lower(r) = repeat('1', 100)::numeric,
             upper(r) = repeat('2', 200)::numeric FROM t75;
ERROR:  type with OID 860 does not exist

§ § § § § §

バルク拡張されたテーブルの新たな最終ブロックがフリースペースマップに即座に追加されるようになりました。 (Jingtang Zhang) (18)(17)(16)

§ § § §

トランザクションのアボート時のリソース解放処理で、メモリの二重解放（クラッシュをひきおこします）、または、エラーの再帰的な無限ループが起きる可能性があり、修正されました。 (Tom Lane) (18)(17)

巨大な入力値を伴うSQLがエラーになって、トランザクションアボートが行なわれたケースで問題が報告されました。

§ §

PostgreSQLの処理内でディレクトリを作成するとき、同じディレクトリの同時作成を許容するようになりました。 (Andrew Dunstan, Tom Lane) (18)(17)(16)(15)(14)

§ § § § §

JITコンパイルされたタプルデフォームを行うコードが、仮想生成列を正しく考慮するように修正されました。 (David Rowley) (18)

NOT NULL制約のある仮想生成列を含むテーブルへの問合せで、誤った問い合わせ結果が生じる例が報告されました。

依存されている全てのオブジェクトに共有ロックを取得することにより、宙に浮いたオブジェクト依存関係の生成が防止されました。 (Bertrand Drouvot) (18)(17)(16)(15)(14)

共有ロックは依存されているオブジェクトの削除と衝突しますので、これまであった競合状態を排除することができます。

§ § § § § § § § § §

SERIALIZABLE分離モードに対する衝突の検出での競合状態が修正されました。 (Peter Geoghegan) (18)(17)(16)(15)(14)

§ § § § § §

バリアイベントの処理で競合状態が修正されました。 (Masahiko Sawada) (18)(17)(16)(15)

LOG:  still waiting for backend with PID %d to accept ProcSignalBarrier

近年追加されたオンラインWALレベル変更などの機能によって、この問題がより目立つようになっています。

§ § § §

同じロックグループに属するプロセス集合が同時に終了したときの競合状態が修正されました。 (Vlad Lesin) (18)(17)(16)(15)(14)

§ § § § § § § § § §

テーブルのビジビリティマップ(VM)でビットをクリアする操作のWAL出力が修正されました。 (Melanie Plageman, Andres Freund) (18)(17)

既存のバックアップやアーカイブWALに潜在的にデータ破損が含まれていることに留意してください。

§ § § § § § § § §

WALサマライズ処理でのタイムライン変更時のハングアップが防止されました。 (Robert Haas) (18)(17)

スタンバイサーバで、以下のログメッセージがwalsummarizerプロセスから継続的に出力される動作が報告されました。

ERROR:  could not read WAL from timeline .. at ...: invalid record length ...

§ § § § § §

スタンバイ昇格のときのロジカルデコーディングのタイムライン選択で、競合状態が修正されました。 (Bertrand Drouvot) (18)(17)(16)

§ § § § § § §

タイムラインを切替するときのwalreceiverの接続文字列の露出が回避されました。 (Chao Li) (18)(17)(16)(15)(14)

§ § § § §

ロジカルレプリケーションで受け取ったタプルの列数が正しいかの検証を、アサートではなく実行時チェックで行うようになりました。 (Varik Matevosyan) (18)(17)(16)(15)(14)

§ § § § §

レプリケーションコマンド内の文字列パラメータへのクォート付加について、実装がクリーンアップされました。 (Tom Lane) (18)(17)(16)(15)(14)

§ § § § §

空のプリペアドトランザクションのロジカルデコーディングについて修正されました。 (Masahiko Sawada) (18)(17)(16)(15)(14)

§ § § § § §

スタンバイ昇格後のUNLOGGEDシーケンスのデータ破損が修正されました。 (Fujii Masao) (18)(17)(16)(15)

§ § § § §

カスケードスタンバイでのWALアーカイブによるリカバリからストリーミングに復帰するときの再接続失敗が、修正されました。 (Marco Nenciarini) (18)(17)(16)(15)(14)

このとき「ERROR: requested starting point ... is ahead of the WAL flush position」が発生する可能性がありました。

§ § § § § §

WALリプレイが一貫性のあるデータベース状態に達する前にホットスタンバイ接続を受け付ける動作が防止されました。 (Nikhil Sontakke) (18)

§ §

スタンバイサーバで、ローカルにpg_database.dathasloginevtのクリアを試みないようになりました。 (Ayush Tiwari) (18)(17)

§ §

使われなくなったレプリケーションスロットを削除するときの競合状態が回避されました。 (Xuneng Zhou) (18)(17)

§ §

一時的なレプリケーションスロット（初期化途中の論理レプリケーションスロット）を削除するときの競合状態が回避されました。 (Zhijie Hou) (18)(17)(16)(15)(14)

§ § § § §

ロジカルレプリケーションのテーブル初期同期で、進捗報告が古い内容となっていた問題が修正されました。 (Shinya Kato) (18)(17)(16)(15)(14)

§ § § § §

バックアップに失敗したなら、ベースバックアップの進捗がクリアされるようになりました。 (Chao Li) (18)(17)(16)(15)

§ § § § § § § § §

設定track_functionsが有効であるとき、実行時統計情報(pgstats)のエントリの同時削除のためにPANICが生じる可能性があり、修正されました。 (Sami Imseih, Michael Paquier) (18)(17)(16)(15)

「PANIC: cannot abort transaction .., it was already committed」が出るケースが報告されました。

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

対応する共有ハッシュテーブルのエントリに対するメモリ領域取得に失敗した後、壊れた実行時統計情報(pgstats)のローカルエントリをクリーンアップするようになりました。 (Niall Newman) (18)(17)(16)(15)

これを行なっていなかったため、次にローカルエントリが使われたときに、NULLポインタ参照によるクラッシュが発生しました。

§ § § § §

読み込みや書き込みの失敗後に誤ったI/O操作統計が記録されないように、修正されました。 (Bertrand Drouvot) (18)

PL/Perlで、不正なPostgreSQL::InServer::ARRAYオブジェクトを扱うときのNULLポインタ参照によるクラッシュが回避されるようになりました。 (Xing Guo) (18)(17)(16)(15)(14)

（クラッシュ発生例）
=# CREATE FUNCTION f102() RETURNS integer[] AS $$
     return bless {}, "PostgreSQL::InServer::ARRAY"; $$ LANGUAGE plperl;
=# SELECT f102();
server closed the connection unexpectedly

§ § § § §

PL/Pythonで、Pythonのシーケンスオブジェクトとマッピングオブジェクトを扱うときにエラーを正しく検査するようになりました。 (Richard Guo) (18)(17)(16)(15)(14)

§ § § § § §

libpqで、pqReadData()の実行中にSSLまたはGSSの復号バッファに残っている未処理バイトを常にすべて取り出すようになりました。 (Jacob Champion) (18)(17)(16)(15)(14)

pqReadData()はサーバ側からデータを読むlibpqの内部実装関数です。

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

libpqのメモリ不足状態の処理が改善されました。 (Anthonin Bonnefoy) (18)

§ §

libpqのトレース機能が、新しい形式のBackendKeyDataメッセージとCancelRequestメッセージを正しく出力するようになりました。 (Anthonin Bonnefoy) (18)

§ §

libpqが30000バイトを超えるParameterDescriptionメッセージを受け付けられるようになりました。 (Ning Sun) (18)(17)(16)(15)(14)

§ § § § §

ecpgコンパイラのNULLポインタ参照によるクラッシュが修正されました。 (Jehan-Guillaume de Rorthais) (18)

構造体の内側に入れ子になった共用体を含むDECLAREセクションをもつ.pgcコードを変換しようとすると、ecpgコマンド実行がクラッシュしました。

（ecpgコマンドがクラッシュするコード例）
EXEC SQL BEGIN DECLARE SECTION;
    struct s1
    {
        char STR1[10];
        union u1
        {
             int NUM1;
             int NUM2;
        } U1;
    } S1;
EXEC SQL END DECLARE SECTION;

ecpgのGET DESCRIPTOR文とSET DESCRIPTOR文で、記述子ヘッダ項目を複数指定する構文が拒否されるようになりました。 (Masashi Kamura) (18)(17)(16)(15)(14)

本修正で構文解析処理でもドキュメント上でもヘッダ項目は1つだけに変更されました。これは非互換性を含む変更です。

§ § § § §

psqlのパイプラインモードにおける遅延エラーの問題が修正されました。 (Michael Paquier) (18)

psqlの拡張表示（expanded）の整形出力で、行の幅が揃うようになりました。 (Pavel Stehule) (18)(17)(16)(15)(14)

（ずれた出力の例）

+-[ RECORD 1 ]-+
| a | 10 |
| b | 20 |
+---+----+

（修正後の出力例）

+-[ RECORD 1 ]-+
| a | 10       |
| b | 20       |
+---+----------+

§ § § § §

psqlの特別変数WATCH_INTERVALについて、既定の上限が強制されるようになりました。 (Sven Klemm, Daniel Gustafsson) (18)

psqlの「\l+」でデータベースサイズを表示する権限検査が修正されました。 (Christoph Berg) (18)(17)(16)(15)(14)

修正後は、「\l+」の権限検査にpg_read_all_statsロールの権限（USAGE）の確認が加わり、pg_database_size()の権限規則と一致するようになりました。

§ § § § § §

psqlの「\df」のタブ補完で、プロシージャも候補に含めるようになりました。 (Erik Wienhold) (18)(17)(16)(15)(14)

「\df」コマンド自体はプロシージャも表示対象に含めるよう拡張されていましたが、タブ補完の候補は関数だけを表示し続けていました。

§ § § § § §

pgbenchのスレッド安全性のバグが修正されました。 (Fujii Masao) (18)(17)(16)(15)

§ § § §

pg_combinebackupで、コピー元ファイルが想定より小さい場合に無限ループが発生することがあり、防止されました。 (Peter Eisentraut) (18)(17)

§ §

pg_createsubscriberで、エラー発生後にパブリッシャ側オブジェクトのクリーンアップが行なわれない場合があり、修正されました。 (Nisha Moond) (18)(17)

§ §

pg_recvlogicalの出力ファイルが、ソースクラスタのグループ読み取り権限に従って作成されるようになりました。 (Fujii Masao) (18)(17)(16)(15)(14)

§ § § § §

pg_restoreの「--statistics」および「--statistics-only」オプションの一貫しない挙動が修正されました。 (Chao Li, Michael Paquier) (18)

（誤動作例）
$ psql -d db1 <
 § §
vacuumdbの「--missing-stats-only」が、パーティションテーブルに対する式インデックスを処理対象から除外するようになりました。  (Baji Shaik) (18)

これまで、本オプションのvacuumdb実行では、パーティションテーブルに式インデックスがあると、常にそのパーティションテーブルにANALYZEを実行しようとしていました。しかし、統計情報は子パーティションのインデックスに作成されても、パーティションテーブルのインデックスには作成されないため、意味がありませんでした。

 §
contrib/amcheckで、btreeインデックスのメタページの「allequalimage」フラグの破損が報告されない問題が修正されました。  (Chao Li) (18)

btreeインデックスを検査する関数は、これまでインデックスキー列のいずれかにinterval_ops演算子クラスを含む場合のみ正しく動作していて、そうでないインデックスでこの破損が見逃される可能性がありました。

 §
contrib/amcheckの GINインデックス検証関数でメモリリークが修正されました。問い合わせが終わるまで未開放メモリが蓄積します。  (Kirill Reshke) (18)

大きなGINインデックスの検証でメモリ使用量が増大するおそれがありました。

 § §
contrib/amcheckで、ショートヘッダのvarlenaデータムが正しく扱われるように修正されました。  (Andrey Borodin) (18)(17)(16)(15)(14)

この誤りで、btreeインデックス検証で無駄な処理が生じる可能性がありますが、それ以上の悪影響は無いと考えられます。


varlenaデータムとはPostgreSQL実装内で使われる長さとデータ本体からなるデータ構造です。ショートヘッダは長さをあらわすのに1バイトだけ使う形式です。

 § § § § §
contrib/btree_gistで、float4とfloat8の演算子クラスにおける「NaN」の扱いが修正されました。  (Bill Kim, Tom Lane) (18)(17)(16)(15)(14)

各種の比較関数と、GiSTのpenalty関数、distance関数が「NaN」を考慮しておらず、「NaN」を渡されたときに誤った結果を返していました。


本修正の適用後、float列のbtree_gistインデックスに「NaN」のエントリが含まれる可能性がある場合は、それらのインデックスの再構築を推奨します。

 § § § § § §
contrib/btree_gistで、GiSTインデックス構築時のbit型とvarbit型の値のソートが修正されました。  (Tom Lane) (18)

これまでbit型の値がbytea型であるかのようにソートされていました。これは明白な誤動作を引き起こすことはありませんでしたが、型本来のソート順に一致しない並びで構築されるため、非効率なインデックスになりました。


本修正の適用後、bit列上のbtree_gistインデックスの再構築を推奨します。

 § §
contrib/btree_gistで、非等価（<>）演算子を使った検索が修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

可変長データ型の場合、非リーフインデックスページを走査するコードが誤った比較関数を適用していました。これは誤った問い合わせ結果、および場合によってはクラッシュにつながる可能性がありました。

 § § § § § §
contrib/dblinkとcontrib/postgres_fdwで、use_scram_passthroughオプションについて、ユーザマッピングの設定が外部サーバの設定より優先されるよう修正されました。  (Matheus Alcantara) (18)

これまでは外部サーバ側の設定が優先されていましたが、これは他の外部テーブルオプションの挙動と一貫していませんでした。他の接続オプション（sslcertやsslkeyなど）と同様に、外部サーバのオプションは共通のデフォルト値を提供し、ユーザマッピングのオプションがそれを上書きする扱いに統一されました。


これは非互換性を含む変更と言えます。

 § §
contrib/dblinkの外部データラッパのuse_scram_passthroughオプションが拒否されるようになりました。  (Matheus Alcantara) (18)

このオプションは外部サーバとユーザマッピングに対してのみ意味を持ちますが、dblinkは外部データラッパ（dblink_fdw）レベルでもこのオプションを受け付けていました（そして受け付けた設定を無視していました）。

 §
contrib/hstore_plperl、contrib/jsonb_plperl、contrib/jsonb_plpythonで保護されていない再帰とループがあり、修正されました。  (Aleksander Alekseev) (18)(17)(16)(15)(14)

深くネストしたjsonb値を扱うときのスタックオーバーフロー（によるクラッシュ）が防止されました。また、Perlのオブジェクト参照の循環チェーンをたどるときに生じる無限ループが割り込み可能になりました。

 § § § § § § § § § §
contrib/intarrayでプランナ統計情報のカタログキャッシュエントリの解放漏れが修正されました。  (Man Zeng) (18)(17)(16)(15)(14)

この解放漏れにより、「WARNING:  resource was not closed: cache pg_statistic ..」のような警告が発生していました。

 § § § § §
contrib/ltreeで比較関数における整数オーバーフローが修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

約14,653個を超えるラベルを含むltree値は、オーバーフローによって誤った比較結果を返していました。btreeインデックスにそのような値が含まれている場合、破損している可能性があるため、本修正の適用後に再構築することを推奨します。

 § § § § §
contrib/pgcryptoで、OSSLCipherオブジェクトの使用中にエラーが発生した後の二重解放によるクラッシュが回避されました。  (Yuelin Wang) (18)(17)
 § §
contrib/pg_prewarmのautoprewarmワーカの範囲外アクセスが修正されました。  (Matheus Alcantara) (18)

このコードは、配列の末尾の1つ先から値を取り出そうとしており、セグメンテーション違反によるクラッシュを引き起こす可能性がありました。

 §
contrib/pg_surgeryのheap_force_kill関数とheap_force_freeze関数で、配列の範囲外書き込みが修正されました。  (Michael Paquier) (18)(17)(16)(15)(14)

オフセット番号がMaxHeapTuplesPerPage（ページあたりの最大タプル数、291など）に等しいTIDを変更しようとすると、確保された配列の末尾の1バイト先に書き込み、サーバをクラッシュさせる可能性がありました。

 § § § § §
contrib/pg_surgeryで、64K要素を超えるTID配列による無限ループが回避されるようになりました。  (Andrey Rachitskiy) (18)(17)(16)(15)(14)
 § § § § § §
contrib/spiのrefint拡張で、check_foreign_key()関数のNULLポインタ参照が回避されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

ON UPDATE CASCADEの場合、参照列の新しいキー値がNULLであると、クラッシュが発生していました。これはCVE-2026-6637の修正の見落しですが、その前からあったコードも正しいものではありませんでした。

 § § § § §
contrib/segで、確実性指示子「~」を持つセグメントの値が正しく出力されるように修正されました。  (Ewan Young) (18)(17)(16)(15)(14)

seg型の出力関数seg_out()はセグメントの上限に付いた「~」を出力していませんでした。さらに悪いことに、下限に「~」があり上限に指示子がない場合、上限がまったく出力されませんでした。なお、文字列としての出力が不正であるだけで、演算結果に影響はありません。

（誤動作例：2番目と3番目が誤動作）
db1=# SELECT '~1 .. ~5'::seg, '1 .. ~5'::seg, '~1 .. 5'::seg;
   seg    |  seg   |  seg
----------+--------+--------
 ~1 .. ~5 | 1 .. 5 | ~1 ..
(1 row)

 § § § § §
contrib/xml2のxpath_nodeset()関数で名前空間ノードを問合せたときのクラッシュが修正されました。  (Andrey Chernyy, Michael Paquier) (18)(17)(16)(15)(14)

以下のように、query引数に「//namespace::」を指定した場合にクラッシュするケースが報告されました。

db1=# SELECT xpath_nodeset(
        '',
        '//namespace::*');

 § § § § §
OpenSSL 4を使ったPostgreSQLのビルドに対応しました。  (Daniel Gustafsson) (18)(17)(16)(15)(14)
 § § § § §
タイムゾーンデータファイルをtzdataリリース2026cに更新しました。  (Tom Lane) (18)(17)(16)(15)(14)

アルバータ州（America/Edmonton）は、2026年11月から年間を通したUTC-06（実質的に、恒久的なサマータイム）になります。このリリースでは、それ以降のタイムゾーン省略形は「CST」と仮定しています。この仮定は将来変更される可能性が高いのですが、新しい省略形に何が使われるかは明らかになっていません。


モロッコ（Africa/Casablanca）は、2026-09-20に、サマータイムの切り替えなしの恒久的なUTC+00に移行します。

 § § § § § §
古いマイナーバージョンが生成したWALのリプレイ時の自己デッドロックが修正されました。  (Andrey Borodin) (16)(15)(14)

この不具合は前回のマイナーリリース(16.14、15.18、14.23)で導入されました。より古いマイナーバージョンのプライマリに追従するスタンバイサーバで、startupプロセスがハングアップしてレプリケーションが先に進まなくなりました。


共有行ロックで使われるマルチトランザクションに関するWALレコードのリプレイで問題が発生しました。

 § § §
変数が1つも渡されていない場合でも、未定義のjsonpath変数をエラーとして扱うようになりました。  (Andrey Rachitskiy) (16)(15)(14)

jsonbの「@?」演算子と「@@」演算子がjsonpath式の中で使う変数を渡せない、という場合のコードパスでは、未知のjsonpath変数が、本来の期待であるエラーの発生ではなく、JSONのnullとして誤って扱われていました。期待される動作でないことに加えて、この誤りは無制限のメモリ消費を引き起こす可能性がありました。

（誤動作例）
db1=# select '{"A":1}'::jsonb @@ '$"no_such_var" == 1';
 ?column?
----------
 f
(1 row)

db1=# SELECT '{"A":1}'::jsonb @? '$"no_such_var"';
 ?column?
----------
 t
(1 row)

（修正後は以下のエラーが出る）
ERROR:  could not find jsonpath variable "no_such_var"

 § § §
Visual Studio 2026を使ったPostgreSQLのビルドに対応しました。  (Andrew Dunstan) (16)(15)(14)
 § § §

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

PostgreSQL 16.15 に関する技術情報

データベース技術グループ — Tue, 01 Sep 2026 04:33:02 +0000

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

しかしながら、最初の 3項目のセキュリティ修正は、設定の修正やデータのクリーンアップが必要となるかもしれません。また、以下に記載の GiSTインデックスがある場合には、インデックス再構築が必要となります。

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

PostgreSQL 16.14 から 16.15 への変更点

ロジカルデコーディングの出力プラグインが厳格化されました。新たな設定パラメータoutput_plugin_librariesでの指定が必要となりました。(CVE-2026-6471) (Jacob Champion) (18)(17)(16)(15)(14)

§ § § § § § § § §

contrib/pgcryptoのPGP暗号化がサポートされない暗号化方式を検出するように、修正されました。(CVE-2026-14663) (Daniel Gustafsson) (18)(17)(16)(15)(14)

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

psqlがスクリプト化された「COPY ... FROM STDIN」コマンドに続くインラインデータを、COPY開始時のエラーであっても、読み飛ばすように修正されました。(CVE-2026-6464) (Tom Lane) (18)(17)(16)(15)(14)

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

EXECUTEやFETCHを実行するポータルの出力行型についてクロスチェックを行うようになりました。(CVE-2026-16239) (Robert Haas) (18)(17)(16)(15)(14)

§ § § § § §

to_char()で、長いタイムゾーン省略形によるバッファオーバーランが修正されました。(CVE-2026-14669) (Tom Lane) (18)(17)(16)(15)(14)

これは容易にバックエンドプロセスのクラッシュができて、任意コード実行をもたらす攻撃も報告されました。

§ § § § § §

正規表現によるマッチ、分割の関数で、バッファオーバーランが修正されました。(CVE-2026-14664) (Masahiko Sawada) (18)(17)(16)(15)(14)

§ § § § § §

ascii()関数が不正な入力に対して頑健になりました。(CVE-2026-18024) (Michael Paquier) (18)(17)(16)(15)(14)

§ § § § § §

pg_restore_attribute_stats()関数でのマルチ範囲型の処理が修正されました。(CVE-2026-16238) (OpenAI Security Research Team) (18)(17)(16)(15)(14)

pg_restore_attribute_stats()はプランナ統計情報のダンプ、リストアで使われる関数です。

誤った統計情報のリストアにより、不適切なプラン選択による問合せ実行の遅延や潜在的なプランナ誤動作の可能性が考えられます。

§ § §

scalarineqsel()が、tid型と想定される定数を実際にそうであるか検査するようになりました。(CVE-2026-14668) (Tom Lane) (18)(17)(16)(15)(14)

この想定は組み込みの演算子については成り立ちますが、悪意で作られた演算子には通用せず、クラッシュやサーバメモリ暴露を引き起こします。

scalarineqsel()は選択率の見積を返すプランナの内部実装関数の1つです。

§ § § § § §

tsvector型とtsquery型の実装コードが（個々の要素、全体の長さの両面で）きわめて長い値に対して頑健になりました。(CVE-2026-14662) (Tom Lane) (18)(17)(16)(15)(14)

ドキュメントに記載されていた上限が、全てのコードパスで必ずしも強制されていませんでした。

ERROR:  lexeme is too long for tsvector ...
ERROR:  string is too long for tsvector ...
ERROR:  word is too long to be indexed ...
ERROR:  tsquery is too large

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

「FUNC_MAX_ARGS」を超える関数引数を処理する必要がない、と誤って想定していた様々な箇所が修正されました。(CVE-2026-14679) (Tom Lane) (18)(17)(16)(15)(14)

「FUNC_MAX_ARGS」はビルド時指定の定数でデフォルト100です。

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

internal型を引数や戻り値とする関数のSQLからの呼び出しを拒否するようになりました。(CVE-2026-14680) (Tom Lane) (18)(17)(16)(15)(14)

拒否するための既存の仕組みはありましたが、不十分であったため、明示的な検査が追加されました。

また、いくつかの集約関数のcombine処理で入力がNULLである場合に正しくSQLとしてのNULLを返すように修正されました。

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

ALTER TABLEコマンドで再構築されたとき、拡張統計オブジェクトの所有者が保たれるようになりました。(CVE-2026-6469) (Masahiko Sawada) (18)(17)(16)(15)(14)

§ § § § § §

EXTRACT()関数呼び出しを逆パースするときに、必要であればフィールド名をクォートするようになりました。(CVE-2026-15741) (Nathan Bossart) (18)(17)(16)(15)(14)

逆パースはダンプ出力やpsqlでの定義表示で行なわれる処理です。

§ § § § § §

これまで検査ができていなかった個所について、データ型に対する「USAGE」権限を検査するようになりました。(CVE-2026-6470) (Nathan Bossart) (18)(17)(16)(15)(14)

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

行単位セキュリティ(RLS)に対して、ロールに依存したキャッシュされたプランを、ロール変更後に無効化するようになりました。(CVE-2026-14666) (Ilya Staroverov, Shinya Kato, Nathan Bossart) (18)(17)(16)(15)(14)

§ § § § § §

直接のSSL接続の後のGSSEncRequestメッセージを拒否するようになりました。(CVE-2026-14681) (Michael Paquier) (18)(17)(16)(15)(14)

§ § §

モックのSCRAM認証シークレットがより本物らしくなりました。(CVE-2026-14672) (Nathan Bossart) (18)(17)(16)(15)(14)

本修正で、モックにもscram_iterations設定パラメータの値を使って、より実際に使われているシークレットに似せるようになりました。

§ § § §

ecpgアプリケーションでの範囲外書き込みが修正されました。サーバから不正なbytea型データを受け取ることで引き起こされます。(CVE-2026-16241) (Michael Paquier) (18)(17)(16)(15)(14)

§ § § § § §

psqlの「\unrestrict」コマンドの引数でバッククォート展開をしないようになりました。(CVE-2026-18408) (Nathan Bossart) (18)(17)(16)(15)(14)

§ § § § § §

pg_dumpにおいてpg_proc.protrftypesのエントリ数がFUNC_MAX_ARGSを超えないという前提が取り除かれました。(CVE-2026-19385) (Tom Lane) (18)(17)(16)(15)(14)

§ § § § § §

tieされたPerlの配列やハッシュに対して、PL/Perlが堅牢化されました。(CVE-2026-14670) (Tom Lane) (18)(17)(16)(15)(14)

tieは、配列やハッシュなどの変数に対して操作用のメソッド群を実装したオブジェクトに結びつける Perl の機能です。

§ § § § § §

PL/PerlおよびPL/Tclにおけるメモリ割り当て計算時の整数オーバーフローが修正されました。(CVE-2026-14677) (Heikki Linnakangas) (18)(17)(16)(15)(14)

これはコードの異なる個所で発生していたCVE-2026-6473と同様の問題で、同じ方法で修正されました。

§ § § § § §

contrib/amcheckの関数がインデックス式を実行する前にsearch_pathを制限するようになりました。(CVE-2026-14673) (Noah Misch) (18)(17)(16)(15)(14)

§ § § § § §

contrib/fuzzystrmatchのlevenshtein()およびlevenshtein_less_equal()関数における整数オーバーフローが修正されました。(CVE-2026-15742) (Nathan Bossart) (18)(17)(16)(15)(14)

§ § § § § §

contrib/pg_stat_statementsにおけるバッファオーバーランが修正されました。(CVE-2026-14676) (Alvaro Herrera) (18)(17)(16)(15)(14)

クエリの正規化処理において、正規化後の文字列が必要とするサイズが正確に考慮されていませんでした。

§ §

contrib/pg_trgmのGiST picksplit関数におけるデータ型エラーが修正されました。(CVE-2026-14678) (Heikki Linnakangas) (18)(17)(16)(15)(14)

§ § § § § §

contrib/refintのプランキャッシュが削除されるようになりました。(CVE-2026-14671) (Ayush Tiwari) (18)(17)(16)(15)(14)

§ § § § §

並列GINインデックスの構築時に、テーブルのpg_class.reltuples値が正しく更新されるようになりました。 (Jan Nidzwetzki, Tomas Vondra) (18)

SELECT DISTINCT t.oid::regclass, t.reltuples
FROM pg_class t
  JOIN pg_index i ON t.oid = i.indrelid
  JOIN pg_class ic ON i.indexrelid = ic.oid
WHERE t.relhasindex AND ic.relam = 2742;

§ §

非同期のAppendプランノードを再スキャンする際の、非同期読み取りの不適切な処理が修正されました。 (Alexander Korotkov, Gleb Kashkin, Etsuro Fujita) (18)(17)(16)(15)(14)

§ § § § § §

RANGEパーティションテーブルにおけるパーティションプルーニングの不具合が修正されました。 (David Rowley) (18)(17)(16)(15)(14)

§ § § § § §

結果リレーションのプルーニング後に、ModifyTableプランノード内の外部データラッパーの状態を正しく更新するようになりました。 (Ayush Tiwari, Rafia Sabih) (18)

§ §

「BEFORE UPDATE」トリガーを持つテーブルに対して、「RETURNING OLD」を指定したUPDATE文で発生していた並行更新の処理漏れが修正されました。 (Dean Rasheed) (18)

§ §

複数の結合キーと多数のNULL値が存在する場合のハッシュ結合の性能問題が修正されました。 (David Rowley) (18)

§ §

RETURNING句の式における括弧で囲まれた「OLD」や「NEW」の解析処理が修正されました。 (Marko Grujic) (18)

value IN (array)式に対するプランナのNULL許容性および厳密性チェックが修正されました。 (Ayush Tiwari) (18)(17)(16)(15)(14)

§ § § § § §

不適切な結合削除のロジックが修正されました。 (Matheus Alcantara, Richard Guo) (18)(17)(16)

§ § § § § § § §

結合の削除処理において、PlaceHolderVarsのクリーンアップがより徹底されるようになりました。 (Richard Guo, Arne Roland) (18)

§ § §

コンテナデータ型（配列、複合型、範囲型）の等価比較におけるハッシュ可能性に関する漏れていたチェックが追加されました。 (Andrei Lepikhov, Tom Lane) (18)(17)(16)(15)(14)

§ § § § §

プランナが、異なる等価性ルールを持つグループ化ステップより下位へ、WHERE句をプッシュダウンすることを避けるようになりました。 (Richard Guo) (18)

§ §

「EXCLUDE」句を指定している、または「ORDER BY」を指定していない、COUNTウィンドウ関数の誤った最適化が修正されました。 (Chengpeng Yan, David Rowley) (18)(17)(16)(15)

（報告された誤動作例）
db1=# CREATE TABLE t41 (id int PRIMARY KEY, k int NOT NULL, v int);
db1=# INSERT INTO t41(id, k, v) VALUES
        (1, 1, 1), (2, 1, NULL), (3, 1, 1), (4, 2, 1);

db1=# SELECT id, count(v) OVER (
        ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        EXCLUDE CURRENT ROW) AS c FROM t41;
 id | c
----+---
  1 | 1
  2 | 2
  3 | 1
  4 | 2
(4 rows)

db1=# SELECT * FROM (
        SELECT id, count(v) OVER (
          ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
          EXCLUDE CURRENT ROW) AS c FROM t41) s WHERE c < 2;
 id | c
----+---
  1 | 1
(1 row)
→ 正しくは id=3 の行も出力されないといけない

§ § § § §

プランナが"char"型の列の統計情報を参照する際に、予期せぬエラー「ERROR: cache lookup failed for collation 0」が発生する障害が修正されました。 (Feng Wu) (18)

"char"型は、一般的に使われるchar(n)型とは別の、主として内部的なシステムカタログで使用されるものです。

複数階層のパーティションが存在する場合でも、ALTER TABLEのALTER COLUMN ... DROP EXPRESSIONが正常に動作するよう修正されました。 (Alberto Piai) (18)(17)(16)(15)(14)

§ § § § § §

排他制約であるインデックスのパーティションをアタッチする処理の不具合が修正されました。 (Japin Li) (18)(17)

この誤りにより、排他制約を持つパーティションテーブルのダンプ/リストアが正常に動作しなくなっていました。

リストア時に以下のようなエラーが発生します。

ERROR:  cannot attach index "..." as a partition of index "..."
DETAIL:  The index definitions do not match.

§ § §

ALTER CONSTRAINTを使用して、パーティションテーブルのNOT NULL制約にNO INHERITを設定することができないように修正されました。 (Andreas Karlsson) (18)

ルールの名前を「_RETURN」に変更できないように修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

具体的には、ダンプ/リストアで「ERROR: non-view rule for "..." must not be named "_RETURN"」というエラーを起こすことが報告されました。

§ § § § § §

DROP OWNED BYにおいて、ロールメンバーシップへのロックの解放漏れが修正されました。 (Jeff Davis) (18)(17)(16)

§ § § §

EXPLAINがSQL/JSONの集約関数をデパースするときに予期せぬエラーを出すことがあり、修正されました。 (Richard Guo) (18)(17)(16)

実行プランの構造によっては、「ERROR: invalid JsonConstructorExpr underlying node type」というエラーが発生していました。

§ § § §

遅延一意性制約のインデックスに対してREINDEX CONCURRENTLYを使用した場合の不具合が修正されました。 (Nitin Motiani) (18)(17)(16)(15)(14)

§ § § § § §

非決定論的照合順序でバックスラッシュ（\）を使用したLIKE句のマッチングの不具合が修正されました。 (Nitin Motiani, Tom Lane) (18)

§ § § §

LIKE句や正規表現の完全一致パターンのインデックススキャン最適化の不具合が修正されました。 (Jelte Fennema-Nio) (18)

§ §

to_date() におけるローカライズされた月名、曜日名のマッチング処理が修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

§ § § § § § §

ギリシャ文字の語末形のシグマに対する大文字小文字の変換のルールが修正されました。 (Jeff Davis) (18)

文字列の直前が大文字小文字を区別しない文字だけで構成されている場合、そのシグマを語末形のシグマとはみなさないようにしました。

§ §

ハングルU+11A7（TBASE）のNFC再合成における誤りが修正されました。 (Diego Frias, Michael Paquier) (18)(17)(16)(15)(14)

この文字は有効なT音節として扱われていましたが、実際にはT音節ではないため、正規化処理中にこの文字が消えてしまっていました。

§ § § § §

大文字小文字を区別しない類義語の辞書において、出力する語彙素が切り捨てられる不具合が修正されました。 (Jeff Davis) (18)(17)(16)(15)(14)

小文字への変換によって語彙素のバイト長が増加した場合、出力時に元のバイト長に誤って切り捨てられていました。

§ § § § §

大文字小文字変換処理において、途中で途切れたUTF-8文字への対処が修正されました。 (Jeff Davis) (18)(17)

§ § §

hash_record_extended()のバグが修正されました。 (Man Zeng) (18)(17)(16)(15)(14)

§ § § § §

公開可能なテーブルが並行して削除された場合に、pg_get_publication_tables()が失敗する不具合が修正されました。 (Bharath Rupireddy) (18)(17)(16)

§ § § §

VARIADIC NULL を指定した場合に、satisfies_hash_partition() がクラッシュする不具合が修正されました。 (Robert Haas) (18)(17)(16)(15)(14)

§ § § § § §

tsvector_filter() および関連する関数で、不正な重みに関するエラーを、より明確かつ一貫した形で報告するよう修正されました。 (Ewan Young) (18)(17)(16)(15)(14)

§ § § § §

uundv7()関数で範囲外のタイムスタンプとなるシフト値を拒絶するようになりました。 (Baji Shaik) (18)

§ §

xpath()関数でnamestapeノードの処理が修正されました。 (Michael Paquier) (18)(17)(16)(15)(14)

予期せぬ「ERROR: could not copy node」エラーが出ていたものが修正されました。

§ § § § § § § § § §

jsonpathの「.decimal」メソッドが、精度やスケールの指定が正しくない場合でもERRORを出さないように、修正されました。 (Ewan Young) (18)(17)

サイレントモード（json_path_*関数のsilent引数がtrue）では、エラーを抑止すべきですが、そのようになっていませんでした。

§ § § § §

「IS JSON」や「JSON()」等の構文が、text型へのキャストを持たない文字列型の引数を与えられたときの、NULLポインタによるクラッシュが修正されました。 (Ayush Tiwari) (18)(17)(16)

PostgreSQL本体コードには該当するデータ型はありませんが、一部の拡張のデータ型で問題を引き起こす可能性がありました。

§ § §

「SQL/JSON」の「ON EMPTY / ON ERROR DEFAULT」の値に正しい型修飾が確実に適用されるようになりました。 (Ewan Young) (18)(17)

例えば、対象numeric型列の宣言された精度とスケールがデフォルト値に適用されませんでした。

（誤動作例）
db1=# SELECT JSON_VALUE(jsonb '{"b":"1234.5"}', '$.a' 
        RETURNING numeric(4,1) DEFAULT 99999.9 ON EMPTY);
 json_value
------------
    99999.9
(1 row)

（以下エラーが出るのが正しい動作）
ERROR:  numeric field overflow

§ § §

money型の最小値（64bit整数最小値）を-1で割ったときの、マシン依存の振る舞いが回避されました。 (Andrey Rachitskiy) (18)(17)(16)(15)(14)

§ § § § § §

全文検索の辞書に対するキャッシュエントリの作成途中でメモリ不足が生じた後にクラッシュする障害が修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

§ § § § § §

誤ったispell/hunspell辞書ファイルに対する処理でメモリ安全性に問題があり、修正されました。 (Andrey Rachitskiy) (18)(17)(16)(15)(14)

§ § § § § §

他セッションの一時テーブルへのアクセスが防止されました。 (Jim Jones, Daniil Davydov, Alexander Korotkov) (18)(17)(16)

§ § § § § §

一時テーブルにアクセスするときの「ERROR: no empty local buffer available」エラーが防止されました。 (Melanie Plageman) (18)

autovacuumがデータベースを処理する順番が修正されました。 (Rustam Khamidullin) (18)(17)

最高スコアから最低スコアに向かう順で処理されるべきところで、意図せず逆順になっていました。

§ § §

VACUUMのXID周回フェールセーフモードで、共有バッファプールを全使用するように動作が復旧されました。 (Melanie Plageman) (18)

§ § § §

パラレルVACUUMワーカーの処理でのメモリリークが修正されました。 (Baji Shaik) (18)(17)

パラレルワーカーからの報告過程で報告ごとに1kB程度のリークがあり、これはワーカープロセスが生きている間は蓄積されていきました。

§ §

問合せのキャンセルとVACUUM遅延が、GINインデックスのポスティングツリーのクリーンアップ中であっても、すぐに行なわれるようになりました。 (Paul Kim, Alexander Korotkov) (18)(17)(16)(15)(14)

よくある値に対するポスティングツリーは大きくなることがあり、ここに割り込みの検査が欠けていたため、処理が長く継続してしまいました。

§ § § § § §

GiSTおよびSP-GiSTのインデックスに対するIndex Only Scanで、インデックスタプルのデコーディングを誤る可能性があり、修正されました。 (Peter Geoghegan) (18)(17)(16)(15)(14)

（誤動作例）
db1=# CREATE TABLE t75 (a inet, r numrange);
db1=# INSERT INTO t75 VALUES 
      ('::1', numrange(repeat('1', 100)::numeric, repeat('2', 200)::numeric)));
db1=# CREATE INDEX ON t75 USING gist (a inet_ops, r range_ops);
db1=# VACUUM ANALYZE t75;
db1=# SET enable_seqscan TO off;
db1=# SELECT lower(r) = repeat('1', 100)::numeric,
             upper(r) = repeat('2', 200)::numeric FROM t75;
ERROR:  type with OID 860 does not exist

§ § § § § §

バルク拡張されたテーブルの新たな最終ブロックがフリースペースマップに即座に追加されるようになりました。 (Jingtang Zhang) (18)(17)(16)

§ § § §

トランザクションのアボート時のリソース解放処理で、メモリの二重解放（クラッシュをひきおこします）、または、エラーの再帰的な無限ループが起きる可能性があり、修正されました。 (Tom Lane) (18)(17)

巨大な入力値を伴うSQLがエラーになって、トランザクションアボートが行なわれたケースで問題が報告されました。

§ §

PostgreSQLの処理内でディレクトリを作成するとき、同じディレクトリの同時作成を許容するようになりました。 (Andrew Dunstan, Tom Lane) (18)(17)(16)(15)(14)

§ § § § §

JITコンパイルされたタプルデフォームを行うコードが、仮想生成列を正しく考慮するように修正されました。 (David Rowley) (18)

NOT NULL制約のある仮想生成列を含むテーブルへの問合せで、誤った問い合わせ結果が生じる例が報告されました。

依存されている全てのオブジェクトに共有ロックを取得することにより、宙に浮いたオブジェクト依存関係の生成が防止されました。 (Bertrand Drouvot) (18)(17)(16)(15)(14)

共有ロックは依存されているオブジェクトの削除と衝突しますので、これまであった競合状態を排除することができます。

§ § § § § § § § § §

SERIALIZABLE分離モードに対する衝突の検出での競合状態が修正されました。 (Peter Geoghegan) (18)(17)(16)(15)(14)

§ § § § § §

バリアイベントの処理で競合状態が修正されました。 (Masahiko Sawada) (18)(17)(16)(15)

LOG:  still waiting for backend with PID %d to accept ProcSignalBarrier

近年追加されたオンラインWALレベル変更などの機能によって、この問題がより目立つようになっています。

§ § § §

同じロックグループに属するプロセス集合が同時に終了したときの競合状態が修正されました。 (Vlad Lesin) (18)(17)(16)(15)(14)

§ § § § § § § § § §

テーブルのビジビリティマップ(VM)でビットをクリアする操作のWAL出力が修正されました。 (Melanie Plageman, Andres Freund) (18)(17)

既存のバックアップやアーカイブWALに潜在的にデータ破損が含まれていることに留意してください。

§ § § § § § § § §

WALサマライズ処理でのタイムライン変更時のハングアップが防止されました。 (Robert Haas) (18)(17)

スタンバイサーバで、以下のログメッセージがwalsummarizerプロセスから継続的に出力される動作が報告されました。

ERROR:  could not read WAL from timeline .. at ...: invalid record length ...

§ § § § § §

スタンバイ昇格のときのロジカルデコーディングのタイムライン選択で、競合状態が修正されました。 (Bertrand Drouvot) (18)(17)(16)

§ § § § § § §

タイムラインを切替するときのwalreceiverの接続文字列の露出が回避されました。 (Chao Li) (18)(17)(16)(15)(14)

§ § § § §

ロジカルレプリケーションで受け取ったタプルの列数が正しいかの検証を、アサートではなく実行時チェックで行うようになりました。 (Varik Matevosyan) (18)(17)(16)(15)(14)

§ § § § §

レプリケーションコマンド内の文字列パラメータへのクォート付加について、実装がクリーンアップされました。 (Tom Lane) (18)(17)(16)(15)(14)

§ § § § §

空のプリペアドトランザクションのロジカルデコーディングについて修正されました。 (Masahiko Sawada) (18)(17)(16)(15)(14)

§ § § § § §

スタンバイ昇格後のUNLOGGEDシーケンスのデータ破損が修正されました。 (Fujii Masao) (18)(17)(16)(15)

§ § § § §

カスケードスタンバイでのWALアーカイブによるリカバリからストリーミングに復帰するときの再接続失敗が、修正されました。 (Marco Nenciarini) (18)(17)(16)(15)(14)

このとき「ERROR: requested starting point ... is ahead of the WAL flush position」が発生する可能性がありました。

§ § § § § §

WALリプレイが一貫性のあるデータベース状態に達する前にホットスタンバイ接続を受け付ける動作が防止されました。 (Nikhil Sontakke) (18)

§ §

スタンバイサーバで、ローカルにpg_database.dathasloginevtのクリアを試みないようになりました。 (Ayush Tiwari) (18)(17)

§ §

使われなくなったレプリケーションスロットを削除するときの競合状態が回避されました。 (Xuneng Zhou) (18)(17)

§ §

一時的なレプリケーションスロット（初期化途中の論理レプリケーションスロット）を削除するときの競合状態が回避されました。 (Zhijie Hou) (18)(17)(16)(15)(14)

§ § § § §

ロジカルレプリケーションのテーブル初期同期で、進捗報告が古い内容となっていた問題が修正されました。 (Shinya Kato) (18)(17)(16)(15)(14)

§ § § § §

バックアップに失敗したなら、ベースバックアップの進捗がクリアされるようになりました。 (Chao Li) (18)(17)(16)(15)

§ § § § § § § § §

設定track_functionsが有効であるとき、実行時統計情報(pgstats)のエントリの同時削除のためにPANICが生じる可能性があり、修正されました。 (Sami Imseih, Michael Paquier) (18)(17)(16)(15)

「PANIC: cannot abort transaction .., it was already committed」が出るケースが報告されました。

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

対応する共有ハッシュテーブルのエントリに対するメモリ領域取得に失敗した後、壊れた実行時統計情報(pgstats)のローカルエントリをクリーンアップするようになりました。 (Niall Newman) (18)(17)(16)(15)

これを行なっていなかったため、次にローカルエントリが使われたときに、NULLポインタ参照によるクラッシュが発生しました。

§ § § § §

読み込みや書き込みの失敗後に誤ったI/O操作統計が記録されないように、修正されました。 (Bertrand Drouvot) (18)

PL/Perlで、不正なPostgreSQL::InServer::ARRAYオブジェクトを扱うときのNULLポインタ参照によるクラッシュが回避されるようになりました。 (Xing Guo) (18)(17)(16)(15)(14)

（クラッシュ発生例）
=# CREATE FUNCTION f102() RETURNS integer[] AS $$
     return bless {}, "PostgreSQL::InServer::ARRAY"; $$ LANGUAGE plperl;
=# SELECT f102();
server closed the connection unexpectedly

§ § § § §

PL/Pythonで、Pythonのシーケンスオブジェクトとマッピングオブジェクトを扱うときにエラーを正しく検査するようになりました。 (Richard Guo) (18)(17)(16)(15)(14)

§ § § § § §

libpqで、pqReadData()の実行中にSSLまたはGSSの復号バッファに残っている未処理バイトを常にすべて取り出すようになりました。 (Jacob Champion) (18)(17)(16)(15)(14)

pqReadData()はサーバ側からデータを読むlibpqの内部実装関数です。

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

libpqのメモリ不足状態の処理が改善されました。 (Anthonin Bonnefoy) (18)

§ §

libpqのトレース機能が、新しい形式のBackendKeyDataメッセージとCancelRequestメッセージを正しく出力するようになりました。 (Anthonin Bonnefoy) (18)

§ §

libpqが30000バイトを超えるParameterDescriptionメッセージを受け付けられるようになりました。 (Ning Sun) (18)(17)(16)(15)(14)

§ § § § §

ecpgコンパイラのNULLポインタ参照によるクラッシュが修正されました。 (Jehan-Guillaume de Rorthais) (18)

構造体の内側に入れ子になった共用体を含むDECLAREセクションをもつ.pgcコードを変換しようとすると、ecpgコマンド実行がクラッシュしました。

（ecpgコマンドがクラッシュするコード例）
EXEC SQL BEGIN DECLARE SECTION;
    struct s1
    {
        char STR1[10];
        union u1
        {
             int NUM1;
             int NUM2;
        } U1;
    } S1;
EXEC SQL END DECLARE SECTION;

ecpgのGET DESCRIPTOR文とSET DESCRIPTOR文で、記述子ヘッダ項目を複数指定する構文が拒否されるようになりました。 (Masashi Kamura) (18)(17)(16)(15)(14)

本修正で構文解析処理でもドキュメント上でもヘッダ項目は1つだけに変更されました。これは非互換性を含む変更です。

§ § § § §

psqlのパイプラインモードにおける遅延エラーの問題が修正されました。 (Michael Paquier) (18)

psqlの拡張表示（expanded）の整形出力で、行の幅が揃うようになりました。 (Pavel Stehule) (18)(17)(16)(15)(14)

（ずれた出力の例）

+-[ RECORD 1 ]-+
| a | 10 |
| b | 20 |
+---+----+

（修正後の出力例）

+-[ RECORD 1 ]-+
| a | 10       |
| b | 20       |
+---+----------+

§ § § § §

psqlの特別変数WATCH_INTERVALについて、既定の上限が強制されるようになりました。 (Sven Klemm, Daniel Gustafsson) (18)

psqlの「\l+」でデータベースサイズを表示する権限検査が修正されました。 (Christoph Berg) (18)(17)(16)(15)(14)

修正後は、「\l+」の権限検査にpg_read_all_statsロールの権限（USAGE）の確認が加わり、pg_database_size()の権限規則と一致するようになりました。

§ § § § § §

psqlの「\df」のタブ補完で、プロシージャも候補に含めるようになりました。 (Erik Wienhold) (18)(17)(16)(15)(14)

「\df」コマンド自体はプロシージャも表示対象に含めるよう拡張されていましたが、タブ補完の候補は関数だけを表示し続けていました。

§ § § § § §

pgbenchのスレッド安全性のバグが修正されました。 (Fujii Masao) (18)(17)(16)(15)

§ § § §

pg_combinebackupで、コピー元ファイルが想定より小さい場合に無限ループが発生することがあり、防止されました。 (Peter Eisentraut) (18)(17)

§ §

pg_createsubscriberで、エラー発生後にパブリッシャ側オブジェクトのクリーンアップが行なわれない場合があり、修正されました。 (Nisha Moond) (18)(17)

§ §

pg_recvlogicalの出力ファイルが、ソースクラスタのグループ読み取り権限に従って作成されるようになりました。 (Fujii Masao) (18)(17)(16)(15)(14)

§ § § § §

pg_restoreの「--statistics」および「--statistics-only」オプションの一貫しない挙動が修正されました。 (Chao Li, Michael Paquier) (18)

（誤動作例）
$ psql -d db1 <
 § §
vacuumdbの「--missing-stats-only」が、パーティションテーブルに対する式インデックスを処理対象から除外するようになりました。  (Baji Shaik) (18)

これまで、本オプションのvacuumdb実行では、パーティションテーブルに式インデックスがあると、常にそのパーティションテーブルにANALYZEを実行しようとしていました。しかし、統計情報は子パーティションのインデックスに作成されても、パーティションテーブルのインデックスには作成されないため、意味がありませんでした。

 §
contrib/amcheckで、btreeインデックスのメタページの「allequalimage」フラグの破損が報告されない問題が修正されました。  (Chao Li) (18)

btreeインデックスを検査する関数は、これまでインデックスキー列のいずれかにinterval_ops演算子クラスを含む場合のみ正しく動作していて、そうでないインデックスでこの破損が見逃される可能性がありました。

 §
contrib/amcheckの GINインデックス検証関数でメモリリークが修正されました。問い合わせが終わるまで未開放メモリが蓄積します。  (Kirill Reshke) (18)

大きなGINインデックスの検証でメモリ使用量が増大するおそれがありました。

 § §
contrib/amcheckで、ショートヘッダのvarlenaデータムが正しく扱われるように修正されました。  (Andrey Borodin) (18)(17)(16)(15)(14)

この誤りで、btreeインデックス検証で無駄な処理が生じる可能性がありますが、それ以上の悪影響は無いと考えられます。


varlenaデータムとはPostgreSQL実装内で使われる長さとデータ本体からなるデータ構造です。ショートヘッダは長さをあらわすのに1バイトだけ使う形式です。

 § § § § §
contrib/btree_gistで、float4とfloat8の演算子クラスにおける「NaN」の扱いが修正されました。  (Bill Kim, Tom Lane) (18)(17)(16)(15)(14)

各種の比較関数と、GiSTのpenalty関数、distance関数が「NaN」を考慮しておらず、「NaN」を渡されたときに誤った結果を返していました。


本修正の適用後、float列のbtree_gistインデックスに「NaN」のエントリが含まれる可能性がある場合は、それらのインデックスの再構築を推奨します。

 § § § § § §
contrib/btree_gistで、GiSTインデックス構築時のbit型とvarbit型の値のソートが修正されました。  (Tom Lane) (18)

これまでbit型の値がbytea型であるかのようにソートされていました。これは明白な誤動作を引き起こすことはありませんでしたが、型本来のソート順に一致しない並びで構築されるため、非効率なインデックスになりました。


本修正の適用後、bit列上のbtree_gistインデックスの再構築を推奨します。

 § §
contrib/btree_gistで、非等価（<>）演算子を使った検索が修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

可変長データ型の場合、非リーフインデックスページを走査するコードが誤った比較関数を適用していました。これは誤った問い合わせ結果、および場合によってはクラッシュにつながる可能性がありました。

 § § § § § §
contrib/dblinkとcontrib/postgres_fdwで、use_scram_passthroughオプションについて、ユーザマッピングの設定が外部サーバの設定より優先されるよう修正されました。  (Matheus Alcantara) (18)

これまでは外部サーバ側の設定が優先されていましたが、これは他の外部テーブルオプションの挙動と一貫していませんでした。他の接続オプション（sslcertやsslkeyなど）と同様に、外部サーバのオプションは共通のデフォルト値を提供し、ユーザマッピングのオプションがそれを上書きする扱いに統一されました。


これは非互換性を含む変更と言えます。

 § §
contrib/dblinkの外部データラッパのuse_scram_passthroughオプションが拒否されるようになりました。  (Matheus Alcantara) (18)

このオプションは外部サーバとユーザマッピングに対してのみ意味を持ちますが、dblinkは外部データラッパ（dblink_fdw）レベルでもこのオプションを受け付けていました（そして受け付けた設定を無視していました）。

 §
contrib/hstore_plperl、contrib/jsonb_plperl、contrib/jsonb_plpythonで保護されていない再帰とループがあり、修正されました。  (Aleksander Alekseev) (18)(17)(16)(15)(14)

深くネストしたjsonb値を扱うときのスタックオーバーフロー（によるクラッシュ）が防止されました。また、Perlのオブジェクト参照の循環チェーンをたどるときに生じる無限ループが割り込み可能になりました。

 § § § § § § § § § §
contrib/intarrayでプランナ統計情報のカタログキャッシュエントリの解放漏れが修正されました。  (Man Zeng) (18)(17)(16)(15)(14)

この解放漏れにより、「WARNING:  resource was not closed: cache pg_statistic ..」のような警告が発生していました。

 § § § § §
contrib/ltreeで比較関数における整数オーバーフローが修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

約14,653個を超えるラベルを含むltree値は、オーバーフローによって誤った比較結果を返していました。btreeインデックスにそのような値が含まれている場合、破損している可能性があるため、本修正の適用後に再構築することを推奨します。

 § § § § §
contrib/pgcryptoで、OSSLCipherオブジェクトの使用中にエラーが発生した後の二重解放によるクラッシュが回避されました。  (Yuelin Wang) (18)(17)
 § §
contrib/pg_prewarmのautoprewarmワーカの範囲外アクセスが修正されました。  (Matheus Alcantara) (18)

このコードは、配列の末尾の1つ先から値を取り出そうとしており、セグメンテーション違反によるクラッシュを引き起こす可能性がありました。

 §
contrib/pg_surgeryのheap_force_kill関数とheap_force_freeze関数で、配列の範囲外書き込みが修正されました。  (Michael Paquier) (18)(17)(16)(15)(14)

オフセット番号がMaxHeapTuplesPerPage（ページあたりの最大タプル数、291など）に等しいTIDを変更しようとすると、確保された配列の末尾の1バイト先に書き込み、サーバをクラッシュさせる可能性がありました。

 § § § § §
contrib/pg_surgeryで、64K要素を超えるTID配列による無限ループが回避されるようになりました。  (Andrey Rachitskiy) (18)(17)(16)(15)(14)
 § § § § § §
contrib/spiのrefint拡張で、check_foreign_key()関数のNULLポインタ参照が回避されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

ON UPDATE CASCADEの場合、参照列の新しいキー値がNULLであると、クラッシュが発生していました。これはCVE-2026-6637の修正の見落しですが、その前からあったコードも正しいものではありませんでした。

 § § § § §
contrib/segで、確実性指示子「~」を持つセグメントの値が正しく出力されるように修正されました。  (Ewan Young) (18)(17)(16)(15)(14)

seg型の出力関数seg_out()はセグメントの上限に付いた「~」を出力していませんでした。さらに悪いことに、下限に「~」があり上限に指示子がない場合、上限がまったく出力されませんでした。なお、文字列としての出力が不正であるだけで、演算結果に影響はありません。

（誤動作例：2番目と3番目が誤動作）
db1=# SELECT '~1 .. ~5'::seg, '1 .. ~5'::seg, '~1 .. 5'::seg;
   seg    |  seg   |  seg
----------+--------+--------
 ~1 .. ~5 | 1 .. 5 | ~1 ..
(1 row)

 § § § § §
contrib/xml2のxpath_nodeset()関数で名前空間ノードを問合せたときのクラッシュが修正されました。  (Andrey Chernyy, Michael Paquier) (18)(17)(16)(15)(14)

以下のように、query引数に「//namespace::」を指定した場合にクラッシュするケースが報告されました。

db1=# SELECT xpath_nodeset(
        '',
        '//namespace::*');

 § § § § §
OpenSSL 4を使ったPostgreSQLのビルドに対応しました。  (Daniel Gustafsson) (18)(17)(16)(15)(14)
 § § § § §
タイムゾーンデータファイルをtzdataリリース2026cに更新しました。  (Tom Lane) (18)(17)(16)(15)(14)

アルバータ州（America/Edmonton）は、2026年11月から年間を通したUTC-06（実質的に、恒久的なサマータイム）になります。このリリースでは、それ以降のタイムゾーン省略形は「CST」と仮定しています。この仮定は将来変更される可能性が高いのですが、新しい省略形に何が使われるかは明らかになっていません。


モロッコ（Africa/Casablanca）は、2026-09-20に、サマータイムの切り替えなしの恒久的なUTC+00に移行します。

 § § § § § §
古いマイナーバージョンが生成したWALのリプレイ時の自己デッドロックが修正されました。  (Andrey Borodin) (16)(15)(14)

この不具合は前回のマイナーリリース(16.14、15.18、14.23)で導入されました。より古いマイナーバージョンのプライマリに追従するスタンバイサーバで、startupプロセスがハングアップしてレプリケーションが先に進まなくなりました。


共有行ロックで使われるマルチトランザクションに関するWALレコードのリプレイで問題が発生しました。

 § § §
変数が1つも渡されていない場合でも、未定義のjsonpath変数をエラーとして扱うようになりました。  (Andrey Rachitskiy) (16)(15)(14)

jsonbの「@?」演算子と「@@」演算子がjsonpath式の中で使う変数を渡せない、という場合のコードパスでは、未知のjsonpath変数が、本来の期待であるエラーの発生ではなく、JSONのnullとして誤って扱われていました。期待される動作でないことに加えて、この誤りは無制限のメモリ消費を引き起こす可能性がありました。

（誤動作例）
db1=# select '{"A":1}'::jsonb @@ '$"no_such_var" == 1';
 ?column?
----------
 f
(1 row)

db1=# SELECT '{"A":1}'::jsonb @? '$"no_such_var"';
 ?column?
----------
 t
(1 row)

（修正後は以下のエラーが出る）
ERROR:  could not find jsonpath variable "no_such_var"

 § § §
Visual Studio 2026を使ったPostgreSQLのビルドに対応しました。  (Andrew Dunstan) (16)(15)(14)
 § § §

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

PostgreSQL 15.19 に関する技術情報

データベース技術グループ — Tue, 01 Sep 2026 04:31:54 +0000

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

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

PostgreSQL 15.18 から 15.19 への変更点

ロジカルデコーディングの出力プラグインが厳格化されました。新たな設定パラメータoutput_plugin_librariesでの指定が必要となりました。(CVE-2026-6471) (Jacob Champion) (18)(17)(16)(15)(14)

§ § § § § § § § §

contrib/pgcryptoのPGP暗号化がサポートされない暗号化方式を検出するように、修正されました。(CVE-2026-14663) (Daniel Gustafsson) (18)(17)(16)(15)(14)

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

psqlがスクリプト化された「COPY ... FROM STDIN」コマンドに続くインラインデータを、COPY開始時のエラーであっても、読み飛ばすように修正されました。(CVE-2026-6464) (Tom Lane) (18)(17)(16)(15)(14)

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

EXECUTEやFETCHを実行するポータルの出力行型についてクロスチェックを行うようになりました。(CVE-2026-16239) (Robert Haas) (18)(17)(16)(15)(14)

§ § § § § §

to_char()で、長いタイムゾーン省略形によるバッファオーバーランが修正されました。(CVE-2026-14669) (Tom Lane) (18)(17)(16)(15)(14)

これは容易にバックエンドプロセスのクラッシュができて、任意コード実行をもたらす攻撃も報告されました。

§ § § § § §

正規表現によるマッチ、分割の関数で、バッファオーバーランが修正されました。(CVE-2026-14664) (Masahiko Sawada) (18)(17)(16)(15)(14)

§ § § § § §

ascii()関数が不正な入力に対して頑健になりました。(CVE-2026-18024) (Michael Paquier) (18)(17)(16)(15)(14)

§ § § § § §

pg_restore_attribute_stats()関数でのマルチ範囲型の処理が修正されました。(CVE-2026-16238) (OpenAI Security Research Team) (18)(17)(16)(15)(14)

pg_restore_attribute_stats()はプランナ統計情報のダンプ、リストアで使われる関数です。

誤った統計情報のリストアにより、不適切なプラン選択による問合せ実行の遅延や潜在的なプランナ誤動作の可能性が考えられます。

§ § §

scalarineqsel()が、tid型と想定される定数を実際にそうであるか検査するようになりました。(CVE-2026-14668) (Tom Lane) (18)(17)(16)(15)(14)

この想定は組み込みの演算子については成り立ちますが、悪意で作られた演算子には通用せず、クラッシュやサーバメモリ暴露を引き起こします。

scalarineqsel()は選択率の見積を返すプランナの内部実装関数の1つです。

§ § § § § §

tsvector型とtsquery型の実装コードが（個々の要素、全体の長さの両面で）きわめて長い値に対して頑健になりました。(CVE-2026-14662) (Tom Lane) (18)(17)(16)(15)(14)

ドキュメントに記載されていた上限が、全てのコードパスで必ずしも強制されていませんでした。

ERROR:  lexeme is too long for tsvector ...
ERROR:  string is too long for tsvector ...
ERROR:  word is too long to be indexed ...
ERROR:  tsquery is too large

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

「FUNC_MAX_ARGS」を超える関数引数を処理する必要がない、と誤って想定していた様々な箇所が修正されました。(CVE-2026-14679) (Tom Lane) (18)(17)(16)(15)(14)

「FUNC_MAX_ARGS」はビルド時指定の定数でデフォルト100です。

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

internal型を引数や戻り値とする関数のSQLからの呼び出しを拒否するようになりました。(CVE-2026-14680) (Tom Lane) (18)(17)(16)(15)(14)

拒否するための既存の仕組みはありましたが、不十分であったため、明示的な検査が追加されました。

また、いくつかの集約関数のcombine処理で入力がNULLである場合に正しくSQLとしてのNULLを返すように修正されました。

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

ALTER TABLEコマンドで再構築されたとき、拡張統計オブジェクトの所有者が保たれるようになりました。(CVE-2026-6469) (Masahiko Sawada) (18)(17)(16)(15)(14)

§ § § § § §

EXTRACT()関数呼び出しを逆パースするときに、必要であればフィールド名をクォートするようになりました。(CVE-2026-15741) (Nathan Bossart) (18)(17)(16)(15)(14)

逆パースはダンプ出力やpsqlでの定義表示で行なわれる処理です。

§ § § § § §

これまで検査ができていなかった個所について、データ型に対する「USAGE」権限を検査するようになりました。(CVE-2026-6470) (Nathan Bossart) (18)(17)(16)(15)(14)

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

行単位セキュリティ(RLS)に対して、ロールに依存したキャッシュされたプランを、ロール変更後に無効化するようになりました。(CVE-2026-14666) (Ilya Staroverov, Shinya Kato, Nathan Bossart) (18)(17)(16)(15)(14)

§ § § § § §

直接のSSL接続の後のGSSEncRequestメッセージを拒否するようになりました。(CVE-2026-14681) (Michael Paquier) (18)(17)(16)(15)(14)

§ § §

モックのSCRAM認証シークレットがより本物らしくなりました。(CVE-2026-14672) (Nathan Bossart) (18)(17)(16)(15)(14)

本修正で、モックにもscram_iterations設定パラメータの値を使って、より実際に使われているシークレットに似せるようになりました。

§ § § §

ecpgアプリケーションでの範囲外書き込みが修正されました。サーバから不正なbytea型データを受け取ることで引き起こされます。(CVE-2026-16241) (Michael Paquier) (18)(17)(16)(15)(14)

§ § § § § §

psqlの「\unrestrict」コマンドの引数でバッククォート展開をしないようになりました。(CVE-2026-18408) (Nathan Bossart) (18)(17)(16)(15)(14)

§ § § § § §

pg_dumpにおいてpg_proc.protrftypesのエントリ数がFUNC_MAX_ARGSを超えないという前提が取り除かれました。(CVE-2026-19385) (Tom Lane) (18)(17)(16)(15)(14)

§ § § § § §

tieされたPerlの配列やハッシュに対して、PL/Perlが堅牢化されました。(CVE-2026-14670) (Tom Lane) (18)(17)(16)(15)(14)

tieは、配列やハッシュなどの変数に対して操作用のメソッド群を実装したオブジェクトに結びつける Perl の機能です。

§ § § § § §

PL/PerlおよびPL/Tclにおけるメモリ割り当て計算時の整数オーバーフローが修正されました。(CVE-2026-14677) (Heikki Linnakangas) (18)(17)(16)(15)(14)

これはコードの異なる個所で発生していたCVE-2026-6473と同様の問題で、同じ方法で修正されました。

§ § § § § §

contrib/amcheckの関数がインデックス式を実行する前にsearch_pathを制限するようになりました。(CVE-2026-14673) (Noah Misch) (18)(17)(16)(15)(14)

§ § § § § §

contrib/fuzzystrmatchのlevenshtein()およびlevenshtein_less_equal()関数における整数オーバーフローが修正されました。(CVE-2026-15742) (Nathan Bossart) (18)(17)(16)(15)(14)

§ § § § § §

contrib/pg_stat_statementsにおけるバッファオーバーランが修正されました。(CVE-2026-14676) (Alvaro Herrera) (18)(17)(16)(15)(14)

クエリの正規化処理において、正規化後の文字列が必要とするサイズが正確に考慮されていませんでした。

§ §

contrib/pg_trgmのGiST picksplit関数におけるデータ型エラーが修正されました。(CVE-2026-14678) (Heikki Linnakangas) (18)(17)(16)(15)(14)

§ § § § § §

contrib/refintのプランキャッシュが削除されるようになりました。(CVE-2026-14671) (Ayush Tiwari) (18)(17)(16)(15)(14)

§ § § § §

並列GINインデックスの構築時に、テーブルのpg_class.reltuples値が正しく更新されるようになりました。 (Jan Nidzwetzki, Tomas Vondra) (18)

SELECT DISTINCT t.oid::regclass, t.reltuples
FROM pg_class t
  JOIN pg_index i ON t.oid = i.indrelid
  JOIN pg_class ic ON i.indexrelid = ic.oid
WHERE t.relhasindex AND ic.relam = 2742;

§ §

非同期のAppendプランノードを再スキャンする際の、非同期読み取りの不適切な処理が修正されました。 (Alexander Korotkov, Gleb Kashkin, Etsuro Fujita) (18)(17)(16)(15)(14)

§ § § § § §

RANGEパーティションテーブルにおけるパーティションプルーニングの不具合が修正されました。 (David Rowley) (18)(17)(16)(15)(14)

§ § § § § §

結果リレーションのプルーニング後に、ModifyTableプランノード内の外部データラッパーの状態を正しく更新するようになりました。 (Ayush Tiwari, Rafia Sabih) (18)

§ §

「BEFORE UPDATE」トリガーを持つテーブルに対して、「RETURNING OLD」を指定したUPDATE文で発生していた並行更新の処理漏れが修正されました。 (Dean Rasheed) (18)

§ §

複数の結合キーと多数のNULL値が存在する場合のハッシュ結合の性能問題が修正されました。 (David Rowley) (18)

§ §

RETURNING句の式における括弧で囲まれた「OLD」や「NEW」の解析処理が修正されました。 (Marko Grujic) (18)

value IN (array)式に対するプランナのNULL許容性および厳密性チェックが修正されました。 (Ayush Tiwari) (18)(17)(16)(15)(14)

§ § § § § §

不適切な結合削除のロジックが修正されました。 (Matheus Alcantara, Richard Guo) (18)(17)(16)

§ § § § § § § §

結合の削除処理において、PlaceHolderVarsのクリーンアップがより徹底されるようになりました。 (Richard Guo, Arne Roland) (18)

§ § §

コンテナデータ型（配列、複合型、範囲型）の等価比較におけるハッシュ可能性に関する漏れていたチェックが追加されました。 (Andrei Lepikhov, Tom Lane) (18)(17)(16)(15)(14)

§ § § § §

プランナが、異なる等価性ルールを持つグループ化ステップより下位へ、WHERE句をプッシュダウンすることを避けるようになりました。 (Richard Guo) (18)

§ §

「EXCLUDE」句を指定している、または「ORDER BY」を指定していない、COUNTウィンドウ関数の誤った最適化が修正されました。 (Chengpeng Yan, David Rowley) (18)(17)(16)(15)

（報告された誤動作例）
db1=# CREATE TABLE t41 (id int PRIMARY KEY, k int NOT NULL, v int);
db1=# INSERT INTO t41(id, k, v) VALUES
        (1, 1, 1), (2, 1, NULL), (3, 1, 1), (4, 2, 1);

db1=# SELECT id, count(v) OVER (
        ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        EXCLUDE CURRENT ROW) AS c FROM t41;
 id | c
----+---
  1 | 1
  2 | 2
  3 | 1
  4 | 2
(4 rows)

db1=# SELECT * FROM (
        SELECT id, count(v) OVER (
          ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
          EXCLUDE CURRENT ROW) AS c FROM t41) s WHERE c < 2;
 id | c
----+---
  1 | 1
(1 row)
→ 正しくは id=3 の行も出力されないといけない

§ § § § §

プランナが"char"型の列の統計情報を参照する際に、予期せぬエラー「ERROR: cache lookup failed for collation 0」が発生する障害が修正されました。 (Feng Wu) (18)

"char"型は、一般的に使われるchar(n)型とは別の、主として内部的なシステムカタログで使用されるものです。

複数階層のパーティションが存在する場合でも、ALTER TABLEのALTER COLUMN ... DROP EXPRESSIONが正常に動作するよう修正されました。 (Alberto Piai) (18)(17)(16)(15)(14)

§ § § § § §

排他制約であるインデックスのパーティションをアタッチする処理の不具合が修正されました。 (Japin Li) (18)(17)

この誤りにより、排他制約を持つパーティションテーブルのダンプ/リストアが正常に動作しなくなっていました。

リストア時に以下のようなエラーが発生します。

ERROR:  cannot attach index "..." as a partition of index "..."
DETAIL:  The index definitions do not match.

§ § §

ALTER CONSTRAINTを使用して、パーティションテーブルのNOT NULL制約にNO INHERITを設定することができないように修正されました。 (Andreas Karlsson) (18)

ルールの名前を「_RETURN」に変更できないように修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

具体的には、ダンプ/リストアで「ERROR: non-view rule for "..." must not be named "_RETURN"」というエラーを起こすことが報告されました。

§ § § § § §

DROP OWNED BYにおいて、ロールメンバーシップへのロックの解放漏れが修正されました。 (Jeff Davis) (18)(17)(16)

§ § § §

EXPLAINがSQL/JSONの集約関数をデパースするときに予期せぬエラーを出すことがあり、修正されました。 (Richard Guo) (18)(17)(16)

実行プランの構造によっては、「ERROR: invalid JsonConstructorExpr underlying node type」というエラーが発生していました。

§ § § §

遅延一意性制約のインデックスに対してREINDEX CONCURRENTLYを使用した場合の不具合が修正されました。 (Nitin Motiani) (18)(17)(16)(15)(14)

§ § § § § §

非決定論的照合順序でバックスラッシュ（\）を使用したLIKE句のマッチングの不具合が修正されました。 (Nitin Motiani, Tom Lane) (18)

§ § § §

LIKE句や正規表現の完全一致パターンのインデックススキャン最適化の不具合が修正されました。 (Jelte Fennema-Nio) (18)

§ §

to_date() におけるローカライズされた月名、曜日名のマッチング処理が修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

§ § § § § § §

ギリシャ文字の語末形のシグマに対する大文字小文字の変換のルールが修正されました。 (Jeff Davis) (18)

文字列の直前が大文字小文字を区別しない文字だけで構成されている場合、そのシグマを語末形のシグマとはみなさないようにしました。

§ §

ハングルU+11A7（TBASE）のNFC再合成における誤りが修正されました。 (Diego Frias, Michael Paquier) (18)(17)(16)(15)(14)

この文字は有効なT音節として扱われていましたが、実際にはT音節ではないため、正規化処理中にこの文字が消えてしまっていました。

§ § § § §

大文字小文字を区別しない類義語の辞書において、出力する語彙素が切り捨てられる不具合が修正されました。 (Jeff Davis) (18)(17)(16)(15)(14)

小文字への変換によって語彙素のバイト長が増加した場合、出力時に元のバイト長に誤って切り捨てられていました。

§ § § § §

大文字小文字変換処理において、途中で途切れたUTF-8文字への対処が修正されました。 (Jeff Davis) (18)(17)

§ § §

hash_record_extended()のバグが修正されました。 (Man Zeng) (18)(17)(16)(15)(14)

§ § § § §

公開可能なテーブルが並行して削除された場合に、pg_get_publication_tables()が失敗する不具合が修正されました。 (Bharath Rupireddy) (18)(17)(16)

§ § § §

VARIADIC NULL を指定した場合に、satisfies_hash_partition() がクラッシュする不具合が修正されました。 (Robert Haas) (18)(17)(16)(15)(14)

§ § § § § §

tsvector_filter() および関連する関数で、不正な重みに関するエラーを、より明確かつ一貫した形で報告するよう修正されました。 (Ewan Young) (18)(17)(16)(15)(14)

§ § § § §

uundv7()関数で範囲外のタイムスタンプとなるシフト値を拒絶するようになりました。 (Baji Shaik) (18)

§ §

xpath()関数でnamestapeノードの処理が修正されました。 (Michael Paquier) (18)(17)(16)(15)(14)

予期せぬ「ERROR: could not copy node」エラーが出ていたものが修正されました。

§ § § § § § § § § §

jsonpathの「.decimal」メソッドが、精度やスケールの指定が正しくない場合でもERRORを出さないように、修正されました。 (Ewan Young) (18)(17)

サイレントモード（json_path_*関数のsilent引数がtrue）では、エラーを抑止すべきですが、そのようになっていませんでした。

§ § § § §

「IS JSON」や「JSON()」等の構文が、text型へのキャストを持たない文字列型の引数を与えられたときの、NULLポインタによるクラッシュが修正されました。 (Ayush Tiwari) (18)(17)(16)

PostgreSQL本体コードには該当するデータ型はありませんが、一部の拡張のデータ型で問題を引き起こす可能性がありました。

§ § §

「SQL/JSON」の「ON EMPTY / ON ERROR DEFAULT」の値に正しい型修飾が確実に適用されるようになりました。 (Ewan Young) (18)(17)

例えば、対象numeric型列の宣言された精度とスケールがデフォルト値に適用されませんでした。

（誤動作例）
db1=# SELECT JSON_VALUE(jsonb '{"b":"1234.5"}', '$.a' 
        RETURNING numeric(4,1) DEFAULT 99999.9 ON EMPTY);
 json_value
------------
    99999.9
(1 row)

（以下エラーが出るのが正しい動作）
ERROR:  numeric field overflow

§ § §

money型の最小値（64bit整数最小値）を-1で割ったときの、マシン依存の振る舞いが回避されました。 (Andrey Rachitskiy) (18)(17)(16)(15)(14)

§ § § § § §

全文検索の辞書に対するキャッシュエントリの作成途中でメモリ不足が生じた後にクラッシュする障害が修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

§ § § § § §

誤ったispell/hunspell辞書ファイルに対する処理でメモリ安全性に問題があり、修正されました。 (Andrey Rachitskiy) (18)(17)(16)(15)(14)

§ § § § § §

他セッションの一時テーブルへのアクセスが防止されました。 (Jim Jones, Daniil Davydov, Alexander Korotkov) (18)(17)(16)

§ § § § § §

一時テーブルにアクセスするときの「ERROR: no empty local buffer available」エラーが防止されました。 (Melanie Plageman) (18)

autovacuumがデータベースを処理する順番が修正されました。 (Rustam Khamidullin) (18)(17)

最高スコアから最低スコアに向かう順で処理されるべきところで、意図せず逆順になっていました。

§ § §

VACUUMのXID周回フェールセーフモードで、共有バッファプールを全使用するように動作が復旧されました。 (Melanie Plageman) (18)

§ § § §

パラレルVACUUMワーカーの処理でのメモリリークが修正されました。 (Baji Shaik) (18)(17)

パラレルワーカーからの報告過程で報告ごとに1kB程度のリークがあり、これはワーカープロセスが生きている間は蓄積されていきました。

§ §

問合せのキャンセルとVACUUM遅延が、GINインデックスのポスティングツリーのクリーンアップ中であっても、すぐに行なわれるようになりました。 (Paul Kim, Alexander Korotkov) (18)(17)(16)(15)(14)

よくある値に対するポスティングツリーは大きくなることがあり、ここに割り込みの検査が欠けていたため、処理が長く継続してしまいました。

§ § § § § §

GiSTおよびSP-GiSTのインデックスに対するIndex Only Scanで、インデックスタプルのデコーディングを誤る可能性があり、修正されました。 (Peter Geoghegan) (18)(17)(16)(15)(14)

（誤動作例）
db1=# CREATE TABLE t75 (a inet, r numrange);
db1=# INSERT INTO t75 VALUES 
      ('::1', numrange(repeat('1', 100)::numeric, repeat('2', 200)::numeric)));
db1=# CREATE INDEX ON t75 USING gist (a inet_ops, r range_ops);
db1=# VACUUM ANALYZE t75;
db1=# SET enable_seqscan TO off;
db1=# SELECT lower(r) = repeat('1', 100)::numeric,
             upper(r) = repeat('2', 200)::numeric FROM t75;
ERROR:  type with OID 860 does not exist

§ § § § § §

バルク拡張されたテーブルの新たな最終ブロックがフリースペースマップに即座に追加されるようになりました。 (Jingtang Zhang) (18)(17)(16)

§ § § §

トランザクションのアボート時のリソース解放処理で、メモリの二重解放（クラッシュをひきおこします）、または、エラーの再帰的な無限ループが起きる可能性があり、修正されました。 (Tom Lane) (18)(17)

巨大な入力値を伴うSQLがエラーになって、トランザクションアボートが行なわれたケースで問題が報告されました。

§ §

PostgreSQLの処理内でディレクトリを作成するとき、同じディレクトリの同時作成を許容するようになりました。 (Andrew Dunstan, Tom Lane) (18)(17)(16)(15)(14)

§ § § § §

JITコンパイルされたタプルデフォームを行うコードが、仮想生成列を正しく考慮するように修正されました。 (David Rowley) (18)

NOT NULL制約のある仮想生成列を含むテーブルへの問合せで、誤った問い合わせ結果が生じる例が報告されました。

依存されている全てのオブジェクトに共有ロックを取得することにより、宙に浮いたオブジェクト依存関係の生成が防止されました。 (Bertrand Drouvot) (18)(17)(16)(15)(14)

共有ロックは依存されているオブジェクトの削除と衝突しますので、これまであった競合状態を排除することができます。

§ § § § § § § § § §

SERIALIZABLE分離モードに対する衝突の検出での競合状態が修正されました。 (Peter Geoghegan) (18)(17)(16)(15)(14)

§ § § § § §

バリアイベントの処理で競合状態が修正されました。 (Masahiko Sawada) (18)(17)(16)(15)

LOG:  still waiting for backend with PID %d to accept ProcSignalBarrier

近年追加されたオンラインWALレベル変更などの機能によって、この問題がより目立つようになっています。

§ § § §

同じロックグループに属するプロセス集合が同時に終了したときの競合状態が修正されました。 (Vlad Lesin) (18)(17)(16)(15)(14)

§ § § § § § § § § §

テーブルのビジビリティマップ(VM)でビットをクリアする操作のWAL出力が修正されました。 (Melanie Plageman, Andres Freund) (18)(17)

既存のバックアップやアーカイブWALに潜在的にデータ破損が含まれていることに留意してください。

§ § § § § § § § §

WALサマライズ処理でのタイムライン変更時のハングアップが防止されました。 (Robert Haas) (18)(17)

スタンバイサーバで、以下のログメッセージがwalsummarizerプロセスから継続的に出力される動作が報告されました。

ERROR:  could not read WAL from timeline .. at ...: invalid record length ...

§ § § § § §

スタンバイ昇格のときのロジカルデコーディングのタイムライン選択で、競合状態が修正されました。 (Bertrand Drouvot) (18)(17)(16)

§ § § § § § §

タイムラインを切替するときのwalreceiverの接続文字列の露出が回避されました。 (Chao Li) (18)(17)(16)(15)(14)

§ § § § §

ロジカルレプリケーションで受け取ったタプルの列数が正しいかの検証を、アサートではなく実行時チェックで行うようになりました。 (Varik Matevosyan) (18)(17)(16)(15)(14)

§ § § § §

レプリケーションコマンド内の文字列パラメータへのクォート付加について、実装がクリーンアップされました。 (Tom Lane) (18)(17)(16)(15)(14)

§ § § § §

空のプリペアドトランザクションのロジカルデコーディングについて修正されました。 (Masahiko Sawada) (18)(17)(16)(15)(14)

§ § § § § §

スタンバイ昇格後のUNLOGGEDシーケンスのデータ破損が修正されました。 (Fujii Masao) (18)(17)(16)(15)

§ § § § §

カスケードスタンバイでのWALアーカイブによるリカバリからストリーミングに復帰するときの再接続失敗が、修正されました。 (Marco Nenciarini) (18)(17)(16)(15)(14)

このとき「ERROR: requested starting point ... is ahead of the WAL flush position」が発生する可能性がありました。

§ § § § § §

WALリプレイが一貫性のあるデータベース状態に達する前にホットスタンバイ接続を受け付ける動作が防止されました。 (Nikhil Sontakke) (18)

§ §

スタンバイサーバで、ローカルにpg_database.dathasloginevtのクリアを試みないようになりました。 (Ayush Tiwari) (18)(17)

§ §

使われなくなったレプリケーションスロットを削除するときの競合状態が回避されました。 (Xuneng Zhou) (18)(17)

§ §

一時的なレプリケーションスロット（初期化途中の論理レプリケーションスロット）を削除するときの競合状態が回避されました。 (Zhijie Hou) (18)(17)(16)(15)(14)

§ § § § §

ロジカルレプリケーションのテーブル初期同期で、進捗報告が古い内容となっていた問題が修正されました。 (Shinya Kato) (18)(17)(16)(15)(14)

§ § § § §

バックアップに失敗したなら、ベースバックアップの進捗がクリアされるようになりました。 (Chao Li) (18)(17)(16)(15)

§ § § § § § § § §

設定track_functionsが有効であるとき、実行時統計情報(pgstats)のエントリの同時削除のためにPANICが生じる可能性があり、修正されました。 (Sami Imseih, Michael Paquier) (18)(17)(16)(15)

「PANIC: cannot abort transaction .., it was already committed」が出るケースが報告されました。

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

対応する共有ハッシュテーブルのエントリに対するメモリ領域取得に失敗した後、壊れた実行時統計情報(pgstats)のローカルエントリをクリーンアップするようになりました。 (Niall Newman) (18)(17)(16)(15)

これを行なっていなかったため、次にローカルエントリが使われたときに、NULLポインタ参照によるクラッシュが発生しました。

§ § § § §

読み込みや書き込みの失敗後に誤ったI/O操作統計が記録されないように、修正されました。 (Bertrand Drouvot) (18)

PL/Perlで、不正なPostgreSQL::InServer::ARRAYオブジェクトを扱うときのNULLポインタ参照によるクラッシュが回避されるようになりました。 (Xing Guo) (18)(17)(16)(15)(14)

（クラッシュ発生例）
=# CREATE FUNCTION f102() RETURNS integer[] AS $$
     return bless {}, "PostgreSQL::InServer::ARRAY"; $$ LANGUAGE plperl;
=# SELECT f102();
server closed the connection unexpectedly

§ § § § §

PL/Pythonで、Pythonのシーケンスオブジェクトとマッピングオブジェクトを扱うときにエラーを正しく検査するようになりました。 (Richard Guo) (18)(17)(16)(15)(14)

§ § § § § §

libpqで、pqReadData()の実行中にSSLまたはGSSの復号バッファに残っている未処理バイトを常にすべて取り出すようになりました。 (Jacob Champion) (18)(17)(16)(15)(14)

pqReadData()はサーバ側からデータを読むlibpqの内部実装関数です。

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

libpqのメモリ不足状態の処理が改善されました。 (Anthonin Bonnefoy) (18)

§ §

libpqのトレース機能が、新しい形式のBackendKeyDataメッセージとCancelRequestメッセージを正しく出力するようになりました。 (Anthonin Bonnefoy) (18)

§ §

libpqが30000バイトを超えるParameterDescriptionメッセージを受け付けられるようになりました。 (Ning Sun) (18)(17)(16)(15)(14)

§ § § § §

ecpgコンパイラのNULLポインタ参照によるクラッシュが修正されました。 (Jehan-Guillaume de Rorthais) (18)

構造体の内側に入れ子になった共用体を含むDECLAREセクションをもつ.pgcコードを変換しようとすると、ecpgコマンド実行がクラッシュしました。

（ecpgコマンドがクラッシュするコード例）
EXEC SQL BEGIN DECLARE SECTION;
    struct s1
    {
        char STR1[10];
        union u1
        {
             int NUM1;
             int NUM2;
        } U1;
    } S1;
EXEC SQL END DECLARE SECTION;

ecpgのGET DESCRIPTOR文とSET DESCRIPTOR文で、記述子ヘッダ項目を複数指定する構文が拒否されるようになりました。 (Masashi Kamura) (18)(17)(16)(15)(14)

本修正で構文解析処理でもドキュメント上でもヘッダ項目は1つだけに変更されました。これは非互換性を含む変更です。

§ § § § §

psqlのパイプラインモードにおける遅延エラーの問題が修正されました。 (Michael Paquier) (18)

psqlの拡張表示（expanded）の整形出力で、行の幅が揃うようになりました。 (Pavel Stehule) (18)(17)(16)(15)(14)

（ずれた出力の例）

+-[ RECORD 1 ]-+
| a | 10 |
| b | 20 |
+---+----+

（修正後の出力例）

+-[ RECORD 1 ]-+
| a | 10       |
| b | 20       |
+---+----------+

§ § § § §

psqlの特別変数WATCH_INTERVALについて、既定の上限が強制されるようになりました。 (Sven Klemm, Daniel Gustafsson) (18)

psqlの「\l+」でデータベースサイズを表示する権限検査が修正されました。 (Christoph Berg) (18)(17)(16)(15)(14)

修正後は、「\l+」の権限検査にpg_read_all_statsロールの権限（USAGE）の確認が加わり、pg_database_size()の権限規則と一致するようになりました。

§ § § § § §

psqlの「\df」のタブ補完で、プロシージャも候補に含めるようになりました。 (Erik Wienhold) (18)(17)(16)(15)(14)

「\df」コマンド自体はプロシージャも表示対象に含めるよう拡張されていましたが、タブ補完の候補は関数だけを表示し続けていました。

§ § § § § §

pgbenchのスレッド安全性のバグが修正されました。 (Fujii Masao) (18)(17)(16)(15)

§ § § §

pg_combinebackupで、コピー元ファイルが想定より小さい場合に無限ループが発生することがあり、防止されました。 (Peter Eisentraut) (18)(17)

§ §

pg_createsubscriberで、エラー発生後にパブリッシャ側オブジェクトのクリーンアップが行なわれない場合があり、修正されました。 (Nisha Moond) (18)(17)

§ §

pg_recvlogicalの出力ファイルが、ソースクラスタのグループ読み取り権限に従って作成されるようになりました。 (Fujii Masao) (18)(17)(16)(15)(14)

§ § § § §

pg_restoreの「--statistics」および「--statistics-only」オプションの一貫しない挙動が修正されました。 (Chao Li, Michael Paquier) (18)

（誤動作例）
$ psql -d db1 <
 § §
vacuumdbの「--missing-stats-only」が、パーティションテーブルに対する式インデックスを処理対象から除外するようになりました。  (Baji Shaik) (18)

これまで、本オプションのvacuumdb実行では、パーティションテーブルに式インデックスがあると、常にそのパーティションテーブルにANALYZEを実行しようとしていました。しかし、統計情報は子パーティションのインデックスに作成されても、パーティションテーブルのインデックスには作成されないため、意味がありませんでした。

 §
contrib/amcheckで、btreeインデックスのメタページの「allequalimage」フラグの破損が報告されない問題が修正されました。  (Chao Li) (18)

btreeインデックスを検査する関数は、これまでインデックスキー列のいずれかにinterval_ops演算子クラスを含む場合のみ正しく動作していて、そうでないインデックスでこの破損が見逃される可能性がありました。

 §
contrib/amcheckの GINインデックス検証関数でメモリリークが修正されました。問い合わせが終わるまで未開放メモリが蓄積します。  (Kirill Reshke) (18)

大きなGINインデックスの検証でメモリ使用量が増大するおそれがありました。

 § §
contrib/amcheckで、ショートヘッダのvarlenaデータムが正しく扱われるように修正されました。  (Andrey Borodin) (18)(17)(16)(15)(14)

この誤りで、btreeインデックス検証で無駄な処理が生じる可能性がありますが、それ以上の悪影響は無いと考えられます。


varlenaデータムとはPostgreSQL実装内で使われる長さとデータ本体からなるデータ構造です。ショートヘッダは長さをあらわすのに1バイトだけ使う形式です。

 § § § § §
contrib/btree_gistで、float4とfloat8の演算子クラスにおける「NaN」の扱いが修正されました。  (Bill Kim, Tom Lane) (18)(17)(16)(15)(14)

各種の比較関数と、GiSTのpenalty関数、distance関数が「NaN」を考慮しておらず、「NaN」を渡されたときに誤った結果を返していました。


本修正の適用後、float列のbtree_gistインデックスに「NaN」のエントリが含まれる可能性がある場合は、それらのインデックスの再構築を推奨します。

 § § § § § §
contrib/btree_gistで、GiSTインデックス構築時のbit型とvarbit型の値のソートが修正されました。  (Tom Lane) (18)

これまでbit型の値がbytea型であるかのようにソートされていました。これは明白な誤動作を引き起こすことはありませんでしたが、型本来のソート順に一致しない並びで構築されるため、非効率なインデックスになりました。


本修正の適用後、bit列上のbtree_gistインデックスの再構築を推奨します。

 § §
contrib/btree_gistで、非等価（<>）演算子を使った検索が修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

可変長データ型の場合、非リーフインデックスページを走査するコードが誤った比較関数を適用していました。これは誤った問い合わせ結果、および場合によってはクラッシュにつながる可能性がありました。

 § § § § § §
contrib/dblinkとcontrib/postgres_fdwで、use_scram_passthroughオプションについて、ユーザマッピングの設定が外部サーバの設定より優先されるよう修正されました。  (Matheus Alcantara) (18)

これまでは外部サーバ側の設定が優先されていましたが、これは他の外部テーブルオプションの挙動と一貫していませんでした。他の接続オプション（sslcertやsslkeyなど）と同様に、外部サーバのオプションは共通のデフォルト値を提供し、ユーザマッピングのオプションがそれを上書きする扱いに統一されました。


これは非互換性を含む変更と言えます。

 § §
contrib/dblinkの外部データラッパのuse_scram_passthroughオプションが拒否されるようになりました。  (Matheus Alcantara) (18)

このオプションは外部サーバとユーザマッピングに対してのみ意味を持ちますが、dblinkは外部データラッパ（dblink_fdw）レベルでもこのオプションを受け付けていました（そして受け付けた設定を無視していました）。

 §
contrib/hstore_plperl、contrib/jsonb_plperl、contrib/jsonb_plpythonで保護されていない再帰とループがあり、修正されました。  (Aleksander Alekseev) (18)(17)(16)(15)(14)

深くネストしたjsonb値を扱うときのスタックオーバーフロー（によるクラッシュ）が防止されました。また、Perlのオブジェクト参照の循環チェーンをたどるときに生じる無限ループが割り込み可能になりました。

 § § § § § § § § § §
contrib/intarrayでプランナ統計情報のカタログキャッシュエントリの解放漏れが修正されました。  (Man Zeng) (18)(17)(16)(15)(14)

この解放漏れにより、「WARNING:  resource was not closed: cache pg_statistic ..」のような警告が発生していました。

 § § § § §
contrib/ltreeで比較関数における整数オーバーフローが修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

約14,653個を超えるラベルを含むltree値は、オーバーフローによって誤った比較結果を返していました。btreeインデックスにそのような値が含まれている場合、破損している可能性があるため、本修正の適用後に再構築することを推奨します。

 § § § § §
contrib/pgcryptoで、OSSLCipherオブジェクトの使用中にエラーが発生した後の二重解放によるクラッシュが回避されました。  (Yuelin Wang) (18)(17)
 § §
contrib/pg_prewarmのautoprewarmワーカの範囲外アクセスが修正されました。  (Matheus Alcantara) (18)

このコードは、配列の末尾の1つ先から値を取り出そうとしており、セグメンテーション違反によるクラッシュを引き起こす可能性がありました。

 §
contrib/pg_surgeryのheap_force_kill関数とheap_force_freeze関数で、配列の範囲外書き込みが修正されました。  (Michael Paquier) (18)(17)(16)(15)(14)

オフセット番号がMaxHeapTuplesPerPage（ページあたりの最大タプル数、291など）に等しいTIDを変更しようとすると、確保された配列の末尾の1バイト先に書き込み、サーバをクラッシュさせる可能性がありました。

 § § § § §
contrib/pg_surgeryで、64K要素を超えるTID配列による無限ループが回避されるようになりました。  (Andrey Rachitskiy) (18)(17)(16)(15)(14)
 § § § § § §
contrib/spiのrefint拡張で、check_foreign_key()関数のNULLポインタ参照が回避されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

ON UPDATE CASCADEの場合、参照列の新しいキー値がNULLであると、クラッシュが発生していました。これはCVE-2026-6637の修正の見落しですが、その前からあったコードも正しいものではありませんでした。

 § § § § §
contrib/segで、確実性指示子「~」を持つセグメントの値が正しく出力されるように修正されました。  (Ewan Young) (18)(17)(16)(15)(14)

seg型の出力関数seg_out()はセグメントの上限に付いた「~」を出力していませんでした。さらに悪いことに、下限に「~」があり上限に指示子がない場合、上限がまったく出力されませんでした。なお、文字列としての出力が不正であるだけで、演算結果に影響はありません。

（誤動作例：2番目と3番目が誤動作）
db1=# SELECT '~1 .. ~5'::seg, '1 .. ~5'::seg, '~1 .. 5'::seg;
   seg    |  seg   |  seg
----------+--------+--------
 ~1 .. ~5 | 1 .. 5 | ~1 ..
(1 row)

 § § § § §
contrib/xml2のxpath_nodeset()関数で名前空間ノードを問合せたときのクラッシュが修正されました。  (Andrey Chernyy, Michael Paquier) (18)(17)(16)(15)(14)

以下のように、query引数に「//namespace::」を指定した場合にクラッシュするケースが報告されました。

db1=# SELECT xpath_nodeset(
        '',
        '//namespace::*');

 § § § § §
OpenSSL 4を使ったPostgreSQLのビルドに対応しました。  (Daniel Gustafsson) (18)(17)(16)(15)(14)
 § § § § §
タイムゾーンデータファイルをtzdataリリース2026cに更新しました。  (Tom Lane) (18)(17)(16)(15)(14)

アルバータ州（America/Edmonton）は、2026年11月から年間を通したUTC-06（実質的に、恒久的なサマータイム）になります。このリリースでは、それ以降のタイムゾーン省略形は「CST」と仮定しています。この仮定は将来変更される可能性が高いのですが、新しい省略形に何が使われるかは明らかになっていません。


モロッコ（Africa/Casablanca）は、2026-09-20に、サマータイムの切り替えなしの恒久的なUTC+00に移行します。

 § § § § § §
古いマイナーバージョンが生成したWALのリプレイ時の自己デッドロックが修正されました。  (Andrey Borodin) (16)(15)(14)

この不具合は前回のマイナーリリース(16.14、15.18、14.23)で導入されました。より古いマイナーバージョンのプライマリに追従するスタンバイサーバで、startupプロセスがハングアップしてレプリケーションが先に進まなくなりました。


共有行ロックで使われるマルチトランザクションに関するWALレコードのリプレイで問題が発生しました。

 § § §
変数が1つも渡されていない場合でも、未定義のjsonpath変数をエラーとして扱うようになりました。  (Andrey Rachitskiy) (16)(15)(14)

jsonbの「@?」演算子と「@@」演算子がjsonpath式の中で使う変数を渡せない、という場合のコードパスでは、未知のjsonpath変数が、本来の期待であるエラーの発生ではなく、JSONのnullとして誤って扱われていました。期待される動作でないことに加えて、この誤りは無制限のメモリ消費を引き起こす可能性がありました。

（誤動作例）
db1=# select '{"A":1}'::jsonb @@ '$"no_such_var" == 1';
 ?column?
----------
 f
(1 row)

db1=# SELECT '{"A":1}'::jsonb @? '$"no_such_var"';
 ?column?
----------
 t
(1 row)

（修正後は以下のエラーが出る）
ERROR:  could not find jsonpath variable "no_such_var"

 § § §
Visual Studio 2026を使ったPostgreSQLのビルドに対応しました。  (Andrew Dunstan) (16)(15)(14)
 § § §

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

PostgreSQL 14.24 に関する技術情報

データベース技術グループ — Tue, 01 Sep 2026 04:29:56 +0000

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

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

PostgreSQL 14.23 から 14.24 への変更点

ロジカルデコーディングの出力プラグインが厳格化されました。新たな設定パラメータoutput_plugin_librariesでの指定が必要となりました。(CVE-2026-6471) (Jacob Champion) (18)(17)(16)(15)(14)

§ § § § § § § § §

contrib/pgcryptoのPGP暗号化がサポートされない暗号化方式を検出するように、修正されました。(CVE-2026-14663) (Daniel Gustafsson) (18)(17)(16)(15)(14)

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

psqlがスクリプト化された「COPY ... FROM STDIN」コマンドに続くインラインデータを、COPY開始時のエラーであっても、読み飛ばすように修正されました。(CVE-2026-6464) (Tom Lane) (18)(17)(16)(15)(14)

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

EXECUTEやFETCHを実行するポータルの出力行型についてクロスチェックを行うようになりました。(CVE-2026-16239) (Robert Haas) (18)(17)(16)(15)(14)

§ § § § § §

to_char()で、長いタイムゾーン省略形によるバッファオーバーランが修正されました。(CVE-2026-14669) (Tom Lane) (18)(17)(16)(15)(14)

これは容易にバックエンドプロセスのクラッシュができて、任意コード実行をもたらす攻撃も報告されました。

§ § § § § §

正規表現によるマッチ、分割の関数で、バッファオーバーランが修正されました。(CVE-2026-14664) (Masahiko Sawada) (18)(17)(16)(15)(14)

§ § § § § §

ascii()関数が不正な入力に対して頑健になりました。(CVE-2026-18024) (Michael Paquier) (18)(17)(16)(15)(14)

§ § § § § §

pg_restore_attribute_stats()関数でのマルチ範囲型の処理が修正されました。(CVE-2026-16238) (OpenAI Security Research Team) (18)(17)(16)(15)(14)

pg_restore_attribute_stats()はプランナ統計情報のダンプ、リストアで使われる関数です。

誤った統計情報のリストアにより、不適切なプラン選択による問合せ実行の遅延や潜在的なプランナ誤動作の可能性が考えられます。

§ § §

scalarineqsel()が、tid型と想定される定数を実際にそうであるか検査するようになりました。(CVE-2026-14668) (Tom Lane) (18)(17)(16)(15)(14)

この想定は組み込みの演算子については成り立ちますが、悪意で作られた演算子には通用せず、クラッシュやサーバメモリ暴露を引き起こします。

scalarineqsel()は選択率の見積を返すプランナの内部実装関数の1つです。

§ § § § § §

tsvector型とtsquery型の実装コードが（個々の要素、全体の長さの両面で）きわめて長い値に対して頑健になりました。(CVE-2026-14662) (Tom Lane) (18)(17)(16)(15)(14)

ドキュメントに記載されていた上限が、全てのコードパスで必ずしも強制されていませんでした。

ERROR:  lexeme is too long for tsvector ...
ERROR:  string is too long for tsvector ...
ERROR:  word is too long to be indexed ...
ERROR:  tsquery is too large

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

「FUNC_MAX_ARGS」を超える関数引数を処理する必要がない、と誤って想定していた様々な箇所が修正されました。(CVE-2026-14679) (Tom Lane) (18)(17)(16)(15)(14)

「FUNC_MAX_ARGS」はビルド時指定の定数でデフォルト100です。

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

internal型を引数や戻り値とする関数のSQLからの呼び出しを拒否するようになりました。(CVE-2026-14680) (Tom Lane) (18)(17)(16)(15)(14)

拒否するための既存の仕組みはありましたが、不十分であったため、明示的な検査が追加されました。

また、いくつかの集約関数のcombine処理で入力がNULLである場合に正しくSQLとしてのNULLを返すように修正されました。

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

ALTER TABLEコマンドで再構築されたとき、拡張統計オブジェクトの所有者が保たれるようになりました。(CVE-2026-6469) (Masahiko Sawada) (18)(17)(16)(15)(14)

§ § § § § §

EXTRACT()関数呼び出しを逆パースするときに、必要であればフィールド名をクォートするようになりました。(CVE-2026-15741) (Nathan Bossart) (18)(17)(16)(15)(14)

逆パースはダンプ出力やpsqlでの定義表示で行なわれる処理です。

§ § § § § §

これまで検査ができていなかった個所について、データ型に対する「USAGE」権限を検査するようになりました。(CVE-2026-6470) (Nathan Bossart) (18)(17)(16)(15)(14)

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

行単位セキュリティ(RLS)に対して、ロールに依存したキャッシュされたプランを、ロール変更後に無効化するようになりました。(CVE-2026-14666) (Ilya Staroverov, Shinya Kato, Nathan Bossart) (18)(17)(16)(15)(14)

§ § § § § §

直接のSSL接続の後のGSSEncRequestメッセージを拒否するようになりました。(CVE-2026-14681) (Michael Paquier) (18)(17)(16)(15)(14)

§ § §

モックのSCRAM認証シークレットがより本物らしくなりました。(CVE-2026-14672) (Nathan Bossart) (18)(17)(16)(15)(14)

本修正で、モックにもscram_iterations設定パラメータの値を使って、より実際に使われているシークレットに似せるようになりました。

§ § § §

ecpgアプリケーションでの範囲外書き込みが修正されました。サーバから不正なbytea型データを受け取ることで引き起こされます。(CVE-2026-16241) (Michael Paquier) (18)(17)(16)(15)(14)

§ § § § § §

psqlの「\unrestrict」コマンドの引数でバッククォート展開をしないようになりました。(CVE-2026-18408) (Nathan Bossart) (18)(17)(16)(15)(14)

§ § § § § §

pg_dumpにおいてpg_proc.protrftypesのエントリ数がFUNC_MAX_ARGSを超えないという前提が取り除かれました。(CVE-2026-19385) (Tom Lane) (18)(17)(16)(15)(14)

§ § § § § §

tieされたPerlの配列やハッシュに対して、PL/Perlが堅牢化されました。(CVE-2026-14670) (Tom Lane) (18)(17)(16)(15)(14)

tieは、配列やハッシュなどの変数に対して操作用のメソッド群を実装したオブジェクトに結びつける Perl の機能です。

§ § § § § §

PL/PerlおよびPL/Tclにおけるメモリ割り当て計算時の整数オーバーフローが修正されました。(CVE-2026-14677) (Heikki Linnakangas) (18)(17)(16)(15)(14)

これはコードの異なる個所で発生していたCVE-2026-6473と同様の問題で、同じ方法で修正されました。

§ § § § § §

contrib/amcheckの関数がインデックス式を実行する前にsearch_pathを制限するようになりました。(CVE-2026-14673) (Noah Misch) (18)(17)(16)(15)(14)

§ § § § § §

contrib/fuzzystrmatchのlevenshtein()およびlevenshtein_less_equal()関数における整数オーバーフローが修正されました。(CVE-2026-15742) (Nathan Bossart) (18)(17)(16)(15)(14)

§ § § § § §

contrib/pg_stat_statementsにおけるバッファオーバーランが修正されました。(CVE-2026-14676) (Alvaro Herrera) (18)(17)(16)(15)(14)

クエリの正規化処理において、正規化後の文字列が必要とするサイズが正確に考慮されていませんでした。

§ §

contrib/pg_trgmのGiST picksplit関数におけるデータ型エラーが修正されました。(CVE-2026-14678) (Heikki Linnakangas) (18)(17)(16)(15)(14)

§ § § § § §

contrib/refintのプランキャッシュが削除されるようになりました。(CVE-2026-14671) (Ayush Tiwari) (18)(17)(16)(15)(14)

§ § § § §

並列GINインデックスの構築時に、テーブルのpg_class.reltuples値が正しく更新されるようになりました。 (Jan Nidzwetzki, Tomas Vondra) (18)

SELECT DISTINCT t.oid::regclass, t.reltuples
FROM pg_class t
  JOIN pg_index i ON t.oid = i.indrelid
  JOIN pg_class ic ON i.indexrelid = ic.oid
WHERE t.relhasindex AND ic.relam = 2742;

§ §

非同期のAppendプランノードを再スキャンする際の、非同期読み取りの不適切な処理が修正されました。 (Alexander Korotkov, Gleb Kashkin, Etsuro Fujita) (18)(17)(16)(15)(14)

§ § § § § §

RANGEパーティションテーブルにおけるパーティションプルーニングの不具合が修正されました。 (David Rowley) (18)(17)(16)(15)(14)

§ § § § § §

結果リレーションのプルーニング後に、ModifyTableプランノード内の外部データラッパーの状態を正しく更新するようになりました。 (Ayush Tiwari, Rafia Sabih) (18)

§ §

「BEFORE UPDATE」トリガーを持つテーブルに対して、「RETURNING OLD」を指定したUPDATE文で発生していた並行更新の処理漏れが修正されました。 (Dean Rasheed) (18)

§ §

複数の結合キーと多数のNULL値が存在する場合のハッシュ結合の性能問題が修正されました。 (David Rowley) (18)

§ §

RETURNING句の式における括弧で囲まれた「OLD」や「NEW」の解析処理が修正されました。 (Marko Grujic) (18)

value IN (array)式に対するプランナのNULL許容性および厳密性チェックが修正されました。 (Ayush Tiwari) (18)(17)(16)(15)(14)

§ § § § § §

不適切な結合削除のロジックが修正されました。 (Matheus Alcantara, Richard Guo) (18)(17)(16)

§ § § § § § § §

結合の削除処理において、PlaceHolderVarsのクリーンアップがより徹底されるようになりました。 (Richard Guo, Arne Roland) (18)

§ § §

コンテナデータ型（配列、複合型、範囲型）の等価比較におけるハッシュ可能性に関する漏れていたチェックが追加されました。 (Andrei Lepikhov, Tom Lane) (18)(17)(16)(15)(14)

§ § § § §

プランナが、異なる等価性ルールを持つグループ化ステップより下位へ、WHERE句をプッシュダウンすることを避けるようになりました。 (Richard Guo) (18)

§ §

「EXCLUDE」句を指定している、または「ORDER BY」を指定していない、COUNTウィンドウ関数の誤った最適化が修正されました。 (Chengpeng Yan, David Rowley) (18)(17)(16)(15)

（報告された誤動作例）
db1=# CREATE TABLE t41 (id int PRIMARY KEY, k int NOT NULL, v int);
db1=# INSERT INTO t41(id, k, v) VALUES
        (1, 1, 1), (2, 1, NULL), (3, 1, 1), (4, 2, 1);

db1=# SELECT id, count(v) OVER (
        ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        EXCLUDE CURRENT ROW) AS c FROM t41;
 id | c
----+---
  1 | 1
  2 | 2
  3 | 1
  4 | 2
(4 rows)

db1=# SELECT * FROM (
        SELECT id, count(v) OVER (
          ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
          EXCLUDE CURRENT ROW) AS c FROM t41) s WHERE c < 2;
 id | c
----+---
  1 | 1
(1 row)
→ 正しくは id=3 の行も出力されないといけない

§ § § § §

プランナが"char"型の列の統計情報を参照する際に、予期せぬエラー「ERROR: cache lookup failed for collation 0」が発生する障害が修正されました。 (Feng Wu) (18)

"char"型は、一般的に使われるchar(n)型とは別の、主として内部的なシステムカタログで使用されるものです。

複数階層のパーティションが存在する場合でも、ALTER TABLEのALTER COLUMN ... DROP EXPRESSIONが正常に動作するよう修正されました。 (Alberto Piai) (18)(17)(16)(15)(14)

§ § § § § §

排他制約であるインデックスのパーティションをアタッチする処理の不具合が修正されました。 (Japin Li) (18)(17)

この誤りにより、排他制約を持つパーティションテーブルのダンプ/リストアが正常に動作しなくなっていました。

リストア時に以下のようなエラーが発生します。

ERROR:  cannot attach index "..." as a partition of index "..."
DETAIL:  The index definitions do not match.

§ § §

ALTER CONSTRAINTを使用して、パーティションテーブルのNOT NULL制約にNO INHERITを設定することができないように修正されました。 (Andreas Karlsson) (18)

ルールの名前を「_RETURN」に変更できないように修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

具体的には、ダンプ/リストアで「ERROR: non-view rule for "..." must not be named "_RETURN"」というエラーを起こすことが報告されました。

§ § § § § §

DROP OWNED BYにおいて、ロールメンバーシップへのロックの解放漏れが修正されました。 (Jeff Davis) (18)(17)(16)

§ § § §

EXPLAINがSQL/JSONの集約関数をデパースするときに予期せぬエラーを出すことがあり、修正されました。 (Richard Guo) (18)(17)(16)

実行プランの構造によっては、「ERROR: invalid JsonConstructorExpr underlying node type」というエラーが発生していました。

§ § § §

遅延一意性制約のインデックスに対してREINDEX CONCURRENTLYを使用した場合の不具合が修正されました。 (Nitin Motiani) (18)(17)(16)(15)(14)

§ § § § § §

非決定論的照合順序でバックスラッシュ（\）を使用したLIKE句のマッチングの不具合が修正されました。 (Nitin Motiani, Tom Lane) (18)

§ § § §

LIKE句や正規表現の完全一致パターンのインデックススキャン最適化の不具合が修正されました。 (Jelte Fennema-Nio) (18)

§ §

to_date() におけるローカライズされた月名、曜日名のマッチング処理が修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

§ § § § § § §

ギリシャ文字の語末形のシグマに対する大文字小文字の変換のルールが修正されました。 (Jeff Davis) (18)

文字列の直前が大文字小文字を区別しない文字だけで構成されている場合、そのシグマを語末形のシグマとはみなさないようにしました。

§ §

ハングルU+11A7（TBASE）のNFC再合成における誤りが修正されました。 (Diego Frias, Michael Paquier) (18)(17)(16)(15)(14)

この文字は有効なT音節として扱われていましたが、実際にはT音節ではないため、正規化処理中にこの文字が消えてしまっていました。

§ § § § §

大文字小文字を区別しない類義語の辞書において、出力する語彙素が切り捨てられる不具合が修正されました。 (Jeff Davis) (18)(17)(16)(15)(14)

小文字への変換によって語彙素のバイト長が増加した場合、出力時に元のバイト長に誤って切り捨てられていました。

§ § § § §

大文字小文字変換処理において、途中で途切れたUTF-8文字への対処が修正されました。 (Jeff Davis) (18)(17)

§ § §

hash_record_extended()のバグが修正されました。 (Man Zeng) (18)(17)(16)(15)(14)

§ § § § §

公開可能なテーブルが並行して削除された場合に、pg_get_publication_tables()が失敗する不具合が修正されました。 (Bharath Rupireddy) (18)(17)(16)

§ § § §

VARIADIC NULL を指定した場合に、satisfies_hash_partition() がクラッシュする不具合が修正されました。 (Robert Haas) (18)(17)(16)(15)(14)

§ § § § § §

tsvector_filter() および関連する関数で、不正な重みに関するエラーを、より明確かつ一貫した形で報告するよう修正されました。 (Ewan Young) (18)(17)(16)(15)(14)

§ § § § §

uundv7()関数で範囲外のタイムスタンプとなるシフト値を拒絶するようになりました。 (Baji Shaik) (18)

§ §

xpath()関数でnamestapeノードの処理が修正されました。 (Michael Paquier) (18)(17)(16)(15)(14)

予期せぬ「ERROR: could not copy node」エラーが出ていたものが修正されました。

§ § § § § § § § § §

jsonpathの「.decimal」メソッドが、精度やスケールの指定が正しくない場合でもERRORを出さないように、修正されました。 (Ewan Young) (18)(17)

サイレントモード（json_path_*関数のsilent引数がtrue）では、エラーを抑止すべきですが、そのようになっていませんでした。

§ § § § §

「IS JSON」や「JSON()」等の構文が、text型へのキャストを持たない文字列型の引数を与えられたときの、NULLポインタによるクラッシュが修正されました。 (Ayush Tiwari) (18)(17)(16)

PostgreSQL本体コードには該当するデータ型はありませんが、一部の拡張のデータ型で問題を引き起こす可能性がありました。

§ § §

「SQL/JSON」の「ON EMPTY / ON ERROR DEFAULT」の値に正しい型修飾が確実に適用されるようになりました。 (Ewan Young) (18)(17)

例えば、対象numeric型列の宣言された精度とスケールがデフォルト値に適用されませんでした。

（誤動作例）
db1=# SELECT JSON_VALUE(jsonb '{"b":"1234.5"}', '$.a' 
        RETURNING numeric(4,1) DEFAULT 99999.9 ON EMPTY);
 json_value
------------
    99999.9
(1 row)

（以下エラーが出るのが正しい動作）
ERROR:  numeric field overflow

§ § §

money型の最小値（64bit整数最小値）を-1で割ったときの、マシン依存の振る舞いが回避されました。 (Andrey Rachitskiy) (18)(17)(16)(15)(14)

§ § § § § §

全文検索の辞書に対するキャッシュエントリの作成途中でメモリ不足が生じた後にクラッシュする障害が修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

§ § § § § §

誤ったispell/hunspell辞書ファイルに対する処理でメモリ安全性に問題があり、修正されました。 (Andrey Rachitskiy) (18)(17)(16)(15)(14)

§ § § § § §

他セッションの一時テーブルへのアクセスが防止されました。 (Jim Jones, Daniil Davydov, Alexander Korotkov) (18)(17)(16)

§ § § § § §

一時テーブルにアクセスするときの「ERROR: no empty local buffer available」エラーが防止されました。 (Melanie Plageman) (18)

autovacuumがデータベースを処理する順番が修正されました。 (Rustam Khamidullin) (18)(17)

最高スコアから最低スコアに向かう順で処理されるべきところで、意図せず逆順になっていました。

§ § §

VACUUMのXID周回フェールセーフモードで、共有バッファプールを全使用するように動作が復旧されました。 (Melanie Plageman) (18)

§ § § §

パラレルVACUUMワーカーの処理でのメモリリークが修正されました。 (Baji Shaik) (18)(17)

パラレルワーカーからの報告過程で報告ごとに1kB程度のリークがあり、これはワーカープロセスが生きている間は蓄積されていきました。

§ §

問合せのキャンセルとVACUUM遅延が、GINインデックスのポスティングツリーのクリーンアップ中であっても、すぐに行なわれるようになりました。 (Paul Kim, Alexander Korotkov) (18)(17)(16)(15)(14)

よくある値に対するポスティングツリーは大きくなることがあり、ここに割り込みの検査が欠けていたため、処理が長く継続してしまいました。

§ § § § § §

GiSTおよびSP-GiSTのインデックスに対するIndex Only Scanで、インデックスタプルのデコーディングを誤る可能性があり、修正されました。 (Peter Geoghegan) (18)(17)(16)(15)(14)

（誤動作例）
db1=# CREATE TABLE t75 (a inet, r numrange);
db1=# INSERT INTO t75 VALUES 
      ('::1', numrange(repeat('1', 100)::numeric, repeat('2', 200)::numeric)));
db1=# CREATE INDEX ON t75 USING gist (a inet_ops, r range_ops);
db1=# VACUUM ANALYZE t75;
db1=# SET enable_seqscan TO off;
db1=# SELECT lower(r) = repeat('1', 100)::numeric,
             upper(r) = repeat('2', 200)::numeric FROM t75;
ERROR:  type with OID 860 does not exist

§ § § § § §

バルク拡張されたテーブルの新たな最終ブロックがフリースペースマップに即座に追加されるようになりました。 (Jingtang Zhang) (18)(17)(16)

§ § § §

トランザクションのアボート時のリソース解放処理で、メモリの二重解放（クラッシュをひきおこします）、または、エラーの再帰的な無限ループが起きる可能性があり、修正されました。 (Tom Lane) (18)(17)

巨大な入力値を伴うSQLがエラーになって、トランザクションアボートが行なわれたケースで問題が報告されました。

§ §

PostgreSQLの処理内でディレクトリを作成するとき、同じディレクトリの同時作成を許容するようになりました。 (Andrew Dunstan, Tom Lane) (18)(17)(16)(15)(14)

§ § § § §

JITコンパイルされたタプルデフォームを行うコードが、仮想生成列を正しく考慮するように修正されました。 (David Rowley) (18)

NOT NULL制約のある仮想生成列を含むテーブルへの問合せで、誤った問い合わせ結果が生じる例が報告されました。

依存されている全てのオブジェクトに共有ロックを取得することにより、宙に浮いたオブジェクト依存関係の生成が防止されました。 (Bertrand Drouvot) (18)(17)(16)(15)(14)

共有ロックは依存されているオブジェクトの削除と衝突しますので、これまであった競合状態を排除することができます。

§ § § § § § § § § §

SERIALIZABLE分離モードに対する衝突の検出での競合状態が修正されました。 (Peter Geoghegan) (18)(17)(16)(15)(14)

§ § § § § §

バリアイベントの処理で競合状態が修正されました。 (Masahiko Sawada) (18)(17)(16)(15)

LOG:  still waiting for backend with PID %d to accept ProcSignalBarrier

近年追加されたオンラインWALレベル変更などの機能によって、この問題がより目立つようになっています。

§ § § §

同じロックグループに属するプロセス集合が同時に終了したときの競合状態が修正されました。 (Vlad Lesin) (18)(17)(16)(15)(14)

§ § § § § § § § § §

テーブルのビジビリティマップ(VM)でビットをクリアする操作のWAL出力が修正されました。 (Melanie Plageman, Andres Freund) (18)(17)

既存のバックアップやアーカイブWALに潜在的にデータ破損が含まれていることに留意してください。

§ § § § § § § § §

WALサマライズ処理でのタイムライン変更時のハングアップが防止されました。 (Robert Haas) (18)(17)

スタンバイサーバで、以下のログメッセージがwalsummarizerプロセスから継続的に出力される動作が報告されました。

ERROR:  could not read WAL from timeline .. at ...: invalid record length ...

§ § § § § §

スタンバイ昇格のときのロジカルデコーディングのタイムライン選択で、競合状態が修正されました。 (Bertrand Drouvot) (18)(17)(16)

§ § § § § § §

タイムラインを切替するときのwalreceiverの接続文字列の露出が回避されました。 (Chao Li) (18)(17)(16)(15)(14)

§ § § § §

ロジカルレプリケーションで受け取ったタプルの列数が正しいかの検証を、アサートではなく実行時チェックで行うようになりました。 (Varik Matevosyan) (18)(17)(16)(15)(14)

§ § § § §

レプリケーションコマンド内の文字列パラメータへのクォート付加について、実装がクリーンアップされました。 (Tom Lane) (18)(17)(16)(15)(14)

§ § § § §

空のプリペアドトランザクションのロジカルデコーディングについて修正されました。 (Masahiko Sawada) (18)(17)(16)(15)(14)

§ § § § § §

スタンバイ昇格後のUNLOGGEDシーケンスのデータ破損が修正されました。 (Fujii Masao) (18)(17)(16)(15)

§ § § § §

カスケードスタンバイでのWALアーカイブによるリカバリからストリーミングに復帰するときの再接続失敗が、修正されました。 (Marco Nenciarini) (18)(17)(16)(15)(14)

このとき「ERROR: requested starting point ... is ahead of the WAL flush position」が発生する可能性がありました。

§ § § § § §

WALリプレイが一貫性のあるデータベース状態に達する前にホットスタンバイ接続を受け付ける動作が防止されました。 (Nikhil Sontakke) (18)

§ §

スタンバイサーバで、ローカルにpg_database.dathasloginevtのクリアを試みないようになりました。 (Ayush Tiwari) (18)(17)

§ §

使われなくなったレプリケーションスロットを削除するときの競合状態が回避されました。 (Xuneng Zhou) (18)(17)

§ §

一時的なレプリケーションスロット（初期化途中の論理レプリケーションスロット）を削除するときの競合状態が回避されました。 (Zhijie Hou) (18)(17)(16)(15)(14)

§ § § § §

ロジカルレプリケーションのテーブル初期同期で、進捗報告が古い内容となっていた問題が修正されました。 (Shinya Kato) (18)(17)(16)(15)(14)

§ § § § §

バックアップに失敗したなら、ベースバックアップの進捗がクリアされるようになりました。 (Chao Li) (18)(17)(16)(15)

§ § § § § § § § §

設定track_functionsが有効であるとき、実行時統計情報(pgstats)のエントリの同時削除のためにPANICが生じる可能性があり、修正されました。 (Sami Imseih, Michael Paquier) (18)(17)(16)(15)

「PANIC: cannot abort transaction .., it was already committed」が出るケースが報告されました。

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

対応する共有ハッシュテーブルのエントリに対するメモリ領域取得に失敗した後、壊れた実行時統計情報(pgstats)のローカルエントリをクリーンアップするようになりました。 (Niall Newman) (18)(17)(16)(15)

これを行なっていなかったため、次にローカルエントリが使われたときに、NULLポインタ参照によるクラッシュが発生しました。

§ § § § §

読み込みや書き込みの失敗後に誤ったI/O操作統計が記録されないように、修正されました。 (Bertrand Drouvot) (18)

PL/Perlで、不正なPostgreSQL::InServer::ARRAYオブジェクトを扱うときのNULLポインタ参照によるクラッシュが回避されるようになりました。 (Xing Guo) (18)(17)(16)(15)(14)

（クラッシュ発生例）
=# CREATE FUNCTION f102() RETURNS integer[] AS $$
     return bless {}, "PostgreSQL::InServer::ARRAY"; $$ LANGUAGE plperl;
=# SELECT f102();
server closed the connection unexpectedly

§ § § § §

PL/Pythonで、Pythonのシーケンスオブジェクトとマッピングオブジェクトを扱うときにエラーを正しく検査するようになりました。 (Richard Guo) (18)(17)(16)(15)(14)

§ § § § § §

libpqで、pqReadData()の実行中にSSLまたはGSSの復号バッファに残っている未処理バイトを常にすべて取り出すようになりました。 (Jacob Champion) (18)(17)(16)(15)(14)

pqReadData()はサーバ側からデータを読むlibpqの内部実装関数です。

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

libpqのメモリ不足状態の処理が改善されました。 (Anthonin Bonnefoy) (18)

§ §

libpqのトレース機能が、新しい形式のBackendKeyDataメッセージとCancelRequestメッセージを正しく出力するようになりました。 (Anthonin Bonnefoy) (18)

§ §

libpqが30000バイトを超えるParameterDescriptionメッセージを受け付けられるようになりました。 (Ning Sun) (18)(17)(16)(15)(14)

§ § § § §

ecpgコンパイラのNULLポインタ参照によるクラッシュが修正されました。 (Jehan-Guillaume de Rorthais) (18)

構造体の内側に入れ子になった共用体を含むDECLAREセクションをもつ.pgcコードを変換しようとすると、ecpgコマンド実行がクラッシュしました。

（ecpgコマンドがクラッシュするコード例）
EXEC SQL BEGIN DECLARE SECTION;
    struct s1
    {
        char STR1[10];
        union u1
        {
             int NUM1;
             int NUM2;
        } U1;
    } S1;
EXEC SQL END DECLARE SECTION;

ecpgのGET DESCRIPTOR文とSET DESCRIPTOR文で、記述子ヘッダ項目を複数指定する構文が拒否されるようになりました。 (Masashi Kamura) (18)(17)(16)(15)(14)

本修正で構文解析処理でもドキュメント上でもヘッダ項目は1つだけに変更されました。これは非互換性を含む変更です。

§ § § § §

psqlのパイプラインモードにおける遅延エラーの問題が修正されました。 (Michael Paquier) (18)

psqlの拡張表示（expanded）の整形出力で、行の幅が揃うようになりました。 (Pavel Stehule) (18)(17)(16)(15)(14)

（ずれた出力の例）

+-[ RECORD 1 ]-+
| a | 10 |
| b | 20 |
+---+----+

（修正後の出力例）

+-[ RECORD 1 ]-+
| a | 10       |
| b | 20       |
+---+----------+

§ § § § §

psqlの特別変数WATCH_INTERVALについて、既定の上限が強制されるようになりました。 (Sven Klemm, Daniel Gustafsson) (18)

psqlの「\l+」でデータベースサイズを表示する権限検査が修正されました。 (Christoph Berg) (18)(17)(16)(15)(14)

修正後は、「\l+」の権限検査にpg_read_all_statsロールの権限（USAGE）の確認が加わり、pg_database_size()の権限規則と一致するようになりました。

§ § § § § §

psqlの「\df」のタブ補完で、プロシージャも候補に含めるようになりました。 (Erik Wienhold) (18)(17)(16)(15)(14)

「\df」コマンド自体はプロシージャも表示対象に含めるよう拡張されていましたが、タブ補完の候補は関数だけを表示し続けていました。

§ § § § § §

pgbenchのスレッド安全性のバグが修正されました。 (Fujii Masao) (18)(17)(16)(15)

§ § § §

pg_combinebackupで、コピー元ファイルが想定より小さい場合に無限ループが発生することがあり、防止されました。 (Peter Eisentraut) (18)(17)

§ §

pg_createsubscriberで、エラー発生後にパブリッシャ側オブジェクトのクリーンアップが行なわれない場合があり、修正されました。 (Nisha Moond) (18)(17)

§ §

pg_recvlogicalの出力ファイルが、ソースクラスタのグループ読み取り権限に従って作成されるようになりました。 (Fujii Masao) (18)(17)(16)(15)(14)

§ § § § §

pg_restoreの「--statistics」および「--statistics-only」オプションの一貫しない挙動が修正されました。 (Chao Li, Michael Paquier) (18)

（誤動作例）
$ psql -d db1 <
 § §
vacuumdbの「--missing-stats-only」が、パーティションテーブルに対する式インデックスを処理対象から除外するようになりました。  (Baji Shaik) (18)

これまで、本オプションのvacuumdb実行では、パーティションテーブルに式インデックスがあると、常にそのパーティションテーブルにANALYZEを実行しようとしていました。しかし、統計情報は子パーティションのインデックスに作成されても、パーティションテーブルのインデックスには作成されないため、意味がありませんでした。

 §
contrib/amcheckで、btreeインデックスのメタページの「allequalimage」フラグの破損が報告されない問題が修正されました。  (Chao Li) (18)

btreeインデックスを検査する関数は、これまでインデックスキー列のいずれかにinterval_ops演算子クラスを含む場合のみ正しく動作していて、そうでないインデックスでこの破損が見逃される可能性がありました。

 §
contrib/amcheckの GINインデックス検証関数でメモリリークが修正されました。問い合わせが終わるまで未開放メモリが蓄積します。  (Kirill Reshke) (18)

大きなGINインデックスの検証でメモリ使用量が増大するおそれがありました。

 § §
contrib/amcheckで、ショートヘッダのvarlenaデータムが正しく扱われるように修正されました。  (Andrey Borodin) (18)(17)(16)(15)(14)

この誤りで、btreeインデックス検証で無駄な処理が生じる可能性がありますが、それ以上の悪影響は無いと考えられます。


varlenaデータムとはPostgreSQL実装内で使われる長さとデータ本体からなるデータ構造です。ショートヘッダは長さをあらわすのに1バイトだけ使う形式です。

 § § § § §
contrib/btree_gistで、float4とfloat8の演算子クラスにおける「NaN」の扱いが修正されました。  (Bill Kim, Tom Lane) (18)(17)(16)(15)(14)

各種の比較関数と、GiSTのpenalty関数、distance関数が「NaN」を考慮しておらず、「NaN」を渡されたときに誤った結果を返していました。


本修正の適用後、float列のbtree_gistインデックスに「NaN」のエントリが含まれる可能性がある場合は、それらのインデックスの再構築を推奨します。

 § § § § § §
contrib/btree_gistで、GiSTインデックス構築時のbit型とvarbit型の値のソートが修正されました。  (Tom Lane) (18)

これまでbit型の値がbytea型であるかのようにソートされていました。これは明白な誤動作を引き起こすことはありませんでしたが、型本来のソート順に一致しない並びで構築されるため、非効率なインデックスになりました。


本修正の適用後、bit列上のbtree_gistインデックスの再構築を推奨します。

 § §
contrib/btree_gistで、非等価（<>）演算子を使った検索が修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

可変長データ型の場合、非リーフインデックスページを走査するコードが誤った比較関数を適用していました。これは誤った問い合わせ結果、および場合によってはクラッシュにつながる可能性がありました。

 § § § § § §
contrib/dblinkとcontrib/postgres_fdwで、use_scram_passthroughオプションについて、ユーザマッピングの設定が外部サーバの設定より優先されるよう修正されました。  (Matheus Alcantara) (18)

これまでは外部サーバ側の設定が優先されていましたが、これは他の外部テーブルオプションの挙動と一貫していませんでした。他の接続オプション（sslcertやsslkeyなど）と同様に、外部サーバのオプションは共通のデフォルト値を提供し、ユーザマッピングのオプションがそれを上書きする扱いに統一されました。


これは非互換性を含む変更と言えます。

 § §
contrib/dblinkの外部データラッパのuse_scram_passthroughオプションが拒否されるようになりました。  (Matheus Alcantara) (18)

このオプションは外部サーバとユーザマッピングに対してのみ意味を持ちますが、dblinkは外部データラッパ（dblink_fdw）レベルでもこのオプションを受け付けていました（そして受け付けた設定を無視していました）。

 §
contrib/hstore_plperl、contrib/jsonb_plperl、contrib/jsonb_plpythonで保護されていない再帰とループがあり、修正されました。  (Aleksander Alekseev) (18)(17)(16)(15)(14)

深くネストしたjsonb値を扱うときのスタックオーバーフロー（によるクラッシュ）が防止されました。また、Perlのオブジェクト参照の循環チェーンをたどるときに生じる無限ループが割り込み可能になりました。

 § § § § § § § § § §
contrib/intarrayでプランナ統計情報のカタログキャッシュエントリの解放漏れが修正されました。  (Man Zeng) (18)(17)(16)(15)(14)

この解放漏れにより、「WARNING:  resource was not closed: cache pg_statistic ..」のような警告が発生していました。

 § § § § §
contrib/ltreeで比較関数における整数オーバーフローが修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

約14,653個を超えるラベルを含むltree値は、オーバーフローによって誤った比較結果を返していました。btreeインデックスにそのような値が含まれている場合、破損している可能性があるため、本修正の適用後に再構築することを推奨します。

 § § § § §
contrib/pgcryptoで、OSSLCipherオブジェクトの使用中にエラーが発生した後の二重解放によるクラッシュが回避されました。  (Yuelin Wang) (18)(17)
 § §
contrib/pg_prewarmのautoprewarmワーカの範囲外アクセスが修正されました。  (Matheus Alcantara) (18)

このコードは、配列の末尾の1つ先から値を取り出そうとしており、セグメンテーション違反によるクラッシュを引き起こす可能性がありました。

 §
contrib/pg_surgeryのheap_force_kill関数とheap_force_freeze関数で、配列の範囲外書き込みが修正されました。  (Michael Paquier) (18)(17)(16)(15)(14)

オフセット番号がMaxHeapTuplesPerPage（ページあたりの最大タプル数、291など）に等しいTIDを変更しようとすると、確保された配列の末尾の1バイト先に書き込み、サーバをクラッシュさせる可能性がありました。

 § § § § §
contrib/pg_surgeryで、64K要素を超えるTID配列による無限ループが回避されるようになりました。  (Andrey Rachitskiy) (18)(17)(16)(15)(14)
 § § § § § §
contrib/spiのrefint拡張で、check_foreign_key()関数のNULLポインタ参照が回避されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)

ON UPDATE CASCADEの場合、参照列の新しいキー値がNULLであると、クラッシュが発生していました。これはCVE-2026-6637の修正の見落しですが、その前からあったコードも正しいものではありませんでした。

 § § § § §
contrib/segで、確実性指示子「~」を持つセグメントの値が正しく出力されるように修正されました。  (Ewan Young) (18)(17)(16)(15)(14)

seg型の出力関数seg_out()はセグメントの上限に付いた「~」を出力していませんでした。さらに悪いことに、下限に「~」があり上限に指示子がない場合、上限がまったく出力されませんでした。なお、文字列としての出力が不正であるだけで、演算結果に影響はありません。

（誤動作例：2番目と3番目が誤動作）
db1=# SELECT '~1 .. ~5'::seg, '1 .. ~5'::seg, '~1 .. 5'::seg;
   seg    |  seg   |  seg
----------+--------+--------
 ~1 .. ~5 | 1 .. 5 | ~1 ..
(1 row)

 § § § § §
contrib/xml2のxpath_nodeset()関数で名前空間ノードを問合せたときのクラッシュが修正されました。  (Andrey Chernyy, Michael Paquier) (18)(17)(16)(15)(14)

以下のように、query引数に「//namespace::」を指定した場合にクラッシュするケースが報告されました。

db1=# SELECT xpath_nodeset(
        '',
        '//namespace::*');

 § § § § §
OpenSSL 4を使ったPostgreSQLのビルドに対応しました。  (Daniel Gustafsson) (18)(17)(16)(15)(14)
 § § § § §
タイムゾーンデータファイルをtzdataリリース2026cに更新しました。  (Tom Lane) (18)(17)(16)(15)(14)

アルバータ州（America/Edmonton）は、2026年11月から年間を通したUTC-06（実質的に、恒久的なサマータイム）になります。このリリースでは、それ以降のタイムゾーン省略形は「CST」と仮定しています。この仮定は将来変更される可能性が高いのですが、新しい省略形に何が使われるかは明らかになっていません。


モロッコ（Africa/Casablanca）は、2026-09-20に、サマータイムの切り替えなしの恒久的なUTC+00に移行します。

 § § § § § §
古いマイナーバージョンが生成したWALのリプレイ時の自己デッドロックが修正されました。  (Andrey Borodin) (16)(15)(14)

この不具合は前回のマイナーリリース(16.14、15.18、14.23)で導入されました。より古いマイナーバージョンのプライマリに追従するスタンバイサーバで、startupプロセスがハングアップしてレプリケーションが先に進まなくなりました。


共有行ロックで使われるマルチトランザクションに関するWALレコードのリプレイで問題が発生しました。

 § § §
変数が1つも渡されていない場合でも、未定義のjsonpath変数をエラーとして扱うようになりました。  (Andrey Rachitskiy) (16)(15)(14)

jsonbの「@?」演算子と「@@」演算子がjsonpath式の中で使う変数を渡せない、という場合のコードパスでは、未知のjsonpath変数が、本来の期待であるエラーの発生ではなく、JSONのnullとして誤って扱われていました。期待される動作でないことに加えて、この誤りは無制限のメモリ消費を引き起こす可能性がありました。

（誤動作例）
db1=# select '{"A":1}'::jsonb @@ '$"no_such_var" == 1';
 ?column?
----------
 f
(1 row)

db1=# SELECT '{"A":1}'::jsonb @? '$"no_such_var"';
 ?column?
----------
 t
(1 row)

（修正後は以下のエラーが出る）
ERROR:  could not find jsonpath variable "no_such_var"

 § § §
Visual Studio 2026を使ったPostgreSQLのビルドに対応しました。  (Andrew Dunstan) (16)(15)(14)
 § § §

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

70歳を超えてなお、OSS活動に情熱を注ぐ。「生涯現役」でコードを書き続ける意義とは？- 石井達夫インタビュー

sraoss — Fri, 14 Aug 2026 06:01:57 +0000

Findy Media様にて、SRA OSS 顧問であり、PostgreSQL コミッターの石井達夫へのインタビュー記事が公開されました。

本記事では、PostgreSQLの黎明期から現在に至るまで、どのような想いで技術開発と組織運営を両立してきたのか、その軌跡と考え方をたどります。

管理職への移行や、最新技術のキャッチアップの難しさなどから「プログラマ35歳定年説」がささやかれる中、今なおOSSへのコントリビューションを続ける石井が、技術者として開発に向き合う姿勢や、OSSに取り組む意義について語っています。

エンジニアの方はもちろん、OSSや技術コミュニティに関心のある方にもおすすめしたい内容です。

石井がコードを書き続ける理由とは――。ぜひ記事でご覧ください。

▼ 記事はこちら ▼
70歳を超えてなお、OSS活動に情熱を注ぐ。「生涯現役」でコードを書き続ける意義とは？

pgsql-hackersウォッチ（2026年7月）

長田悠吾 (Yugo Nagata) — Fri, 07 Aug 2026 01:15:49 +0000

今回は、PostgreSQL の開発者向けメーリングリストである pgsql-hackers で、2026年7月に行われた議論の中から、筆者が注目した話題を紹介します。網羅的なまとめではなく、筆者が追跡した範囲での内容となります。

エグゼキュータ・プランナ関連

SQL の実行を担当するエグゼキュータにおけるバッチ処理実装に関する進捗がありました。現在の PostgreSQL のエグゼキュータは、テーブルページからタプル（行）を1行ずつ取得して処理しています。しかし、この方式では関数呼び出しなどのオーバーヘッドが大きいという課題があります。一方、ページ内の複数タプルをまとめて取得するバッチ処理に対応できれば、CPU の SIMD （1つの命令で複数のデータを同時に処理する）命令を利用した最適化なども可能となり、大きな性能向上が期待されています。

この提案は2025年から議論が続いていますが、その間にアーキテクチャも変化してきました。当初はバッチ処理用にタプルを格納する「タプルスロット」を複数を用いる設計でしたが、管理コストが課題となり、その後はスロットを1つだけ用いて複数タプルを参照する方式へ変更されました。そして7月には、新しいデータ構造を導入する代わりに既存のタプルスロットへバッチ管理機能を追加する、よりシンプルな設計が提案されています。この実装では、ワークロードによって20〜40%程度の性能向上が報告されています。さらに、別の開発者からは API の変更を伴わない別アプローチも提案されるなど議論が続いています。

同じく性能改善に関する提案として、ブルームフィルタ（Bloom Filter）を利用したハッシュ結合の高速化も議論されました。ハッシュ結合は、結合先テーブルから構築したハッシュ表を利用して結合相手を高速に探す結合アルゴリズムです。また、ブルームフィルタは、集合に要素が含まれていないことを高速に判定できる確率的データ構造です。この性質を利用して、ハッシュ表に結合先が存在しないことが分かるタプルを、ハッシュ結合より前の順スキャンやインデックススキャンの段階で除外することで、処理対象行数を大幅に削減できます。さらに、実行計画の改善やキャッシュ効率の向上、外部キー制約との組み合わせなどについても議論されており、ワークロードによっては1.5倍から最大10倍程度の性能向上が報告されています。複数の開発者が共同でパッチを改善していく形で活発に議論が進められています。

論理レプリケーション

論理レプリケーション関連では、競合（conflict）情報を専用テーブルへ保存する機能に動きがありました。本格的なサポートに向けた基盤として、競合ログテーブルを作成する機能が先行してコミットされています。CREATE SUBSCRIPTION の新しい conflict_log_destination オプションに table または all を指定すると、pg_conflict スキーマ内に pg_conflict_log_ という名前のログテーブルが自動的に作成されるようになりました。

一方で、実際に競合情報をテーブルに書き込む機能については引き続き議論が続いています。現在の設計では、一意性制約違反などで発生した ERROR を一旦捕捉し、競合情報を記録した後に再度エラーを発生させる方式となっています。しかし、このような例外処理によるトランザクション終了方法に対して安全性の懸念が示され、設計の見直しが議論されています。

また、PostgreSQL 19 の新機能であるシーケンス同期について不具合が見つかり、Open Item として議論されました。ALTER SUBSCRIPTION … REFRESH SEQUENCES コマンドは、サブスクライバ側のシーケンス値をパブリッシャ側と同期する機能ですが、シーケンス同期の実行中に再度コマンドが実行されると、新しい要求が反映されない競合状態がありました。一度は同期実行中のコマンド実行を禁止する修正がコミットされましたが、ユーザビリティの観点から見直され、最終的には実行中の同期処理を中断して、新しい要求に基づいて同期をやり直す、という方法で解決されました。

SQL構文関連

SQL 構文に関する話題もいくつかありました。

まず、PostgreSQL 19 でサポート予定だった GROUP BY ALL 構文が見送られることになりました。これは、SELECT 文において集約関数やウィンドウ関数に含まれない項目を自動的に GROUP BY 対象とする便利な構文ですが、ORDER BY USING と組み合わせた場合にセマンティクス上の問題が見つかったため、PostgreSQL 19 への導入は断念され、PostgreSQL 20 以降で改めて検討されることになりました。

また、次期 SQL 標準に採用された INSERT BY NAME 構文の提案も行われました。これは、「INSERT INTO tbl (x, y) BY NAME SELECT 1 AS y, 2 AS x FROM …」のように列の位置ではなく列名を基準に挿入される列の対応付けを行う構文で、Oracle や DuckDB などでも同様の機能がサポートされています。

少し変わった提案として、「FROM tbl SELECT *」のように FROM 句を SELECT 句より前に記述する「FROM ファースト構文」も投稿されました。このパッチは PostgreSQL の開発者向け教育課題として作成されたもので、投稿者自身も本当の動機は「ただ楽しいから（”just for fun”）」と説明しています。しかしその一方で、SQL の記述が簡潔になることや、psql コマンドのタブ補完を改善しやすいこと、DuckDB や ClickHouse など他の DBMS との互換性といった利点も挙げられており、予想以上に盛り上がりを見せた議論となっていました。

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

PostgreSQL – SRA OSS Tech Blog

pgsql-hackersウォッチ（2026年9月）

PostgreSQL 19 で相次いだ機能の差し戻し

TOAST の改善

圧縮プロトコル

UNDO ログエンジン

ブルームフィルタによるハッシュ結合改善

PostgreSQLのデータ型を「なんとなく」で選ばない

1. 文字列型は上限と条件の表し方で選ぶ

1.1. char(n)を選ぶ場面は限られる

1.2. varchar(n)は文字数の上限を型に記せる

1.3. 長さの上限は型か制約で表す

1.4. 保存できる文字列でもB-treeインデックスに入らない場合がある

2. 数値型は必要な正確さと値の範囲で選ぶ

2.1. double precisionは2進数で表せる値しか正確に扱えない

2.2. 金額にはnumeric、個数には整数型を使う

2.3. 新規設計ではmoney型よりnumericを優先する

3. 日付時刻型は保存したい時刻の意味で選ぶ

3.1. 受信した表記を残すなら文字列型を選べる

3.2. timestamp without time zoneは時差を変換しない

3.3. timestamp with time zoneは同じ一瞬を保存する

4. JSON型は原文の保持と検索の必要性で選ぶ

4.1. text、json、jsonbは保存後の用途が異なる

4.2. JSONのキーや値を検索するならjsonbを使う

5. まとめ: 列の用途から型を決める

pgsql-hackersウォッチ（2026年8月）

PostgreSQL 19 リリースにむけて

SSIで相次いで報告された不具合

INSERT SELECT のパラレル化

リカバリのパイプライン化

VACUUMを妨げる要因を可視化する pg_xmin_horizon

PostgreSQL 18.6 に関する技術情報

PostgreSQL 18.4 から 18.6 への変更点

PostgreSQL 17.11 に関する技術情報

PostgreSQL 17.10 から 17.11 への変更点

PostgreSQL 16.15 に関する技術情報

PostgreSQL 16.14 から 16.15 への変更点

PostgreSQL 15.19 に関する技術情報

PostgreSQL 15.18 から 15.19 への変更点

PostgreSQL 14.24 に関する技術情報

PostgreSQL 14.23 から 14.24 への変更点

70歳を超えてなお、OSS活動に情熱を注ぐ。「生涯現役」でコードを書き続ける意義とは？- 石井 達夫インタビュー

pgsql-hackersウォッチ（2026年7月）

エグゼキュータ・プランナ関連

論理レプリケーション

SQL構文関連

1.1. `char(n)`を選ぶ場面は限られる

1.2. `varchar(n)`は文字数の上限を型に記せる

2.1. `double precision`は2進数で表せる値しか正確に扱えない

2.2. 金額には`numeric`、個数には整数型を使う

2.3. 新規設計では`money`型より`numeric`を優先する

3.2. `timestamp without time zone`は時差を変換しない

3.3. `timestamp with time zone`は同じ一瞬を保存する

4.1. `text`、`json`、`jsonb`は保存後の用途が異なる

4.2. JSONのキーや値を検索するなら`jsonb`を使う

70歳を超えてなお、OSS活動に情熱を注ぐ。「生涯現役」でコードを書き続ける意義とは？- 石井達夫インタビュー