PostgreSQL – SRA OSS Tech Blog

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 のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

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 のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

PostgreSQL 19検証報告

データベース技術グループ — Thu, 02 Jul 2026 22:30:13 +0000

2026年秋にリリース予定となっている PostgreSQL 19 の新機能や性能向上、非互換変更点の主要なものについて内容を説明し、動作検証を報告する文書を公開します。インストール手順やコマンド実行手順が記載してあるため、PostgreSQL 19 の新機能を実際に動かしながら確認しようとする方へのガイドブックとしても利用できます。

PostgreSQL 19 の主な強化点は以下の通りです。これらについてレポートで取り扱っています。
なお、2026年 9月リリースの beta4版までで「バイナリpg_dumpall」「プロパティグラフ問合せ」「テンポラルテーブル更新」「パーティションの分割／統合」など、当初の beta1 には含まれていた機能追加が取り下げられました。

性能向上
- 各種プランナ改善
- タプルデフォーム高速化
- SIMD利用拡大
- 外部キー制約検査の高速化
- 基数ソート
SQL機能
- グルーピングの拡張
- COPYコマンドの拡張
- 各種の追加関数
運用管理
- Autovacuumスコア
- 各種モニタリングビューの追加
- ログ出力の拡張
- REPACKコマンド
レプリケーション
- ストリーミングレプリケーションの拡張
- 論理レプリケーションの拡張
拡張モジュール
- pg_plan_advice追加
- pg_stash_advice追加
- pg_stat_statements改善

検証レポート

レポートは以下リンクから参照できます。

PostgreSQL 19 検証レポート(2026年 9月 24日版、PDFファイル、94ページ、2.1MB)

PostgreSQL 19の機能のさらなる詳細はPostgreSQL 19公式ドキュメントを参照してください。

PostgreSQL 19 公式ドキュメント（英語）

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

PostgreSQL であなたの UPDATE が終わらない理由〜トランザクション、ロック、MVCC を実験で理解する〜

正野裕大 (Yuta Masano) — Tue, 30 Jun 2026 05:21:12 +0000

アプリケーションから次のようなSQLを実行したのに、なかなか応答が返ってこないことがあります。

UPDATE accounts SET balance = balance - 100 WHERE id = 1;

こういうときに原因の一つとして早めに確認しておきたいものがロック待ちです。ロック待ちとは、あるトランザクションが更新中の行などを、別のトランザクションが同時に変更しようとして、先のトランザクションが終わるまで待っている状態です。PostgreSQLはデータの矛盾を防ぐため、同じ行を複数の処理が同時に勝手に書き換えられないようにします。そのため、後から実行したUPDATEは、必要なロックを取得できるまで待つことがあります。

本記事では、同じ行へのUPDATEによってロック待ちが起きる状況を作り、どこを確認すれば原因を切り分けられるのかを説明します。

対象読者は、PostgreSQLを使い始めたアプリケーション開発者や運用初心者です。SQLは書けるものの、トランザクション、ロック、MVCC、監視ビューの関係をまだ整理できていない人を想定しています。

実験の前に

この実験では、psqlのセッションを3つ使います。

セッションA:先に行を更新して、ロックを保持する
セッションB:同じ行を更新しようとして待つ
セッションC: PostgreSQLの状態を確認する

ここで、実験に入る前にトランザクションについて簡単に整理します。

トランザクションとは、複数のSQL操作をひとまとまりの処理として扱う仕組みです。たとえば、口座Aから100円を引き、口座Bに100円を足す処理を考えます。この2つの更新は、片方だけの成功は許されません。引き落としだけ成功して、入金が失敗すると、データの整合性が崩れるためです。そこで、PostgreSQLでは、関連するSQLを1つのトランザクションとして扱えます。

BEGINを実行すると、トランザクションが始まります。

BEGIN;

トランザクション内で実行した変更は、COMMITするまで確定しません。

COMMIT;

COMMITは、トランザクション内で行った変更を確定する操作です。COMMIT すると、他のセッションからもその変更が見えるようになります。一方、変更を取り消したい場合はROLLBACKを実行します。

ROLLBACK;

ROLLBACKは、トランザクション内で行った変更を取り消す操作です。ROLLBACKすると、そのトランザクションで実行した更新はなかったことになります。

本記事のロック待ちを理解するうえで重要なのは、次の点です。トランザクション中にUPDATE文の実行が終わっていても、COMMITまたはROLLBACKを実行するまで、トランザクションは終わりません。そして、トランザクションが終わるまで、更新に関係するロックが保持されることがあります。つまり、次のような状態が問題になります。

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- COMMITもROLLBACKもしていない

この状態では、UPDATE 自体は終わっています。しかし、トランザクションはまだ終わっていません。そのため、別のセッションが同じ行を更新しようとすると、先のトランザクションが終わるまで待つことがあります。

本記事では実験を通して、この「トランザクションが終わっていないために、別の更新が待たされる状態」を意図的に作ります。つまり、単に UPDATEを実行するだけでなく、BEGINでトランザクションを開始し、あえて COMMITせずに残す操作が重要になります。

以降の実験では、セッションAがトランザクションを開いたまま行を更新し、セッションBが同じ行を更新しようとして待つ、という流れを何度か使います。

実験の準備

まず、検証用のテーブルを作ります。ここでは、口座残高を表すaccountsテーブルを使います。

-- accountsテーブルを作成
CREATE TABLE accounts (
  id integer PRIMARY KEY
  , owner_name text NOT NULL
  , balance integer NOT NULL
);

-- データを2件登録
INSERT INTO accounts (id, owner_name, balance)
VALUES
  (1, 'alice', 1000),
  (2, 'bob', 2000);

初期状態を確認します。

SELECT * FROM accounts ORDER BY id;
 id | owner_name | balance
----+------------+---------
  1 | alice      |    1000
  2 | bob        |    2000
(2 rows)

以降は各実験を始める前に、セッションAとセッションBで次を実行しておくと安全です。

-- 各実験の前にROLLBACKを実行してトランザクションを終了しておく
-- Session A/B
ROLLBACK;

すでにトランザクションが終わっている場合は、警告が出ることがあります。その場合でも、この実験では問題ありません。

合わせて、セッションAとセッションBのPIDも確認しておきます。

-- セッションA
SELECT pg_backend_pid();
 pg_backend_pid
----------------
             52
(1 row)


-- セッションB
SELECT pg_backend_pid();
 pg_backend_pid
----------------
             57
(1 row)

実験1:同じ行をUPDATEすると片方が待つ

この実験で確認すること

この実験では、同じ行を2つのトランザクションからUPDATEすると、後から実行した UPDATEが待たされることを確認します。ポイントは、先にUPDATEしたセッションがCOMMITするまで、後続の UPDATEが進めないことです。

手順1:セッションAでトランザクションを開始する

まず、セッションAでトランザクションを開始します。

-- Session A
BEGIN;

この時点で、セッションAはトランザクションの中に入ります。まだデータは更新していません。

手順2:セッションAでid = 1の行を更新する

続けて、セッションAでid = 1の行を更新します。

-- Session A
UPDATE accounts SET balance = balance - 100 WHERE id = 1;

このUPDATE自体はすぐに終わります。ただし、まだCOMMITしていません。そのため、セッションA のトランザクションは開いたままです。

ここが重要です。UPDATE文の実行が終わっていても、トランザクションが終わっていなければ、PostgreSQL はその更新に関係するロックを保持し続けます。

手順3:セッションBで同じ行を更新する

次に、セッションBでもトランザクションを開始します。

-- Session B
BEGIN;

そのあと、セッションBで同じid = 1の行を更新します。

-- Session B
UPDATE accounts SET balance = balance - 50 WHERE id = 1;

このUPDATEは応答が返ってきません。アプリケーションから見ると、「UPDATEが終わらない」状態に見えます。

なぜ待つのか

セッションAは、id = 1の行を先に更新しました。しかし、まだCOMMITも ROLLBACKもしていません。この状態で、セッションBが同じ行を更新しようとすると、PostgreSQLはセッションB の更新をすぐには進めません。セッションAの更新が確定するのか、取り消されるのかがまだ分からないからです。そのため、セッションBはセッションA のトランザクションが終わるのを待ちます。この待ちが、ロック待ちです。

この実験で分かったこと

同じ行を同時に更新しようとすると、後から実行したUPDATEが待つことがあります。ただし、画面上で UPDATEが返ってこないだけでは、SQLの処理が重いのか、ロックを待っているのかは分かりません。

次は、PostgreSQLの中でその待ち状態を確認します。

実験2: pg_stat_activityで何を待っているかを確認する

この実験で確認すること

この実験では、待っているセッションが本当にロック待ちなのかを確認します。使うのは、pg_stat_activityです。pg_stat_activity は、PostgreSQLに接続している各セッションの状態を確認できるビューです。

確認するSQL

セッションCから、次のSQLを実行します。

-- Session C
SELECT
  pid
  , state
  , wait_event_type
  , wait_event
  , xact_start
  , query_start
  , query
FROM
  pg_stat_activity
WHERE
  datname = current_database()
  AND pid <> pg_backend_pid()
  AND query LIKE '%UPDATE accounts%'
ORDER BY
  query_start;
 pid |        state        | wait_event_type |  wait_event   |          xact_start           |          query_start          |                           query
-----+---------------------+-----------------+---------------+-------------------------------+-------------------------------+-----------------------------------------------------------
  52 | idle in transaction | Client          | ClientRead    | 2026-06-15 05:57:26.539576+00 | 2026-06-15 05:57:26.541089+00 | UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  57 | active              | Lock            | transactionid | 2026-06-15 05:57:31.885276+00 | 2026-06-15 05:57:31.886839+00 | UPDATE accounts SET balance = balance - 50 WHERE id = 1;
(2 rows)

まず確認する列

ここで最初に確認する列は、次の3つです。

state
wait_event_type
wait_event

stateは、そのセッションの大まかな状態を示します。ここでは、pid = 57のセッションBは state = 'active'になっています。これは、PostgreSQLがそのSQLを処理中として扱っているという意味です。ただし、active
だからといって、CPUを使って計算し続けているとは限りません。何かを待っていても、SQLの実行中であれば
activeと表示されることがあります。

そこで、wait_event_typeとwait_eventを合わせて確認します。

結果の読み方

セッションBの行を確認すると、次のようになっています。

wait_event_type = Lock
wait_event      = transactionid

wait_event_type = Lockは、ロックを待っていることを示します。wait_event = transactionid は、別のトランザクションが終わるのを待っていることを示します。この例では、セッションBがセッションAのトランザクション終了を待っています。

つまり、セッションBのUPDATEは、検索や計算に時間がかかっているのではありません。ロック待ちで止まっています。

