<title>Release date:</title> リリース日: 2026-02-12
This release contains a variety of fixes from 18.1. For information about new features in major release 18, see <xref linkend="release-18"/>. このリリースは18.1に対し、様々な不具合を修正したものです。 18メジャーリリースにおける新機能については、E.4を参照してください。
A dump/restore is not required for those running 18.X. 18.Xからの移行ではダンプ/リストアは不要です。
However, if you have any indexes on <type>ltree</type> columns, it may
be necessary to reindex them after updating. See the sixth changelog
entry below.
しかし、ltree列にインデックスがある場合は、更新後にインデックス再作成が必要になる可能性があります。
以下の6番目の変更ログの項目を参照してください。
Guard against unexpected dimensions
of <type>oidvector</type>/<type>int2vector</type> (Tom Lane)
予期しない次元に対してoidvector/int2vectorが保護されるようになりました。
(Tom Lane)
§
These data types are expected to be 1-dimensional arrays containing no nulls, but there are cast pathways that permit violating those expectations. Add checks to some functions that were depending on those expectations without verifying them, and could misbehave in consequence. これらのデータ型は、NULLを含まない1次元配列であることが想定されていますが、これらの想定に違反するキャスト経路が存在しました。 これらの想定を検証せずに依存し、結果として誤動作を引き起こす可能性があった一部の関数にチェックが追加されました。
The <productname>PostgreSQL</productname> Project thanks Altan Birler for reporting this problem. (CVE-2026-2003) PostgreSQLプロジェクトは、本問題を報告してくれたAltan Birlerに感謝します。 (CVE-2026-2003)
Harden selectivity estimators against being attached to operators that accept unexpected data types (Tom Lane) 予期しないデータ型を受け入れる演算子に関連付けられる選択性推定関数が厳格化されました。 (Tom Lane) § §
<filename>contrib/intarray</filename> contained a selectivity
estimation function that could be abused for arbitrary code
execution, because it did not check that its input was of the
expected data type. Third-party extensions should check for similar
hazards and add defenses using the technique intarray now uses.
Since such extension fixes will take time, we now require superuser
privilege to attach a non-built-in selectivity estimator to an
operator.
contrib/intarrayには、入力が想定されるデータ型であるかどうかをチェックしていなかったため、任意のコード実行に悪用される可能性のある選択性推定関数が含まれていました。
サードパーティの拡張は、同様の危険性に対してチェックを行い、現在intarrayが使用している手法を用いて防御策を追加する必要があります。
このような拡張の修正には時間がかかるため、組み込みではない選択性推定関数を演算子にアタッチするにはスーパーユーザ権限が必要になりました。
The <productname>PostgreSQL</productname> Project thanks Daniel Firer, as part of zeroday.cloud, for reporting this problem. (CVE-2026-2004) PostgreSQLプロジェクトは、本問題を報告してくれたzeroday.cloudの一員であるDaniel Firerに感謝します。 (CVE-2026-2004)
Fix buffer overrun in <filename>contrib/pgcrypto</filename>'s
PGP decryption functions (Michael Paquier)
contrib/pgcryptoのPGP復号関数におけるバッファオーバーランが修正されました。
(Michael Paquier)
§
Decrypting a crafted message with an overlength session key caused a buffer overrun, with consequences as bad as arbitrary code execution. 細工されたメッセージを長すぎるセッションキーで復号するとバッファオーバーランが発生し、任意のコードの実行と同等の深刻な問題を引き起こす可能性がありました。
The <productname>PostgreSQL</productname> Project thanks Team Xint Code, as part of zeroday.cloud, for reporting this problem. (CVE-2026-2005) PostgreSQLプロジェクトは、本問題を報告してくれたzeroday.cloudの一員のTeam Xint Codeに感謝します。 (CVE-2026-2005)
Fix inadequate validation of multibyte character lengths (Thomas Munro, Noah Misch) マルチバイト文字長の不十分な検証が修正されました。 (Thomas Munro, Noah Misch) § § § § § §
Assorted bugs allowed an attacker able to issue crafted SQL to overrun string buffers, with consequences as bad as arbitrary code execution. After these fixes, applications may observe <quote>invalid byte sequence for encoding</quote> errors when string functions process invalid text that has been stored in the database. さまざまなバグにより、攻撃者が細工したSQLを発行して文字列バッファをオーバーランさせることが可能になり、任意のコード実行と同等の深刻な結果を招く可能性がありました。 これらの修正後、文字列関数がデータベースに保存された不正なテキストを処理する際に、アプリケーションで「invalid byte sequence for encoding」エラーが発生する可能性があります。
The <productname>PostgreSQL</productname> Project thanks Paul Gerste and Moritz Sanft, as part of zeroday.cloud, for reporting this problem. (CVE-2026-2006) PostgreSQLプロジェクトは、本問題を報告してくれたzeroday.cloudの一員であるPaul GersteとMoritz Sanftに感謝します。 (CVE-2026-2006)
Harden <filename>contrib/pg_trgm</filename> against changes in
string lowercasing behavior (Heikki Linnakangas)
contrib/pg_trgmにおいて、文字列の小文字化動作変更に対する強化が実施されました。
(Heikki Linnakangas)
§
§
Fix potential buffer overruns arising from the fact that in some locales lower-casing a string can produce more characters (not bytes) than were in the original. That behavior is new in version 18, and so is the bug. 一部のロケールでは、文字列を小文字化すると元の文字列より多くの文字数（バイト数ではない）を生成する可能性があることから生じる潜在的なバッファオーバーランの発生が修正されました。 この動作はバージョン18で新しく追加されたものであり、このバグも同様です。
The <productname>PostgreSQL</productname> Project thanks Heikki Linnakangas for reporting this problem. (CVE-2026-2007) PostgreSQLプロジェクトは、本問題を報告してくれたHeikki Linnakangasに感謝します。 (CVE-2026-2007)
Fix inconsistent case-insensitive matching
in <filename>contrib/ltree</filename> (Jeff Davis)
contrib/ltreeにおける大文字小文字を区別しないマッチングの不一致が修正されました。
(Jeff Davis)
§
§
Index-related routines in <filename>ltree</filename> used a
different implementation of case-folding than the primary operators
did. Their behavior was equivalent only if the default collation
provider was libc and the encoding was single-byte.
ltreeのインデックス関連ルーチンは、主要な演算子とは異なる大文字と小文字の変換実装を使用していました。
これらの動作は、デフォルト照合順序プロバイダがlibcで、エンコーディングがシングルバイトの場合にのみ同等でした。
To fix, change the code to use case-folding with the database's
default collation.
This change will require reindexing indexes on <type>ltree</type>
columns (regardless of the index access method) unless the database
uses libc as collation provider and its encoding is single-byte.
Without that, searches of such indexes will fail to locate relevant
entries.
修正のため、データベースのデフォルトの照合順序で大文字と小文字の変換を使用するようコードが変更されました。
この変更により、データベースが照合順序プロバイダとしてlibcを使用し、エンコーディングがシングルバイトでない限り、インデックスアクセスメソッドに関係なくltree列のインデックスの再インデックスが必要になります。
再インデックスを行わないと、そのようなインデックスの検索で関連エントリを見つけることができません。
When using <command>ALTER TABLE ... ADD CONSTRAINT</command> to add
a not-null constraint with an explicit name, if the column is
already marked NOT NULL, require that the provided name match the
existing constraint name (Álvaro Herrera, Srinath Reddy Sadipiralla)
ALTER TABLE ... ADD CONSTRAINTを使用して明示的な名前を持つNOT NULL制約を追加する場合、列がすでにNOT NULLとマークされている場合は、指定された名前が既存の制約名と一致する必要があります。
(Álvaro Herrera, Srinath Reddy Sadipiralla)
§
Don't allow CTE references in sub-selects to determine semantic levels of aggregate functions (Tom Lane) 副SELECT内のCTE参照を用いて集約関数のセマンティックレベルを決定するのが禁止されました。 (Tom Lane) §
This change undoes a change made two minor releases ago, instead throwing an error if a sub-select references a CTE that's below the semantic level that standard SQL rules would assign to the aggregate based on contained column references and aggregates. The attempted fix turned out to cause problems of its own, and it's unclear what to do instead. Since sub-selects within aggregates are disallowed altogether by the SQL standard, treating such cases as errors seems sufficient. この変更は、2つ前のマイナーリリースで行われた変更を元に戻すものであり、代わりに標準SQLルールが包含列参照と集計に基づいて集計に割り当てるセマンティックレベルよりも低いCTEを副SELECTが参照している場合に、エラーを発生させるようになりました。 試みられた修正は、それ自体が問題を引き起こすことが判明し、代わりに何をすべきかは不明です。 集計関数内の副SELECTは標準SQLでは完全に禁止されているため、このようなケースをエラーとして処理すれば十分であると思われます。
Fix trigger transition table capture for <command>MERGE</command>
in CTE queries (Dean Rasheed)
CTE問い合わせにおけるMERGEのトリガ遷移テーブルキャプチャが修正されました。
(Dean Rasheed)
§
When executing a data-modifying CTE query containing both
a <command>MERGE</command> and another DML operation on a table with
statement-level <literal>AFTER</literal> triggers, the transition
tables passed to the triggers would not include the rows affected by
the <command>MERGE</command>, only those affected by the other
operation(s).
ステートメントレベルAFTERトリガが設定されたテーブルに対して、MERGEおよび別のDML操作の両方を含むデータ変更CTE問い合わせを実行すると、トリガに渡される遷移テーブルにはMERGEによって影響を受ける行が含まれず、他の操作によって影響を受ける行のみが含まれる問題が発生していました。
Fix incorrect pruning of rowmarks belonging to non-relation rangetable entries, such as subqueries (Dean Rasheed) 副問い合わせなど、非リレーション範囲テーブルエントリに属する行マークの不適切なプルーニングが修正されました。 (Dean Rasheed) §
This led to incorrect results if a proposed row update needed to be modified by EvalPlanQual rechecking, as could happen if there was a concurrent update to that row. これにより、提案された行の更新をEvalPlanQualの再チェックによって修正する必要がある場合、その行へ同時更新があった場合に結果を誤ることがありました。
Fix failure when all children of a partitioned target table of an update or delete have been pruned (Amit Langote) UPDATEまたはDELETEの対象となるパーティションテーブルのすべての子テーブルが除外されている場合に発生するエラーが修正されました。 (Amit Langote) §
In such cases, the executor could report <quote>could not find junk ctid column</quote> errors, even though nothing needs to be done. このような場合、何もする必要がないにもかかわらず、エグゼキュータが「could not find junk ctid column」エラーを報告する可能性がありました。
Fix expression evaluation bug for a sub-select within an array subscript (Andres Freund) 配列添字内の副問い合わせに対する式評価の不具合が修正されました。 (Andres Freund) §
Fix text substring search for non-deterministic collations (Laurenz Albe) 非決定論的照合順序におけるテキストの部分文字列検索が修正されました。 (Laurenz Albe) §
When using a non-deterministic collation, we failed to detect a match occurring at the very end of the searched string. 非決定論的照合順序を使用した場合、検索文字列の末尾で発生する一致を検出できませんでした。
Avoid possible planner failure when a query contains duplicate window function calls (Meng Zhang, David Rowley) 問い合わせに重複したウィンドウ関数呼び出しが含まれている場合に発生する可能性のあるプランナの失敗が回避されました。 (Meng Zhang, David Rowley) §
Confusion over de-duplication of such calls could result in errors like <quote>WindowFunc with winref 2 assigned to WindowAgg with winref 1</quote>. このような呼び出しの重複排除に関する混乱により、「WindowFunc with winref 2 assigned to WindowAgg with winref 1」のようなエラーが発生する可能性がありました。
Fix planner error with set-returning functions and grouping sets (Richard Guo) 集合を返す関数とグループ化集合に関するプランナエラーが修正されました。 (Richard Guo) §
When constructing a ProjectSet plan node, the planner failed to detect that subexpressions involving grouping expressions were already computed by the input plan. This led to inefficient plans or errors such as <quote>variable not found in subplan target list</quote>. ProjectSetプランノードの構築時、プランナはグループ化式を含む部分式が入力プランによって既に計算されていることを検出できませんでした。 これにより、非効率的なプランや、「variable not found in subplan target list」などのエラーが発生していました。
Avoid incorrect optimization when a subquery's grouping clause contains a volatile or set-returning function (Richard Guo) 副問い合わせのGROUPING句にVOLATILE関数または集合を返す関数が含まれている場合の誤った最適化が回避されました。 (Richard Guo) §
The planner was willing to push down outer-query restrictions
referencing such a grouping column, leading to incorrect behavior
due to multiple evaluation of a volatile function, or errors caused
by introduction of a set-returning function into the
subquery's <literal>WHERE</literal>/<literal>HAVING</literal>
clauses.
プランナは、そのようなグループ化列を参照する外部問い合わせの制約をプッシュダウンしようとしたため、その結果VOLATILE関数の多重評価による誤った動作が発生したり、副問い合わせのWHERE/HAVING句に集合返却関数が導入されることによってエラーが発生していました。
Look through PlaceHolderVar nodes when searching for statistics about an expression (Richard Guo) 式に関する統計情報を検索する際は、PlaceHolderVarノードを調べるようになりました。 (Richard Guo) §
This change allows the planner to find relevant statistics about
expressions pulled up from subqueries or used in <literal>GROUP
BY</literal>, avoiding falling back to a default estimate.
(Arguably we should adjust any found statistics to account for an
increased probability of the value being NULL, but we've never done
the equivalent thing for plain Vars either.) While this restriction
is old, changes in <productname>PostgreSQL</productname> version 18
made PlaceHolderVars more common than before, so make the change to
avoid plan regressions in affected cases.
この変更により、プランナは、副問い合わせからプルアップされた式やGROUP BYで使用された式に関連する統計情報を見つけることができ、デフォルトの推定値へのフォールバックが回避されます。
（おそらく、値がNULLになる確率が高まったことを考慮して、見つかった統計情報を調整する必要がありますが、単純な変数に対しても同等のことを行ったことはありません。）
この制限は古いものですが、PostgreSQLバージョン18での変更により、PlaceHolderVarsが以前よりも一般的になったため、影響を受けた場合のプランの退行を回避するために変更が実施されました。
Look through no-op PlaceHolderVar nodes when matching expressions to indexes (Richard Guo) 式をインデックスと照合する際に、何もしない(no-opの)PlaceHolderVarノードを調べるようになりました。 (Richard Guo) §
Because <productname>PostgreSQL</productname> version 18 uses PlaceHolderVars in more cases than before, some queries that formerly could use an index failed to do so. Add logic to prevent that regression. PostgreSQLバージョン18では、以前よりも多くの場合にPlaceHolderVarsが使用されるため、以前はインデックスを使用できた問い合わせの一部がインデックスを使用できなくなりました。 この後退を防ぐためのロジックが追加されました。
Fix planner's conversion of <literal>OR</literal> clauses to
ScalarArrayOp index conditions (Tender Wang, Tom Lane)
プランナのOR句からScalarArrayOpインデックス条件への変換が修正されました。
(Tender Wang, Tom Lane)
§
The code did not handle RelabelType nodes correctly, and could generate invalid expressions or fail to perform a valid conversion. コードがRelabelTypeノードを正しく処理しなかったため、無効な式が生成されたり、有効な変換の実行に失敗することがありました。
Allow indexscans on partial hash indexes even when the index's predicate implies the truth of the WHERE clause (Tom Lane) インデックスの述語がWHERE句の真を暗示する場合でも、部分ハッシュインデックスによるインデックススキャンが可能になりました。 (Tom Lane) §
Normally we drop a WHERE clause that is implied by the predicate, since it's pointless to test it; it must hold for every index entry. However that can prevent creation of an indexscan plan if the index is one that requires a WHERE clause on the leading index key, as hash indexes do. Don't drop implied clauses when considering such an index. 通常、述語によって暗黙的に示されるWHERE句は、全てのインデックスエントリに対して真である必要があるので、テストする意味が無いため削除します。 しかし、ハッシュインデックスのように、先頭インデックスキーに対するWHERE句を必要とするインデックスの場合、この処理がインデックススキャンプランの作成を妨げる可能性がありました。 このようなインデックスを検討する場合は、暗黙的な句を削除しないようになりました。
Do not emit WAL for unlogged BRIN indexes (Kirill Reshke) UNLOGGEDのBRINインデックスに対してWALが出力されなくなりました。 (Kirill Reshke) §
One seldom-taken code path incorrectly emitted a WAL record relating to a BRIN index even if the index was marked unlogged. Crash recovery would then fail to replay that record, complaining that the file already exists. めったに使用されないコードパスの1つでは、インデックスがUNLOGGEDとマークされている場合でも、BRINインデックスに関連するWALレコードが誤って出力されていました。 その結果、クラッシュリカバリでファイルが既に存在するといったエラーが発生して、WALレコードのリプレイに失敗していました。
Use the correct ordering function in parallel GIN index builds (Tomas Vondra) 並列GINインデックス構築で正しい順序付け関数を使用するようになりました。 (Tomas Vondra) §
The parallel code used the default ordering operator (which is determined by the column data type's btree opclass), whereas it should use the ordering function specified by the GIN opclass, if any. This led to a failure if the data type has no btree opclass, or to an invalid index if the opclass specifies an ordering function that doesn't agree with the btree opclass. 並列コードはデフォルトの順序付け演算子（列のデータ型のbtree演算子クラスによって決定される）が使用されていましたが、もしあればGIN演算子クラスによって指定された順序付け関数を使用する必要がありました。 これにより、データ型にbtree演算子クラスが存在しない場合には失敗となり、btree演算子クラスが適合しない順序付け関数を指定している場合には無効なインデックスが生成される問題が発生していました。
Prevent truncation of CLOG that is still needed by
unread <command>NOTIFY</command> messages (Joel Jacobson, Heikki
Linnakangas)
未読のNOTIFYメッセージによってまだ必要とされているCLOGの切り捨てが防止されました。
(Joel Jacobson, Heikki Linnakangas)
§
§
§
This fix prevents <quote>could not access status of
transaction</quote> errors when a backend is slow to
absorb <command>NOTIFY</command> messages.
この修正により、バックエンドによるNOTIFYメッセージの吸い上げが遅い場合に「could not access status of transaction」エラーの発生が防止されます。
Escalate errors occurring during <command>NOTIFY</command> message
processing to FATAL, i.e. close the connection (Heikki Linnakangas)
NOTIFYメッセージ処理中に発生したエラーをFATALにエスカレートします。 つまり、接続を切断します。
(Heikki Linnakangas)
§
Formerly, if a backend got an error while absorbing
a <command>NOTIFY</command> message, it would advance past that
message, report the error to the client, and move on. That behavior
was fraught with problems though. One big concern is that the
client has no good way to know that a notification was lost, and
certainly no way to know what was in it. Depending on the
application logic, missing a notification could cause the
application to get stuck waiting, for example. Also, any remaining
messages would not get processed until someone sent a
new <command>NOTIFY</command>.
以前は、バックエンドがNOTIFYメッセージを吸い上げている間にエラーを検出した場合、そのメッセージを読み飛ばし、クライアントにエラーを報告して処理を続行していました。
しかし、その動作には多くの問題がありました。大きな懸念点の一つは、クライアントが通知の損失を知る適切な手段がなく、ましてやその内容を知る手段がないことです。
アプリケーションロジックによっては、通知を失うと例えばアプリケーションが待機状態となってしまう可能性がありました。
また、残りのメッセージは、誰かが新しいNOTIFYを送信するまで処理されません。
Also, if the connection is idle at the time of receiving
a <command>NOTIFY</command> signal, any ERROR would be escalated to
FATAL anyway, due to unrelated concerns. Therefore, we've chosen to
make that happen in all cases, for consistency and to provide a
clear signal to the application that it might have missed some
notifications.
さらに、NOTIFY信号受信時に接続がアイドル状態の場合、無関係な理由によりERRORは常にFATALにエスカレートされていました。
一貫性を保ち、アプリケーションに通知が失われた可能性があることを明確に伝えるために、すべてのケースでこの動作(FATALで切断)を実行することにしました。
Consider grouping expressions when computing a query ID hash (Jian He) クエリIDのハッシュ計算をする際に、グループ化式を考慮するようになりました。 (Jian He) §
Previously, two queries that were the same except in <literal>GROUP
BY</literal> expressions would be merged
by <filename>contrib/pg_stat_statements</filename> and other users
of query IDs.
以前は、GROUP BY式を除いて同一である2つの問い合わせは、contrib/pg_stat_statementsおよびその他のクエリIDの利用者によって誤ってマージされていました。
Fix erroneous counting of updates in <command>EXPLAIN ANALYZE
MERGE</command> with a concurrent update (Dean Rasheed)
同時の更新と共にEXPLAIN ANALYZE MERGEが行なわれる際に、更新回数が誤ってカウントされる問題が修正されました。
(Dean Rasheed)
§
This situation led to an incorrect count of <quote>skipped</quote>
tuples in <command>EXPLAIN</command>'s output, or to an assertion
failure in an assert-enabled build.
この状況により、EXPLAINの出力における「スキップされた(skipped)」タプルの数が間違っていたり、アサートが有効なビルドではアサーションエラーが発生していました。
Fix bug in following update chain when locking a tuple (Jasper Smit) タプルをロックする際の後続の更新チェーンにおける不具合が修正されました。 (Jasper Smit) §
This code path neglected to check the xmin of the first new tuple in
the update chain, making it possible to lock an unrelated tuple if
the original updater aborted and the space was immediately reclaimed
by <command>VACUUM</command> and then re-used.
That could cause unexpected transaction delays or deadlocks.
Errors associated with having identified the wrong tuple have also
been observed.
このコードパスでは、更新チェーン内の最初の新しいタプルのxmin値の確認が省略されていたため、元の更新処理が中止され、その領域がVACUUMによってすぐに回収されて再利用された場合に、無関係なタプルがロックされる可能性がありました。
これにより、予期せぬトランザクションの遅延やデッドロックが発生する可能性がありました。
誤ったタプルを識別したことに関連するエラーも確認されています。
Fix incorrect handling of incremental backups of large tables (Robert Haas, Oleg Tkachenko) 大規模テーブルの増分バックアップにおける不正な処理が修正されました。 (Robert Haas, Oleg Tkachenko) §
If a table exceeding 1GB (or in general, the installation's segment
size) is truncated by <literal>VACUUM</literal> between the base
backup and the incremental
backup, <application>pg_combinebackup</application> could fail with
an error about <quote>truncation block length in excess of segment
size</quote>. This prevented restoring the incremental backup.
ベースバックアップと増分バックアップとの間に、1GB(または一般的にはインストールセグメントサイズ)を超えるテーブルがVACUUMによって切り詰められた場合、pg_combinebackupが「truncation block length in excess of segment size」というエラーで失敗する可能性がありました。
これにより、増分バックアップのリストアが妨げられていました。
Fix potential backend process crash at process exit due to trying to release a lock in an already-unmapped shared memory segment (Rahila Syed) 既にマップされていない共有メモリセグメントのロックを解除しようとしたことによる、プロセス終了時のバックエンドプロセスのクラッシュの可能性が修正されました。 (Rahila Syed) §
Fix race condition in async I/O code (Andres Freund) 非同期I/Oコードの競合状態が修正されました。 (Andres Freund) §
It was possible for the result code of an asynchronous I/O operation to be overwritten before it was fetched. 非同期I/O操作の結果コードが取得される前に上書きされる可能性がありました。
Guard against incorrect truncation of the multixact log after a crash (Heikki Linnakangas) クラッシュ後のマルチトランザクションログの不適切な切り捨てが防止されました。 (Heikki Linnakangas) §
Fix possibly mis-encoded result
of <function>pg_stat_get_backend_activity()</function> (Chao Li)
pg_stat_get_backend_activity()の結果が誤ってエンコードされる可能性があった問題が修正されました。
(Chao Li)
§
The shared-memory buffer holding a session's activity string can end with an incomplete multibyte character. Readers are supposed to truncate off any such incomplete character, but this function failed to do so. セッションのアクティビティ文字列を保持する共有メモリバッファは、不完全なマルチバイト文字で終わる可能性がありました。 読取り側はそのような不完全な文字を切り捨てるべきですが、この関数はそれを実行していませんでした。
Guard against recursive memory context logging (Fujii Masao) 再帰的なメモリコンテキストのログ出力が防止されました。 (Fujii Masao) §
A constant flow of signals requesting memory context logging could cause recursive execution of the logging code, which in theory could lead to stack overflow. メモリコンテキストのログ出力を要求するシグナルが継続的に送信されると、ログ出力コードの再帰的な実行が引き起こされる可能性があり、理論上はスタックオーバーフローが発生する可能性がありました。
Fix memory context usage when reinitializing a parallel execution context (Jakub Wartak, Jeevan Chalke) 並列実行コンテキストの再初期化時のメモリコンテキストの使用が修正されました。 (Jakub Wartak, Jeevan Chalke) §
This error could result in a crash due to a subsidiary data structure having a shorter lifespan than the parallel context. The problem is not known to be reachable using only core <productname>PostgreSQL</productname>, but we have reports of trouble in extensions. この誤りは、並列コンテキストよりも短い寿命を持つ補助データ構造が原因でクラッシュを引き起こす可能性がありました。 この問題はPostgreSQLコアのみでは発生しないことが分かっていますが、拡張で問題が発生した報告がありました。
Set next multixid's offset when creating a new multixid, to remove the wait loop that was needed in corner cases (Andrey Borodin) 新しいマルチトランザクションID(multixid)を作成する際に、次のmultixidのオフセットを設定することで、特殊なケースで必要だった待機ループが削除されました。 (Andrey Borodin) § §
The previous logic could get stuck waiting for an update that would never occur. 以前のロジックでは、決して発生しない更新を待機して立ち往生する可能性がありました。
Avoid rewriting data-modifying CTEs more than once (Bernice Southey, Dean Rasheed) データを変更するCTEの複数回の書き換えが回避されました。 (Bernice Southey, Dean Rasheed) §
Formerly, when updating an auto-updatable view or a relation with rules, if the original query had any data-modifying CTEs, the rewriter would rewrite those CTEs multiple times due to recursion. This was inefficient and could produce false errors if a CTE included an update of an always-generated column. 以前は、自動更新可能なビューやルール付きリレーションを更新する際、元の問い合わせにデータを変更するCTEが含まれている場合、再帰処理によりリライタはそれらのCTEを複数回書き換えていました。 これは非効率的であり、CTEにALWAYS指定の生成列が含まれている場合、誤ったエラーが発生する可能性がありました。
Allow retrying initialization of a DSM registry entry (Nathan Bossart) DSM(動的共有メモリ)レジストリエントリの初期化の再試行ができるようになりました。 (Nathan Bossart) §
If we fail partway through initialization of a dynamic shared memory entry, allow the next attempt to use that entry to retry initialization. Previously the entry was left in a permanently-failed state. 動的共有メモリエントリの初期化途中で失敗した場合、次回の施行でそのエントリの初期化を再試行できるようになりました。 以前は、エントリは永続的に失敗した状態のままでした。
Avoid failure of NUMA status views when a page has been swapped out (Tomas Vondra) ページがスワップアウトされた場合のNUMAページビューの失敗が回避されました。 (Tomas Vondra) §
Avoid <quote>operation not permitted</quote> errors when querying NUMA page status with older libnuma versions (Tomas Vondra) 古いバージョンのlibnumaを使用してNUMAページ状態を問い合わせた際の「operation not permitted」エラーが回避されました。 (Tomas Vondra) §
Fail recovery if WAL does not exist back to the redo point indicated by the checkpoint record (Nitin Jadhav) チェックポイントレコードで指定されたREDOポイントまでのWALが存在しない場合はリカバリを失敗させるよう修正されました。 (Nitin Jadhav) §
Add an explicit check for this before starting recovery, so that no harm is done and a useful error message is provided. Previously, recovery might crash or corrupt the database in this situation. リカバリを開始する前に、このことを明示的にチェックする機能を追加することで、問題が発生せず、有用なエラーメッセージが提供されるようになります。 以前は、このような状況でリカバリをおこなうと、データベースがクラッシュしたり破損したりする可能性がありました。
Avoid scribbling on the source query tree during <command>ALTER
PUBLICATION</command> (Sunil S)
ALTER PUBLICATIONの実行中の、元の問い合わせツリーへの書き込みが回避されました。
(Sunil S)
§
This error had the visible effect that an event trigger fired for
the query would see only the first <literal>publish</literal>
option, even if several had been specified. If such a query were
set up as a prepared statement, re-executions would misbehave too.
この誤りにより、問い合わせに対して起動されたイベントトリガは、複数のpublishオプションが指定されていたとしても、最初のオプションしか認識しないという目に見える影響がありました。
このような問い合わせがプリペアドステートメントとして設定されていた場合、再実行時も不正な動作が発生していました。
Pass connection options specified in <literal>CREATE SUBSCRIPTION
... CONNECTION</literal> to the publisher's walsender (Fujii Masao)
CREATE SUBSCRIPTION ... CONNECTIONで指定された接続オプションをパブリッシャーのwalsenderに渡すようになりました。
(Fujii Masao)
§
Before this fix, the <literal>options</literal> connection option
(if any) was ignored, thus for example preventing setting custom
server parameter values in the walsender session. It was intended
for that to work, and it did work before refactoring
in <productname>PostgreSQL</productname> version 15 broke it, so
restore the previous behavior.
この修正以前は、options接続オプションが存在する場合は無視されていたため、例えばwalsenderセッションでカスタムサーバパラメータ値を設定できなくなっていました。
これは動作するように意図されており、PostgreSQLバージョン15のリファクタリングで機能しなくなる前は動作していました。そのため、以前の動作に戻します。
Prevent invalidation of newly created or newly synced replication slots (Zhijie Hou) 新しく作成された、または新たに同期されたレプリケーションスロットが無効化されるのが防止されました。 (Zhijie Hou) § § §
A race condition with a concurrent checkpoint could allow WAL to be removed that is needed by the replication slot, causing the slot to immediately get marked invalid. 同時にチェックポイントが実行される競合状態により、レプリケーションスロットが必要とするWALが削除され、そのスロットが即座に無効とマークされる可能性がありました。
Fix race condition in computing a replication slot's required xmin (Zhijie Hou) レプリケーションスロットが必要とするxminを計算する際の競合状態が修正されました。 (Zhijie Hou) §
This could lead to the error <quote>cannot build an initial slot snapshot as oldest safe xid follows snapshot's xmin</quote>. これにより、「cannot build an initial slot snapshot as oldest safe xid follows snapshot's xmin」というエラーが発生する可能性がありました。
During initial synchronization of a logical replication
subscription, commit the addition of
a <structname>pg_replication_origin</structname> entry before
starting to copy data (Zhijie Hou)
論理レプリケーションサブスクリプションの初期同期中、データのコピーを開始する前にpg_replication_originエントリの追加をコミットするようになりました。
(Zhijie Hou)
§
Previously, if the copy step failed, the
new <structname>pg_replication_origin</structname> entry would be
lost due to transaction rollback. This led to inconsistent state in
shared memory.
以前は、コピーステップが失敗した場合、トランザクションのロールバックにより新しいpg_replication_originエントリが失われていました。
これにより、共有メモリの状態が不整合になっていました。
Don't advance logical replication progress after a parallel worker apply failure (Zhijie Hou) パラレルワーカーの適用が失敗した後、論理レプリケーションの進捗を進めないよう修正されました。 (Zhijie Hou) §
The previous behavior allowed transactions to be lost by a subscriber. 以前の動作では、サブスクライバーによってトランザクションが失われる可能性がありました。
Fix logical replication slotsync worker processes to handle LOCK_TIMEOUT signals correctly (Zhijie Hou) LOCK_TIMEOUTシグナルを正しく処理できるように論理レプリケーションのスロット同期(slotsync)ワーカープロセスが修正されました。 (Zhijie Hou) §
Previously, timeout signals were effectively ignored. 以前は、タイムアウトシグナルは事実上無視されていました。
Fix possible failure with <quote>unexpected data beyond EOF</quote> during restart of a streaming replica server (Anthonin Bonnefoy) ストリーミングレプリカサーバの再起動中に「unexpected data beyond EOF」によって発生する可能性があった障害が修正されました。 (Anthonin Bonnefoy) §
Fix error reporting for SQL/JSON path type mismatches (Jian He) SQL/JSON pathの型不一致に関するエラーメッセージが修正されました。 (Jian He) §
The code could produce a <quote>cache lookup failed for type 0</quote> error instead of the intended complaint about the path expression not being of the right type. このコードではpath式が正しい型ではないという意図したエラーではなく、「cache lookup failed for type 0」というエラーが生成される可能性がありました。
Fix erroneous tracking of column position when parsing partition range bounds (myzhen) パーティション範囲の境界を解析する際の列位置の誤った追跡が修正されました。 (myzhen) §
This could, for example, lead to the wrong column name being cited in error messages about casting partition bound values to the column's data type. これにより、例えば、パーティション境界値を列のデータ型にキャストする際のエラーメッセージに、誤った列名が表示されるといった問題が発生する可能性がありました。
Fix assorted minor errors in error messages (Man Zeng, Tianchen Zhang) エラーメッセージにおける様々な軽微な誤りが修正されました。 (Man Zeng, Tianchen Zhang) § § § § §
For example, an error report about mismatched timeline number in a backup manifest showed the starting timeline number where it meant to show the ending timeline number. 例えば、バックアップマニフェスト内のタイムライン番号不一致に関するエラー報告で、本来表示されるべき終了タイムライン番号が開始タイムライン番号として表示されていました。
Fix failure to perform function inlining when doing JIT compilation with LLVM version 17 or later (Anthonin Bonnefoy) LLVMバージョン17以降でJITコンパイルを行う際に、関数インライン化が失敗する問題が修正されました。 (Anthonin Bonnefoy) §
Adjust our JIT code to work with LLVM 21 (Holger Hoffstätte) LLVM 21で動作するようにJITコードが調整されました。 (Holger Hoffstätte) §
The previous coding failed to compile on aarch64 machines. 以前のコードは、aarch64マシンでコンパイルに失敗していました。
Fix aarch64-specific code to build with old (RHEL7-era) system header files (Tom Lane) 古い（RHEL7時代の）システムヘッダファイルを使用してビルドできるように、aarch64固有のコードが修正されました。 (Tom Lane) § §
Fix incorrect configure probe
for <function>io_uring_queue_init_mem()</function> (Masahiko Sawada)
io_uring_queue_init_mem()に対する誤ったconfigureプローブが修正されました。
(Masahiko Sawada)
§
This error resulted in failure to optimize async I/O buffer allocations in autotools-based builds, though the code did work when building with meson. The main impact of the omission was slower-than-necessary backend process exits. この誤りにより、autotoolsベースのビルドでは非同期I/Oバッファ割り当ての最適化が失敗していましたが、mesonを使用したビルドではコードは正常に動作していました。 この修正漏れによる主な影響は、バックエンドプロセスの終了処理が不必要に遅くなることでした。
Add new server parameter <xref linkend="guc-file-extend-method"/> to
control use of <function>posix_fallocate()</function> (Thomas Munro)
posix_fallocate()の使用を制御するために、新しいサーバ変数file_extend_methodが追加されました。
(Thomas Munro)
§
<productname>PostgreSQL</productname> version 16 and later will
use <function>posix_fallocate()</function>, if the platform provides
it, to extend relation files. However, this has been reported to
interact poorly with some file systems: BTRFS compression is
disabled by the use of <function>posix_fallocate()</function>, and
XFS could produce spurious <literal>ENOSPC</literal> errors in older
Linux kernel versions. To provide a workaround, introduce this new
server parameter. Setting <varname>file_extend_method</varname>
to <literal>write_zeros</literal> will cause the server to return to
the old method of extending files by writing blocks of zeroes.
PostgreSQLバージョン16以降では、プラットフォームが提供している場合、リレーションファイルの拡張にposix_fallocate()を使用します。
しかし、これは一部のファイルシステムとうまく連携しないことが報告されています。
具体的には、posix_fallocate()の使用によりBTRFSの圧縮が無効になり、XFSでは古いバージョンのLinuxカーネルで誤ったENOSPCエラーが発生する可能性がありました。
この問題を回避するため、この新しいサーバ変数が導入されました。
file_extend_methodをwrite_zerosに設定すると、サーバはゼロブロックを書き込むことでファイルを拡張する従来の方法に戻ります。
Honor <function>open()</function>'s <literal>O_CLOEXEC</literal>
flag on Windows (Bryan Green, Thomas Munro)
Windowsにおいてopen()のO_CLOEXECフラグを正しく処理するようになりました。
(Bryan Green, Thomas Munro)
§
§
§
Make this flag work like it does on POSIX platforms, so that we
don't leak file handles into child processes such as <literal>COPY
TO/FROM PROGRAM</literal>. While that leakage hasn't caused many
problems, it seems undesirable.
このフラグをPOSIXプラットフォームと同様に動作させることで、COPY TO/FROM PROGRAMなどの子プロセスへのファイルハンドルリークが防止されるようになりました。
このリークによって大きな問題が生じたわけではありませんが、望ましくない状況でした。
Fix failure to parse long options on the server command line in Solaris executables built with meson (Tom Lane) MesonでビルドされたSolaris実行ファイルにおいて、サーバコマンドラインの長いオプションの解析エラーが修正されました。 (Tom Lane) §
Support process title changes on GNU/Hurd (Michael Banck) GNU/Hurd上でプロセスタイトルの変更がサポートされました。 (Michael Banck) §
Fix <application>psql</application>'s tab completion
for <command>VACUUM</command> option values (Yugo Nagata)
psqlでのVACUUMオプション値に対するタブ補完を修正しました。
(Yugo Nagata)
§
In <application>psql</application> command prompts,
do not show a value for <literal>%P</literal> (pipeline status) when
there is no server connection (Chao Li)
psqlコマンドプロンプトにおいて、サーバ接続がない場合は%P（パイプライン状態）の値を表示しないようになりました。
(Chao Li)
§
This makes <literal>%P</literal> act like other prompt escape
sequences whose values depend on the active connection.
これにより、%Pは、アクティブな接続状況に応じて値が変化する他のプロンプトエスケープシーケンスと同様の動作をするようになります。
Fix <application>pg_dump</application>'s logic for collecting sequence values (Nathan Bossart) pg_dumpによるシーケンス値の収集ロジックが修正されました。 (Nathan Bossart) § §
<application>pg_dump</application> failed if a sequence was dropped concurrently with the dump, even if the sequence was not among the database objects to be dumped. Also, if the calling user lacks privileges to read a sequence's value, <application>pg_dump</application> emitted incorrect values rather than failing as expected. ダンプ対象のデータベースオブジェクトに含まれていないシーケンスであっても、ダンプ実行中にそのシーケンスが削除されるとpg_dumpは失敗していました。 また、呼び出し元のユーザにシーケンスの値を読み取る権限がない場合、pg_dumpは期待どおりに失敗するのではなく、誤った値を出力していました。
Fix potentially-incorrect quoting
of <varname>oauth_validator_libraries</varname> values
by <application>pg_dump</application> (ChangAo Chen)
pg_dumpによるoauth_validator_librariesの値の潜在的な誤った引用符付けが修正されました。
(ChangAo Chen)
§
<application>pg_dump</application> applied the wrong quoting rule if it needed to dump a value of this setting. pg_dumpは、この設定の値をダンプする必要がある場合、誤った引用ルールを適用していました。
Avoid <application>pg_dump</application> assertion failure in binary-upgrade mode (Vignesh C) バイナリアップグレードモードでのpg_dumpのアサーションエラーが回避されました。 (Vignesh C) §
Failure to handle subscription-relation objects in the object sorting code triggered an assertion, though there were no serious ill effects in production builds. オブジェクトのソート処理コードにおいて、サブスクリプション関連オブジェクトの処理に失敗したためアサーションエラーが発生していましたが、本番環境のビルドでは深刻な悪影響はありませんでした。
Fix incorrect error handling in <application>pgbench</application>
with multiple <command>\syncpipeline</command> commands
in pipeline mode (Yugo Nagata)
パイプラインモードで複数の\syncpipelineコマンドが実行された場合のpgbenchのエラー処理の誤りが修正されました。
(Yugo Nagata)
§
If multiple <command>\syncpipeline</command> commands are
encountered after a query error, <application>pgbench</application>
would report <quote>failed to exit pipeline mode</quote>, or get an
assertion failure in an assert-enabled build.
問い合わせエラーの後に複数の\syncpipelineコマンドが検出された場合、pgbench は「failed to exit pipeline mode」と報告するか、アサートが有効なビルドではアサーションエラーが発生していました。
Make <application>pg_resetwal</application> print the updated value when changing OldestXID (Heikki Linnakangas) pg_resetwalがOldestXIDを変更した際に、更新された値が出力されるようになりました。 (Heikki Linnakangas) §
It already did that for every other variable it can change. 他の変更可能な変数については既にそのように動作していました。
Make <application>pg_resetwal</application> allow setting next multixact xid to 0 or next multixact offset to UINT32_MAX (Maxim Orlov) pg_resetwalで、次のmultixact xidを0にしたり、次のmultixactオフセットをUINT32_MAXに設定できるようになりました。 (Maxim Orlov) §
These are valid values, so rejecting them was incorrect. In the worst case, if a pg_upgrade is attempted when exactly at the point of multixact wraparound, the upgrade would fail. これらは有効な値であるため、拒否していたのは誤りでした。 最悪の場合、multixactの周回が発生するまさにその時点でpg_upgradeが試行されると、アップグレードは失敗していました。
In <filename>contrib/amcheck</filename>, use the correct snapshot
for btree index parent checks (Mihail Nikalayeu)
contrib/amcheckで、btreeインデックスの親チェックで正しいスナップショットを使用するようになりました。
(Mihail Nikalayeu)
§
§
The previous coding caused spurious errors when examining indexes
created with <command>CREATE INDEX CONCURRENTLY</command>.
以前のコードでは、CREATE INDEX CONCURRENTLYで作成されたインデックスを検査する際に誤ったエラーが発生していました。
Fix <filename>contrib/amcheck</filename> to
handle <quote>half-dead</quote> btree index pages correctly
(Heikki Linnakangas)
「half-dead」状態のbtreeインデックスページを正しく処理するようにcontrib/amcheckが修正されました。
(Heikki Linnakangas)
§
<filename>amcheck</filename> expected such a page to have a parent
downlink, but it does not, leading to a false error report
about <quote>mismatch between parent key and child high key</quote>.
amcheckは、このようなページには親のダウンリンクが存在することを想定していましたが、実際には存在しないため、「mismatch between parent key and child high key」という誤ったエラー報告が発生していました。
Fix <filename>contrib/amcheck</filename> to
handle incomplete btree root page splits correctly
(Heikki Linnakangas)
不完全なbtreeルートページ分割を正しく処理するようにcontrib/amcheckが修正されました。
(Heikki Linnakangas)
§
<filename>amcheck</filename> could report a false error
about <quote>block is not true root</quote>.
amcheckは「block is not true root」という誤ったエラーを報告する可能性がありました。
Fix excessive memory allocation
in <filename>contrib/pg_buffercache</filename> (David Geier)
contrib/pg_buffercacheにおける過剰なメモリ割り当てが修正されました。
(David Geier)
§
The code allocated twice as much memory as it needed for NUMA page status. このコードは、NUMAページステータスに必要なメモリ量の2倍のメモリを割り当てていました。
Fix edge-case integer overflow
in <filename>contrib/intarray</filename>'s selectivity estimator
for <literal>@@</literal> (Chao Li)
contrib/intarrayの@@の選択度推定において、エッジケースの整数オーバーフローが修正されました。
(Chao Li)
§
This could cause poor selectivity estimates to be produced for cases involving the maximum integer value. これにより、整数の最大値を含む場合に、不適切な選択度推計が生成される可能性がありました。
Fix multibyte-encoding issue in <filename>contrib/ltree</filename>
(Jeff Davis)
contrib/ltreeにおけるマルチバイトエンコーディング問題が修正されました。
(Jeff Davis)
§
The previous coding could pass an incomplete multibyte character
to <function>lower()</function>, probably resulting in incorrect
behavior.
以前のコードでは、不完全なマルチバイト文字がlower()に渡される可能性があり、その結果、誤った動作を引き起こす可能性がありました。
Avoid crash in <filename>contrib/pg_stat_statements</filename> when
an <literal>IN</literal> list contains both constants and
non-constant expressions (Sami Imseih)
contrib/pg_stat_statementsにおいて、INリストに定数と非定数式の両方が含まれている場合に発生するクラッシュが回避されました。
(Sami Imseih)
§
Update time zone data files to <application>tzdata</application> release 2025c (Tom Lane) タイムゾーンデータファイルをtzdataリリース2025cに更新しました。 (Tom Lane) §
The only change is in historical data for pre-1976 timestamps in Baja California. 変更点は、バハカリフォルニアの1976年以前のタイムスタンプに関する履歴データのみです。