<title>Release date:</title> リリース日: 2026-05-14
This release contains a variety of fixes from 18.3. For information about new features in major release 18, see <xref linkend="release-18"/>. このリリースは18.3に対し、様々な不具合を修正したものです。 18メジャーリリースにおける新機能については、E.5を参照してください。
A dump/restore is not required for those running 18.X. 18.Xからの移行ではダンプ/リストアは不要です。
However, if you are upgrading from a version earlier than 18.2, see <xref linkend="release-18-2"/>. しかしながら、18.2より前のバージョンからアップグレードする場合は、E.3を参照してください。
Prevent unbounded recursion while processing startup packets (Michael Paquier) スタートアップパケット処理中の無限の再帰が防止されました。 (Michael Paquier) §
A malicious client could crash the connected backend by alternating rejected SSL and GSS encryption requests indefinitely. 悪意のあるクライアントは、SSLおよびGSS暗号要求を交互に拒否し続けることによって、接続されているバックエンドをクラッシュさせる可能性がありました。
The <productname>PostgreSQL</productname> Project thanks Calif.io (in collaboration with Claude and Anthropic Research) for reporting this problem. (CVE-2026-6479) PostgreSQLプロジェクトは、本問題を報告してくれたCalif.io（ClaudeおよびAnthropic Researchとの協力）に感謝します。 (CVE-2026-6479)
Fix assorted integer overflows in memory-allocation calculations (Tom Lane, Nathan Bossart, Heikki Linnakangas) メモリ割り当て計算における様々な整数オーバーフローが修正されました。 (Tom Lane, Nathan Bossart, Heikki Linnakangas) § § § § § § § § §
Various places were incautious about the possibility of integer overflow in calculations of how much memory to allocate. Overflow would lead to allocating a too-small buffer which the caller would then write past the end of. This would at least trigger server crashes, and probably could be exploited for arbitrary code execution. In many but by no means all cases, the hazard exists only in 32-bit builds. メモリ割り当て量を計算する際、整数オーバーフローの可能性に対する配慮が不十分な箇所が複数ありました。 オーバーフローが発生すると、割り当てられるバッファが小さすぎるため、呼び出し元はそのバッファの末尾を超えて書き込みを行なうことになります。 これは少なくともサーバのクラッシュを引き起こし、場合によっては任意のコード実行に悪用される可能性がありました。 すべてのケースではありませんが、多くの場合、この脆弱性は32ビットビルドでのみ発生します。
The <productname>PostgreSQL</productname> Project thanks Xint Code, Bruce Dang, Sven Klemm, and Pavel Kohout for reporting these problems. (CVE-2026-6473) PostgreSQLプロジェクトは、本問題を報告してくれたXint Code、Bruce Dang、Sven Klemm、Pavel Kohoutに感謝します。 (CVE-2026-6473)
Properly quote subscription names in <application>pg_createsubscriber</application> (Nathan Bossart) pg_createsubscriberにおいて、サブスクリプション名が正しくクォートされるようになりました。 (Nathan Bossart) §
The given subscription name was inserted into SQL commands without quoting, so that SQL injection could be achieved in the (perhaps unlikely) case that the subscription name comes from an untrusted source. 指定されたサブスクリプション名がクォートされずにSQLコマンドに挿入されていたため、サブスクリプション名が信頼できないソースから取得された場合（可能性は低いですが）SQLインジェクション攻撃が可能になる恐れがありました。
The <productname>PostgreSQL</productname> Project thanks Yu Kunpeng for reporting this problem. (CVE-2026-6476) PostgreSQLプロジェクトは、本問題を報告してくれたYu Kunpengに感謝します。 (CVE-2026-6476)
Properly quote object names in logical replication origin checks (Pavel Kohout) 論理レプリケーション起点チェックで、オブジェクトの名前を正しく引用符で囲うようになりました。 (Pavel Kohout) §
<command>ALTER SUBSCRIPTION ... REFRESH PUBLICATION</command>
interpolated schema and relation names into SQL commands without
quoting them, allowing execution of arbitrary SQL on the publisher.
ALTER SUBSCRIPTION ... REFRESH PUBLICATIONでは、スキーマ名とリレーション名を引用符で囲まずにSQLコマンドに挿入していたため、パブリッシャー上で任意のSQLが実行されてしまう可能性がありました。
The <productname>PostgreSQL</productname> Project thanks Pavel Kohout for reporting this problem. (CVE-2026-6638) PostgreSQLプロジェクトは、本問題を報告してくれたPavel Kohoutに感謝します。 (CVE-2026-6638)
Reject over-length options in <function>ts_headline()</function>
(Michael Paquier)
ts_headline()で、長すぎるオプションを拒否するようになりました。
(Michael Paquier)
§
The <literal>StartSel</literal>, <literal>StopSel</literal>
and <literal>FragmentDelimiter</literal> strings must not exceed
32Kb in length, but this was not checked for. An over-length value
would typically crash the server.
StartSel、StopSel、FragmentDelimiterの文字列長は32キロバイトを超えてはなりませんが、これまでチェックされていませんでした。
長すぎる値を指定すると、通常はサーバがクラッシュします。
The <productname>PostgreSQL</productname> Project thanks Xint Code for reporting this problem. (CVE-2026-6473) PostgreSQLプロジェクトは、本問題を報告してくれたXint Codeに感謝します。 (CVE-2026-6473)
Detect faulty input when restoring attribute MCV statistics (Michael Paquier) MCV(最頻値)の統計情報のリストア時に不正な入力を検出するようになりました。 (Michael Paquier) §
The statistics restore functions were insufficiently careful about validating most-common-value statistics, and would accept values that could crash the planner later on. 統計情報のリストア関数は、最頻値の統計情報の検証に十分な注意を払っておらず、後でプランナをクラッシュする可能性のある値を受け入れていました。
The <productname>PostgreSQL</productname> Project thanks Jeroen Gui for reporting this problem. (CVE-2026-6575) PostgreSQLプロジェクトは、本問題を報告してくれたJeroen Guiに感謝します。 (CVE-2026-6575)
Guard against malicious time zone names
in <function>timeofday()</function>
and <function>pg_strftime()</function> (Tom Lane)
timeofday()およびpg_strftime()において、悪意のあるタイムゾーン名への対策が講じられました。
(Tom Lane)
§
§
A crafted time zone setting could pass <literal>%</literal>
sequences to <function>snprintf()</function>, potentially causing
crashes or disclosure of server memory. Another path to similar
results was to overflow the limited-size output buffer used
by <function>pg_strftime()</function>.
細工されたタイムゾーン設定によって、%シーケンスがsnprintf()に渡され、クラッシュやサーバメモリの漏洩を引き起こす可能性がありました。
同様の結果をもたらす別の方法として、pg_strftime()で使用される容量制限付きの出力バッファをオーバーフローさせる方法がありました。
The <productname>PostgreSQL</productname> Project thanks Xint Code for reporting this problem. (CVE-2026-6474) PostgreSQLプロジェクトは、本問題を報告してくれたXint Codeに感謝します。 (CVE-2026-6474)
When creating a multirange type, ensure the user
has <literal>CREATE</literal> privilege on the schema specified for
the multirange type (Jelte Fennema-Nio)
マルチレンジ型を作成する際に、ユーザがそのマルチレンジ型に指定されたスキーマに対してCREATE権限を持っていることを確認するようになりました。
(Jelte Fennema-Nio)
§
The multirange type can be put into a different schema than its parent range type, but we neglected to apply the required privilege check when doing so. マルチレンジ型は、その親となるレンジ型とは異なるスキーマに入れることも可能ですが、その際に必要な権限チェックを怠っていました。
The <productname>PostgreSQL</productname> Project thanks Jelte Fennema-Nio for reporting this problem. (CVE-2026-6472) PostgreSQLプロジェクトは、本問題を報告してくれたJelte Fennema-Nioに感謝します。 (CVE-2026-6472)
Use timing-safe string comparisons in authentication code (Michael Paquier) 認証コードでタイミングセーフな文字列比較を使用するようになりました。 (Michael Paquier) §
Use <function>timingsafe_bcmp()</function> instead
of <function>memcpy()</function> or <function>strcmp()</function>
when checking passwords, hashes, etc. It is not known whether the
data dependency of those functions is usefully exploitable in any of
these places, but in the interests of safety, replace them.
パスワードやハッシュなどの検証には、 memcpy()やstrcmp()の代わりにtimingsafe_bcmp()を使用するようになりました。
これらの関数のデータ依存性が、これらの箇所で悪用される可能性があるかどうかは不明ですが、安全を期してこれらが置き換えられました。
The <productname>PostgreSQL</productname> Project thanks Joe Conway for reporting this problem. (CVE-2026-6478) PostgreSQLプロジェクトは、本問題を報告してくれたJoe Conwayに感謝します。 (CVE-2026-6478)
Mark <function>PQfn()</function> as unsafe, and avoid using it
within <application>libpq</application> (Nathan Bossart)
PQfn()を安全ではないとマークし、libpq内での使用を避けました。
(Nathan Bossart)
§
For a non-integral result type, <function>PQfn()</function> is not
passed the size of the output buffer, so it cannot check that the
data returned by the server will fit. A malicious server could
therefore overwrite client memory. This is unfixable without an
API change, so mark the function as deprecated. Internally
to <application>libpq</application>, use a variant version that can
apply the missing check.
非整数型の結果の場合、PQfn()には出力バッファのサイズが渡されないので、サーバから返されたデータがバッファに収まるかどうかをチェックすることができません。
そのため、悪意のあるサーバがクライアントメモリを上書きする可能性がありました。
これはAPIの変更なしには修正できないため、この関数を非推奨としてマークします。
libpq内部では、不足しているチェックを適用できる異なるバージョンを使用します。
The <productname>PostgreSQL</productname> Project thanks Yu Kunpeng and Martin Heistermann for reporting this problem. (CVE-2026-6477) PostgreSQLプロジェクトは、本問題を報告してくれたYu KunpengとMartin Heistermannに感謝します。 (CVE-2026-6477)
Prevent path traversal in <application>pg_basebackup</application> and <application>pg_rewind</application> (Michael Paquier) pg_basebackupおよびpg_rewindにおけるパス横断が防止されました。 (Michael Paquier) §
These applications failed to validate output file paths read from their input, so that a malicious source could overwrite any file writable by these applications. Constrain where data can be written by rejecting paths that are absolute or contain parent-directory references. これらのアプリケーションは、入力から読み取った出力ファイルのパスを検証できなかったため、悪意のあるソースによってこれらのアプリケーションが書き込み可能なファイルを上書きする可能性がありました。 絶対パスや親ディレクトリ参照を含むパスを拒否することで、データの書き込み場所を制限します。
The <productname>PostgreSQL</productname> Project thanks XlabAI Team of Tencent Xuanwu Lab and Valery Gubanov for reporting this problem. (CVE-2026-6475) PostgreSQLプロジェクトは、本問題を報告してくれたTencent Xuanwu Lab XlabAIチームとValery Gubanovに感謝します。 (CVE-2026-6475)
Guard against field overflow
within <filename>contrib/intarray</filename>'s <type>query_int</type>
type and <filename>contrib/ltree</filename>'s <type>ltxtquery</type>
type (Tom Lane)
contrib/intarrayのquery_int型およびcontrib/ltreeのltxtquery型におけるフィールドのオーバーフローが防止されました。
(Tom Lane)
§
§
Parsing of these query structures did not check for overflow of 16-bit fields, so that construction of an invalid query tree was possible. This can crash the server when executing the query. これらのクエリ構造体の解析において、16ビットフィールドのオーバーフローがチェックされていなかったため、無効なクエリツリーが構築される可能性がありました。 これにより、クエリの実行時にサーバがクラッシュする可能性がありました。
The <productname>PostgreSQL</productname> Project thanks Xint Code for reporting this problem. (CVE-2026-6473) PostgreSQLプロジェクトは、本問題を報告してくれたXint Codeに感謝します。 (CVE-2026-6473)
Guard against overly long values
of <filename>contrib/ltree</filename>'s <type>lquery</type> type
(Michael Paquier)
contrib/ltreeのlquery型の過度に長い値が防止されました。
(Michael Paquier)
§
Values with more than 64K items caused internal overflows, potentially resulting in stack smashes or wrong answers. 64Kを超える項目を持つ値は内部オーバーフローを引き起こし、スタック破壊や誤った結果を引き起こす可能性がありました。
The <productname>PostgreSQL</productname> Project thanks Vergissmeinnicht, A1ex, and Jihe Wang for reporting this problem. (CVE-2026-6473) PostgreSQLプロジェクトは、本問題を報告してくれたVergissmeinnicht、A1ex、Jihe Wangに感謝します。 (CVE-2026-6473)
Prevent SQL injection and buffer overruns
in <filename>contrib/spi</filename> (Nathan Bossart)
contrib/spiにおけるSQLインジェクションとバッファオーバーランが防止されました。
(Nathan Bossart)
§
<function>check_foreign_key()</function> was insufficiently careful
about quoting key values, and also used fixed-length buffers for
constructing queries. While this module is only meant as example
code, it still shouldn't contain such dangerous errors.
check_foreign_key()はキー値の引用符付けに十分な注意を払っておらず、クエリの構築に固定長バッファを使用していました。
このモジュールはあくまでサンプルコードとして作成されたものですが、このような危険なエラーは含まれるべきではありません。
The <productname>PostgreSQL</productname> Project thanks Nikolay Samokhvalov for reporting this problem. (CVE-2026-6637) PostgreSQLプロジェクトは、本問題を報告してくれたNikolay Samokhvalovに感謝します。 (CVE-2026-6637)
Check for nondeterministic collations before assuming that an equality condition on a collatable type implies uniqueness (Richard Guo) 照合可能な型における等価条件が一意性を意味すると仮定する前に、非決定論的照合順序を確認するようになりました。 (Richard Guo) § § § § §
Numerous planner optimizations assume that, for example, at most one
table row can satisfy <literal>WHERE x = 'abc'</literal> if there is
a unique index on <literal>x</literal>. However this conclusion is
unsafe in general if the index and the <literal>WHERE</literal>
clause have different collations attached. It is safe when both
collations are deterministic, because that property essentially
requires that equality of two strings means bitwise equality. But
nondeterministic collations don't act that way, so that optimizing
on the assumption of unique matches can give wrong query answers if
either the <literal>WHERE</literal> clause or the index has a
nondeterministic collation.
多くのプランナ最適化では、例えばxに一意インデックスが存在する場合、WHERE x = 'abc'を満たすテーブル行は最大で1つであると仮定しています。
しかし、インデックスとWHERE句に異なる照合順序が設定されている場合には、この結論は一般的に安全ではありません。
両方の照合順序が決定論的である場合は安全です。なぜなら、その性質上、2つの文字列の等価性はビット単位の等価性を意味するからです。
しかし、非決定論的な照合順序はそのように動作しないため、WHERE句またはインデックスのいずれかに非決定論的照合順序が設定されている場合、一意一致を前提とした最適化は誤ったクエリ結果をもたらす可能性がありました。
Fix incomplete removal of relation references
in <literal>RestrictInfo</literal> structs during join removal
(Tom Lane)
結合の削除時にRestrictInfo構造体内のリレーション参照の削除が不完全になる問題が修正されました。
(Tom Lane)
§
This oversight has been shown to result in planner failures such as unexpected <quote>FULL JOIN is only supported with merge-joinable or hash-joinable join conditions</quote> errors. It may also have caused failure to consider valid plans in other cases. この見落としにより、「FULL JOIN is only supported with merge-joinable or hash-joinable join conditions」といった予期しないエラーが発生するなどプランナの失敗を引き起こすことが確認されています。 また、他の場合には、有効なプランを考慮できない原因となっていた可能性もありました。
Improve planner's matching of partition key columns to sub-query outputs (Richard Guo) プランナによるパーティションキー列とサブクエリ出力の照合が改善されました。 (Richard Guo) §
Strip no-op PlaceHolderVars from operands before comparing them to partition keys. This change enables partition pruning to succeed in some cases where it previously failed to recognize that a partition need not be scanned. オペランドをパーティションキーと比較する前に、オペランドから何もしない(no-op)PlaceHolderVarsを削除します。 この変更により、以前はパーティションのスキャンが不要であると認識できなかった場合でも、パーティション除去が成功するようになりました。
Fix self-join removal to handle join clauses that are bare boolean
columns, e.g. <literal>ON t1.boolcol</literal> (Andrei Lepikhov,
Tender Wang, Alexander Korotkov)
例えばON t1.boolcolのようなブール型列のみで構成される結合句を処理できるよう、自己結合の削除処理が修正されました。
(Andrei Lepikhov, Tender Wang, Alexander Korotkov)
§
Previously such a case led to a <quote>no relation entry
for relid <replaceable>N</replaceable></quote> error.
以前は、このような場合は「no relation entry for relid N」エラーが発生していました。
Fix <literal>UPDATE/DELETE ... WHERE CURRENT OF</literal> to work on
tables with virtual generated columns (Satyanarayana Narlapuram,
Dean Rasheed)
仮想生成列を持つテーブルでUPDATE/DELETE ... WHERE CURRENT OFが正常に動作するよう修正されました。
(Satyanarayana Narlapuram, Dean Rasheed)
§
Fix expansion of virtual generated columns
in <literal>EXCLUDED</literal> column references in <literal>INSERT
... ON CONFLICT</literal> (Satyanarayana Narlapuram, Dean Rasheed)
INSERT ... ON CONFLICT内でのEXCLUDED列参照における仮想生成列の展開が修正されました。
(Satyanarayana Narlapuram, Dean Rasheed)
§
Fix incorrect handling of <literal>NEW</literal> generated columns
in rule actions and rule qualifications (Richard Guo, Dean Rasheed)
ルールアクションおよびルール条件におけるNEW生成列の誤った処理が修正されました。
(Richard Guo, Dean Rasheed)
§
Previously, such column references would produce NULL
in <literal>INSERT</literal> cases, or be equivalent to
the <literal>OLD</literal> value in <literal>UPDATE</literal> cases.
以前は、このような列参照は、INSERTの場合にNULLとなり、UPDATEの場合はOLDの値と同じになっていました。
Fix spurious <quote>indexes on virtual generated columns are not supported</quote> errors (Robert Haas) 「indexes on virtual generated columns are not supported」という誤ったエラーが修正されました。 (Robert Haas) §
Creation of an expression index could sometimes incorrectly report this error. 式インデックスの作成時に、このエラーが誤って報告されることがありました。
Fix spurious <quote>generated columns are not supported in COPY FROM WHERE conditions</quote> errors (Tom Lane) 「generated columns are not supported in COPY FROM WHERE conditions」という誤ったエラーが修正されました。 (Tom Lane) §
Use of a system column in a <literal>COPY FROM WHERE</literal>
condition could sometimes incorrectly report this error.
COPY FROM WHERE条件でシステム列を使用すると、このエラーが誤って報告されることがありました。
Correctly report a serialization failure
when <command>MERGE</command> encounters a concurrently-updated
tuple in repeatable-read or serializable mode (Tender Wang)
MERGEがリピータブルリードモードまたはシリアライザブルモードで同時に更新されるタプルを検出した場合、直列化の失敗を正しく報告するようになりました。
(Tender Wang)
§
Previously, such cases behaved the same as in lower isolation levels. 以前は、このような場合は、より低い分離レベルの場合と同じ動作をしていました。
Fix <literal>CREATE TABLE ... LIKE ... INCLUDING
STATISTICS</literal> for cases where the source table has dropped
column(s) (Julien Tachoires)
ソーステーブルから列が削除された場合におけるCREATE TABLE ... LIKE ... INCLUDING STATISTICSの動作が修正されました。
(Julien Tachoires)
§
In such cases, extended statistics objects could be copied incorrectly, or the command could give an incorrect error. このような場合、拡張統計オブジェクトが誤ってコピーされたり、コマンドが誤ったエラーを返す可能性がありました。
Allow <literal>ALTER INDEX ... ATTACH PARTITION</literal> to mark
the parent index valid if appropriate (Sami Imseih)
ALTER INDEX ... ATTACH PARTITIONで、必要に応じて親インデックスを有効とマークできるようになりました。
(Sami Imseih)
§
There are edge cases in which a partitioned index might remain marked as invalid even when all its leaf indexes are valid. This change provides a mechanism whereby a user can correct such a situation without resorting to manual catalog updates. すべてのリーフインデックスが有効であるにもかかわらず、パーティションインデックスが無効とマークされたままになる特殊なケースが存在していました。 この変更により、ユーザは手動でカタログを更新せずに、このような状況を修正できる仕組みが提供されました。
Fix <literal>ALTER TABLE ... SET NOT NULL</literal> to invoke
object-access hook functions only after completing the catalog
change (Artur Zakirov)
ALTER TABLE ... SET NOT NULLが、カタログの変更を完了した後にのみオブジェクトアクセスフック関数を呼び出すよう修正されました。
(Artur Zakirov)
§
Fix <command>ALTER FOREIGN DATA WRAPPER</command> to not drop the
wrapper object's dependency on its handler function (Jeff Davis)
ALTER FOREIGN DATA WRAPPERが、ラッパーオブジェクトのハンドラ関数への依存を削除しないよう修正されました。
(Jeff Davis)
§
Fix loss of deferrability of foreign-key triggers (Yasuo Honda) 外部キートリガの遅延実行が失われる問題が修正されました。 (Yasuo Honda) §
Previously, a foreign key defined as <literal>DEFERRABLE INITIALLY
DEFERRED</literal> would behave as <literal>NOT DEFERRABLE</literal>
after being set to <literal>NOT ENFORCED</literal> status and then
back to <literal>ENFORCED</literal>.
以前は、DEFERRABLE INITIALLY DEFERREDとして定義された外部キーが、NOT ENFORCEDステータスに設定された後、再びENFORCEDに戻されるとNOT DEFERRABLEとして動作していました。
If you have a foreign key with this problem, it can be repaired
(after installing this update) by again setting it to <literal>NOT
ENFORCED</literal> and then back to <literal>ENFORCED</literal>.
この問題が発生している外部キーがある場合は、この更新をインストールした後に再度NOT ENFORCEDに設定してからENFORCEDに戻すことで修復できます。
Fix <literal>WITHOUT OVERLAPS</literal> to allow domains (Jian He)
ドメインを許可するようにWITHOUT OVERLAPSが修正されました。
(Jian He)
§
<literal>UNIQUE/PRIMARY KEY ... WITHOUT OVERLAPS</literal> requires
the no-overlap column to be a range or multirange, but it should
allow a domain over such a type too.
UNIQUE/PRIMARY KEY ... WITHOUT OVERLAPSでは、重複しない列がレンジまたはマルチレンジである必要がありますが、そのような型に対してもドメインを許可する必要がありました。
Disallow making a composite type be a member of itself via a multirange (Heikki Linnakangas) マルチ範囲型を経由して複合型が自分自身をメンバとして持つことが禁止されました。 (Heikki Linnakangas) §
We already forbade such cases when the intermediate type is a domain, array, composite type, or range; but multiranges were overlooked. 中間型がドメイン、配列、複合型、範囲型の場合はすでにこのようなケースを禁止していましたが、マルチ範囲型については見落とされていました。
Fix datum-image comparisons to be insensitive to sign-extension variations (David Rowley) Datumのイメージ比較が符号拡張の差異に影響されないように修正されました。 (David Rowley) §
This fixes some situations that previously led to <quote>could not find memoization table entry</quote> errors or wrong query results. これにより、以前は「could not find memoization table entry」というエラーや誤ったクエリ結果につながっていたいくつかの状況が修正されました。
Fix incorrect logic for hashed <literal>IN</literal>/<literal>NOT
IN</literal> with non-strict equality operator (Chengpeng Yan)
ハッシュ化されたIN/NOT INにおける非厳密な等価演算子の誤ったロジックが修正されました。
(Chengpeng Yan)
§
The previous coding could crash or give wrong answers. All built-in data types have strict equality operators, so that this issue could only arise with an extension data type. 以前のコードでは、クラッシュしたり、誤った結果が返される可能性がありました。 すべての組み込みデータ型には厳密な等価演算子があるため、この問題は拡張データ型でのみ発生する可能性がありました。
Truncate overly-long locale-specific numeric symbols
in <function>to_char()</function> (Tom Lane)
to_char()において、長すぎるロケール固有の数値記号を切り捨てるようになりました。
(Tom Lane)
§
If a locale specified a currency symbol, thousands separator, or decimal or sign symbol more than 8 bytes long, a buffer overrun was possible. No such locales exist in the real world, and it's impractical for an unprivileged attacker to install a malicious locale definition underneath a Postgres server; but for safety's sake check for overlength symbols and truncate if needed. ロケールで指定された通貨記号、千の位区切り記号、小数点記号、符号記号が8バイトを超える場合、バッファオーバーランが発生する可能性がありました。 現実の世界にはそのようなロケールは存在せず、権限のない攻撃者がPostgresサーバに悪意のあるロケール定義をインストールすることは現実的ではありませんが、安全のために、長すぎる記号をチェックし、必要に応じて切り捨てます。
Prevent buffer overruns when parsing an affix file for
an <literal>Ispell</literal> dictionary (Tom Lane)
Ispell辞書用の接辞ファイルを解析する際のバッファオーバーランが防止されました。
(Tom Lane)
§
§
A corrupt or malicious affix file could crash the server. This is not considered a security issue because text search configuration files are presumed trustworthy, but it still seems worth fixing. 破損した接辞ファイルや悪意のある接辞ファイルは、サーバをクラッシュさせる可能性がありました。 テキスト検索の設定ファイルは信頼できるものと見なされるため、これはセキュリティ上の問題とは考えられませんが、修正する価値があると思われます。
Guard against integer overflow in calculations of frame start and end positions for window aggregates (Richard Guo) ウィンドウ集約のフレーム開始位置および終了位置の計算において、整数オーバーフローが発生しないよう対策されました。 (Richard Guo) §
Very large user-specified offsets (close to INT64_MAX) could result in errors or incorrect query results. ユーザ指定のオフセット値が非常に大きい場合（INT64_MAXに近い値）では、エラーが発生したり、クエリの結果が不正確になる可能性がありました。
Fix <function>array_agg_array_combine()</function> to combine the
arrays' null bitmaps correctly (Dmytro Astapov)
配列のNULLビットマップを正しく結合するようarray_agg_array_combine()が修正されました。
(Dmytro Astapov)
§
This mistake resulted in sometimes-incorrect output from
parallelized <function>array_agg(anyarray)</function> calculations.
この不具合により、並列化されたarray_agg(anyarray)計算で、誤った出力が発生する場合がありました。
Retry <function>sync_file_range()</function> if it returns error
code <literal>EINTR</literal> (DaeMyung Kang)
sync_file_range()がエラーコードEINTRを返した場合に再試行するようになりました。
(DaeMyung Kang)
§
Fix incorrect behavior
of <function>pg_stat_reset_single_table_counters()</function> on a
shared catalog (Chao Li)
共有カタログにおけるpg_stat_reset_single_table_counters()の誤った動作が修正されました。
(Chao Li)
§
Such cases had a side-effect of resetting the
current database's <literal>stat_reset_timestamp</literal>, which
was unintended.
このような場合、現在のデータベースのstat_reset_timestampが意図せずリセットされるという副作用が発生していました。
Update activity statistics when a parallel apply worker is idle (Zhijie Hou) パラレル適用ワーカーがアイドル状態の時にアクティビティ統計が更新されるようになりました。 (Zhijie Hou) §
Previously, statistics from a recently-completed transaction might go unreported for long intervals, particularly if the workload is light. 以前は、特にワークロードが軽い場合、最近完了したトランザクションの統計情報が長時間で報告されない可能性がありました。
Fix <quote>no relation entry for relid 0</quote> failure while estimating array lengths in set operations (Tender Wang) 集合演算で配列長を推定する際に発生する「no relation entry for relid 0」エラーが修正されました。 (Tender Wang) §
Fix buffer overread when <function>pglz_decompress()</function>
receives corrupt input (Andrew Dunstan)
pglz_decompress()が破損した入力を受け取った際に発生するバッファの超過読取りが修正されました。
(Andrew Dunstan)
§
It was possible to read a few bytes past the end of the input, which in very unlucky cases might cause a crash. 入力の末尾を数バイト超えて読み取られる可能性があり、非常に不運な場合ではクラッシュを引き起こす可能性がありました。
Fix incremental JSON parser's handling of numeric tokens that cross input buffer boundaries (Andrew Dunstan) インクリメンタルJSONパーサにおいて入力バッファ境界をまたぐ数値トークンの処理が修正されました。 (Andrew Dunstan) §
It was possible to accept an incorrectly-formatted number, leading to failures later. 誤った形式の数値を受け入れる可能性があり、その結果後でエラーが発生する可能性がありました。
Prevent bloating relation visibility maps during restore of an incremental backup (Robert Haas) 増分バックアップのリストア時にリレーションの可視性マップが肥大化することが防止されました。 (Robert Haas) §
Restore could append many blocks of zeroes to a visibility map, due to incorrect computation of the expected file length. This does not result in data corruption, but it could waste a substantial amount of disk space. リストア時に、予想されるファイル長の計算が誤っているため、可視性マップに多数のゼロブロックが追加される可能性がありました。 これによりデータが破損することはありませんが、相当量のディスクスペースが無駄になる可能性がありました。
Use C collation, not the database's default collation, in catalog cache lookups on text columns (Jeff Davis) テキスト列のカタログキャッシュ検索では、データベースのデフォルト照合順序ではなく、C照合順序を使用するようになりました。 (Jeff Davis) §
This avoids failures in edge cases such as physical replication startup, where there is no identified database so that a default collation cannot be determined. これにより、物理レプリケーションの起動時など、データベースが特定されずデフォルト照合順序も決定できないような特殊なケースでの失敗が回避されます。
Prevent stuck slotsync worker processes from blocking promotion of a standby server (Nisha Moond, Ajin Cherian) 応答不能になったスロット同期ワーカープロセスがスタンバイサーバの昇格を妨げないようになりました。 (Nisha Moond, Ajin Cherian) § § §
A worker process that was vainly waiting for a response from the primary would delay promotion for an unreasonable amount of time. プライマリからの応答を無駄に待ち続けていたワーカープロセスが、昇格を不必要に長時間遅延させていました。
Fix excessive log output from idle slotsync worker processes (Zhijie Hou) アイドル状態のスロット同期ワーカープロセスによる過剰なログ出力が修正されました。 (Zhijie Hou) §
Ensure that tuplestore data structures are internally consistent even after an error (Tom Lane) エラー発生後もtuplestoreのデータ構造が内部的に一貫性を保つようになりました。 (Tom Lane) §
The code was previously careless about this, which is fine most of
the time but is problematic for the tuplestore backing
a <literal>WITH HOLD</literal> cursor. In v15 and before this
leads to easily-reproducible crashes; later branches are not known
to be vulnerable, but it seems best to preserve consistency in all.
以前のコードではこの点に関して不注意でした。ほとんどの場合は問題ないものの、WITH HOLDカーソルをサポートするtuplestoreでは問題が生じます。
バージョン15以前では、この問題により容易に再現可能なクラッシュが発生していました。それ以降のバージョンでは脆弱性は確認されていませんが、すべてのバージョンで一貫性を維持するのが最善と思われます。
Make the <structname>pg_aios</structname> system
view's <structfield>pid</structfield> column show NULL not
0 when an entry has no owning process (ChangAo Chen)
エントリに所有プロセスが無い場合、pg_aiosシステムビューのpid列に0ではなくNULLが表示されるようになりました。
(ChangAo Chen)
§
Fix premature NULL lag reporting
in <structname>pg_stat_replication</structname> (Shinya Kato)
pg_stat_replicationにおけるlag列での早すぎるNULL報告が修正されました。
(Shinya Kato)
§
The lag columns frequently read as NULL even while replication activity was happening. lag列が、レプリケーション処理が行われている最中でも、頻繁にNULLとして読み取られていました。
Fix under-allocation of shared memory used for parallel btree index scans (Siddharth Kothari) 並列Btreeインデックススキャンに使用される共有メモリの割り当て不足が修正されました。 (Siddharth Kothari) §
In edge cases this could result in a server crash. 特殊なケースでは、サーバがクラッシュする可能性がありました。
Avoid rare flush failure when working with non-WAL-logged GiST indexes (Tomas Vondra) WALログ非対応のGiSTインデックスを使用する際、稀に発生するフラッシュエラーが回避されました。 (Tomas Vondra) §
A non-logged GiST index could nonetheless sometimes
produce <quote>xlog flush request <replaceable>n/nnnn</replaceable>
is not satisfied</quote> errors, due to incorrect selection of
a <quote>fake LSN</quote> to represent an insertion point.
ログ非対応のGiSTインデックスでは、挿入ポイントを表す「偽のLSN」の選択ミスにより、「xlog flush requestn/nnnnis not satisfied」エラーが発生する場合がありました。
Fix underestimate of required size of DSA page maps for odd-size segments (Paul Bunn) 奇数サイズのセグメントにおけるDSAページマップの必要サイズの過小評価が修正されました。 (Paul Bunn) §
This miscalculation led to out-of-bounds accesses and hence server crashes. この計算ミスにより、境界外アクセスが発生し、サーバがクラッシュしていました。
Fix indexing of oldest-multixact arrays in shared memory (Yura Sokolov) 共有メモリ内の最も古いmultixact配列のインデックス付けが修正されました。 (Yura Sokolov) § §
This mistake could cause a prepared-but-not-yet-committed transaction's row locks to appear invisible to other sessions, or other visibility issues for the results of such a transaction. With a very small max_connections setting, memory stomps were also possible. この不具合により、PREPARED状態であるがまだコミットされていないトランザクションの行ロックが他のセッションから見えなくなったり、そのようなトランザクションの結果の可視性に他の問題が発生する可能性がありました。 また、max_connectionsの設定値が非常に小さい場合、メモリ破壊も発生する可能性がありました。
Fix array overrun when too many <command>EXPLAIN</command> extension
options are installed (Joel Jacobson)
EXPLAIN拡張オプションが多数インストールされている場合に発生する配列オーバーランが修正されました。
(Joel Jacobson)
§
Fix possible server crash when processing extended statistics on expressions of extension data types (Michael Paquier) 拡張データ型の式に対する拡張統計処理時に発生する可能性のあるサーバクラッシュが修正されました。 (Michael Paquier) §
NULL pointer dereferences were possible if the data type's typanalyze function does not compute any useful statistics. No in-core typanalyze function behaves that way, but extensions could. データ型のtypanalyze関数が有用な統計を計算しない場合、NULLポインタの参照が発生する可能性がありました。 コア内のtypanalyze関数はそのように動作をするものはありませんが、拡張では可能性がありました。
Correctly display join alias Vars that are used in <literal>GROUP
BY</literal> (Tom Lane)
GROUP BYで使用される結合エイリアス変数が正しく表示されるようになりました。
(Tom Lane)
§
In views containing queries like <literal>SELECT ... t1 LEFT JOIN t2
USING (x) GROUP BY x</literal>, the <literal>GROUP BY</literal>
clause could be displayed incorrectly by deparsing, leading to
dump/restore failures. Failures occurred only
if <literal>t1.x</literal> and <literal>t2.x</literal> were not of
identical data types and <literal>t1.x</literal> was the side that
required an implicit coercion.
SELECT ... t1 LEFT JOIN t2 USING (x) GROUP BY xのような問い合わせを含むビューでは、GROUP BY句が逆解析によって誤って表示され、ダンプ/リストアの失敗につながる可能性がありました。
この問題は、t1.xとt2.xのデータ型が同一ではなく、t1.x側で暗黙の型変換が必要だった場合にのみ発生しました。
Fix minor memory leaks in ICU-based string processing (Jeff Davis) ICUベースの文字列処理における軽微なメモリリークが修正されました。 (Jeff Davis) §
If the startup process fails, properly shut down other child processes before exiting the postmaster (Ayush Tiwari) startupプロセスが失敗した場合、postmasterを終了する前に他の子プロセスを適切にシャットダウンするようになりました。 (Ayush Tiwari) §
The handling of this situation relied on a long-obsolete assumption that no other postmaster children exist while the startup process is running, so that immediate postmaster exit is acceptable. Orphaned children would eventually notice the postmaster's death and exit on their own, but a cleaner shutdown procedure is desirable. この状況への対処法は、startupプロセスの実行中は他のpostmasterの子プロセスが存在しないという、現在では廃止された前提に基づいていたため、postmasterの即時終了は許容されていました。 孤児となった子プロセスは最終的にpostmasterの終了を検知して自力で終了しますが、よりクリーンなシャットダウン手続きが望まれます。
Fix race condition between WAL replay of checkpoints and multixact ID creations (Heikki Linnakangas) チェックポイントのWALリプレイ処理とマルチトランザクションID作成との間の競合状態が修正されました。 (Heikki Linnakangas) §
A standby server following WAL from a primary of an older minor version could get into a crash-and-restart loop complaining about <quote>could not access status of transaction</quote>. 古いマイナーバージョンのプライマリサーバからのWALを追従するスタンバイサーバが、「could not access status of transaction」というエラーを表示し、クラッシュと再起動を繰り返すループに陥る可能性がありました。
Prevent indefinite wait in shutdown of a walsender process (Anthonin Bonnefoy) walsenderプロセスのシャットダウン時に発生する無期限の待機が防止されました。 (Anthonin Bonnefoy) § §
At shutdown of a cluster that is publishing logical replication data, the walsender waits for all pending WAL to be written out. But it did not correctly request that to happen, so that in some cases this could become an indefinite wait. 論理レプリケーションデータを公開しているクラスタのシャットダウン時、walsenderは保留中のすべてのWALが書き出されるまで待機します。 しかし、その処理を正しく要求しなかったため、場合によっては無期限の待機となる可能性がありました。
Ensure that changes to tables' free space maps are persisted during recovery (Alexey Makhmutov) テーブルの空き領域マップへの変更が、リカバリ中に確実に永続化されるようになりました。 (Alexey Makhmutov) §
Previously, while WAL replay did update the free space map while replaying operations that should change it, the map page buffer did not get marked dirty if checksums are enabled, so that the changes might never get written out. On a standby server, over time this would result in a map wildly at variance with the table's actual contents. While the map is only used as a hint, this condition could cause significant performance degradation for some period of time after the standby server is promoted to be active, until most of the map has been repaired by updates. 以前は、WALリプレイは変更が必要な操作をリプレイする際に空き領域マップを更新していましたが、チェックサムが有効になっている場合、マップのページバッファがダーティとしてマークされなかったため、変更内容が書き出されない可能性がありました。 スタンバイサーバでは、時間の経過とともに、マップがテーブルの実際の内容と大きく乖離してしまう可能性がありました。 マップはヒントとしてのみ使用されますが、この状態はスタンバイサーバがアクティブに昇格した後、マップの大部分が更新によって修復されるまでの間、パフォーマンスの著しい低下を引き起こす可能性がありました。
Fix crashes in some <application>ecpg</application> functions when called without any established connection (Shruthi Gowda) 接続が確立されていない状態で呼び出された際に、一部のecpg関数がクラッシュする問題が修正されました。 (Shruthi Gowda) §
Harden tar-file parsing logic against archives it can't handle (Tom Lane) 処理できないアーカイブに対するtarファイル解析ロジックが強化されました。 (Tom Lane) §
The tar-file reading code used in <application>pg_basebackup</application> and <application>pg_verifybackup</application> failed to verify that the input is a tar file at all, let alone that it fits into the subset of valid tar files that we can handle. This isn't a problem for the normal scenario where the input file was generated by <productname>PostgreSQL</productname> code, but it can be an issue if the input has been generated by some other <application>tar</application> program. pg_basebackupとpg_verifybackupで使用されているtarファイルの読み取りコードは、入力がtarファイルであることをまったく検証できず、ましてや、処理可能な有効なtarファイルのサブセットに該当するかどうかも検証できていませんでした。 これは、入力のファイルがPostgreSQLコードによって生成された場合の通常のシナリオでは問題になりませんが、入力が他のtarプログラムによって生成された場合には問題になる可能性がありました。
Fix assorted bugs in backup decompression and tar-parsing code (Andrew Dunstan, Tom Lane, Chao Li) バックアップの解凍およびtarファイル解析コードのさまざまなバグが修正されました。 (Andrew Dunstan, Tom Lane, Chao Li) § § §
The decompression and tar-file reading code used in <application>pg_basebackup</application> and <application>pg_verifybackup</application> mishandled tar-file padding data, could corrupt LZ4-compressed data in edge cases, failed to check for some unusual error conditions, failed to exit after compression/decompression errors (leading to cascading error reports), and leaked memory. pg_basebackupおよびpg_verifybackupで使用されている解凍およびtarファイル読み取りコードは、tarファイルのパディングデータ処理に不備があり、特殊なケースではLZ4圧縮データが破損する可能性があり、一部の異常なエラー状態チェックの失敗、圧縮/解凍エラー後に終了できず（連鎖的なエラー報告の原因）、さらにメモリリークも発生していました。
In <application>pg_dump</application>, preserve <literal>NO
INHERIT</literal> property of <literal>NOT NULL</literal>
constraints (Jian He)
pg_dumpでNOT NULL制約のNO INHERITプロパティを保持するようになりました。
(Jian He)
§
Some cases missed printing the <literal>NO INHERIT</literal> clause.
一部のケースでNO INHERIT句が出力されないことがありました。
In <application>pg_dumpall</application>, don't skip
role <literal>GRANT</literal>s with dangling grantor OIDs
(Tom Lane)
pg_dumpallで、権限付与者のOIDが存在しないロールのGRANTがスキップされなくなりました。
(Tom Lane)
§
Instead, handle such cases by emitting <literal>GRANT</literal>
without any <literal>GRANTED BY</literal> clause, as we did before
v16. This avoids losing the grant in foreseeable cases, since
pre-v16 servers didn't prevent dropping the grantor role. Continue
to emit a warning about the missing grantor, but only if the source
server is v16 or later.
代わりに、v16以前と同様に、GRANTED BY句のないGRANTを出力することで、このケースを処理します。
v16以前のサーバでは権限付与者のロール削除が阻止されなかったため、これにより予測可能なケースでの権限付与の喪失が回避されます。
ソースサーバがv16以降の場合に限り、権限付与者の欠落に関する警告は引き続き出力されます。
In <application>pg_upgrade</application>, take care to use the correct protocol version when connecting to older source servers (Jacob Champion) pg_upgradeで、古いソースサーバに接続する際に、正しいプロトコルバージョンを使用するように修正されました。 (Jacob Champion) §
This could be problematic when attempting to upgrade from a pre-2018 server. これは、2018年以前のサーバからアップグレードしようとする際に問題となる可能性がありました。
In <filename>contrib/basic_archive</filename>, allow the archive
directory to be missing at startup (Nathan Bossart)
contrib/basic_archiveにおいて、起動時にアーカイブディレクトリが存在しなくても許容されるようになりました。
(Nathan Bossart)
§
Previously, the setting
of <literal>basic_archive.archive_directory</literal> was rejected
if it didn't point to an existing directory. This is undesirable
because archiving will be stuck indefinitely, even if the directory
appears later.
以前は、basic_archive.archive_directoryの設定が既存のディレクトリを指していない場合、拒否されていました。
これは、後からディレクトリが作成されたとしてもアーカイブ処理が永久に停止してしまうため、望ましくありませんでした。
Fix <filename>contrib/ltree</filename> to cope when case-folding
changes a string's byte length (Jeff Davis)
大文字小文字を区別しない処理によって文字列のバイト長が変化する場合に対応できるようcontrib/ltreeが修正されました。
(Jeff Davis)
§
§
Previously, <type>lquery</type> patterns specifying case-insensitive
matching might fail to match labels they should match.
以前は、大文字小文字を区別しないマッチングを指定するlqueryパターンが、本来マッチングするはずのラベルにマッチングしない場合がありました。
Fix mis-structured output
from <filename>contrib/pg_overexplain</filename>'s
<literal>RANGE_TABLE</literal> option (Satyanarayana Narlapuram)
contrib/pg_overexplainのRANGE_TABLEオプションの出力構造の不具合が修正されました。
(Satyanarayana Narlapuram)
§
Some fields were misplaced in JSON, YAML, and XML formats, resulting in structurally invalid output. JSON、YAML、XML形式において、一部のフィールドの位置が誤っていたため、構造的に無効な出力が生成されていました。
In <filename>contrib/pg_stat_statements</filename>, don't leak
memory if an error occurs while parsing the
<filename>pgss_query_texts.stat</filename> file (Heikki Linnakangas)
contrib/pg_stat_statementsでpgss_query_texts.statファイルの解析中にエラーが発生した場合に、メモリリークしないように修正されました。
(Heikki Linnakangas)
§
In <filename>contrib/postgres_fdw</filename>, avoid crash due to
premature cleanup of a failed connection (Etsuro Fujita)
contrib/postgres_fdwにおいて、接続失敗時の早期クリーンアップによるクラッシュが回避されました。
(Etsuro Fujita)
§
If a remote connection fails abort cleanup, we can't use it any longer. But delay closing the connection object until end of transaction, because there might still be references to it within data structures such as open cursors. リモート接続が失敗した場合、クリーンアップを中止すればその接続はもはや使用できなくなります。 しかし、オープンカーソルなどのデータ構造内に接続オブジェクトへの参照が残っている可能性があるため、トランザクションの終わりまで接続オブジェクトのクローズが遅延されます。
Update time zone data files to <application>tzdata</application> release 2026b (Tom Lane) タイムゾーンデータファイルがtzdataリリース2026bに更新されました。 (Tom Lane) §
British Columbia (America/Vancouver) will be on year-round UTC-07
(effectively, permanent DST) beginning in November 2026. This
release assumes that their TZ abbreviation will
be <literal>MST</literal> from that time forward. That seems likely
to change, but it's unclear what new abbreviation will be used.
Also a historical correction for Moldova: they have followed EU DST
transition times since 2022.
ブリティッシュコロンビア州(America/Vancouver)は、2026年11月から年間を通してUTC-07（事実上の恒久的な夏時間）になります。
このリリースでは、それ以降同地域のタイムゾーン略称がMSTになると想定しています。
これは変更される可能性が高いですが、新しい略称が使用されるかどうかは不明です。
また、モルドバの歴史的な修正事項として、モルドバは2022年以降、EUの夏時間切り替え時刻に従っています。