この実験で分かったこと

UPDATEが返ってこないときは、まずpg_stat_activityを確認します。特に、state
だけで判断しないことが重要です。wait_event_typeと
wait_eventを合わせて確認すると、そのセッションが何を待っているのかを確認できます。

次は、どのセッションが待たせているのかを確認します。

実験3: pg_blocking_pids()で待たせている相手を探す

この実験で確認すること

この実験では、待っているセッションを止めている相手を特定します。待っている側を、ここではウェイターと呼びます。待たせている側を、ここではブロッカーと呼びます。

PostgreSQLでは、pg_blocking_pids()を使うと、当該PIDのブロッカーPIDを確認できます。

確認するSQL

セッションCで次のSQLを実行します。pg_blocking_pids()は引数に指定したPIDのブロッカーPIDの配列を返します。

-- Session C
WITH activity AS (
  SELECT
    pid
    , state
    , wait_event_type
    , wait_event
    , pg_blocking_pids(pid) AS blocking_pids
    , query
  FROM
    pg_stat_activity
  WHERE
    datname = current_database()
    AND pid <> pg_backend_pid()
)
SELECT
  *
FROM
  activity
WHERE
  query LIKE '%UPDATE accounts%'
ORDER BY
  pid;
 pid |        state        | wait_event_type |  wait_event   | blocking_pids |                           query
-----+---------------------+-----------------+---------------+---------------+-----------------------------------------------------------
  57 | active              | Lock            | transactionid | {52}          | UPDATE accounts SET balance = balance - 50 WHERE id = 1;
  52 | idle in transaction | Client          | ClientRead    | {}            | UPDATE accounts SET balance = balance - 100 WHERE id = 1;

結果の読み方

pid = 57の行を確認すると、blocking_pidsが{52}になっています。これは、pid = 57 のセッションが、pid = 52のセッションで待たされているという意味です。

この例では、次の関係になります。

ウェイター（待っている側）:     pid = 57
ブロッカー（待たせている側）:   pid = 52

つまり、pid = 57のSQLだけを確認しても原因は分かりません。次に確認すべきなのは、ブロッカーのpid = 52の状態です。

実験4: idle in transactionはロックを保持し得る状態

この実験で確認すること

この実験では、idle in transactionの意味を確認します。idle in transactionは、トランザクションの中にいるが、現在はSQL を実行していない状態です。何もしていないように見えても、トランザクションが終わっていなければ、ロックを保持していることがあります。

状況の確認

ここまでの状態では、セッションAがid = 1の行を更新し、まだCOMMITしていません。セッションB は、同じ行を更新しようとして待っています。

セッションCから次のSQLを実行します。実験3のSQLに表示列(xact_start, state_change)を追加しています。

-- Session C
WITH activity AS (
  SELECT
    pid
    , state
    , wait_event_type
    , wait_event
    , pg_blocking_pids(pid) AS blocking_pids
    , xact_start
    , state_change
    , query
  FROM
    pg_stat_activity
  WHERE
    datname = current_database()
    AND pid <> pg_backend_pid()
)
SELECT
  *
FROM
  activity
WHERE
  query LIKE '%UPDATE accounts%'
ORDER BY
  xact_start NULLS LAST;
 pid |        state        | wait_event_type |  wait_event   | blocking_pids |          xact_start           |         state_change          |                           query
-----+---------------------+-----------------+---------------+---------------+-------------------------------+-------------------------------+-----------------------------------------------------------
  52 | idle in transaction | Client          | ClientRead    | {}            | 2026-06-15 05:57:26.539576+00 | 2026-06-15 05:57:26.542127+00 | UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  57 | active              | Lock            | transactionid | {52}          | 2026-06-15 05:57:31.885276+00 | 2026-06-15 05:57:31.886842+00 | UPDATE accounts SET balance = balance - 50 WHERE id = 1;
(2 rows)

結果の読み方

pid = 52のセッションは、state = 'idle in transaction'になっています。

これは、次の状態を意味します。

トランザクションはまだ開いている
ただし、現在はSQLを実行していない

また、この行ではwait_event_type = Client、wait_event = ClientReadになっています。これは、PostgreSQL がクライアントから次の命令を待っていることを示します。つまり、セッションAはデータベース内部でロックを待っているのではなく、クライアント側から次の SQL、COMMIT、またはROLLBACKが送られるのを待っている状態です。

この状態でも、セッションAはロックを解放していません。ロックは、トランザクションがCOMMITまたは ROLLBACKで終わるまで保持されます。そのため、セッションBは待ち続けます。

なぜ問題になりやすいのか

idle in transactionは、アプリケーションの作りによって長引くことがあります。

たとえば、次のような処理です。

トランザクションを開始したあとに、外部APIの応答を待つ
トランザクションを開始したあとに、ユーザー入力を待つ
例外が発生したのに、ROLLBACKしないまま接続を残す

これらは、ロックを保持したまま待ち時間を伸ばす原因になります。

実務で確認する列

実務でidle in transactionを見つけたときは、すぐにセッションを終了する前に、まず次の列を確認します。

xact_start
state_change
query
application_name
client_addr

特に
xact_start
が古い場合は、長時間トランザクションが開いたままになっている可能性があります。ただし、セッションを強制終了すると、アプリケーション側ではエラーになります。注文更新や残高更新の途中であれば、業務処理にも影響します。そのため、まずはどのアプリケーション、どの接続元、どの処理がトランザクションを開いたままにしたのかを特定することが重要です。

timeout設定について

idle in transactionを長時間残したくない場合は、idle_in_transaction_session_timeout を使う方法もあります。この設定は、トランザクション内で何もしていないセッションを、指定時間後に切断します。ただし、切断された側のアプリケーションにはエラーとして見えます。本番環境で使う場合は、事前に影響を確認する必要があります。

この実験で分かったこと

idle in transaction
は、何もしていない安全な状態とは限りません。トランザクションが終わっていなければ、ロックを保持し続けることがあります。ロック待ちを調べるときは、待っている側だけでなく、待たせている側の
stateとxact_startを確認します。

次は、通常のロック待ちとデッドロックの違いを確認します。

実験5:通常のロック待ちとデッドロックは違う

この実験で確認すること

ここまでの実験では、セッションBがセッションAを一方的に待っていました。この場合、セッションAがCOMMITまたは ROLLBACKすれば、セッションBは進めます。これは通常のロック待ちです。

一方で、デッドロックは違います。デッドロックは、複数のトランザクションが互いに相手を待ってしまい、どちらも先へ進めなくなる状態です。

実験前の準備

セッションAとセッションBの両方でROLLBACKを実行し、前の実験の状態を終わらせます。

-- Session A / Session B
ROLLBACK;

手順1:セッションAがid = 1を更新する

-- Session A
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;

セッションAは、id = 1の行を更新します。まだCOMMITはしません。

手順2:セッションBがid = 2を更新する

-- Session B
BEGIN;
UPDATE accounts SET balance = balance - 50 WHERE id = 2;

セッションBは、id = 2の行を更新します。こちらも、まだCOMMITはしません。

この時点では、セッションAとBは別々の行を更新しているため、互いに待っていません。

手順3:セッションAがid = 2を更新しようとする

次に、セッションAがid = 2の行を更新しようとします。

-- Session A
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

id = 2は、すでにセッションBが更新しています。そのため、セッションAはセッションBのトランザクション終了を待ちます。

この時点では、まだデッドロックではありません。セッションAが、セッションBを一方的に待っているだけです。

手順4:セッションBがid = 1を更新しようとする

最後に、セッションBがid = 1の行を更新しようとします。

-- Session B
UPDATE accounts SET balance = balance + 50 WHERE id = 1;

id = 1は、すでにセッションAが更新しています。そのため、セッションBはセッションAのトランザクション終了を待ちます。

これで、次の状態になります。

セッションAは、セッションBを待っている
セッションBは、セッションAを待っている

これがデッドロックです。

デッドロック時のエラー

PostgreSQLはデッドロックを検出すると、どちらか一方のトランザクションを中止します。

エラーの例です。

ERROR:  deadlock detected
DETAIL:  Process 57 waits for ShareLock on transaction 2317; blocked by process 52.
Process 52 waits for ShareLock on transaction 2318; blocked by process 57.
HINT:  See server log for query details.
CONTEXT:  while updating tuple (0,1) in relation "accounts"

このエラーが出たあとは、エラーになったトランザクションはそのまま続けられません。次の実験へ進む前に、セッションAとBの両方で ROLLBACKを実行します。

-- Session A / Session B
ROLLBACK;

通常のロック待ちとの違い

通常のロック待ちは、ブロッカー側が終われば解消します。一方、デッドロックでは、互いに相手を待っています。そのままではどちらも進めません。

そのため、PostgreSQL はどちらか一方を中止して、待ち続ける状態を解消します。どちらのトランザクションが中止されるかをアプリケーション側で決め打ちしてはいけません。デッドロックで失敗した場合は、失敗したSQLだけを再実行するのではなく、トランザクション全体を最初からやり直す必要があります。

デッドロックを減らす考え方

複数行を更新する処理では、更新する順序をそろえることが基本です。たとえば、ある処理はid = 1のあとに id = 2を更新し、別の処理はid = 2のあとにid = 1を更新すると、デッドロックが起きやすくなります。

更新順序を決められるなら、常に同じ順序で更新します。たとえば、常にidの小さい順に更新するなどが考えられます。

lock_timeoutについて

通常のロック待ちが長すぎる場合の安全装置として、lock_timeoutがあります。

SET lock_timeout = '3s';

lock_timeoutは、ロックを取得できない状態が指定時間を超えたときに、そのSQL をエラーにします。これは、デッドロックを検出する設定ではありません。ロック待ちが長くなりすぎたSQLを失敗させるための設定です。また、statement_timeout との関係にも注意が必要です。statement_timeoutは、SQL全体の実行時間に対する制限です。lock_timeout
は、ロック取得待ちに対する制限です。statement_timeoutが
lock_timeout以下に設定されていると、ロック待ち専用のエラーより先に statement_timeoutが発生します。ロック待ちを切り分けたい場合は、両者の値を分けて設定します。

この実験で分かったこと

通常のロック待ちは、ブロッカー側が終われば解消します。一方、デッドロックは、互いに相手を待つため、そのままでは解消しません。PostgreSQL はどちらか一方のトランザクションを中止します。アプリケーションでは、デッドロックやロックタイムアウトで失敗した場合に、トランザクション全体をやり直せるようにしておく必要があります。

次は、書き込みではなく、読み取りがどう見えるのかを確認します。

実験6:通常のSELECTは止まらない

この実験で確認すること

ここまでの実験では、UPDATE同士の待ちを見てきました。では、あるセッションが行を更新してまだ COMMITしていないとき、別のセッションがその行をSELECTするとどうなるのでしょうか。

FOR UPDATEなどを付けない通常のSELECTは、多くの場合、更新中の行を待たずに結果を返します。これは、PostgreSQL が、読み取り時点で見えてよい行の版を選んで読みます。この仕組みをMVCC (Multi-Version Concurrency Control) と呼びます。日本語では、多版型同時実行制御と呼ばれます。

以降では、「見えてよい行の版を読む仕組み」を簡単に説明します。

実験前の準備

セッションAとセッションBの両方でROLLBACKを実行します。

-- Session A / Session B
ROLLBACK;

手順1:セッションAでid = 1を更新する

まず、更新前の値を確認します。

-- Session A
SELECT id, owner_name, balance FROM accounts WHERE id = 1;
 id | owner_name | balance
----+------------+---------
  1 | alice      |    1000
(1 row)

セッションAでトランザクションを開始します。

-- Session A
BEGIN;

次に、id = 1の残高を999に更新します。

-- Session A
UPDATE accounts SET balance = 999 WHERE id = 1;

ここでも、まだCOMMITはしません。つまり、セッションAの変更はまだ確定していません。

手順2:セッションBで通常のSELECTを実行する

セッションBから、BEGINでトランザクションを開始して、同じ行を読み取ります。

-- Session B
BEGIN;
SELECT id, owner_name, balance FROM accounts WHERE id = 1;
 id | owner_name | balance
----+------------+---------
  1 | alice      |    1000
(1 row)

セッションBのSELECTはロック待ちになりません。また、セッションAが更新したbalance = 999も見えません。セッションB からは、最後にCOMMIT済みの値である1000が見えます。

なぜ止まらないのか

セッションAのUPDATEは、まだCOMMITされていません。もし、セッションBから未コミットの 999が見えてしまうと、あとからセッションAが ROLLBACKしたときに困ります。存在しなかった変更を読んだことになるからです。そのため、PostgreSQLは通常の SELECTに対して、未コミットの変更を見せません。代わりに、読み取り時点で見えてよい、古い行の版を返します。

PostgreSQLのデフォルト設定では、各SQLを実行するたびに、その時点で COMMIT済みのデータを読みます。この設定を、トランザクション分離レベルの
Read Committed
と呼びます。トランザクション分離レベルとは、あるトランザクションから、他のトランザクションの変更をどこまで見せるかを決める設定です。

SELECT FOR UPDATEは待つ

ただし、すべてのSELECTが待たないわけではありません。SELECT FOR UPDATE は、読み取った行をあとで更新する前提でロックしようとします。

-- Session B
SELECT id, owner_name, balance FROM accounts WHERE id = 1 FOR UPDATE;

この場合は、セッションAのトランザクション終了を待ちます。通常の SELECTは、見えてよい行の版を読めるため、止まらないことが多いです。一方、SELECT FOR UPDATE は行をロックしようとするため、更新中の行と競合します。

この実験で分かったこと

PostgreSQLでは、未コミットの変更は通常のSELECTから見えません。この実験では、通常の SELECTは、更新中の行を待たずに、見えてよい行の版を読みます。一方、SELECT FOR UPDATE は行をロックしようとするため、対象の行が他のトランザクションで更新中の場合は、待つことがあります。

次は、ロック待ちしていたUPDATEが再開したときに、どの条件で更新されるのかを確認します。

実験7: UPDATEは待ったあとにWHEREを再確認する

この実験で確認すること

この実験では、ロック待ちしていたUPDATEが再開したときの動きを確認します。重要なのは、ロック待ちしていた UPDATEが、ロック待ちの前に見えていた古い行をそのまま更新するわけではない、という点です。

PostgreSQLのデフォルト設定では、ロック待ちが終わったあと、更新後の行に対してWHERE条件をもう一度確認します。

実験前の準備

セッションAとセッションBの両方でROLLBACKを実行します。

-- Session A / Session B
ROLLBACK;

手順1:セッションAがid = 1を更新する

まず、更新前の値を確認します。

-- Session A
SELECT id, owner_name, balance FROM accounts WHERE id = 1;
 id | owner_name | balance
----+------------+---------
  1 | alice      |    1000
(1 row)

セッションAでトランザクションを開始します。

-- Session A
BEGIN;

次に、id = 1の残高を1000にします。ここでは、同じ行を更新中の状態にするため、id = 1の残高を 1000に更新します。値は変わりませんが、UPDATEは実行されるため、この行はセッションA のトランザクションが終わるまで、他の更新と競合する状態になります。

-- Session A
UPDATE accounts SET balance = 1000 WHERE id = 1;

まだCOMMITはしません。

手順2:セッションBが条件付きUPDATEを実行する

セッションBでトランザクションを開始します。

-- Session B
BEGIN;

次に、残高が500以上の場合だけ、50減らすUPDATEを実行します。

-- Session B
UPDATE accounts
SET balance = balance - 50
WHERE id = 1
  AND balance >= 500
RETURNING *;

このUPDATEは待ちます。セッションAが同じid = 1の行を更新して、まだCOMMITしていないからです。

手順3:セッションAが残高を400にしてCOMMITする

セッションBが待っている間に、セッションAで同じ行の残高を400にします。

-- Session A
UPDATE accounts SET balance = 400 WHERE id = 1;

そのあと、セッションAのトランザクションを確定します。

-- Session A
COMMIT;

これで、セッションBの待ちが解除されます。

セッションBの結果

セッションBのUPDATEは再開します。ただし、セッションB は、ロック待ちの前に見えていた行をそのまま更新するわけではありません。セッションAがCOMMITした後の行に対して、WHERE 条件をもう一度確認します。

この時点で、id = 1のbalanceは400です。セッションBの条件は次のとおりでした。

WHERE id = 1
  AND balance >= 500

balance = 400なので、balance >= 500は成り立ちません。そのため、セッションBのUPDATEは0 行更新になります。

 id | owner_name | balance
----+------------+---------
(0 rows)

この動きが重要な理由

アプリケーションで避けたいのは、先にSELECTで値を確認し、その結果だけを前提にして、あとから無条件に UPDATEする書き方です。

BEGIN;
SELECT balance FROM accounts WHERE id = 1;

UPDATE accounts
SET balance = balance - 500
WHERE id = 1;
COMMIT;

この書き方では、SELECTしてから UPDATEするまでの間に、別のトランザクションが同じ行を更新する可能性があります。つまり、アプリケーションが事前に見た残高と、実際に UPDATEする時点の残高が同じとは限りません。

残高不足を防ぎたいなら、更新してよい条件をUPDATEのWHEREに入れます。

BEGIN;
UPDATE accounts
SET balance = balance - 500
WHERE id = 1
  AND balance >= 500;
COMMIT;

このSQLは、UPDATEする時点のbalanceが500以上の場合だけ、残高を減らします。1行更新されれば成功です。0 行なら、残高不足として扱えます。

分離レベルを上げる場合

トランザクション分離レベルをRepeatable Readや
Serializable
に上げる方法もあります。ただし、その場合は競合する更新を検出して、トランザクションがエラーになることがあります。分離レベルを上げる場合は、失敗した SQLだけでなく、トランザクション全体を最初から再試行できる設計が必要です。

この実験で分かったこと

ロック待ちしていたUPDATEは、ロック待ちが終わったあとに WHERE条件を再確認します。そのため、並行更新に強い処理にしたい場合は、事前のSELECT結果だけに頼らず、UPDATE のWHEREに更新条件を入れることが重要です。

実務での切り分け手順

ここまでの実験で、ロック待ちの見方を段階的に確認しました。実務でも、まず見るところは同じです。

UPDATEが返ってこないときは、最初にpg_stat_activityを確認します。ここで見るのは、待っているセッションの state、wait_event_type、wait_eventです。wait_event_typeが Lockであれば、そのセッションはロック待ちしている可能性が高いです。

次に、pg_blocking_pids()を使って、そのセッションを待たせているPIDを確認します。待っているSQL だけを見ても、原因は分かりません。重要なのは、待っている（ウェイター）側と、待たせている（ブロッカー）側を分けて見ることです。

待たせている（ブロッカー）側のPIDが分かったら、もう一度
pg_stat_activity
を確認します。特に、state、xact_start、state_change、application_name、client_addr、query を見ます。state = 'idle in transaction'で、xact_start が古い場合は、トランザクションを開いたまま放置している可能性があります。ただし、すぐにセッションを終了すればよいとは限りません。まず、どのアプリケーション、どの接続元、どの処理がトランザクションを開いたままにしているのかを確認します。

再発を減らす設計

ロック待ちそのものは、PostgreSQLの異常ではありません。同じ行を同時に更新しようとすれば、待つことがあります。

問題になるのは、待たせているトランザクションが長く残り、他の処理を止め続けることです。

ここでは、再発を減らすための基本的な考え方を整理します。

トランザクションを短くする

更新や明示的なロックを取得したあとは、できるだけ早くCOMMITまたはROLLBACKします。トランザクション中に外部API 呼び出し、ユーザー入力待ち、重いファイル処理などを入れると、ロックを持ったまま待ち時間が伸びます。また、例外が発生した場合は、必ず ROLLBACKします。

更新順序をそろえる

複数行を更新する処理では、更新順序をそろえます。ある処理はid = 1のあとにid = 2を更新し、別の処理は id = 2のあとにid = 1を更新すると、デッドロックが起きやすくなります。順序を決められるなら、常に同じ順序で更新します。

lock_timeoutを検討する

長時間待たせたくない処理では、lock_timeoutを検討します。

SET lock_timeout = '3s';

これは、ロックを取得できない状態が指定時間を超えたら、そのSQL をエラーにする設定です。ただし、エラーになった場合にアプリケーション側でどう扱うかを決めておく必要があります。

log_lock_waitsを確認する

本番環境では、log_lock_waitsも確認対象になります。log_lock_waitsを有効にすると、deadlock_timeout を超えたロック待ちをログに出せます。常にpg_stat_activityを手動で見続けるのではなく、ログから、どのSQL がいつ、どの程度ロック待ちしたのかを後から確認できます。

アプリケーションで再試行を考える

デッドロックやロックタイムアウトで失敗した場合、失敗したSQL だけを途中から再実行するのは危険です。基本は、トランザクション全体を最初からやり直します。ただし、無制限に再試行し続けるのではなく、再試行回数には上限を設けます。

UPDATEのWHEREに条件を入れる

並行更新で条件が変わる処理では、事前のSELECT結果だけに頼らないようにします。たとえば、残高が足りる場合だけ引き落とすなら、条件を UPDATEのWHEREに入れます。

BEGIN;
UPDATE accounts
SET balance = balance - 500
WHERE id = 1
  AND balance >= 500;
COMMIT;

以上、UPDATEが返ってこない状況を、同じ行への更新、ロック待ち、待たせているトランザクション、通常の SELECTの見え方に分けて確認しました。

ロック待ちそのものは、PostgreSQL の異常ではありません。同じデータを同時に矛盾なく更新するために必要な動きです。問題になるのは、ロックを持ったトランザクションが長く残り、他の処理を止め続けることです。

UPDATEが返ってこないときは、待っているSQLだけを見るのではなく、PostgreSQLの中で何を待っているのかを確認します。そのうえで、pg_blocking_pids() を使い、待たせている相手を探します。

待っている側と、待たせている側を分けて見る。この見方を持っておくと、ロック待ちを原因の一つとして落ち着いて切り分けられます。

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

ロジカルレプリケーションによるメジャーバージョンアップ手順

越野太基 (Taiki Koshino) — Thu, 18 Jun 2026 02:17:26 +0000

PostgreSQL のメジャーバージョンアップにはいくつかの手法がありますが、本記事ではその中でもロジカルレプリケーションを利用した方法を紹介します。ロジカルレプリケーションを用いることで、新旧バージョンのデータベースを並行稼働させながらデータを同期できるため、切り替え時のダウンタイムを最小限に抑えたアップグレードが可能です。その具体的な手順とあわせて、実施時に注意すべきポイントについて解説します。

なお、PostgreSQLのロジカルレプリケーション自体についての基本的な解説は、以下の記事を参考にしてください。

ロジカルレプリケーションによるアップグレードの概要

ロジカルレプリケーションを利用することで、異なるメジャーバージョン間でデータを同期しながら新しい環境を構築することが可能です。新旧データベースを並行稼働させ、最終的に接続先を切り替えることで、数秒程度のダウンタイムで移行を実現できます。

上記イメージはロジカルレプリケーションを用いたバージョンアップのアーキテクチャイメージです。

対応バージョンとしては、Publisher（旧バージョンのデータベース）は PostgreSQL 10 以上である必要があります。例えば PostgreSQL 13 から 16 へのアップグレードは可能ですが、9.6 からの移行には対応していません。

全体の流れは以下のとおりです。これらの手順について詳しく解説します。
ロジカルレプリケーションはデータベース単位で構成されるため、各データベースごとに個別に設定・同期を行います。

旧バージョンのデータベースを稼働させたまま、新バージョンのデータベースクラスタを initdb で構築し起動する

以下の手順を、対象となるすべてのデータベースに対して実施します。

旧バージョンの各データベースで全テーブルを対象としたパブリケーションを作成
新バージョン側に移行するデータベースを作成
旧バージョンの各データベースから pg_dump -s でスキーマ定義の SQL を取得して新バージョンの各データベースにリストア
新バージョンの各データベースでサブスクリプションを作成

すべてのデータベースでサブスクリプション作成および同期が完了した後、
以下の作業を実施します。

旧バージョンのデータベースクラスタへの更新処理を停止する
各データベースで pg_stat_subscription を確認し、LSN の一致を確認する
同期完了後、シーケンス位置やラージオブジェクトなどロジカルレプリケーションで同期されないデータを各データベースで手動同期する
アプリケーションの接続先を切り替える

ロジカルレプリケーションによるアップグレードの注意点

ロジカルレプリケーションでは、テーブルの行データに対する変更がサブスクライバへ同期されます。一方で、行データ以外の更新情報は同期されません。

そのため、以下のようなオブジェクトは別途作成または移行する必要があります。

テーブルやスキーマの定義
ビューおよびマテリアライズドビューの定義
パーティションテーブルや外部テーブルの定義
シーケンスの現在値
ラージオブジェクト
拡張機能
UNLOGGED TABLE
ロール

特にスキーマ、テーブル定義についてはロジカルレプリケーションでは同期されず、サブスクライバ側で定義されていない状態でロジカルレプリケーションを行うと伝播先のテーブルがないとしてレプリケーションに失敗します。よってスキーマ、テーブル定義については pg_dump を用いて定義の SQL を取得して新バージョンのデータベースで実行するなどして事前にリストアしておく必要があります。今回紹介する手順では pg_dump に -s オプションを付与して実行し、各 DDL を取得してロジカルレプリケーション前に新バージョンのデータベースで実行するようにします。

またその他にも拡張機能やロールなどもロジカルレプリケーションでレプリケーションされないため必要に応じて別途リストアする必要があります。

アップグレード手順

旧バージョンデータベースのロジカルレプリケーションのセットアップ

今回使用する環境は以下の通りで、PostgreSQL 14 から PostgreSQL 18 に移行します。

領域	パス
旧バージョンのデータベースクラスタ	/var/lib/pgsql/14
新バージョンのデータベースクラスタ	/var/lib/pgsql/18
旧バージョンのPostgreSQLコマンドパス	/usr/local/pgsql14/bin
新バージョンのPostgreSQLコマンドパス	/usr/local/pgsql18/bin

まず最初に旧バージョンのデータベースを稼働させたまま新データベースクラスタを構築し、旧バージョンでロジカルレプリケーションの有効化とパブリケーションを作成を行います。

#新しいバージョンのデータベースクラスタを作成して起動
$ /usr/local/pgsql18/bin/initdb -D /var/lib/pgsql/18
[postgres@server1 ~]$ /usr/local/pgsql18/bin/pg_ctl -D /var/lib/pgsql/18 -o "-p 5433" start

ロジカルレプリケーションではパブリッシャの wal_level は logical である必要があります。ロジカルレプリケーションとは別にストリーミングレプリケーションを利用している場合は既に使用しているレプリケーションスロット数に今回のロジカルレプリケーション用に必要なスロット数を加えた値を max_replication_slots に設定してください。複数のデータベースを新バージョンへ移行する場合は、旧バージョン側でデータベースの数分レプリケーションスロットを作成しますのでその分のスロット数も max_replication_slots に乗じてください。

またパブリッシャから WAL 情報を送信する walsender プロセスの上限を決定する max_wal_senders もレプリケーション接続される数を超えるように設定してください。設定後にサーバーを再起動して設定を反映します。

# ロジカルレプリケーションを利用できるよう旧バージョンの postgresql.conf を編集して再起動
[postgres@server1 ~]$ vi /var/lib/pgsql/14/postgresql.conf
wal_level = logical
#max_replication_slots = 10
#max_wal_senders = 10
[postgres@server1 ~]$ /usr/local/pgsql14/bin/pg_ctl -D /var/lib/pgsql/14 -o "-p 5432" restart

再起動後、今回のレプリケーションの動作確認用に、旧バージョンのデータベースに users テーブルを作成します。

[postgres@server1 ~]$ /usr/local/pgsql14/bin/psql -p 5432
psql (14.22)
Type "help" for help.

postgres=# CREATE TABLE users (
id SERIAL PRIMARY KEY,
name TEXT
);
CREATE TABLE
postgres=# INSERT INTO users(name) VALUES ('taro');
INSERT 0 1
postgres=# INSERT INTO users(name) VALUES ('jiro');
INSERT 0 1
postgres=# \d
List of relations
Schema | Name         | Type     | Owner
-------+--------------+----------+----------
public |    users     |  table   | postgres
public | users_id_seq | sequence | postgres
(2 rows)

postgres=# SELECT * FROM users;
id | name
---+------
1  | taro
2  | jiro
(2 rows)

その後パブリケーションを作成します。パブリケーションの対象を FOR ALL TABLES とし、すべてのテーブルを同期対象にするようにします。複数データベースを移行する場合はデータベースごとにパブリケーションを作成してください。

postgres=# CREATE PUBLICATION pub_all FOR ALL TABLES;

# 他データベースも必要であれば同様に作成する
db2=# CREATE PUBLICATION pub_all_2 FOR ALL TABLES;

旧バージョンデータベースの pg_hba.conf 設定

旧バージョン側 pg_hba.conf には、新バージョンデータベースからのレプリケーション接続を許可する設定を追加します。論理レプリケーションでは、サブスクライバからパブリッシャへ接続してデータ取得を行うため、replication 権限を持つ接続許可が必要です。

# サブスクライバからのレプリケーション接続を許可
host replication postgres 0.0.0.0/0 trust

新バージョンに移行するデータベースとスキーマを移行

ロジカルレプリケーションではテーブルデータのみが同期対象となり、ロール、データベース、スキーマ定義などは自動的には同期されません。そのため、ロジカルレプリケーションを開始する前にこれらを新バージョン側へ移行しておく必要があります。

まずはロールやテーブルスペースなどのグローバルオブジェクトを移行します。

# グローバルオブジェクトをダンプ・リストア
[postgres@server1 ~]$ /usr/local/pgsql18/bin/pg_dumpall -g | /usr/local/pgsql18/bin/psql -p 5433

次に新バージョンの各データベースに pg_dump -s -C でスキーマ定義を旧バージョンのデータベースからリストアしたのちにサブスクリプションを作成してテーブルデータを同期します。注意点でも述べた通りロジカルレプリケーションではスキーマやテーブル定義といった DDL までは同期されないので別途に pg_dump によって手動でリストアしておく必要があります。

pg_dump, psql は -d で対象データベースを指定します。データベースを複数移行する場合はデータベースごとに pg_dump, psql を実施し、-d で指定するデータベースを変更してください。

pg_dump の結果を psql で実行した後に \d でリレーションを確認すると旧バージョンで作成した users テーブルやシーケンスがコピーされていることが分かります。

[postgres@server1 ~]$ /usr/local/pgsql18/bin/pg_dump -p 5432 -s -C -d postgres |  /usr/local/pgsql18/bin/psql -p 5433
[postgres@server1 ~]$ /usr/local/pgsql18/bin/psql -p 5433
psql (18.3)
Type "help" for help.
postgres=# \d
List of relations
Schema | Name         | Type     | Owner
-------+--------------+----------+----------
public | users        |  table   | postgres
public | users_id_seq | sequence | postgres
(2 rows)

新バージョンの各データベースでのサブスクリプションのセットアップ

次に旧バージョンの各データベースで作成したパブリケーションに対してサブスクリプションを作成します。サブスクリプションは移行するデータベースごとに作成し、CONNECTION の引数内の dbname や PUBLICATION でしているパブリケーション名は適宜変更してください。

その後テーブルの中身を SELECT するとテーブルデータが同期されていることが分かります。

postgres=# CREATE SUBSCRIPTION sub_all
CONNECTION 'host=localhost port=5432 dbname=postgres'
PUBLICATION pub_all;
NOTICE: created replication slot "sub_all" on publisher
CREATE SUBSCRIPTION
postgres=# SELECT * FROM users;
id | name
---+------
1  | taro
2  | jiro
(2 rows)

旧バージョンの各データベースへの更新を停止して同期の完了を待ち、シーケンス位置を揃える

サブスクリプション作成後、旧バージョンの各データベースへの更新を一時停止します。これによって旧バージョン側の LSN を止め、新バージョン側の LSN が追い付ける状態にします。

更新処理停止後、新バージョン各データベースごとに pg_stat_subscription 内を確認して received_lsn と latest_end_lsn が一致していることが確認できれば同期は完了です。received_lsn はパブリッシャから受け取った WAL 位置を、latest_end_lsn はパブリッシャから受け取った WAL をサブスクライバで適用し、その完了をパブリッシャに報告した位置を示します。

postgres=# SELECT * FROM pg_stat_subscription;
-[ RECORD 1 ]---------+------------------------------
subid                 | 16395
subname               | sub_all
worker_type           | apply
pid                   | 3457
leader_pid            |
relid                 |
received_lsn          | 0/1718270
last_msg_send_time    | 2026-04-27 15:33:53.961503+09
last_msg_receipt_time | 2026-04-27 15:33:53.961586+09
latest_end_lsn        | 0/1718270
latest_end_time       | 2026-04-27 15:33:53.961503+09

その後シーケンス位置を手動で同期します。ロジカルレプリケーションではシーケンス位置はレプリケーションされず、また pg_dump -s でもシーケンス位置を設定する SQL は出力されません。そのためシーケンスの位置は手動で揃える必要があります。

新バージョン側でシーケンスを調整する前の時点ではシーケンスの開始値が初期値である 1 のままとなっています。そのため、新バージョンのデータベース側で INSERT を実行すると、すでにテーブルに存在する id=1 の行と重複し、ユニーク制約違反が発生します。

postgres=# SELECT currval('users_id_seq');
ERROR: currval of sequence "users_id_seq" is not yet defined in this session
postgres=# INSERT INTO users(name) VALUES ('saburo');
ERROR: duplicate key value violates unique constraint "users_pkey"
DETAIL: Key (id)=(1) already exists.

シーケンス位置は pg_dump の出力に含まれる setval の SQL を新バージョン側の各データベースで実行して反映します。-d オプションの引数もデータベースごとに適宜変更してください。

[postgres@server1 ~]$ pg_dump -p 5432 -d postgres > dump.sql
[postgres@server1 ~]$ cat dump.sql
(省略)

--
-- Name: users_id_seq; Type: SEQUENCE SET; Schema: public; Owner: postgres
--

SELECT pg_catalog.setval('public.users_id_seq', 2, true);

[postgres@server1 ~]$ /usr/local/pgsql18/bin/psql -p 5433
psql (18.3)
Type "help" for help.
postgres=# SELECT pg_catalog.setval('public.users_id_seq', 2, true);

その他ラージオブジェクトや拡張機能など、WAL 書き出されずロジカルレプリケーションの対象外となっているものについても手動で同期を行います。これによって旧バージョンと新バージョンの同期は完了です。

同期完了後アプリケーションの接続先を新バージョンのデータベースに切り替える

すべてのデータベースの同期完了後にアプリケーションの接続先を切り替えます。

新バージョンの各データベースのサブスクリプションを無効化、マテリアライズドビューをすべて REFRESH したのちに、新バージョン側のpg_hba.conf にアプリケーションからの接続の認証情報を記述し、アプリケーションの接続先を切り替えればアップグレードは完了です。

# サブスクリプションを無効化
postgres=# ALTER SUBSCRIPTION sub_all DISABLE;

# マテリアライズドビューがあれば REFRESH
postgres=# REFRESH MATERIALIZED VIEW my_mv;

# pg_hba.conf にアプリケーションからの接続の認証情報を記載(環境に合わせて適宜記載)
host all application 0.0.0.0/0 trust

まとめ

ロジカルレプリケーションを用いた PostgreSQL のメジャーアップグレードは、適切に設計・運用することで、サービス停止時間を最小限に抑えた安全な移行を実現できます。ただし、データ以外の要素は自動的には同期されないため、スキーマ、シーケンス位置などを含めた包括的な準備が不可欠です。

事前検証と十分な計画を行うことで、本番環境においても安定したアップグレードを実施できます。

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

PostgreSQL 18.4 に関する技術情報

データベース技術グループ — Thu, 28 May 2026 03:11:36 +0000

このリリースは 18.3 からの修正リリース（2026年 5月 14日リリース）です。
18.X からのアップデートではダンプ、リストアは不要です。
しかしながら、18.2 よりも前のバージョンからアップデートする場合には、18.2のリリース情報も参照してください。

PostgreSQL 18.3 から 18.4 への変更点

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

スタートアップパケットの処理での際限ない再帰を防止するようになりました。(CVE-2026-6479) (Michael Paquier) (18)(17)(16)(15)(14)

悪意のクライアントが、拒絶されたSSLとGSSの暗号化の要求を交互に何度も繰り返すことで、接続先バックエンドをクラッシュさせることができました。

§ § § § § § § § §

メモリ割り当て計算における整数オーバーフローがいくつか修正されました。(CVE-2026-6473) (Tom Lane, Nathan Bossart, Heikki Linnakangas) (18)(17)(16)(15)(14)

様々な場所のメモリ割り当てサイズの計算で整数オーバーフローの可能性について不注意がありました。整数オーバーフローにより小さすぎるメモリ確保が行なわれて、その結果、範囲外に書き込みが行なわれて、サーバプロセスのクラッシュを引き起こす可能性がありました。また、おそらく任意コード実行も可能と考えられます。

全てとは言えませんが、この危険があるのは概ね 32ビットビルドだけです。

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

pg_createsubscriberコマンドで、オプションで指定されたサブスクリプション名を適切にクォートするようになりました。(CVE-2026-6476) (Nathan Bossart) (18)(17)

（ありそうにないことですが）信頼できない者がサブスクリプション名を任意に指定しているとして、サブスクリプション名にクォート無しのSQLコマンドを含めることで、SQLインジェクションが可能でした。

§ §

論理レプリケーションのオリジンの検査で、オブジェクト名を適切にクォートするようになりました。(CVE-2026-6638) (Pavel Kohout) (18)(17)(16)

「ALTER SUBSCRIPTION ... REFRESH PUBLICATION」はクォートを付加することなくSQLコマンドにスキーマ名とリレーション名を埋め込んでいて、これによりSQLインジェクションでパブリッシャ側で任意のSQL実行ができました。

§ § §

ts_headline()関数で長すぎるオプションをエラーを出して拒絶するようになりました。(CVE-2026-6473) (Michael Paquier) (18)(17)(16)(15)(14)

オプション「StartSel」「StopSel」「FragmentDelimiter」の文字列長は32Kbが上限でしたが、入力の検査が行われていませんでした。これを超える長い文字列の指定は、典型的にはサーバプロセスのクラッシュを引き起こしました。

§ § § § §

列のMCV（最頻値）統計情報をリストアするときに、誤った入力を検出するようになりました。(CVE-2026-6575) (Michael Paquier) (18)

プランナ統計情報をリストアする関数はMCV統計値の検証が不十分でした。そのため、誤った値を受け入れて、後のプランナのクラッシュを引き起こすことがありました。

timeofday()およびpg_strfname()関数で、悪意のタイムゾーン名による攻撃を防ぐようになりました。(CVE-2026-6474) (Tom Lane) (18)(17)(16)(15)(14)

作りこまれたタイムゾーン設定により、pg_strfname()関数に続いて実行されるsnprintf()関数のテンプレート文字列引数に「%」シーケンスを渡すことができました。これにより潜在的にクラッシュやサーバメモリ暴露を引き起こすことができました。また、pg_strftime()で使われるサイズに限りのある出力バッファのオーバーフローを起こすこともありました。

§ § § § § § § § § §

マルチ範囲型を作るときに、ユーザに指定されたスキーマに対するCREATE権限があることの確認が漏れており、修正されました。(CVE-2026-6472) (Jelte Fennema-Nio) (18)(17)(16)(15)(14)

マルチ範囲型は元となる範囲型と異なるスキーマに作成することが可能ですが、このときマルチ範囲型のスキーマについて権限確認が行なわれませんでした。

（誤動作例：scm_without_privilegeに権限がなくともエラーなく実行できてしまう）
db1=> CREATE TYPE scm_with_privilege.typ1_range AS RANGE
        (SUBTYPE=int4, MULTIRANGE_TYPE_NAME=scm_without_privilege.typ1_multi)
CREATE TYPE

§ § § § §

認証のコードでタイミング攻撃に安全な文字列比較を使うようになりました。(CVE-2026-6478) (Michael Paquier) (18)(17)(16)(15)(14)

これからはパスワードやハッシュ文字列などの検査で、memcpy()やstrcmp()に替えてtimingsafe_bcmp()を使用します。所要時間のデータ依存性がどれほど攻撃に有用であるかは不明ですが、安全のため置き換える判断がされました。

§ § § § § § § § §

libpqのPQfn()を安全でない関数であるとドキュメント記載し、libpq実装内部でも使用しないようになりました。(CVE-2026-6477) (Nathan Bossart) (18)(17)(16)(15)(14)

非整数の結果型に対してPQfn()には出力バッファのサイズが渡されないため、サーバから返ったデータのサイズが一致するか検査できません。悪意のサーバはこれを使ってクライアントのメモリを上書きできました。PQfn()は既に「廃れたもの」とドキュメント記載されていました。

PQfn()をresult_is_int引数に0を指定して使用しているクライアントで危険性を回避するには、使用するAPIを変更するほかありません。

§ § § § §

pg_basebackupとpg_rewindでパス横断が防止されました。(CVE-2026-6475) (Michael Paquier) (18)(17)(16)(15)(14)

これらのアプリケーションでは入力から読み込まれた出力ファイルのパスを検証できていませんでした。そのため、（PostgreSQLサーバ側の）入力を与える悪意の者がこれらのアプリケーションにクライアント側の任意のファイル上書きをさせることができました。これからは絶対パスと親ディレクトリ参照を含むパスを拒絶するようになります。

§ § § § §

contrib/intarrayのquery_int型とcontrib/ltreeのltxtquery型の中で、フィールドのオーバーフローが防止されました。(CVE-2026-6473) (Tom Lane) (18)(17)(16)(15)(14)

16ビットのフィールドがオーバーフローを起こすか検査されていなかったため、これらのデータ型として多すぎる要素数を持つ値を与えると、問合せを実行したバックエンドプロセスのクラッシュが発生する可能性がありました。これから、そのような値は ERROR になります。

§ § § § § § § § § §

contrib/ltreeのlquery型の長すぎる値を防止するようになりました。(CVE-2026-6473) (Michael Paquier) (18)(17)(16)(15)(14)

64Kアイテムを超える値は内部オーバーフローを起こしていて、潜在的にスタック破壊や誤った問い合わせ結果をもたらすおそれがありました。

§ § § § §

contrib/spiでSQLインジェクションとバッファオーバーランが防止されました。(CVE-2026-6637) (Nathan Bossart) (18)(17)(16)(15)(14)

check_foreign_key()関数はキー値のクォート付加が不十分で、また、クエリの組み立てに固定長のバッファを使用していました。このモジュールはサンプルコードにすぎないとはいえ、このような危険な誤りは含まれるべきでないため、修正されました。

§ § § § §

照合順序を適用できる型では、等価条件が一意性を示すものと仮定するのでなく、非決定論的照合順序を検査するようになりました。 (Richard Guo) (18)(17)(16)(15)(14)

多数のプランナ最適化がこれを仮定していました。例えば、一意性インデックスがx列にあれば、ある1行だけが「WHERE x = 'abc'」を満たします。しかしながら、WHERE句にインデックスと異なる照合順序が付加されている場合、この結論は一般には安全ではありません。両方の照合順序が決定論的であるときは文字列の等価がビット単位での等価を意味するため安全ですが、非決定論的な場合にはそのように動作しないため、WHERE句またはインデックスに非決定論的な照合順序が適用される場合に、一意性を前提とした最適化で、誤った問い合わせ結果が返される可能性がありました。

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

結合の削除時に、RestrictInfo構造体内のリレーション参照が完全に削除されない問題が修正されました。 (Tom Lane) (18)(17)(16)

この見落としにより、「ERROR: FULL JOIN is only supported with merge-joinable or hash-joinable join conditions」といった予期しないプランナでのエラーを引き起こすことが判明しています。また、他のケースでも有効なプランが考慮されない原因となっていた可能性がありました。

§ § § § §

プランナによるパーティションキー列とサブクエリ出力の照合が改善されました。 (Richard Guo) (18)

オペランドをパーティションキーと比較する前に、オペランドから何もしない（no-opの）PlaceHolderVarsを削除します。この変更により、以前はパーティションのスキャンが不要であると認識できなかった場合でも、パーティションプルーニングが正常に実行されるようになります。

「ON t1.boolcol」のようなboolean型の列のみで構成される結合句を処理できるように、自己結合の削除処理が修正されました。 (Andrei Lepikhov, Tender Wang, Alexander Korotkov) (18)

以前は、このような場合に「ERROR: no relation entry for relid ...」が発生していました。

仮想生成列を持つテーブルで、カーソルを使った更新「UPDATE/DELETE ... WHERE CURRENT OF」が正常に動作するように修正されました。 (Satyanarayana Narlapuram, Dean Rasheed) (18)

これまでは、実行時に「ERROR: WHERE CURRENT OF on a view is not implemented」が発生する動作が報告されていました。

「INSERT ... ON CONFLICT」内のEXCLUDED列参照における仮想生成列の展開が修正されました。 (Satyanarayana Narlapuram, Dean Rasheed) (18)

不具合によって、予期せぬエラー「ERROR: unexpected virtual generated column reference」が発生したり、誤った問い合わせ結果が発生したりしていました。

ルールアクションおよびルール条件における「NEW」生成列の誤った処理が修正されました。 (Richard Guo, Dean Rasheed) (18)(17)(16)(15)(14)

以前は、このような列参照がINSERTの場合にNULLとなり、UPDATEの場合にはOLDと同じ値になっていました。

（誤動作例）
db1=# CREATE TABLE t21 (id int PRIMARY KEY, a int,
        gen int GENERATED ALWAYS AS (a * 2) VIRTUAL);
db1=# CREATE TABLE t21log (op text, old_gen int, new_gen int);
db1=# CREATE RULE r21i AS ON INSERT TO t21 DO ALSO
        INSERT INTO t21log VALUES ('I', NULL, NEW.gen);
db1=# CREATE RULE r21u AS ON UPDATE TO t21 DO ALSO
        INSERT INTO t21log VALUES ('U', OLD.gen, NEW.gen);
db1=# INSERT INTO t21 (id, a) VALUES (1, 10);
db1=# UPDATE t21 SET a = 100 WHERE id = 1;
db1=# SELECT * FROM t21log;
 op | old_gen | new_gen
----+---------+---------
 I  |  *null* |  *null*
 U  |      20 |      20
(2 rows)

§ § § § §

偽性のエラー「ERROR: indexes on virtual generated columns are not supported」が修正されました。 (Robert Haas) (18)

式インデックスの作成時に、このエラーが誤って報告されることがありました。

偽性のエラー「ERROR: generated columns are not supported in COPY FROM WHERE conditions」が修正されました。 (Tom Lane) (18)(17)(16)(15)(14)

「COPY t23 FROM stdin WHERE tableoid > 0」のように「COPY FROM」のWHERE句でシステム列を使用すると、このエラーが誤って報告されることがありました。アサート有効のビルドでのアサート失敗も報告されました。

§ § § § §

MERGEがrepeatable readモードまたはserializableモードで同時更新されるタプルを検出した場合に、「ERROR: could not serialize access due to concurrent update」を出して直列化失敗を正しく報告するようになりました。 (Tender Wang) (18)(17)(16)(15)

以前は、このような場合により低い分離レベルの場合と同じ動作をしていて、トランザクションがアボートせず、不整合が見過ごされる可能性がありました。

（誤動作例 - 字下げは並行する別セッションをあらわします）
db1=# CREATE TABLE t24 (id int, v int);
db1=# INSERT INTO t24 VALUES (1,0);

　　　db1=# BEGIN;
　　　db1=*# UPDATE t24 SET v = v + 100;

db1=# START TRANSACTION ISOLATION LEVEL serializable;
db1=*# MERGE INTO t24 t USING (VALUES (1, 100)) AS s (id, inc) ON t.id = s.id
         WHEN MATCHED THEN UPDATE SET v = t.v + s.inc
         WHEN NOT MATCHED THEN INSERT (id, v) VALUES (s.id, s.inc);

　　　db1=*# COMMIT;

db1=*# SELECT * FROM t24;
 id |  v
----+-----
  1 |   0
  1 | 200
(2 rows)

db1=*# COMMIT;
db1=# SELECT * FROM t24;
 id |  v
----+-----
  1 | 200
(1 row)

§ § § §

ソーステーブルから列が削除されている場合における「CREATE TABLE ... LIKE ... INCLUDING STATISTICS」の動作が修正されました。 (Julien Tachoires) (18)(17)(16)(15)(14)

LIKEで指定するテーブルが作成後にALTER TABLEで列の削除を行なっているときに該当します。このような場合、拡張統計オブジェクトが正しくコピーされなかったり、コマンドが下記のような予期せぬエラーを返す可能性がありました。

ERROR:  cache lookup failed for attribute 3 of relation 17106

§ § § § §

「ALTER INDEX ... ATTACH PARTITION」で、そうすべき場合には親インデックスを有効とマークできるようになりました。 (Sami Imseih) (18)(17)(16)(15)(14)

すべてのリーフインデックスが有効であるにもかかわらず、パーティションインデックスが無効とマークされたままになる特殊なケースが存在していました。本修正は、ユーザが手動でカタログを更新することなく、このような状況を補正する仕組みを提供します。

§ § § § §

「ALTER TABLE ... SET NOT NULL」がシステムテーブル（カタログ）の変更が完了した後にのみオブジェクトアクセスフック関数を呼び出すように修正されました。 (Artur Zakirov) (18)

これはpg_constraintにNOT NULL制約用の行が追加された際につくられた不具合の修正です。

ALTER FOREIGN DATA WRAPPERが、ラッパーオブジェクトのハンドラ関数への依存関係を削除しないように修正されました。 (Jeff Davis) (18)(17)(16)(15)(14)

以前は、VALIDATORパラメータの指定により、誤ってハンドラ関数への依存関係が削除されていました。

§ § § § §

外部キー制約のトリガーに対する遅延実行指定が効かなくなる問題が修正されました。 (Yasuo Honda) (18)

以前は「DEFERRABLE INITIALLY DEFERRED」として定義された外部キー制約が、「NOT ENFORCED」ステータスに設定された後、再び「ENFORCED」に戻されると「NOT DEFERRABLE」として動作していました。

この問題が発生している外部キー制約がある場合は、本マイナーバージョンアップ適用後に「ALTER TABLE ..」で再度「NOT ENFORCED」に設定してから「ENFORCED」に戻すことで修復できます。

ドメインを許可するように「WITHOUT OVERLAPS」が修正されました。 (Jian He) (18)

「UNIQUE/PRIMARY KEY ... WITHOUT OVERLAPS」で指定する重複しない列は範囲型またはマルチ範囲型である必要がありますが、そのような型を元にしたドメインも許可する必要がありました。これまでは以下のようなエラーになっていました。

（修正前の動作例）
db1=# CREATE DOMAIN dtsrange AS tsrange CHECK (lower(VALUE) IS NOT NULL);
db1=# CREATE TABLE t30 (id int, tsr dtsrange, PRIMARY KEY (id, tsr WITHOUT OVERLAPS));
ERROR:  column "tsr" in WITHOUT OVERLAPS is not a range or multirange type

マルチ範囲型を介して、複合型が再帰的に自身をメンバーとして含むことが禁止されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

これまでも ALTER TABLE ADD COLUMN や ALTER TYPE ADD ATTRIBUTE の際に、ドメイン、配列、複合型、範囲型を通して自身をメンバーとして含まないことを検査していましたが、マルチ範囲型を経由する場合について見落とされていました。

（誤動作例）
db1=# CREATE TYPE typ31 AS (a int, b int);
db1=# CREATE TYPE typ31range AS RANGE (subtype = typ31);
db1=# ALTER TYPE typ31 ADD ATTRIBUTE c typ31range;
→ 修正前は実行できてしまう
　 修正後は「ERROR:  composite type two_ints cannot be made a member of itself」

§ § § § §

Datumのイメージ比較が符号拡張の違いに依存しないよう修正されました。 (David Rowley) (18)(17)(16)(15)(14)

従来は「ERROR: could not find memoization table entry」といったエラーメッセージが出力されたり、誤った問合せ結果を招いていました。

DatumとはSQLの各種データ型の値を格納する汎用的な内部実装上のデータ型です。そのイメージ比較とはビット単位での一致を調べる処理です。

§ § § § §

ハッシュ化された「IN」/「NOT IN」において、非STRICTな等価演算子を使用した場合の処理が修正されました。 (Chengpeng Yan) (18)(17)(16)(15)(14)

これまでは、NULLを空文字と等価とする独自の等価演算子を拡張機能で定義している場合などで、NULLを含む検索時にクラッシュや誤った問い合わせ結果を引き起こす可能性がありました。

なお、組み込みデータ型の等価演算子はすべてSTRICTであるため、この問題は拡張機能で定義されたデータ型でのみ発生します。

§ § § § §

to_char()における、ロケール依存の長すぎる数値記号を切り詰められるようになりました。 (Tom Lane) (18)(17)(16)(15)(14)

to_char()は、パターン内の各フォーマットコードごとに8バイトを見込んで出力バッファを確保しています。ロケールで指定された通貨記号、桁区切り記号、小数点記号、または符号記号が8バイトを超える場合、理論上はバッファオーバーランが発生する可能性がありました。

現実にはそのようなロケールは存在せず、さらに権限のない攻撃者がPostgresSQLサーバ配下に悪意あるロケール定義をインストールするのは現実的ではありませんが、安全性を考慮し、記号が長すぎる場合にはそれを検出し、必要に応じて切り詰めるようになりました。

§ § § § §

「Ispell」辞書用のaffixファイル解析時に発生し得るバッファオーバーランが防止されました。 (Tom Lane) (18)(17)(16)(15)(14)

破損した、あるいは悪意あるaffixファイルによってサーバプロセスがクラッシュする可能性があったため、入力値検証を強化し、異常に長いデータを安全に扱えるよう修正されました。

なお、テキスト検索設定ファイルは信頼できるものと想定されているため、これはセキュリティ問題の扱いにはなりませんでした。

§ § § § § § § § § §

ウィンドウ集約におけるフレーム開始位置および終了位置の計算で、整数オーバーフローが発生しないよう保護されました。 (Richard Guo) (18)(17)(16)(15)(14)

ユーザ指定のオフセット値が非常に大きい場合（INT64_MAXに近い値）、予期せぬエラーや誤った問い合わせ結果を引き起こす可能性がありました。開発用ビルドではアサート失敗も報告されました。

（誤動作例）
db1=# CREATE TABLE t36 (i int);
db1=# INSERT INTO t36 SELECT generate_series(1, 1000) g;
db1=# SELECT sum(i) 
        OVER (ROWS BETWEEN 0x7fffffffffffffff FOLLOWING AND 1 FOLLOWING), i FROM t36;
ERROR:  window frame head moved backward

§ § § § §

array_agg_array_combine()が、配列のNULLビットマップを正しく結合するよう修正されました。 (Dmytro Astapov) (18)(17)(16)

array_agg_array_combine() はarray_agg()集約関数の内部実装で使われている関数です。

この不具合により、NULLと非NULL要素が混在する入力において、並列化されたarray_agg(anyarray)の計算が失敗し、誤った問い合わせ結果が生じるおそれがありました。このエラーは並列ワーカーの実行タイミングに依存するため、再現性の低い不具合として現れていました。

（並列実行プランのときに誤動作が発生する可能性のある問い合わせ例）
db1=# CREATE TABLE t37 (id int, grpid int, c1 int, c2 int, c3 int);
db1=# INSERT INTO t37 SELECT g, g % 10000, 
        nullif(g % 3, 0), nullif(g % 5, 0), nullif(g % 7, 0)
        FROM generate_series(1, 100000) g;
db1=# SELECT grpid, array_agg(ARRAY[c1, c2, c3]) FROM t37 GROUP BY grpid;
　→ この結果が並列実行プランを無効化したときと一致しない場合がある

§ § §

sync_file_range()がエラーコード「EINTR」を返した場合に再試行するようになりました。 (DaeMyung Kang) (18)(17)(16)

これまでは、割り込み発生時のリトライ処理が正しく機能していませんでした。sync_file_range()はファイル書き込みをストレージに反映させるときに使われるLinuxのシステムコールです。

§ § §

共有システムテーブル（カタログ）に対するpg_stat_reset_single_table_counters()の誤動作が修正されました。 (Chao Li) (18)(17)(16)(15)

これまでは、共有システムテーブルに対して同関数を実行すると、現在のデータベースの「stat_reset_timestamp」（pg_stat_databaseシステムビューのstats_reset列で報告される値）が誤って更新されていました。

（誤動作例）
db1=# SELECT now(), pg_stat_reset_single_table_counters('pg_authid'::regclass);
              now              | pg_stat_reset_single_table_counters
-------------------------------+-------------------------------------
 2026-05-22 13:07:49.624814+09 |
(1 row)

db1=# SELECT datname, stats_reset FROM pg_stat_database
        WHERE datname = current_database();
 datname |          stats_reset
---------+-------------------------------
 db1     | 2026-05-22 13:07:49.627562+09
(1 row)

§ § § §

並列applyワーカーがidle状態のときにアクティビティ統計を更新するようになりました。 (Zhijie Hou) (18)(17)(16)

これまでは、直近に完了したトランザクションの統計情報が長時間報告されない場合があり、特にワークロードが軽い環境で顕著でした。

§ § §

集合演算で配列長を推定中するときに、予期せぬエラー「ERROR: no relation entry for relid 0」が発生することがあり、修正されました。 (Tender Wang) (18)(17)

UNIONなどの集合演算で、元となる型の異なる配列型を型変換する場合に発生することがありました。

（発生例）
db1=# SELECT null::int[] UNION ALL SELECT null::int[] UNION ALL SELECT null::bigint[];
ERROR:  no relation entry for relid 0

§ §

pglz_decompress()が破損した入力を受け取った場合にバッファの超過読み取りが発生することがあり、修正されました。 (Andrew Dunstan) (18)(17)(16)(15)(14)

pglz_decompress()はpglz形式の圧縮データを展開する内部実装関数です。破損した圧縮データによって入力末尾を越えた読み取りが発生する可能性があり、ごくまれにクラッシュを引き起こすおそれがありました。

§ § § § §

インクリメンタルJSONパーサにおいて、入力バッファの境界をまたぐ数値トークンの処理が修正されました。 (Andrew Dunstan) (18)(17)

JSON数値の文法に反する不正な形式の数値を受け入れてしまう可能性があり、その結果として後の処理でエラー（「ERROR: invalid input syntax for type json」など）が発生することがありえました。デバッグ用ビルドではアサート失敗を引き起こしました。

§ §

インクリメンタルバックアップのリストア時に、リレーションの可視性マップが肥大化することがあり、防止されました。 (Robert Haas) (18)(17)

このリストア処理では、期待されるファイル長の計算が誤っていたため、可視性マップに多数のゼロブロックが追加される可能性がありました。これはデータ破損にはつながりませんが、大量のディスク領域を無用に消費する可能性がありました。

§ §

カタログキャッシュのテキスト列検索において、データベースのデフォルト照合順序ではなく、C照合順序が使用されるようになりました。 (Jeff Davis) (18)(17)

これにより、データベースが特定できずデフォルト照合順序も決定できない特殊ケースでも、物理レプリケーションが開始できるようになります。pg_receivewalによるレプリケーション接続の開始時に「FATAL: cannot read pg_class without having selected a database」が発生するケースが報告されました。

§ §

スタンバイサーバ昇格時に、応答待ちのまま停止したslotsyncワーカープロセスが昇格処理をブロックする問題が修正されました。 (Nisha Moond, Ajin Cherian) (18)(17)

プライマリサーバからの応答を待ち続けていたワーカープロセスにより、昇格処理が不必要に長時間遅延することがありました。

§ § § § § §

アイドル状態のslotsyncワーカープロセスによる過剰なログ出力が修正されました。 (Zhijie Hou) (18)(17)

§ §

tuplestoreデータ構造で、エラー発生後に内部状態の不整合が生じないようになりました。 (Tom Lane) (18)(17)(16)(15)(14)

通常は問題になりませんが、WITH HOLDカーソルのtuplestoreでは問題となる可能性がありました。PostgreSQL 15以前では、この問題により容易に再現可能なクラッシュが発生することがありました。PostgreSQL 16以降での影響は確認されていませんが、すべてのサポートバージョンで内部状態の整合性が保たれるよう修正されました。

§ § § § §

pg_aiosシステムビューのpid列が、所有プロセスが存在しない場合に0ではなくNULLを示すようになりました。 (ChangAo Chen) (18)

pg_stat_replicationのlag列が実際より早い段階でNULLと報告されてしまう問題が修正されました。 (Shinya Kato) (18)(17)(16)(15)(14)

特に論理レプリケーション環境で、レプリケーション処理中であるにもかかわらず、過度に早くNULLとなることがありました。

§ § § § §

並列Btreeインデックススキャンで使用される共有メモリの割り当て不足が修正されました。 (Siddharth Kothari) (18)

稀なケースで、この共有メモリの割り当て不足によりサーバがクラッシュする可能性がありました。

WAL出力無しのGiSTインデックスを使用する際に、稀に発生するフラッシュ失敗を回避するようになりました。 (Tomas Vondra) (18)(17)(16)(15)(14)

WAL出力無しのGiSTインデックスにおいて、挿入ポイントを表す擬似LSNの選択が不適切であったため、誤って「ERROR: xlog flush request n/nnnn is not satisfied」が発生することがありました。（なお、ここでのWAL出力無しはUNLOGGEDテーブルを意味していません。）

§ § § § §

変則的なサイズのセグメント使用時に、DSAページマップの必要サイズの過小評価が修正されました (Paul Bunn) (18)(17)(16)(15)(14)

この計算ミスにより、範囲外アクセスが発生し、サーバがクラッシュする可能性がありました。

§ § § § §

共有メモリ内における最も古いマルチトランザクション配列のインデックス計算が修正されました。 (Yura Sokolov) (18)(17)

PREPARED状態であるが、未コミットのトランザクションが保持する行ロックが他セッションから見えなくなるなど、可視性の不整合が発生する可能性がありました。また、max_connectionsが非常に小さい場合には、メモリ破壊が発生する可能性もありました。

§ § § §

多数のEXPLAIN拡張オプションを登録した場合に発生する配列オーバーランが修正されました。 (Joel Jacobson) (18)

この問題により、メモリ破損やサーバプロセスのクラッシュが発生する可能性がありました。

拡張データ型の式に対する拡張統計情報処理時にクラッシュが発生する可能性があり、修正されました。 (Michael Paquier) (18)(17)(16)(15)(14)

データ型のtypanalyze関数が有効な統計情報を生成しない場合、NULLポインタ参照が発生する可能性がありました。PostgreSQL本体のtypanalyzeでは発生しませんが、拡張機能では発生する可能性がありました。

§ § § § §

GROUP BY句で使用される結合エイリアス変数を正しく表示するよう修正されました。 (Tom Lane) (18)

「SELECT ... t1 LEFT JOIN t2 USING (x) GROUP BY x」のようなクエリを含むビューにおいて、GROUP BY句のSQL文が内部からの逆解析時に誤って表示され、データベースのダンプ/リストアが失敗する可能性がありました。この問題は、「t1.x」と「t2.x」のデータ型が同一ではなく、「t1.x」側で暗黙的な型変換が必要だった場合にのみ発生しました。

（誤動作例）
db1=# CREATE TABLE t1 (x integer, a numeric);
db1=# CREATE TABLE t2 (x bigint, b text);
db1=# CREATE VIEW test_view AS SELECT x::integer AS x FROM t1 LEFT JOIN t2 USING (x) GROUP BY x;
（18.3以前では、以下のように誤ったSQLへ逆解析される）
db1=# SELECT pg_get_viewdef('test_view'::regclass, true);
       pg_get_viewdef
-----------------------------
  SELECT t1.x::integer AS x +
    FROM t1                 +
      LEFT JOIN t2 USING (x)+
   GROUP BY (t1.x::bigint);
(1 row)

（この状態でダンプしリストアすると、以下のようなエラーが発生する）
$ pg_dump db1 > dump.sql
$ psql restore_test < dump.sql
ERROR:  column "t1.x" must appear in the GROUP BY clause or be used in an aggregate function
LINE 2:  SELECT (t1.x)::integer AS x

ICUを使用した文字列処理における、軽微なメモリリークが修正されました。 (Jeff Davis) (18)(17)(16)

§ § §

startupプロセス失敗時に、他の子プロセスを適切にシャットダウンするよう修正されました。 (Ayush Tiwari) (18)(17)(16)(15)

従来は「startupプロセス実行中は他のpostmaster子プロセスは存在しない」という古い前提に依存しており、postmasterの即時終了でも問題ないとされていました。残存した子プロセスも最終的にはpostmasterの終了を検知して自主的に終了しますが、より適切なシャットダウン手順が望まれていました。

§ § § §

チェックポイントのWALリプレイ処理とマルチトランザクションID生成の間に存在する競合状態が修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

古いマイナーバージョンのプライマリからWALを追従するスタンバイサーバにおいて、「ERROR: could not access status of transaction」というエラーを伴うクラッシュおよび再起動ループが発生する可能性がありました。

§ § § § §

walsenderプロセス終了時に無限待機状態となりうる不具合が修正されました。 (Anthonin Bonnefoy) (18)(17)(16)(15)(14)

論理レプリケーションのパブリッシャ側のPostgreSQLを停止する際に、walsenderプロセスは未書き込みのWALがすべて書き出されるまで待機します。しかし、その書き出し要求が正しく行われていなかったため、状況によっては待機が終了せず、無限に停止処理が続く場合がありました。

§ § § § § § § § § §

リカバリ中にテーブルの空き領域マップ（FSM）の変更内容が確実に保持されるように修正されました。 (Alexey Makhmutov) (18)(17)(16)(15)(14)

これまでは、WALリプレイ時にFSMの更新自体は行われていたものの、チェックサムが有効な場合に、FSMページのバッファがダーティページとして印付けされていませんでした。そのため、変更内容がディスクへ書き出されず、反映されない場合がありました。

スタンバイサーバでは、この問題により時間の経過とともにFSMの内容が実際のテーブル状態と大きく乖離することがありました。FSMはあくまでヒント情報として使用されるだけですが、スタンバイサーバがアクティブに昇格した際、FSMの大部分が更新によって修復されるまでの間、大きく性能低下するおそれがありました。

§ § § § §

ecpgプリプロセッサで、接続が確立されていない状態で一部の関数を呼び出した場合に、クラッシュする不具合が修正されました。 (Shruthi Gowda) (18)(17)(16)(15)(14)

ECPGdeallocate_all()、ECPGprepared_statement()、ECPGget_desc()、および、ecpg_freeStmtCacheEntry()でセグメンテーション違反が生じました。

§ § § § §

pg_basebackupおよびpg_verifybackupでtarファイルの読み込み処理が強化されました。 (Tom Lane) (18)

これまでは、入力ファイルがtarファイルであるかどうか、さらにPostgreSQLが処理可能なtar形式かどうかの検証が十分に行われていませんでした。そのため、PostgreSQLではない他のtar作成ツールによって生成されたtarファイルを入力とした場合、想定外の形式であることで問題が生じる可能性がありました。

pg_basebackupおよびpg_verifybackupでバックアップの展開およびtar読み込み処理における各種バグが修正されました。 (Andrew Dunstan, Tom Lane, Chao Li) (18)(17)(16)(15)

具体的には、tarファイルのパディング領域の扱いの不備、特殊ケースにおいてLZ4圧縮データが破損する可能性、一部の異常系エラー条件の検査漏れ、圧縮／展開のエラー発生後に終了しないことによる連鎖的なエラー報告、メモリリークの発生、ということが含まれます。

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

pg_dumpにおいて、NOT NULL制約のNO INHERIT属性が正しく保持されるように修正されました。 (Jian He) (18)

これまでは、一部のケースでNO INHERIT句がダンプ出力されませんでした。

pg_dumpallにおいて、OIDが存在しないロールが権限を与えた場合にもGRANT文を出力するように、修正されました。 (Tom Lane) (18)(17)(16)

これまでは、このような状態のGRANTがダンプ対象から除外される場合がありました。今回の修正で、PostgreSQL v16より前と同様に、GRANTED BY句を付けずにGRANT文を出力するよう変更されました。

なお、権限を与えたロールのOIDが存在しないことに対する警告メッセージは引き続き出力されますが、警告を出すのはソースサーバがPostgreSQL v16以降の場合のみに限定されます。

§ § §

pg_upgradeにおいて、古いソースサーバへ接続する際に正しいプロトコルバージョンを使用するように修正されました。 (Jacob Champion) (18)(17)(16)(15)(14)

これまでは、2018年2月のマイナーリリース（10.2、9.6.7、9.5.11、9.4.16、9.3.21）よりも古いPostgreSQLサーバからアップグレードを行う場合に、不具合が発生する可能性がありました。

「FATAL: unsupported frontend protocol ...」が発生するケースが報告されました。

§ § § § §

contrib/basic_archiveが、起動時にアーカイブディレクトリが存在しなくてもよくなりました。 (Nathan Bossart) (18)(17)(16)(15)

これまでは、起動時点でbasic_archive.archive_directoryに指定したディレクトリが存在しない場合、その設定自体が無効なものとして扱われました。今回の修正により、起動時点でディレクトリが存在しなくても、後からディレクトリが作成された場合にアーカイブ処理を継続できるようになりました。

§ § § §

contrib/ltreeが、大文字小文字のフォールドで文字列のバイト長が変化する場合に対応できるように修正されました。 (Jeff Davis) (18)(17)(16)(15)(14)

これまでは、大文字小文字を区別しないマッチングを指定するlqueryパターンにおいて、本来一致するはずのラベルにマッチしない場合がありました。

§ § § § § §

contrib/pg_overexplainにおいて、RANGE_TABLEオプションの出力構造の不具合が修正されました。 (Satyanarayana Narlapuram) (18)

これまでは、JSON、YAML、XML形式の出力で一部のフィールドが誤った位置に出力される場合がありました。

contrib/pg_stat_statementsで、pgss_query_texts.statファイルの解析中にエラーが発生した時に、メモリリークが発生しないように修正されました。 (Heikki Linnakangas) (18)(17)(16)(15)(14)

§ § § § §

contrib/postgres_fdwにおいて、利用不能になった接続を早期に解放してしまうことでクラッシュすることがあり、修正されました。 (Etsuro Fujita) (18)(17)(16)(15)(14)

オープン中のカーソルなどのデータ構造に接続オブジェクトへの参照が残っている可能性があるため、トランザクション終了まで接続オブジェクトのクローズを遅延させるようになりました。

§ § § § §

タイムゾーンデータファイルがtzdata release 2026bに更新されました。 (Tom Lane) (18)(17)(16)(15)(14)

ブリティッシュコロンビア州（America/Vancouver）は、2026年11月から通年でUTC-07を使用するようになります（事実上の恒久的な夏時間）。同地域のタイムゾーン略称がそれ以降「MST」になると想定しています。実際には別の略称へ変更される可能性もありますが、現時点では未確定です。

モルドバの歴史的変更も行なわれました。モルドバは2022年以降、EUの夏時間切替時刻に従っていたことが反映されました。

§ § § § §

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

PostgreSQL – SRA OSS Tech Blog

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. まとめ: 列の用途から型を決める

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 への変更点

PostgreSQL 19検証報告

検証レポート

PostgreSQL であなたの UPDATE が終わらない理由 〜トランザクション、ロック、MVCC を実験で理解する〜

実験の前に

実験の準備

実験1:同じ行をUPDATEすると片方が待つ

この実験で確認すること

手順1:セッションAでトランザクションを開始する

手順2:セッションAでid = 1の行を更新する

手順3:セッションBで同じ行を更新する

なぜ待つのか

この実験で分かったこと

実験2: pg_stat_activityで何を待っているかを確認する

この実験で確認すること

確認するSQL

まず確認する列

結果の読み方

この実験で分かったこと

実験3: pg_blocking_pids()で待たせている相手を探す

この実験で確認すること

確認するSQL

結果の読み方

実験4: idle in transactionはロックを保持し得る状態

この実験で確認すること

状況の確認

結果の読み方

なぜ問題になりやすいのか

実務で確認する列

timeout設定について

この実験で分かったこと

実験5:通常のロック待ちとデッドロックは違う

この実験で確認すること

実験前の準備

手順1:セッションAがid = 1を更新する

手順2:セッションBがid = 2を更新する

手順3:セッションAがid = 2を更新しようとする

手順4:セッションBがid = 1を更新しようとする

デッドロック時のエラー

通常のロック待ちとの違い

デッドロックを減らす考え方

lock_timeoutについて

この実験で分かったこと

実験6:通常のSELECTは止まらない

この実験で確認すること

実験前の準備

手順1:セッションAでid = 1を更新する

手順2:セッションBで通常のSELECTを実行する

なぜ止まらないのか

SELECT FOR UPDATEは待つ

この実験で分かったこと

実験7: UPDATEは待ったあとにWHEREを再確認する

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`を使う

PostgreSQL であなたの UPDATE が終わらない理由〜トランザクション、ロック、MVCC を実験で理解する〜