バージョンごとのドキュメント一覧

E.1. Release 18.6 #

<title>Release date:</title> リリース日: 2026-08-13

This release contains a variety of fixes from 18.4. For information about new features in major release 18, see <xref linkend="release-18"/>. このリリースは18.4に対し、様々な不具合を修正したものです。 18メジャーリリースにおける新機能については、E.6を参照してください。

Note: 18.5 was never released, due to a regression discovered post-wrap. 《機械翻訳》ノート:18.5は、ラップ後に発見されたリグレッションのため、リリースされませんでした。

E.1.1. バージョン18.6への移行 #

<title>Migration to Version 18.6</title>

A dump/restore is not required for those running 18.X. 18.Xからの移行ではダンプ/リストアは不要です。

However, the first three security entries below describe configuration adjustments and data cleanups that you may need to make after updating. 《機械翻訳》ただし、以下の最初の3つのセキュリティ項目では、更新後にmakeする必要がある設定調整とデータ清掃について説明します。

Also, if you have any GIN indexes, see the changelog entry below about possibly-corrupt <structfield>reltuples</structfield> values for their tables. 《機械翻訳》また、GINインデックスがある場合は、以下のエントリの変更ログで破損の可能性reltuplesテーブルの値について確認してください。

Also, if you use <filename>contrib/btree_gist</filename> or <filename>contrib/ltree</filename>, you may need to reindex indexes made with those extensions; see the relevant entries below. 《機械翻訳》また、contrib/btree_gistまたはcontrib/ltreeを使用する場合は、これらの拡張で作成されたインデックスをインデックス再作成する必要があるかもしれません。 以下の関連するエントリを参照してください。

Also, if you are upgrading from a version earlier than 18.2, see <xref linkend="release-18-2"/>. 《機械翻訳》また、18.2より前のバージョンからアップグレードする場合は、E.4を参照してください。

E.1.2. 変更点 #

<title>Changes</title>
  • Author: Jacob Champion <jchampion@postgresql.org> Branch: master [226e49cbe] 2026-08-10 06:37:49 -0700 Branch: REL_19_STABLE [5d47df21e] 2026-08-10 06:38:05 -0700 Branch: REL_18_STABLE [2a29b607d] 2026-08-10 06:38:12 -0700 Branch: REL_17_STABLE [01992176e] 2026-08-10 06:38:18 -0700 Branch: REL_16_STABLE [4e1252ee5] 2026-08-10 06:38:24 -0700 Branch: REL_15_STABLE [99f205407] 2026-08-10 06:38:30 -0700 Branch: REL_14_STABLE [bf3842a64] 2026-08-10 06:38:36 -0700 Author: Jacob Champion <jchampion@postgresql.org> Branch: master [20e9dcefd] 2026-08-10 06:37:49 -0700 Branch: REL_19_STABLE [7082ce248] 2026-08-10 06:38:05 -0700 Branch: REL_18_STABLE [82fd68801] 2026-08-10 06:38:12 -0700 Branch: REL_17_STABLE [4fcccea97] 2026-08-10 06:38:18 -0700

    Restrict logical decoding output plugins to the set specified by a new server parameter <varname>output_plugin_libraries</varname> (Jacob Champion) 《機械翻訳》ロジカルデコーディング出力プラグインを、新しいサーバパラメータoutput_plugin_libraries. (Jacob Champion) § §

    Previously, a replication user could select any loadable library for logical decoding, allowing exploits of various sorts. To allow locking this down without breaking setups that worked before, introduce a whitelist of allowed output plugins. 《機械翻訳》これまでは、レプリケーションユーザはロジカルデコーディングのロード可能ライブラリをセレクトすることができ、さまざまな種類のエクスプロイトを可能にしていた。 前で動作していたセットアップを壊すことなくこのダウンをロックできるようにするために、許可されたアウトプットプラグインのホワイトリストを導入した。

    By default, only the output plugins shipped as part of <productname>PostgreSQL</productname> (<literal>pgoutput</literal> and <literal>test_decoding</literal>) are included in <varname>output_plugin_libraries</varname>. Installations that rely on other output plugins must add them after updating the server, for example 《機械翻訳》デフォルト別では、パートで出荷されたPostgreSQLpgoutputおよびtest_decodingの出力プラグインのみがoutput_plugin_librariesに含まれます。 他の出力プラグインに依存するインストールでは、例のサーバ更新の後にそれらを追加する必要があります。

    output_plugin_libraries = 'pgoutput, test_decoding, my_trusted_decoder'
    

    Additionally, <command>pg_upgrade &#45;-check</command> will fail if the <varname>output_plugin_libraries</varname> parameter on the new cluster does not permit the plugins of logical replication slots on the old cluster, when migrating from versions 17 and later. Make necessary additions to the new cluster's setting before performing <application>pg_upgrade</application>. 《機械翻訳》さらに、pg_upgrade--チェックは、バージョン17以降から移行する場合、output_plugin_libraries新しいクラスタのパラメータが古いクラスタの論理レプリケーションスロットのプラグインを許可しない場合に失敗します。 makeは、新しいクラスタの設定前に必要な追加を実行しますpg_upgrade

    The <productname>PostgreSQL</productname> Project thanks Vladimir Tokarev and Yu Kunpeng for reporting this problem. (CVE-2026-6471) PostgreSQLプロジェクトは、本問題を報告してくれたVladimir TokarevとYu Kunpengに感謝します。 (CVE-2026-6471)

  • Author: Daniel Gustafsson <dgustafsson@postgresql.org> Branch: master [d0ecee6de] 2026-08-10 06:37:50 -0700 Branch: REL_19_STABLE [ba207f58f] 2026-08-10 06:38:06 -0700 Branch: REL_18_STABLE [fe32b10fc] 2026-08-10 06:38:13 -0700 Branch: REL_17_STABLE [b05cfc693] 2026-08-10 06:38:19 -0700 Branch: REL_16_STABLE [6ca6023ca] 2026-08-10 06:38:25 -0700 Branch: REL_15_STABLE [472ef7e4a] 2026-08-10 06:38:31 -0700 Branch: REL_14_STABLE [7e29eb6f4] 2026-08-10 06:38:37 -0700 Author: Jacob Champion <jchampion@postgresql.org> Branch: master [49e795414] 2026-08-10 06:37:50 -0700 Branch: REL_19_STABLE [d97b3f58c] 2026-08-10 06:38:06 -0700 Branch: REL_18_STABLE [4c5128ca0] 2026-08-10 06:38:13 -0700 Branch: REL_17_STABLE [7eed42aa8] 2026-08-10 06:38:19 -0700 Branch: REL_16_STABLE [ba2a63faf] 2026-08-10 06:38:25 -0700 Branch: REL_15_STABLE [953be116c] 2026-08-10 06:38:31 -0700 Branch: REL_14_STABLE [e2c48c81f] 2026-08-10 06:38:37 -0700

    Fix <filename>contrib/pgcrypto</filename>'s PGP encryption to detect unsupported ciphers (Daniel Gustafsson) 《機械翻訳》サポートされていない暗号を検出するために、contrib/pgcryptoのPGP暗号化を修正。 (Daniel Gustafsson) § §

    Previously, if OpenSSL rejected the requested cipher (for example, because it is running in FIPS mode, or the legacy provider hasn't been loaded), <application>pgcrypto</application> failed to notice the failure and simply XOR'd the non-encrypted block with the plaintext, rendering the <quote>encryption</quote> trivially breakable. This will typically occur with deprecated or non-FIPS cipher algorithms (cipher-algo=blowfish/bf, twofish, cast5, or 3des). 《機械翻訳》以前は、OpenSSLが要求された暗号を拒否した場合(FIPS例で実行されているか、レガシープロバイダがロードされていないため、モード用、pgcrypto失敗に気づかず、暗号化されていないブロックとプレーンテキストを単純にXORして、暗号化を些細な解読可能なものにしていました。 これは通常、非推奨またはFIPS以外の暗号アルゴリズム(cipher-algo=blowfish/bf、twofish、キャスト5、または3 des)で発生します。

    By default, <application>pgcrypto</application> will now fail to decrypt any messages that were affected in this way. To allow retrieval of such data, a new option <literal>ignore-cipher-failure</literal> has been added to <function>pgp_pub_decrypt()</function> and <function>pgp_sym_decrypt()</function>. Setting <literal>ignore-cipher-failure=1</literal> will restore their previous behavior, allowing the faulty encryption wrapper to be stripped off: 《機械翻訳》デフォルトにより、pgcryptoはこの方法で影響を受けたメッセージの復号化に失敗するようになりました。 このようなデータを取得できるようにするために、新しいオプションignore-cipher-failurepgp_pub_decrypt()pgp_sym_decrypt()。 Setting ignore-cipher-failure=1は以前の動作をリストアし、欠陥のある暗号化ラッパーをオフから取り除くことができますに追加されました。

    pgp_sym_decrypt(encrypted_column, any key, 'ignore-cipher-failure=1')
    

    Once the affected messages are identified and stripped of their wrappers, they can then be re-encrypted with a modern algorithm. It is important however that the behavior of OpenSSL be the same as it was when the faulty messages were created: if the set of unsupported algorithms is not the same, this approach will not work. See the documentation for <literal>ignore-cipher-failure</literal>. 《機械翻訳》影響を受けたメッセージが特定され、ラッパーが取り除かれると、最新のアルゴリズムで再暗号化できます。 ただし、OpenSSLの動作が、欠陥のあるメッセージが作成されたときと同じであることが重要です。 サポートされていないアルゴリズムのセットが同じでない場合、このアプローチは機能しません。 については、文書を参照してくださいignore-cipher-failure

    The <productname>PostgreSQL</productname> Project thanks Shishir Sharma for reporting this problem. (CVE-2026-14663) PostgreSQLプロジェクトは、本問題を報告してくれたShishir Sharmaに感謝します。 (CVE-2026-14663)

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [3045a25ba] 2026-08-10 06:37:50 -0700 Branch: REL_19_STABLE [d6ab88d37] 2026-08-10 06:38:06 -0700 Branch: REL_18_STABLE [29921259e] 2026-08-10 06:38:13 -0700 Branch: REL_17_STABLE [46fa1f6f3] 2026-08-10 06:38:19 -0700 Branch: REL_16_STABLE [2bdfd5cdc] 2026-08-10 06:38:25 -0700 Branch: REL_15_STABLE [3fdcfa8f7] 2026-08-10 06:38:31 -0700 Branch: REL_14_STABLE [5c51ae455] 2026-08-10 06:38:36 -0700 Branch: master [cf754f741] 2026-08-10 06:37:50 -0700 Branch: REL_19_STABLE [8cf01e213] 2026-08-10 06:38:06 -0700 Branch: REL_18_STABLE [900894d35] 2026-08-10 06:38:13 -0700 Branch: REL_17_STABLE [dca6627de] 2026-08-10 06:38:19 -0700 Branch: REL_16_STABLE [db96e87f9] 2026-08-10 06:38:25 -0700 Branch: REL_15_STABLE [8cdbabea7] 2026-08-10 06:38:31 -0700 Branch: REL_14_STABLE [7215c7e96] 2026-08-10 06:38:36 -0700

    Fix <application>psql</application> to skip in-line data following a scripted <command>COPY ... FROM STDIN</command> command, even if the <command>COPY</command> fails before sending <literal>PGRES_COPY_IN</literal> (Tom Lane) 《機械翻訳》COPYpsqlの送信に失敗した場合でも、スクリプト化されたCOPY ... FROM STDINデータに従って、直線内のコピーコマンドに前を修正する。 PGRES_COPY_IN (Tom Lane) § §

    Previously, if a <literal>COPY</literal> command failed at startup (for instance, because the target table doesn't exist) <application>psql</application> would not realize that and would proceed to read the following in-line data as SQL commands. In the best case that's wrong and in the worst case it's a SQL-injection hazard. Teach <application>psql</application> to recognize syntactically-valid <command>COPY ... FROM STDIN</command> commands and to skip data on its own authority if the server doesn't respond with <literal>PGRES_COPY_IN</literal>. 《機械翻訳》これまでは、COPYコマンドがスタートアップで失敗した場合インスタンスにはターゲットテーブルが存在しないためpsqlはそれを認識せず、以下の直線データ内をSQLコマンドとして読み進めていました。 ベストケースでは間違いであり、最悪のケースではSQLインジェクションハザードです。 psqlに構文的に有効なコピー.FROM STDINコマンドを認識させ、サーバがPGRES_COPY_INで応答しない場合はスキップデータを権限上でにするように教えました。

    While this fix is unlikely to affect any production SQL scripts, test scripts might intentionally exercise failing <command>COPY ... FROM STDIN</command> commands. Those will need to gain a <literal>\.</literal> data terminator line after each such command. 《機械翻訳》この修正が稼働のSQLスクリプトに影響を与える可能性は低いですが、テストスクリプトが意図的に練習で失敗するコピー.FROM STDINコマンドを実行する可能性があります。 これらのスクリプトは、このようなコマンドの後に\.データターミネータ直線を取得する必要があります。

    The <productname>PostgreSQL</productname> Project thanks Alexander Lakhin for reporting this problem. (CVE-2026-6464) PostgreSQLプロジェクトは、本問題を報告してくれたAlexander Lakhinに感謝します。 (CVE-2026-6464)

  • Author: Robert Haas <rhaas@postgresql.org> Branch: master [9e02e2e18] 2026-08-10 06:37:49 -0700 Branch: REL_19_STABLE [64a65ead1] 2026-08-10 06:38:05 -0700 Branch: REL_18_STABLE [37b8f3b0e] 2026-08-10 06:38:12 -0700 Branch: REL_17_STABLE [60887d348] 2026-08-10 06:38:18 -0700 Branch: REL_16_STABLE [7d150b5c9] 2026-08-10 06:38:24 -0700 Branch: REL_15_STABLE [fc933ce00] 2026-08-10 06:38:30 -0700 Branch: REL_14_STABLE [1f49beef2] 2026-08-10 06:38:36 -0700

    Cross-check the output row type of a portal running <command>EXECUTE</command> or <command>FETCH</command> (Robert Haas) 《機械翻訳》クロス-チェックEXECUTEまたはFETCH.を実行する行の出力ポータルタイプ。 (Robert Haas) §

    <command>EXECUTE</command> and <command>FETCH</command> use two portals: an outer one for the statement itself, and an inner one running the query being executed on its behalf. It was previously possible to make the declared row types of the two portals diverge, leading to server memory disclosure and arbitrary code execution. 《機械翻訳》EXECUTEおよびFETCH 2つのポータルを使用します。 1つはステートメント自分自身用の外部ポータルで、もう1つは問い合わせを実行する内部ポータルです。 以前は、2つのポータルの宣言された行タイプをmakeすることが可能であったため、サーバメモリの開示と任意のコードの実行につながりました。

    The <productname>PostgreSQL</productname> Project thanks Ben Morris (in collaboration with Claude and Anthropic Research) and Peter Geoghegan for reporting this problem. (CVE-2026-16239) PostgreSQLプロジェクトは、本問題を報告してくれたBen Morris(Claude and Anthropic Researchと共同で)とPeter Geogheganに感謝します。 (CVE-2026-16239)

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [3d724bf4f] 2026-08-10 06:37:47 -0700 Branch: REL_19_STABLE [3294ab839] 2026-08-10 06:38:03 -0700 Branch: REL_18_STABLE [4fafe2380] 2026-08-10 06:38:10 -0700 Branch: REL_17_STABLE [12a620686] 2026-08-10 06:38:17 -0700 Author: Álvaro Herrera <alvherre@kurilemu.de> Branch: REL_16_STABLE [5dbeb69bc] 2026-07-29 17:15:45 +0200 Branch: REL_15_STABLE [8f64cc83f] 2026-07-29 17:15:45 +0200 Branch: REL_14_STABLE [5fb3c6389] 2026-07-29 17:15:45 +0200

    Fix buffer overrun with long time zone abbreviation in <function>to_char()</function> (Tom Lane) 《機械翻訳》to_char()では、バッファオーバーランを長いタイムゾーン省略形で固定します。 (Tom Lane) §

    This can easily crash the server, and exploits leading to arbitrary code execution have been reported. 《機械翻訳》これは容易にサーバをクラッシュすることができ、恣意的なコードの実行につながるエクスプロイトが報告されている。

    The <productname>PostgreSQL</productname> Project thanks Hcamael, Amjad Shahzad, Tan Zhen of AntAISecurityLab, Tomer Fichman, Zheng Yu, Amy Burnett (OpenAI Codex Security), Rick de Jager, Heewon Song, Sylvie Mayer, Aleksander Alekseev, and Hillai Ben Sasson for reporting this problem. (CVE-2026-14669) 《機械翻訳》PostgreSQLプロジェクトは、本問題を報告してくれたHcamael、Amjad Shahzad、AntAISecurityLabのTan Zhen、Tomer Fichman、Zheng Yu、Amy Burnett(OpenAI Codexセキュリティ)、Rick de Jager、Heewon Song、Sylvie Mayer、Aleksander Alekseev、およびHillai Ben Sassonに感謝します。 CVE-2026-14669。

  • Author: Masahiko Sawada <msawada@postgresql.org> Branch: master [343aabf1d] 2026-08-10 06:37:48 -0700 Branch: REL_19_STABLE [7df2aa8ef] 2026-08-10 06:38:04 -0700 Branch: REL_18_STABLE [b7e5c3f63] 2026-08-10 06:38:10 -0700 Branch: REL_17_STABLE [e91dcfcca] 2026-08-10 06:38:17 -0700 Branch: REL_16_STABLE [3179253c2] 2026-08-10 06:38:23 -0700 Branch: REL_15_STABLE [127a0673f] 2026-08-10 06:38:29 -0700 Branch: REL_14_STABLE [890327639] 2026-08-10 06:38:35 -0700

    Fix buffer overrun in regexp match/split functions (Masahiko Sawada) 《機械翻訳》regexpバッファオーバーラン/split関数のマッチを修正しました。 (Masahiko Sawada) §

    If passed invalidly-encoded data, these functions could write past the end of their conversion buffer. 《機械翻訳》不正にエンコードされたデータが渡された場合、これらの関数は変換バッファの末尾を超えて書き込む可能性があります。

    The <productname>PostgreSQL</productname> Project thanks Francesco Verardi for reporting this problem. (CVE-2026-14664) PostgreSQLプロジェクトは、本問題を報告してくれたFrancesco Verardiに感謝します。 (CVE-2026-14664)

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master [a16c31d39] 2026-08-10 06:37:50 -0700 Branch: REL_19_STABLE [80ce920a5] 2026-08-10 06:38:06 -0700 Branch: REL_18_STABLE [08e812c02] 2026-08-10 06:38:13 -0700 Branch: REL_17_STABLE [849da8210] 2026-08-10 06:38:19 -0700 Branch: REL_16_STABLE [ac450853d] 2026-08-10 06:38:25 -0700 Branch: REL_15_STABLE [3b925133b] 2026-08-10 06:38:31 -0700 Branch: REL_14_STABLE [42d333a78] 2026-08-10 06:38:36 -0700

    Harden the <function>ascii()</function> function against invalid input (Michael Paquier) 《機械翻訳》無効な入力に対してascii()関数を固定します。 (Michael Paquier) §

    By supplying invalidly-encoded input, this function could be coaxed to read and return a few bytes of data that it shouldn't. In assert-enabled builds, its assertions could be triggered too. 《機械翻訳》無効にエンコードされた入力を提供することで、この関数は、読み取るべきではない結果の数バイトを読み取り、データするように誘導することができます。 assertが有効なビルドでは、そのアサーションもトリガされる可能性があります。

    The <productname>PostgreSQL</productname> Project thanks Hcamael for reporting this problem. (CVE-2026-18024) PostgreSQLプロジェクトは、本問題を報告してくれたHcamaelに感謝します。 (CVE-2026-18024)

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master [57835938f] 2026-08-10 06:37:49 -0700 Branch: REL_19_STABLE [b3d9262bb] 2026-08-10 06:38:05 -0700 Branch: REL_18_STABLE [08454e8b2] 2026-08-10 06:38:12 -0700 Branch: REL_18_STABLE [8d428c6e6] 2026-08-10 06:38:12 -0700

    Fix multirange type handling in <function>pg_restore_attribute_stats()</function> (OpenAI Security Research Team) 《機械翻訳》複数範囲のタイプハンドリングをpg_restore_attribute_stats()で修正します。 (OpenAI Security Research Team) § §

    <function>pg_restore_attribute_stats()</function> treated multirange types just like their underlying range type. This works correctly for the bounds histogram, but it was wrong for all the other statistics kinds. 《機械翻訳》pg_restore_attribute_stats()は基底の範囲型と同じように多重範囲型を扱いました。 これは境界のヒストグラムでは正しく動作しますが、他のすべての種類の間違いでは統計処理でした。

    The <productname>PostgreSQL</productname> Project thanks Amy Burnett (OpenAI Codex Security) for reporting this problem. (CVE-2026-16238) PostgreSQLプロジェクトは、本問題を報告してくれたAmy Burnett(OpenAI Codex Security)に感謝します。 (CVE-2026-16238)

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [8f0c3d2fe] 2026-08-10 06:37:48 -0700 Branch: REL_19_STABLE [0d60ee717] 2026-08-10 06:38:04 -0700 Branch: REL_18_STABLE [a2cb5a1cf] 2026-08-10 06:38:11 -0700 Branch: REL_17_STABLE [0ebf896f4] 2026-08-10 06:38:17 -0700 Branch: REL_16_STABLE [591192e2e] 2026-08-10 06:38:23 -0700 Branch: REL_15_STABLE [005ffaa7f] 2026-08-10 06:38:29 -0700 Branch: REL_14_STABLE [59205c7e9] 2026-08-10 06:38:35 -0700

    Make <function>scalarineqsel()</function> check that a constant it expects to be of type <type>tid</type> actually is (Tom Lane) 《機械翻訳》make scalarineqsel()タイプTIDであると予想されるチェックが実際にある定数。 (Tom Lane) §

    This expectation will hold for all the built-in operators that use this estimator, but a maliciously-constructed operator could violate it, leading to a crash or server memory disclosure. 《機械翻訳》この期待は、この推定量を使用するすべての組み込み演算子に当てはまるが、悪意を持って構築された演算子はそれに違反し、クラッシュやサーバメモリの開示につながる可能性がある。

    The <productname>PostgreSQL</productname> Project thanks Hcamael for reporting this problem. (CVE-2026-14668) PostgreSQLプロジェクトは、本問題を報告してくれたHcamaelに感謝します。 (CVE-2026-14668)

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [23d9ad771] 2026-08-10 06:37:47 -0700 Branch: REL_19_STABLE [cb947ca31] 2026-08-10 06:38:03 -0700 Branch: REL_18_STABLE [e25135057] 2026-08-10 06:38:10 -0700 Branch: REL_17_STABLE [fe0b5bd6d] 2026-08-10 06:38:17 -0700 Branch: REL_16_STABLE [7c1a8805a] 2026-08-10 06:38:23 -0700 Branch: REL_15_STABLE [f443d0a0a] 2026-08-10 06:38:29 -0700 Branch: REL_14_STABLE [7c2ba321d] 2026-08-10 06:38:34 -0700 Branch: master [90649b6f8] 2026-08-10 06:37:47 -0700 Branch: REL_19_STABLE [3b2238fbe] 2026-08-10 06:38:03 -0700 Branch: REL_18_STABLE [dddc8a69f] 2026-08-10 06:38:10 -0700 Branch: REL_17_STABLE [8e87bd473] 2026-08-10 06:38:17 -0700 Branch: REL_16_STABLE [84b6a7a06] 2026-08-10 06:38:23 -0700 Branch: REL_15_STABLE [4f8b37b6b] 2026-08-10 06:38:29 -0700 Branch: REL_14_STABLE [1e3014f37] 2026-08-10 06:38:34 -0700

    Harden <type>tsvector</type> and <type>tsquery</type> code against overly long values (both individual lexemes and total vector/query length) (Tom Lane) 《機械翻訳》過度に長い値個々のコードとベクタ/問い合わせ語彙素の合計の両方に対して長さtsvectorとtsqueryを強化します。 (Tom Lane) § §

    The documented limits were not enforced in all code paths. 《機械翻訳》文書化された制限は、コードのすべての経路で実施されたわけではありません。

    The <productname>PostgreSQL</productname> Project thanks Yuhang Wu, Zhenpeng Lin, Zheng Yu, and Hcamael for reporting these problems. (CVE-2026-14662) PostgreSQLプロジェクトは、本問題を報告してくれたYuhang Wu、Zhenpeng Lin、Zheng Yu、Hcamaelに感謝します。 (CVE-2026-14662)

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [7bd56f7a3] 2026-08-10 06:37:48 -0700 Branch: REL_19_STABLE [92972e815] 2026-08-10 06:38:04 -0700 Branch: REL_18_STABLE [7f0e1aac7] 2026-08-10 06:38:11 -0700 Branch: REL_17_STABLE [797e3cc4c] 2026-08-10 06:38:17 -0700 Branch: REL_16_STABLE [8c67c4cf5] 2026-08-10 06:38:23 -0700 Branch: REL_15_STABLE [b417744a7] 2026-08-10 06:38:29 -0700 Branch: REL_14_STABLE [cf44ff5e6] 2026-08-10 06:38:35 -0700 Branch: master [60e7329b9] 2026-08-10 06:37:48 -0700 Branch: REL_19_STABLE [42d9749b7] 2026-08-10 06:38:04 -0700 Branch: REL_18_STABLE [2a03f21da] 2026-08-10 06:38:11 -0700 Branch: REL_17_STABLE [8a40f4b09] 2026-08-10 06:38:17 -0700 Branch: REL_16_STABLE [32e0d25d4] 2026-08-10 06:38:23 -0700 Branch: REL_15_STABLE [eb2fa2704] 2026-08-10 06:38:29 -0700 Branch: REL_14_STABLE [c7f462838] 2026-08-10 06:38:35 -0700

    Fix various places that mistakenly assumed they would not have to deal with more than <literal>FUNC_MAX_ARGS</literal> function arguments (Tom Lane) 《機械翻訳》FUNC_MAX_ARGS関数の議論以上のものを扱う必要がないと誤って想定していたさまざまな場所を修正します。 (Tom Lane) § §

    Notably, the server's actual limit on the number of arguments to an aggregate function is <literal>FUNC_MAX_ARGS - 1</literal>, but the parser failed to enforce that, creating hazards downstream. 《機械翻訳》注目すべきことに、サーバの集約関数への引数の数に対する実際の制限はFUNC_MAX_ARGS - 1であるが、パーサはそれを強制することに失敗し、下流に危険をもたらした。

    The <productname>PostgreSQL</productname> Project thanks Zheng Yu, ylwangtju, and Masahiko Sawada for reporting these problems. (CVE-2026-14679) PostgreSQLプロジェクトは、本問題を報告してくれたZheng Yu、ylwangtju、Masahiko Sawadaに感謝します。 (CVE-2026-14679)

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [8f7e35b08] 2026-08-10 06:37:48 -0700 Branch: REL_19_STABLE [21a00de43] 2026-08-10 06:38:04 -0700 Branch: REL_18_STABLE [54649de65] 2026-08-10 06:38:11 -0700 Branch: REL_17_STABLE [eb9e55297] 2026-08-10 06:38:17 -0700 Branch: REL_16_STABLE [4c0c1b2cd] 2026-08-10 06:38:23 -0700 Branch: REL_15_STABLE [e926a9aac] 2026-08-10 06:38:29 -0700 Branch: REL_14_STABLE [155dacbc5] 2026-08-10 06:38:35 -0700 Branch: master [1aa601b4f] 2026-08-10 06:37:48 -0700 Branch: REL_19_STABLE [21d8cfb18] 2026-08-10 06:38:04 -0700 Branch: REL_18_STABLE [722695db1] 2026-08-10 06:38:11 -0700 Branch: REL_17_STABLE [83d0a083f] 2026-08-10 06:38:18 -0700 Branch: REL_16_STABLE [7f308dd7c] 2026-08-10 06:38:23 -0700 Branch: REL_15_STABLE [d6e861e19] 2026-08-10 06:38:29 -0700 Branch: REL_14_STABLE [913fe0c31] 2026-08-10 06:38:35 -0700

    Reject calls from SQL to functions that take or return type <type>internal</type> (Tom Lane) 《機械翻訳》SQLから、または戻り値の型内部を取る機能へのコールを拒否します。 (Tom Lane) § §

    The existing defenses against doing this have been shown to be insufficient, so add more explicit checks. 《機械翻訳》これを行うことに対する既存の防御策は不十分であることが示されているため、より明示的なチェックを追加します。

    The <productname>PostgreSQL</productname> Project thanks Amy Burnett (OpenAI Codex Security) for reporting this problem. (CVE-2026-14680) PostgreSQLプロジェクトは、本問題を報告してくれたAmy Burnett(OpenAI Codex Security)に感謝します。 (CVE-2026-14680)

  • Author: Masahiko Sawada <msawada@postgresql.org> Branch: master [6713a6e04] 2026-08-10 06:37:48 -0700 Branch: REL_19_STABLE [93b93f28f] 2026-08-10 06:38:04 -0700 Branch: REL_18_STABLE [a1fa24127] 2026-08-10 06:38:11 -0700 Branch: REL_17_STABLE [75a03c569] 2026-08-10 06:38:18 -0700 Branch: REL_16_STABLE [7c3367ab5] 2026-08-10 06:38:24 -0700 Branch: REL_15_STABLE [fb6d1ca8d] 2026-08-10 06:38:29 -0700 Branch: REL_14_STABLE [70a3b4e18] 2026-08-10 06:38:35 -0700

    Preserve the ownership of extended statistics objects when they are rebuilt by <command>ALTER TABLE</command> (Masahiko Sawada) 《機械翻訳》拡張統計情報オブジェクトがALTER TABLEによって再建された場合、その所有権を保持します。 (Masahiko Sawada) §

    Previously, the role running <command>ALTER TABLE</command> gained ownership of such objects, but that seems inappropriate. 《機械翻訳》以前は、ロールランニングALTER TABLEがそのようなオブジェクトのオーナーシップを取得しましたが、それは不適切なようです。

    The <productname>PostgreSQL</productname> Project thanks Noah Misch for reporting this problem. (CVE-2026-6469) PostgreSQLプロジェクトは、本問題を報告してくれたNoah Mischに感謝します。 (CVE-2026-6469)

  • Author: Nathan Bossart <nathan@postgresql.org> Branch: master [f9729b507] 2026-08-10 06:37:49 -0700 Branch: REL_19_STABLE [a3832a757] 2026-08-10 06:38:05 -0700 Branch: REL_18_STABLE [0ddd9098a] 2026-08-10 06:38:12 -0700 Branch: REL_17_STABLE [5981fe370] 2026-08-10 06:38:18 -0700 Branch: REL_16_STABLE [5e5ea74e3] 2026-08-10 06:38:24 -0700 Branch: REL_15_STABLE [44ea6764b] 2026-08-10 06:38:30 -0700 Branch: REL_14_STABLE [967acab87] 2026-08-10 06:38:35 -0700

    When deparsing an <function>EXTRACT()</function> function call, quote the field name if needed (Nathan Bossart) 《機械翻訳》EXTRACT()関数呼び出しを構文解析する際には、必要に応じてフィールド名前を引用してください。 (Nathan Bossart) §

    The parser accepts any string literal as a field name in <function>EXTRACT()</function>, deferring validation to execution. If the call is stored and deparsed (for example during <application>pg_dump</application>), the string body was regurgitated verbatim, allowing SQL injection. 《機械翻訳》パーサは、文字列リテラルをフィールド名前として受け入れますEXTRACT()バリデーションの実行を延期します。 呼び出しが保存され、pg_dumpの間に例に対して解析解除されると、文字列本体が逐語的に戻され、SQLインジェクションが可能になります。

    The <productname>PostgreSQL</productname> Project thanks Ben Morris (in collaboration with Claude and Anthropic Research) for reporting this problem. (CVE-2026-15741) PostgreSQLプロジェクトは、本問題を報告してくれたBen Morris(Claude and Anthropic Researchと共同で)に感謝します。 (CVE-2026-15741)

  • Author: Nathan Bossart <nathan@postgresql.org> Branch: master [a9f6e768a] 2026-08-10 06:37:49 -0700 Branch: REL_19_STABLE [efdb26072] 2026-08-10 06:38:05 -0700 Branch: REL_18_STABLE [2e91f8548] 2026-08-10 06:38:12 -0700 Branch: REL_17_STABLE [fd6d3e7e9] 2026-08-10 06:38:19 -0700 Branch: REL_16_STABLE [24855357c] 2026-08-10 06:38:24 -0700 Branch: REL_15_STABLE [97e277402] 2026-08-10 06:38:30 -0700 Branch: REL_14_STABLE [323af0a4e] 2026-08-10 06:38:36 -0700 Branch: master [53ed5ebd8] 2026-08-10 06:37:50 -0700 Branch: REL_19_STABLE [bb1bc525d] 2026-08-10 06:38:06 -0700 Branch: REL_18_STABLE [57f59ca1d] 2026-08-10 06:38:12 -0700 Branch: REL_17_STABLE [671359605] 2026-08-10 06:38:19 -0700 Branch: REL_16_STABLE [7a761fe40] 2026-08-10 06:38:25 -0700 Branch: REL_15_STABLE [c062734cd] 2026-08-10 06:38:30 -0700 Branch: REL_14_STABLE [b6e45b4f8] 2026-08-10 06:38:36 -0700 Branch: master [4fac4c108] 2026-08-10 06:37:50 -0700 Branch: REL_19_STABLE [424fb7160] 2026-08-10 06:38:06 -0700 Branch: REL_18_STABLE [278053843] 2026-08-10 06:38:12 -0700 Branch: REL_17_STABLE [d1c8aa0b0] 2026-08-10 06:38:19 -0700 Branch: REL_16_STABLE [7ce056b17] 2026-08-10 06:38:24 -0700 Branch: REL_15_STABLE [6dbedd48b] 2026-08-10 06:38:30 -0700 Branch: REL_14_STABLE [1a358b8f2] 2026-08-10 06:38:36 -0700

    Check for <literal>USAGE</literal> privilege on data types in places that formerly failed to check that (Nathan Bossart) 《機械翻訳》チェック、以前はそれをチェックすることができなかった場所のUSAGEデータの権限タイプのために。 (Nathan Bossart) § § §

    <command>CREATE TYPE AS RANGE</command> did not check, nor did <command>ALTER TABLE OF</command>, nor did commands that create stored expressions. These omissions allowed roles without <literal>USAGE</literal> privilege to nonetheless create objects depending on the type, possibly blocking the type's owner from changing the type later. 《機械翻訳》CREATEタイプASレンジはチェックを行わず、ALTERテーブルOFも行わず、格納された式を作成するコマンドも行いませんでした。 これらの省略により、USAGE権限を持たないロールでもタイプに依存するオブジェクトを作成することができました。 タイプの所有者であるブロッキングは後でタイプを変更する可能性がありました。

    The <productname>PostgreSQL</productname> Project thanks Jingzhou Fu for reporting this problem. (CVE-2026-6470) PostgreSQLプロジェクトは、本問題を報告してくれたJingzhou Fuに感謝します。 (CVE-2026-6470)

  • Author: Nathan Bossart <nathan@postgresql.org> Branch: master [ffca23839] 2026-08-10 06:37:50 -0700 Branch: REL_19_STABLE [567286b76] 2026-08-10 06:38:06 -0700 Branch: REL_18_STABLE [0b12f56bf] 2026-08-10 06:38:13 -0700 Branch: REL_17_STABLE [1974acf23] 2026-08-10 06:38:19 -0700 Branch: REL_16_STABLE [f5f2da795] 2026-08-10 06:38:25 -0700 Branch: REL_15_STABLE [17b6083db] 2026-08-10 06:38:30 -0700 Branch: REL_14_STABLE [f4174aa84] 2026-08-10 06:38:36 -0700

    Invalidate role-dependent cached plans after role changes (Ilya Staroverov, Shinya Kato, Nathan Bossart) 《機械翻訳》ロールの変更後に、ロールに依存するキャッシュ済計画を無効化します。 (Ilya Staroverov, Shinya Kato, Nathan Bossart) §

    Role membership, role attribute, and database ownership changes may impact the expected behavior of row-level security policies, but previously we'd continue to use cached plans that were made according to the old state of affairs. 《機械翻訳》ロールメンバシップ、ロール属性、データベースの所有者の変更は、行-レベルセキュリティポリシーの期待される動作をインパクトする可能性がありますが、以前は、古い状況に従って作成されたキャッシュされたプランを引き続き使用していました。

    The <productname>PostgreSQL</productname> Project thanks Ilya Staroverov and Shinya Kato for reporting this problem. (CVE-2026-14666) PostgreSQLプロジェクトは、本問題を報告してくれたIlya StaroverovとShinya Katoに感謝します。 (CVE-2026-14666)

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master [3bf185b4b] 2026-08-10 06:37:49 -0700 Branch: REL_19_STABLE [bf1bb7e29] 2026-08-10 06:38:05 -0700 Branch: REL_18_STABLE [203a48209] 2026-08-10 06:38:11 -0700 Branch: REL_17_STABLE [067a64d40] 2026-08-10 06:38:18 -0700

    Reject GSSEncRequest after direct SSL connection (Michael Paquier) 《機械翻訳》直接SSLコネクション後にGSSEncRequestを拒否します。 (Michael Paquier) §

    After establishing a TLS-encrypted connection, the server would still accept a request for GSSAPI encryption. If that succeeded, the connection would proceed using TLS encryption, but it would look like a GSS connection to the <filename>pg_hba</filename> rules. Thus, a <filename>pg_hba</filename> policy intending to disallow TLS would not be enforced correctly. 《機械翻訳》TLSで暗号化されたコネクションを確立した後も、サーバはGSSAPI暗号化用のリクエストを受け入れます。 それが成功した場合、コネクションはTLS暗号化を使用して処理を進めますが、pg_hbaルールに対してGSSコネクションのように見えます。 したがって、TLSを許可しないpg_hbaポリシーは正しく適用されません。

    The <productname>PostgreSQL</productname> Project thanks p4p3r for reporting this problem. (CVE-2026-14681) PostgreSQLプロジェクトは、本問題を報告してくれたp4p3rに感謝します。 (CVE-2026-14681)

  • Author: Nathan Bossart <nathan@postgresql.org> Branch: master [feb8b0182] 2026-08-10 06:37:49 -0700 Branch: REL_19_STABLE [4d192fa16] 2026-08-10 06:38:05 -0700 Branch: REL_18_STABLE [822143c4d] 2026-08-10 06:38:12 -0700 Branch: REL_17_STABLE [dec60e8ad] 2026-08-10 06:38:18 -0700 Branch: REL_16_STABLE [fadbe882d] 2026-08-10 06:38:24 -0700

    Make mock SCRAM authentication secrets more plausible (Nathan Bossart) 《機械翻訳》makeはスクラム認証の秘密をよりもっともらしく模倣している。 (Nathan Bossart) §

    If a SCRAM login is attempted against a role that doesn't exist or doesn't have a SCRAM secret, we generate a mock secret and carry out the authentication handshake anyway, to avoid revealing these facts to an attacker. But the mock secret was made with a fixed iteration count, which in itself can be an observable response discrepancy. Use the configuration setting <varname>scram_iterations</varname> instead, to make the mock secret look more like the installation's real secrets. 《機械翻訳》もしSCRAMログインが存在しないかSCRAM秘密を持っていないロールに対して試みられるなら、攻撃者にこれらの事実を明らかにすることを避けるために、模擬秘密を生成し、とにかく認証ハンドシェイクを実行します。 しかし、模擬秘密は固定反復カウントで作られました、自分自身では観測可能な回答不一致である可能性があります。 設定設定を使用してくださいscram_iterations代わりに、makeするために模擬秘密はインストールの本当の秘密のように見えます。

    The <productname>PostgreSQL</productname> Project thanks Radim Marek for reporting this problem. (CVE-2026-14672) PostgreSQLプロジェクトは、本問題を報告してくれたRadim Marekに感謝します。 (CVE-2026-14672)

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master [c7da85fec] 2026-08-10 06:37:49 -0700 Branch: REL_19_STABLE [457b8737a] 2026-08-10 06:38:05 -0700 Branch: REL_18_STABLE [a14ba29b1] 2026-08-10 06:38:11 -0700 Branch: REL_17_STABLE [c3c830272] 2026-08-10 06:38:18 -0700 Branch: REL_16_STABLE [39f855e0e] 2026-08-10 06:38:24 -0700 Branch: REL_15_STABLE [5737110b6] 2026-08-10 06:38:30 -0700 Branch: REL_14_STABLE [74c59d062] 2026-08-10 06:38:35 -0700

    Fix out-of-bounds writes in <application>ecpg</application> applications caused by invalid <type>bytea</type> data received from the server (Michael Paquier) 《機械翻訳》サーバから受信した無効なbyteaデータによって引き起こされたecpgアプリケーションの範囲外の書き込みを修正しました。 (Michael Paquier) §

    <application>ecpg</application> assumed without checking that any <type>bytea</type> value must begin with <literal>\x</literal>. A broken or malicious server might send a string shorter than 2 bytes, resulting in memory clobber in the application. 《機械翻訳》ecpgは、bytea値が\xで始まらなければならないことをチェックせずに想定されます。 破損した、または悪意のあるサーバは2バイトより短い文字列を送信する可能性があり、その結果、アプリケーションのメモリが破壊されます。

    The <productname>PostgreSQL</productname> Project thanks ylwangtju for reporting this problem. (CVE-2026-16241) PostgreSQLプロジェクトは、本問題を報告してくれたylwangtjuに感謝します。 (CVE-2026-16241)

  • Author: Nathan Bossart <nathan@postgresql.org> Branch: master [086f6f176] 2026-08-10 06:37:50 -0700 Branch: REL_19_STABLE [0119aa30e] 2026-08-10 06:38:06 -0700 Branch: REL_18_STABLE [71ca694c7] 2026-08-10 06:38:13 -0700 Branch: REL_17_STABLE [0bfac9e1f] 2026-08-10 06:38:19 -0700 Branch: REL_16_STABLE [33d0c63fb] 2026-08-10 06:38:25 -0700 Branch: REL_15_STABLE [df245c374] 2026-08-10 06:38:31 -0700 Branch: REL_14_STABLE [2006fca40] 2026-08-10 06:38:37 -0700

    Do not do backquote expansion on the argument of <application>psql</application>'s <command>\unrestrict</command> command (Nathan Bossart) 《機械翻訳》psql\unrestrictコマンドの引数で逆引用符拡張をしないでください。 (Nathan Bossart) §

    This oversight in the fix for CVE-2025-8714 allows a malicious server to inject shell commands into plain-text dump output that will be run at restore time on the machine running <application>psql</application>, the exact scenario that CVE-2025-8714 intended to prevent. 《機械翻訳》CVE-2025-8714の修正におけるこの見落としは、悪意のあるサーバが、psql CVE-2025-8714が防止しようとした正確なシェルであるを実行しているテキストでダンプ時間に実行されるプレーンなリストア出力にマシンコマンドを注入することを可能にする。 シナリオ

    The <productname>PostgreSQL</productname> Project thanks Lucas Velgus, Filip Janus, and Daniel Bakker for reporting this problem. (CVE-2026-18408) PostgreSQLプロジェクトは、本問題を報告してくれたLucas Velgus、Filip Janus、Daniel Bakkerに感謝します。 (CVE-2026-18408)

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [13bb73aeb] 2026-08-10 06:37:48 -0700 Branch: REL_19_STABLE [86cd82bf4] 2026-08-10 06:38:04 -0700 Branch: REL_18_STABLE [3392cce5c] 2026-08-10 06:38:11 -0700 Branch: REL_17_STABLE [c2b16f5d4] 2026-08-10 06:38:17 -0700 Branch: REL_16_STABLE [3299c2ba0] 2026-08-10 06:38:23 -0700 Branch: REL_15_STABLE [71ba5705d] 2026-08-10 06:38:29 -0700 Branch: REL_14_STABLE [57aa21f69] 2026-08-10 06:38:35 -0700

    Remove <application>pg_dump</application>'s assumption that <structname>pg_proc</structname>.<structfield>protrftypes</structfield> cannot have more than <literal>FUNC_MAX_ARGS</literal> entries (Tom Lane) 《機械翻訳》pg_proc.prontftypesFUNC_MAX_ARGSエントリより多く持つことはできないというpg_dumpの仮定を削除しました。 (Tom Lane) §

    Since there could be entries for both input and output arguments, it's feasible for this array's length to exceed <literal>FUNC_MAX_ARGS</literal> (which constrains only input arguments). Even if that were not so, <application>pg_dump</application> cannot assume that the server was built with the same value of <literal>FUNC_MAX_ARGS</literal> that it has. An overrun would lead to a memory clobber inside <application>pg_dump</application>. 《機械翻訳》入出力引数の両方に対してエントリが存在する可能性があるため、この配列の長さがFUNC_MAX_ARGS入力引数のみを制約するを超える可能性があります。 たとえそうでなかったとしても、pg_dumpはサーバがFUNC_MAX_ARGSそれが持つと同じ値で構築されたと想定することはできません。 オーバーランは内部でメモリを破壊することになりますpg_dump

    The <productname>PostgreSQL</productname> Project thanks Masahiko Sawada for reporting this problem. (CVE-2026-19385) PostgreSQLプロジェクトは、本問題を報告してくれたMasahiko Sawadaに感謝します。 (CVE-2026-19385)

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [63cb15f40] 2026-08-10 06:37:48 -0700 Branch: REL_19_STABLE [8c48cd615] 2026-08-10 06:38:04 -0700 Branch: REL_18_STABLE [87c4b8219] 2026-08-10 06:38:11 -0700 Branch: REL_17_STABLE [2d78c34f8] 2026-08-10 06:38:17 -0700 Branch: REL_16_STABLE [477a6bdb0] 2026-08-10 06:38:23 -0700 Branch: REL_15_STABLE [cf4ae7c3b] 2026-08-10 06:38:29 -0700 Branch: REL_14_STABLE [d7fcfead3] 2026-08-10 06:38:35 -0700

    Harden <application>PL/Perl</application> against <quote>tied</quote> Perl arrays and hashes (Tom Lane) 《機械翻訳》Perlの配列とハッシュをPL/Perl結合されたものに対して強化する。 (Tom Lane) §

    A tied object that doesn't behave like a regular one could lead to memory overwrite, or to constructing a corrupt result array (which would likely cause problems later). 《機械翻訳》通常のオブジェクトのように動作しないメモリが関連付けられていると、配列が上書きされたり、不正な結果リザルトが構築されたりする可能性があります(これは後で問題を引き起こす可能性があります)。

    The <productname>PostgreSQL</productname> Project thanks Hcamael for reporting this problem. (CVE-2026-14670) PostgreSQLプロジェクトは、本問題を報告してくれたHcamaelに感謝します。 (CVE-2026-14670)

  • Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> Branch: master [776467301] 2026-08-10 06:37:49 -0700 Branch: REL_19_STABLE [a1c1727cb] 2026-08-10 06:38:05 -0700 Branch: REL_18_STABLE [028ee716a] 2026-08-10 06:38:11 -0700 Branch: REL_17_STABLE [b56cc7deb] 2026-08-10 06:38:18 -0700 Branch: REL_16_STABLE [8bbdc0540] 2026-08-10 06:38:24 -0700 Branch: REL_15_STABLE [1eb0d5380] 2026-08-10 06:38:30 -0700 Branch: REL_14_STABLE [aff9dac1c] 2026-08-10 06:38:35 -0700

    Fix integer overflows in memory-allocation calculations in <application>PL/Perl</application> and <application>PL/Tcl</application> (Heikki Linnakangas) 《機械翻訳》メモリ内の整数オーバーフローを修正しました。 PL/PerlPL/Tcl.アロケーション (Heikki Linnakangas) §

    This is the same type of problem as CVE-2026-6473, just in a different part of the code, and is fixed in the same way. 《機械翻訳》これは、コードの別のタイプにあるだけで、CVE-2026-6473と同じ問題のパートであり、同じ方法で修正されます。

    The <productname>PostgreSQL</productname> Project thanks the Tulya Project (Team Dhiutsa, Bitecope Technologies Private Ltd) for reporting this problem. (CVE-2026-14677) PostgreSQLプロジェクトは、本問題を報告してくれたTulyaプロジェクト(チームDhiutsa、Bitecope TechnologiesプライベートLtdに感謝します。 (CVE-2026-14677)

  • Author: Noah Misch <noah@leadboat.com> Branch: master [0fbf785b1] 2026-08-10 06:37:49 -0700 Branch: REL_19_STABLE [557cc7186] 2026-08-10 06:38:05 -0700 Branch: REL_18_STABLE [0a61fcde0] 2026-08-10 06:38:12 -0700 Branch: REL_17_STABLE [e41c72aff] 2026-08-10 06:38:18 -0700 Branch: REL_16_STABLE [2cc147318] 2026-08-10 06:38:24 -0700 Branch: REL_15_STABLE [e43e74756] 2026-08-10 06:38:30 -0700 Branch: REL_14_STABLE [39d792040] 2026-08-10 06:38:36 -0700

    Ensure that <filename>contrib/amcheck</filename> functions restrict <varname>search_path</varname> before executing index expressions (Noah Misch) 《機械翻訳》保証who contrib/amcheck functions restrict search_path前はインデックス式を実行します。 (Noah Misch) §

    Because amcheck will run such index expressions as the owner of their tables, a caller could potentially hijack <varname>search_path</varname>-dependent functions to run arbitrary code as the table owner. By default this is not a vulnerability because only superusers are allowed to call amcheck functions; but if that privilege was granted out, it created a larger hazard than the documentation suggests. 《機械翻訳》amcheckはテーブルのインデックス式のような所有者式を実行しますので、呼び出し元が任意のコードをテーブル所有者として実行するためにsearch_path-dependent関数を乗っ取る可能性があります。 デフォルトではスーパーユーザのみがamcheck関数を呼び出しで実行することを許可されているため、これは弱点ではありません。 しかし、権限が許可された場合、文書が示唆するよりも大きな危険をもたらしました。

    The <productname>PostgreSQL</productname> Project thanks Yuelin Wang and Jacob Brazeal for reporting this problem. (CVE-2026-14673) PostgreSQLプロジェクトは、本問題を報告してくれたYuelin WangとJacob Brazealに感謝します。 (CVE-2026-14673)

  • Author: Nathan Bossart <nathan@postgresql.org> Branch: master [918683d12] 2026-08-10 06:37:49 -0700 Branch: REL_19_STABLE [62c31b490] 2026-08-10 06:38:05 -0700 Branch: REL_18_STABLE [e88eb4e76] 2026-08-10 06:38:12 -0700 Branch: REL_17_STABLE [c4d51b627] 2026-08-10 06:38:19 -0700 Branch: REL_16_STABLE [61481aa0e] 2026-08-10 06:38:24 -0700 Branch: REL_15_STABLE [74916136f] 2026-08-10 06:38:30 -0700 Branch: REL_14_STABLE [9505175f2] 2026-08-10 06:38:36 -0700

    Fix integer overflows in <filename>contrib/fuzzystrmatch</filename>'s <function>levenshtein()</function> and <function>levenshtein_less_equal()</function> functions (Nathan Bossart) 《機械翻訳》contrib/fuzzystrmatchlevenshtein()およびlevenshtein_less_equal()関数での整数オーバーフローを修正しました。 (Nathan Bossart) §

    Passing large cost values to these functions could cause integer overflows, thereby producing nonsensical results, and even causing out-of-bounds writes in some cases. 《機械翻訳》これらの関数にラージコストの値を渡すと整数オーバーフローが発生し、意味のない結果が生成されたり、場合によっては範囲外の書き込みが発生したりする可能性がありました。

    The <productname>PostgreSQL</productname> Project thanks Ben Morris (in collaboration with Claude and Anthropic Research) for reporting this problem. (CVE-2026-15742) PostgreSQLプロジェクトは、本問題を報告してくれたBen Morris(Claude and Anthropic Researchと共同で)に感謝します。 (CVE-2026-15742)

  • Author: Álvaro Herrera <alvherre@kurilemu.de> Branch: master [1e2795dde] 2026-08-10 06:37:48 -0700 Branch: REL_19_STABLE [bb02eba53] 2026-08-10 06:38:04 -0700 Branch: REL_18_STABLE [8a31ffc2d] 2026-08-10 06:38:11 -0700

    Fix buffer overrun in <filename>contrib/pg_stat_statements</filename> (Álvaro Herrera) 《機械翻訳》バッファオーバーランをcontrib/pg_stat_statements. (Álvaro Herrera) §

    Query normalization didn't accurately account for the amount of space the normalized string would require. 《機械翻訳》問い合わせ正規化は、正規化されたアカウントが必要とするスペースの量に対して、文字列を正確に計算しなかった。

    The <productname>PostgreSQL</productname> Project thanks Sajeeb Lohani (with TrendAI Zero Day Initiative) and Yuelin Wang for reporting this problem. (CVE-2026-14676) PostgreSQLプロジェクトは、本問題を報告してくれたSajeeb Lohani(TrendAI Zero Day Initiativeと共に)とYuelin Wangに感謝します。 (CVE-2026-14676)

  • Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> Branch: master [66c2dbb20] 2026-08-10 06:37:48 -0700 Branch: REL_19_STABLE [aa7b5815e] 2026-08-10 06:38:04 -0700 Branch: REL_18_STABLE [849019a50] 2026-08-10 06:38:11 -0700 Branch: REL_17_STABLE [1af08af69] 2026-08-10 06:38:18 -0700 Branch: REL_16_STABLE [24c88cd39] 2026-08-10 06:38:24 -0700 Branch: REL_15_STABLE [c7c82a88c] 2026-08-10 06:38:29 -0700 Branch: REL_14_STABLE [a74aa0854] 2026-08-10 06:38:35 -0700

    Fix datatype error in <filename>contrib/pg_trgm</filename>'s GiST picksplit function (Heikki Linnakangas) 《機械翻訳》contrib/pg_trgm's GiST picksplitエラーのデータ型関数を修正しました。 (Heikki Linnakangas) §

    This mistake resulted in reading past the end of the buffer, typically causing bad split decisions; but a crash could ensue if you're very unlucky. 《機械翻訳》このミスの結果、バッファの終わりを超えて読むことになり、通常は誤った分割決定が発生しました。 しかし、非常に運が悪いとクラッシュが起こる可能性があります。

    The <productname>PostgreSQL</productname> Project thanks Mehmet D. Ince for reporting this problem. (CVE-2026-14678) PostgreSQLプロジェクトは、本問題を報告してくれたMehmet D. Inceに感謝します。 (CVE-2026-14678)

  • Author: Nathan Bossart <nathan@postgresql.org> Branch: master Release: REL_19_BR [1fbe2066d] 2026-06-05 12:08:05 -0500 Branch: REL_18_STABLE [79a506228] 2026-06-05 12:08:05 -0500 Branch: REL_17_STABLE [66a5146dc] 2026-06-05 12:08:05 -0500 Branch: REL_16_STABLE [a572dd213] 2026-06-05 12:08:05 -0500 Branch: REL_15_STABLE [b7b513d9a] 2026-06-05 12:08:05 -0500 Branch: REL_14_STABLE [5b72d0279] 2026-06-05 12:08:05 -0500

    Remove the plan cache in <filename>contrib/refint</filename> (Ayush Tiwari) 《機械翻訳》プランのキャッシュを削除しますcontrib/refint。 (Ayush Tiwari) §

    This caching behavior has several serious bugs, notably that <function>check_foreign_key()</function> embeds the new key values in its cascade-UPDATE queries, so a cached plan reuses the originally-needed values rather than the key values that should be used. The simplest solution is to remove it. 《機械翻訳》このキャッシュ動作にはいくつかの重大なバグがあります。 特に、check_foreign_key()は新しいキー値をカスケード-更新問い合わせに埋め込むため、キャッシュされたプランは、使用されるべきキー値ではなく、本来必要な値を再利用する。 最も簡単な解決策は、それを削除することです。

    The <productname>PostgreSQL</productname> Project thanks Hcamael for reporting this problem. (CVE-2026-14671) PostgreSQLプロジェクトは、本問題を報告してくれたHcamaelに感謝します。 (CVE-2026-14671)

  • Author: Tomas Vondra <tomas.vondra@postgresql.org> Branch: master [1232f7a08] 2026-07-30 14:59:12 +0200 Branch: REL_19_STABLE [5707d7517] 2026-07-30 14:59:30 +0200 Branch: REL_18_STABLE [d4420a972] 2026-07-30 14:59:39 +0200

    Ensure that parallel GIN index builds update the table's <structname>pg_class</structname>.<structfield>reltuples</structfield> value correctly (Jan Nidzwetzki, Tomas Vondra) 《機械翻訳》パラレルGINインデックスが更新を建設する保証は、テーブルのpg_クラスです。 reltuples値は正しく。 (Jan Nidzwetzki, Tomas Vondra) §

    A parallel worker could report an uninitialized value for the number of rows it processed, leading to a bogus value for <structfield>reltuples</structfield>, even Infinity or NaN. Such values could lead to subsequent autovacuum and autoanalyze operations never deciding that the table needs to be processed. If so, the situation will not self-heal. A manual <command>ANALYZE</command> command, or creation of another index, will be needed to reset <structfield>reltuples</structfield> to the correct value. If you have any tables with GIN indexes, it's recommended to check to see if their <structfield>reltuples</structfield> entries look sane. A query such as this may be helpful: 《機械翻訳》パラレルワーカーは、処理した行数の初期化されていない値をレポートし、reltuples InfinityやNaNであっても偽の値をもたらす可能性があります。 このような値は、後続のオートバキュームおよび自動分析操作で、テーブルニーズを処理することを決定しない可能性があります。 その場合、シチュエーションは自己修復しません。 マニュアルreltuplesコマンド、または別のインデックスの作成は、正しい値にリセットするために必要になります。 GINインデックスを持つテーブルがある場合は、チェックにreltuplesエントリが正常に見えるかどうかを確認することをお勧めします。 次のような問い合わせが役立つ場合があります。 ANALYZE

    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;
    

  • Author: Etsuro Fujita <efujita@postgresql.org> Branch: master [f57df2068] 2026-08-07 17:30:00 +0900 Branch: REL_19_STABLE [7d74b2644] 2026-08-07 17:30:01 +0900 Branch: REL_18_STABLE [4ea497a92] 2026-08-07 17:30:02 +0900 Branch: REL_17_STABLE [3704870b2] 2026-08-07 17:30:03 +0900 Branch: REL_16_STABLE [894da35b3] 2026-08-07 17:30:04 +0900 Branch: REL_15_STABLE [7213cbfa0] 2026-08-07 17:30:05 +0900 Branch: REL_14_STABLE [cec48686a] 2026-08-07 17:30:06 +0900

    Fix mis-handling of asynchronous reads when rescanning an asynchronous Append plan node (Alexander Korotkov, Gleb Kashkin, Etsuro Fujita) 《機械翻訳》非同期Appendプランのハンドリングを再スキャンする際に、ノードの読み取りが正しく行われない問題を修正しました。 非同期 (Alexander Korotkov, Gleb Kashkin, Etsuro Fujita) §

    When an upper plan node rescans an Append before having read the entire Append output, we need to discard any in-flight requests sent to external servers (by <filename>postgres_fdw</filename> for example). This was not done correctly in cases where a subplan has parameter changes or is discarded by partition pruning in the next scan. The outcome could be incorrect query results, an infinite loop, or an assertion failure. 《機械翻訳》上位プランノードがAppend前を再スキャンしてAppendの出力全体を読み込んだら、外部サーバに送信されたin-フライト要求を破棄する必要がありますpostgres_fdw by for例)。 これは、サブプランにパラメータの変更がある場合や、次のスキャンのパーティションプルーニングによって破棄される場合には正しく行われませんでした。 結果は、問い合わせの結果が正しくない、無限ループ、またはアサーションの失敗となる可能性があります。

  • Author: David Rowley <drowley@postgresql.org> Branch: master [709dfd27f] 2026-07-31 15:36:31 +1200 Branch: REL_19_STABLE [f9282a650] 2026-07-31 15:37:12 +1200 Branch: REL_18_STABLE [02e69be47] 2026-07-31 15:37:42 +1200 Branch: REL_17_STABLE [31f2acde5] 2026-07-31 15:38:10 +1200 Branch: REL_16_STABLE [9a0cd8e73] 2026-07-31 15:38:34 +1200 Branch: REL_15_STABLE [5190732c9] 2026-07-31 15:39:01 +1200 Branch: REL_14_STABLE [6098f35f4] 2026-07-31 15:39:21 +1200

    Fix error in partition pruning for RANGE-partitioned tables (David Rowley) 《機械翻訳》レンジ~テーブルパーティションのパーティション剪定でエラーを固定。 (David Rowley) §

    In some cases the DEFAULT partition would be skipped when it should not be, which could lead to rows missing from query results. 《機械翻訳》場合によっては、デフォルトパーティションが本来でないときにスキップされたになり、問い合わせの結果から行が欠落することがあります。

  • Author: Amit Langote <amitlan@postgresql.org> Branch: master Release: REL_19_BR [b43f8aa4c] 2026-06-24 08:59:22 +0900 Branch: REL_18_STABLE [1ef917e3a] 2026-06-23 21:08:50 +0900 Branch: REL_18_STABLE [bba4e095d] 2026-06-25 12:15:02 +0900

    Correctly update foreign-data-wrapper state in a ModifyTable plan node after pruning result relations (Ayush Tiwari, Rafia Sabih) 《機械翻訳》結果のラッパーをプルーニングした後、ModifyTableプランノードで外国-データ-リレーションの状態が正しく更新されます。 (Ayush Tiwari, Rafia Sabih) § §

    Previously, if run-time partition pruning determined that some partitions of a partitioned target table need not be scanned and the table had any foreign-table partitions, a crash or erroneous behavior was likely. 《機械翻訳》以前は、実行時のパーティションプルーニングによって、分割されたターゲットテーブルの一部のパーティションをスキャンする必要がないと判断され、そのテーブルに外部テーブルパーティションがある場合、クラッシュまたは誤った動作が発生する可能性があった。

  • Author: Dean Rasheed <dean.a.rasheed@gmail.com> Branch: master [8e0c25275] 2026-07-08 20:46:25 +0100 Branch: REL_19_STABLE [7048e50f8] 2026-07-08 20:46:25 +0100 Branch: REL_18_STABLE [4908225be] 2026-07-08 20:46:26 +0100

    Fix missed concurrent update in <command>UPDATE</command> with <literal>RETURNING OLD</literal> on a table that has a <literal>BEFORE UPDATE</literal> trigger (Dean Rasheed) 《機械翻訳》BEFORE UPDATEトリガを持つテーブル上のwith RETURNING OLDで同時更新が失敗する問題を修正しました。 UPDATE (Dean Rasheed) §

    If the target row was concurrently updated, then at isolation level <literal>READ COMMITTED</literal> any <literal>OLD</literal> values in <literal>RETURNING</literal> should reflect the updated row. But stale values were returned if there was a trigger (although the trigger itself, and the final output row, saw the correct values). 《機械翻訳》ターゲット行が同時に更新された場合、隔離レベルでREAD COMMITTED RETURNING内の任意のOLD値は更新された行を反映する必要があります。 しかし、トリガがある場合は古い値が返されました(ただし、トリガ自分自身と最終的な出力行には正しい値が表示されました)。

  • Author: David Rowley <drowley@postgresql.org> Branch: master [60826a352] 2026-07-31 23:23:21 +1200 Branch: REL_19_STABLE [a71a348ed] 2026-07-31 23:24:23 +1200 Branch: REL_18_STABLE [f70acc8a2] 2026-07-31 23:24:46 +1200

    Fix hash join performance issue when there are multiple join keys and many NULL values (David Rowley) 《機械翻訳》ハッシュ結合パフォーマンスキーと多くのNULL値がある場合のマルチプル結合問題を修正しました。 (David Rowley) §

    Null-keyed tuples should not get inserted into the hash table, since they will never match any other tuples. The code got this wrong if the null was in a non-last join column, bloating the hash table quite a lot if many inputs contain nulls. 《機械翻訳》NULLキー付きタプルはハッシュテーブルに挿入されるべきではありません。 なぜなら、それらは他のタプルをマッチにすることは決してないからです。 コードは、NULLが最後以外の結合カラムにあった場合にこの間違いを取得し、多くの入力にNULLが含まれている場合にハッシュテーブルをかなり膨張させます。

  • Author: Dean Rasheed <dean.a.rasheed@gmail.com> Branch: master Release: REL_19_BR [79c65b9d9] 2026-06-11 12:08:47 +0100 Branch: REL_18_STABLE [9108fed3e] 2026-06-11 12:08:48 +0100

    Fix parsing of parenthesized <literal>OLD</literal>/<literal>NEW</literal> in <literal>RETURNING</literal> expressions (Marko Grujic) 《機械翻訳》RETURNINGエクスプレッション内でカッコで囲まれたOLD/NEWのパースを修正しました。 (Marko Grujic) §

    Expressions such as <literal>(old).colname</literal> and <literal>(old).*</literal> were mis-handled, effectively converting them to <literal>NEW</literal> references. 《機械翻訳》(old).colname(old).*などの式は誤って処理され、事実上NEW参照に変換されました。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [239eabda4] 2026-07-28 16:09:03 -0400 Branch: REL_19_STABLE [9740c68ff] 2026-07-28 16:09:03 -0400 Branch: REL_18_STABLE [277122036] 2026-07-28 16:09:03 -0400 Branch: REL_17_STABLE [26d6b7dc9] 2026-07-28 16:09:04 -0400 Branch: REL_16_STABLE [6fcee189b] 2026-07-28 16:09:04 -0400 Branch: REL_15_STABLE [53470ffba] 2026-07-28 16:09:04 -0400 Branch: REL_14_STABLE [13b627a3e] 2026-07-28 16:09:04 -0400

    Fix planner's nullability and strictness checks for <literal><replaceable>value</replaceable> IN (<replaceable>array</replaceable>)</literal> expressions (Ayush Tiwari) 《機械翻訳》プランナのvalue IN (array)式に対するNULL許容性と厳密性のチェックを修正した。 (Ayush Tiwari) §

    These checks should only succeed if the array operand is known to be non-empty, but that consideration was missed, allowing optimizations to be applied that should not be. This could result in wrong query answers if the array actually was empty. 《機械翻訳》これらのチェックは、配列オペランドが空でないことがわかっているが、考慮されていないため、本来適用されるべきではない最適化が適用された場合にのみ成功します。 これにより、間違い問い合わせが実際に空の場合に、配列地域の回答が得られる可能性があります。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [1df9e8d96] 2026-07-18 14:09:10 -0400 Branch: REL_19_STABLE [8bc479627] 2026-07-18 14:09:10 -0400 Branch: REL_18_STABLE [21f5e659e] 2026-07-18 14:09:10 -0400 Branch: REL_17_STABLE [cdcec567d] 2026-07-18 14:09:10 -0400 Branch: REL_16_STABLE [3e1fe25e6] 2026-07-18 14:09:10 -0400 Author: Richard Guo <rguo@postgresql.org> Branch: master [0da71d90d] 2026-07-20 12:13:11 +0900 Branch: REL_19_STABLE [72457f1df] 2026-07-20 12:15:09 +0900 Branch: REL_18_STABLE [9e40d07e1] 2026-07-20 12:15:57 +0900 Branch: REL_17_STABLE [b308eb366] 2026-07-20 12:16:58 +0900 Branch: REL_16_STABLE [d610d8e8b] 2026-07-20 12:17:40 +0900

    Fix incorrect join removal logic (Matheus Alcantara, Richard Guo) 《機械翻訳》誤った結合取外しロジックを修正する。 (Matheus Alcantara, Richard Guo) § §

    In edge cases, it was possible for a constant output value coming from within the nullable side of an outer join to not be replaced by NULL when it should be. 《機械翻訳》エッジケースでは、定数のNull許容側の内部から取得した外部結合の出力の値が、NULLによって置換されるべきときに置換されない可能性がありました。

  • Author: Richard Guo <rguo@postgresql.org> Branch: master Release: REL_19_BR [9a60f295b] 2026-06-22 10:40:40 +0900 Branch: REL_18_STABLE [e02526795] 2026-06-22 10:43:01 +0900 Branch: master [d68576bcf] 2026-07-15 09:20:35 +0900 Branch: REL_19_STABLE [aae47813a] 2026-07-15 09:21:44 +0900 Branch: REL_18_STABLE [18105e6db] 2026-07-15 09:22:58 +0900

    Clean up PlaceHolderVars more thoroughly during join removal (Richard Guo, Arne Roland) 《機械翻訳》結合の撤去作業中は、PlaceHolderVarsをより徹底的に清掃してください。 (Richard Guo, Arne Roland) § §

    This fix corrects various edge cases that could trip assertions or result in incorrect plans. 《機械翻訳》この修正では、アサーションをトリップしたり、誤った計画を生成する可能性のあるさまざまなエッジケースが修正されている。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master Release: REL_19_BR [06e94eccf] 2026-06-08 11:48:16 -0400 Branch: REL_18_STABLE [11aed8d19] 2026-06-08 11:48:17 -0400 Branch: REL_17_STABLE [19152e3c2] 2026-06-08 11:48:17 -0400 Branch: REL_16_STABLE [cf2bfe073] 2026-06-08 11:48:17 -0400 Branch: REL_15_STABLE [caebac5f1] 2026-06-08 11:48:18 -0400 Branch: REL_14_STABLE [64778fac7] 2026-06-08 11:48:18 -0400

    Add missed checks for hashability of equality comparisons on container datatypes (arrays, composites, ranges) (Andrei Lepikhov, Tom Lane) 《機械翻訳》コンテナデータ型(配列、コンポジット、範囲)での等価性比較のハッシュ可能性のチェック漏れが追加された。 (Andrei Lepikhov, Tom Lane) §

    The planner must verify hashability of the container's component type(s) before deciding it can use a hash-based plan type. This step was missed in some places, leading to <quote>could not identify a hash function</quote> failures at execution. 《機械翻訳》プランナは、コンテナのコンポーネントタイプ前のハッシュ可能性を検証し、ハッシュを拠点とするプランタイプを使用できることを決定する必要があります。 このステップがいくつかの場所で欠落していたため、実行時に失敗しましたハッシュ機能を識別できませんでした

  • Author: Richard Guo <rguo@postgresql.org> Branch: master [44fb59fc6] 2026-07-06 16:13:14 +0900 Branch: REL_19_STABLE [98d5d7ee6] 2026-07-06 16:14:13 +0900 Branch: REL_18_STABLE [fe5d62951] 2026-07-06 16:15:45 +0900

    Avoid pushing <literal>WHERE</literal> clauses down past a grouping step that has a different equivalence rule (Richard Guo) 《機械翻訳》同等ダウンが異なるグループ化ステップを通過してWHERE条項ルールをプッシュすることは避けてください。 (Richard Guo) §

    A test on a grouping column that is grouped by a nondeterministic collation is safe to push down only if it is a comparison using that same collation. Otherwise it might filter some rows the grouping would have merged. 《機械翻訳》非決定性テストによってグループ化されたグループ化カラムの照合順序は、同じ照合順序を使用する比較である場合にのみ、セーフからプッシュダウンになります。 そうでない場合は、グループ化がマージしたはずの行をフィルタする可能性があります。

  • Author: David Rowley <drowley@postgresql.org> Branch: master [d007800f0] 2026-07-07 23:57:45 +1200 Branch: REL_19_STABLE [fcd58c6d9] 2026-07-07 23:58:29 +1200 Branch: REL_18_STABLE [cf184ec77] 2026-07-07 23:59:08 +1200 Branch: REL_17_STABLE [be63b285e] 2026-07-07 23:59:33 +1200 Branch: REL_16_STABLE [a85732162] 2026-07-08 00:00:03 +1200 Branch: REL_15_STABLE [842e34efa] 2026-07-08 00:00:34 +1200

    Fix mis-optimization of <function>COUNT</function> window functions that have an <literal>EXCLUDE</literal> clause or lack <literal>ORDER BY</literal> (Chengpeng Yan, David Rowley) 《機械翻訳》EXCLUDE最適化または欠損ORDER BYを持つCOUNTウィンドウ関数の句ミスを修正した。 (Chengpeng Yan, David Rowley) §

    These window functions were treated as monotonic when they should not be, allowing wrong answers to be computed. 《機械翻訳》これらの窓関数は、単調であるべきでないときに単調として扱われ、間違いの回答を計算することを可能にした。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master Release: REL_19_BR [b574fec00] 2026-06-28 12:31:29 -0400 Branch: REL_18_STABLE [5fd1c3f28] 2026-06-28 12:31:29 -0400

    Avoid <quote>cache lookup failed for collation 0</quote> error when planner looks up statistics for a column of type <type>"char"</type> (Feng Wu) 《機械翻訳》プランナが統計処理でタイプ"char"のキャッシュを検索する場合は、照合順序0のカラム検索に失敗エラーを回避します。 (Feng Wu) §

  • Author: Álvaro Herrera <alvherre@kurilemu.de> Branch: master [fef160d8b] 2026-08-04 09:06:46 +0200 Branch: REL_19_STABLE [ce6e434ce] 2026-08-04 09:06:46 +0200 Branch: REL_18_STABLE [c374f2807] 2026-08-04 09:06:46 +0200 Branch: REL_17_STABLE [18006c1bd] 2026-08-04 09:06:46 +0200 Branch: REL_16_STABLE [34785a0d5] 2026-08-04 09:06:46 +0200 Branch: REL_15_STABLE [785289de0] 2026-08-04 09:06:46 +0200 Branch: REL_14_STABLE [cad17745e] 2026-08-04 09:06:46 +0200

    Fix <command>ALTER COLUMN ... DROP EXPRESSION</command> to work when there are multiple levels of partitions (Alberto Piai) 《機械翻訳》ALTER COLUMN ... DROP EXPRESSIONマルチプルレベルの間仕切りがある場合に機能するように修正します。 (Alberto Piai) §

  • Author: Álvaro Herrera <alvherre@kurilemu.de> Branch: master [d049a31a4] 2026-07-20 17:21:20 +0200 Branch: REL_19_STABLE [2b2c2492c] 2026-07-20 17:21:20 +0200 Branch: REL_18_STABLE [19e3aa704] 2026-07-20 17:21:20 +0200 Branch: REL_17_STABLE [1d6c654c8] 2026-07-20 17:21:20 +0200

    Fix attaching partitions of indexes that are exclusion constraints (Japin Li) 《機械翻訳》排他制約であるインデックスのパーティションの付加を修正しました。 (Japin Li) §

    Notably, this oversight broke dump/restore of partitioned exclusion constraints. 《機械翻訳》特に、この見落としは、分割された排他制約のダンプ/リストアを破壊した。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master Release: REL_19_BR [d8b5d87e5] 2026-05-22 23:59:04 +0900 Branch: REL_18_STABLE [41247cdf6] 2026-05-23 00:01:24 +0900

    Prevent setting <literal>NO INHERIT</literal> on partitioned <literal>NOT NULL</literal> constraints via <command>ALTER CONSTRAINT</command> (Andreas Karlsson) 《機械翻訳》設定を禁止するNO INHERITパーティション化されたNOT NULL ALTER CONSTRAINTによる制約。 (Andreas Karlsson) §

    <literal>NOT NULL</literal> constraints on partitioned tables are supposed to be inherited by all partitions, and therefore must not be marked <literal>NO INHERIT</literal>. This rule was correctly enforced by constraint creation, but not by <command>ALTER TABLE ... ALTER CONSTRAINT</command>. 《機械翻訳》NOT NULLテーブルパーティションの制約はすべてのパーティションに継承されることになっているため、NO INHERITとマークされてはなりません。 このルールは制約の作成時に正しく適用されましたが、ALTER TABLE ... ALTER CONSTRAINTでは適用されませんでした。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [a8c2547ea] 2026-07-04 11:34:26 -0400 Branch: REL_19_STABLE [80c7f5467] 2026-07-04 11:34:26 -0400 Branch: REL_18_STABLE [a7f7958ab] 2026-07-04 11:34:26 -0400 Branch: REL_17_STABLE [e99fb3262] 2026-07-04 11:34:26 -0400 Branch: REL_16_STABLE [a69503fb1] 2026-07-04 11:34:26 -0400 Branch: REL_15_STABLE [eada45dd8] 2026-07-04 11:34:26 -0400 Branch: REL_14_STABLE [1b17a6e3c] 2026-07-04 11:34:26 -0400

    Disallow renaming a rule to <literal>_RETURN</literal> (Tom Lane) 《機械翻訳》ルール名を_RETURN. (Tom Lane) §

    That name is reserved for a view's <literal>ON SELECT</literal> rule, but <command>ALTER RULE</command> allowed renaming other rules to <literal>_RETURN</literal>, causing trouble later. 《機械翻訳》その名前はビューの予約であるON SELECTルールだが、ALTERルールは他のルールを_RETURNに改名することを許可し、後にトラブルを引き起こした。

  • Author: Jeff Davis <jdavis@postgresql.org> Branch: master [b48caa7df] 2026-08-03 12:21:05 -0700 Branch: REL_19_STABLE [9eccdae22] 2026-08-03 12:25:15 -0700 Branch: REL_18_STABLE [a0daa0b41] 2026-08-03 12:25:31 -0700 Branch: REL_17_STABLE [25e54cec7] 2026-08-03 12:25:41 -0700 Branch: REL_16_STABLE [e61d44fde] 2026-08-03 12:25:49 -0700

    Fix missing lock release for role membership grants in <command>DROP OWNED BY</command> (Jeff Davis) 《機械翻訳》DROP OWNED BYで欠落しているロックリリースのロールメンバシップ認可を修正します。 (Jeff Davis) §

    This oversight resulted in a warning message, followed by retaining a lock on the membership grant until the end of the transaction. 《機械翻訳》この見落としの結果、ワーニングメッセージが誕生し、その後、トランザクションの終わりまでメンバシップ助成金のロックが維持されました。

  • Author: Richard Guo <rguo@postgresql.org> Branch: master [96ab9a990] 2026-07-08 08:46:43 +0900 Branch: REL_19_STABLE [eaa561fb6] 2026-07-08 08:48:29 +0900 Branch: REL_18_STABLE [45364e496] 2026-07-08 08:49:12 +0900 Branch: REL_17_STABLE [dcda1f07d] 2026-07-08 08:50:14 +0900 Branch: REL_16_STABLE [485527190] 2026-07-08 08:51:09 +0900

    Fix failure of <command>EXPLAIN</command> when deparsing <literal>SQL/JSON</literal> aggregates (Richard Guo) 《機械翻訳》EXPLAINdeparse SQL/JSON aggregates.*の失敗を修正しました。 (Richard Guo) §

    Some plan structures resulted in <quote>invalid JsonConstructorExpr underlying node type</quote> errors. 《機械翻訳》一部のプラン構造でノードタイプの基礎となる無効なJsonConstructorExprエラーが発生しました。

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master [74276e685] 2026-07-28 08:33:23 +0900 Branch: REL_19_STABLE [9f6fb1191] 2026-07-28 08:35:09 +0900 Branch: REL_18_STABLE [e4527519b] 2026-07-28 08:35:12 +0900 Branch: REL_17_STABLE [28269fed6] 2026-07-28 08:35:14 +0900 Branch: REL_16_STABLE [ac222bea5] 2026-07-28 08:35:17 +0900 Branch: REL_15_STABLE [5b3712e31] 2026-07-28 08:35:19 +0900 Branch: REL_14_STABLE [55adef7ab] 2026-07-28 08:35:21 +0900

    Fix use of <command>REINDEX CONCURRENTLY</command> with a deferred uniqueness constraint (Nitin Motiani) 《機械翻訳》REINDEX CONCURRENTLY with a遅延一意性制約の使用を修正しました。 (Nitin Motiani) §

    The transient index copy created during <command>REINDEX CONCURRENTLY</command> was incorrectly marked as enforcing immediate uniqueness, causing spurious reports of constraint violation. 《機械翻訳》の間に作成された一時的なインデックスコピーは、即時の一意性を強制するものとして誤ってマークされ、制約違反の誤った報告を引き起こした。 REINDEX CONCURRENTLY

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [d6ffcae32] 2026-07-06 14:35:21 -0400 Branch: REL_19_STABLE [99775b388] 2026-07-06 14:35:21 -0400 Branch: REL_18_STABLE [a99bd8d58] 2026-07-06 14:35:21 -0400 Branch: master [42b7ff3aa] 2026-07-06 14:47:58 -0400 Branch: REL_19_STABLE [54d5947ef] 2026-07-06 14:47:58 -0400 Branch: REL_18_STABLE [51652c42d] 2026-07-06 14:47:58 -0400

    Fix <literal>LIKE</literal> matching with nondeterministic collations and backslashes (Nitin Motiani, Tom Lane) 《機械翻訳》照合とバックスラッシュが明確でないLIKEマッチングを修正しました。 (Nitin Motiani, Tom Lane) § §

    When using a nondeterministic collation, <literal>LIKE</literal> mishandled an escaped backslash (<literal>\\</literal>), treating it as effectively not there. It also did the wrong thing with a leading backslash preceding an ordinary character; in that case the backslash should be effectively ignored, but it caused the ordinary character to be matched exactly rather than allowing the nondeterministic collation to decide if there's a match. 《機械翻訳》非決定性照合順序を使用する場合、LIKEエスケープされたバックスラッシュ\\を誤って処理し、実質的に存在しないものとして処理しました。 また、通常の文字の前に間違いが先行するバックスラッシュの処理も行いました。 このケースではバックスラッシュは実質的に無視されるはずですが、非決定性照合順序がマッチがあるかどうかを決定できるようにするのではなく、通常の文字が正確に一致するようにしました。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [2d7808e6f] 2026-07-06 13:06:24 -0400 Branch: REL_19_STABLE [67cf73ddb] 2026-07-06 13:06:25 -0400 Branch: REL_18_STABLE [d0bb49e61] 2026-07-06 13:06:25 -0400

    Fix <literal>LIKE</literal>/regex optimization for indexscan with exact-match pattern (Jelte Fennema-Nio) 《機械翻訳》正確な最適化マッチを使用するインデックススキャン用のLIKE/regexパターンを修正しました。 (Jelte Fennema-Nio) §

    Refactoring for <literal>LIKE</literal> with non-deterministic collations accidentally broke the optimization for converting a <literal>LIKE</literal> or regex exact-match pattern to an equality index condition when the index collation doesn't match the expression collation. Among other things, that made <application>psql</application>'s <literal>\d <replaceable>tablename</replaceable></literal> command much slower. 《機械翻訳》LIKE非決定性照合を使用したのリファクタリングでは、最適化パターンがマッチインデックスをマッチしていない場合に、LIKEまたは正規表現の正確な式照合順序を等式条件に変換するためのが誤って壊れた。 とりわけ、psql\d tablenameコマンドははるかに遅くなった。 インデックス照合順序

  • Author: Álvaro Herrera <alvherre@kurilemu.de> Branch: master [fd2b89854] 2026-08-05 11:40:39 +0200 Branch: REL_19_STABLE [55ea76426] 2026-08-05 11:40:39 +0200 Branch: REL_18_STABLE [011384ba4] 2026-08-05 11:40:39 +0200 Branch: REL_17_STABLE [8acfaa12a] 2026-08-05 11:40:39 +0200 Branch: REL_16_STABLE [b594efe52] 2026-08-05 11:40:39 +0200 Branch: REL_15_STABLE [0de744cd5] 2026-08-05 11:40:39 +0200 Branch: REL_14_STABLE [49a712f32] 2026-08-05 11:40:39 +0200 Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> Branch: REL_18_STABLE [5f003855e] 2026-08-11 21:24:28 +0300

    Fix matching of localized month/day names in <function>to_date()</function> (Heikki Linnakangas) 《機械翻訳》ローカライズされた月/日の名前のマッチングを修正しましたto_date(). (Heikki Linnakangas) § §

    The matching logic misbehaved in cases where case-folding changes the byte length of the string. 《機械翻訳》マッチングロジックでは、ケース折りによって文字列のバイト長さが変更された場合に問題が発生した。

  • Author: Jeff Davis <jdavis@postgresql.org> Branch: master [368693689] 2026-07-07 14:53:41 -0700 Branch: REL_19_STABLE [28d498e28] 2026-07-07 14:29:21 -0700 Branch: REL_18_STABLE [66ec24276] 2026-07-07 15:04:31 -0700

    Correct case-folding rules for Greek final sigma (Jeff Davis) 《機械翻訳》ケース最終シグマのギリシャフォールディング規則を修正する。 (Jeff Davis) §

    If the string is preceded only by Case Ignorable characters, don't consider it to be a final sigma. This only affects the built-in <literal>pg_unicode_fast</literal> locale. 《機械翻訳》文字列の前にケースIgnorable文字しかない場合、それを最終シグマとはみなさない。 これは組み込みのpg_unicode_fastロケールにのみ影響する。

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [f2ff15e4c] 2026-06-05 07:50:08 +0900 Branch: REL_18_STABLE [273fe9485] 2026-06-05 07:50:12 +0900 Branch: REL_17_STABLE [0c9cbbfb5] 2026-06-05 07:50:13 +0900 Branch: REL_16_STABLE [82116023e] 2026-06-05 07:50:15 +0900 Branch: REL_15_STABLE [c391375ba] 2026-06-05 07:50:16 +0900 Branch: REL_14_STABLE [8bb935d61] 2026-06-05 07:50:18 +0900

    Fix incorrect NFC recomposition for Hangul U+11A7 (TBASE) (Diego Frias, Michael Paquier) 《機械翻訳》ハングルU+11A7(TBASE)の不正なNFC再構成を修正します。 (Diego Frias, Michael Paquier) §

    This character was treated as a valid T syllable, which it is not, and hence silently swallowed during normalization. 《機械翻訳》この文字は有効なT音節として扱われましたが、実際はそうではないため、正規化中に静かに飲み込まれました。

  • Author: Jeff Davis <jdavis@postgresql.org> Branch: master Release: REL_19_BR [9234e3337] 2026-06-08 11:47:53 -0700 Branch: REL_18_STABLE [89e648498] 2026-06-08 11:47:40 -0700 Branch: REL_17_STABLE [3805641cb] 2026-06-08 11:48:27 -0700 Branch: REL_16_STABLE [b32df590c] 2026-06-08 11:48:48 -0700 Branch: REL_15_STABLE [a7e0e42a2] 2026-06-08 11:49:11 -0700 Branch: REL_14_STABLE [1e0458172] 2026-06-08 11:49:27 -0700

    Avoid possible truncation of output lexemes in case-insensitive <literal>synonym</literal> dictionaries (Jeff Davis) 《機械翻訳》ケースの影響を受けないsynonym辞書語彙素では、出力が切り捨てられる可能性があります。 (Jeff Davis) §

    If folding to lower case increased the byte length of a lexeme, it was incorrectly truncated to its original byte length when emitted. 《機械翻訳》下部ケースへの折り畳みが語彙素のバイト長さを増加させた場合、放出時にオリジナルバイト長さに誤って切り捨てられた。

  • Author: Jeff Davis <jdavis@postgresql.org> Branch: master [21ffc271d] 2026-07-07 13:34:55 -0700 Branch: REL_19_STABLE [05da336dd] 2026-07-07 13:35:07 -0700 Branch: REL_18_STABLE [9021c8f3c] 2026-07-07 13:35:15 -0700 Branch: REL_17_STABLE [5e78ebca5] 2026-07-07 13:35:23 -0700

    Defend against truncated UTF-8 characters in case-conversion logic (Jeff Davis) 《機械翻訳》ケース-変換ロジックで切り捨てられたUTF-8文字に対する防御。 (Jeff Davis) §

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [273a3c776] 2026-06-03 12:47:22 +0900 Branch: REL_18_STABLE [b3f13c032] 2026-06-03 12:47:26 +0900 Branch: REL_17_STABLE [203e238bb] 2026-06-03 12:47:28 +0900 Branch: REL_16_STABLE [8b5580a05] 2026-06-03 12:47:30 +0900 Branch: REL_15_STABLE [259b627d5] 2026-06-03 12:47:32 +0900 Branch: REL_14_STABLE [74d3482f4] 2026-06-03 12:47:34 +0900

    Fix typo in <function>hash_record_extended()</function> (Man Zeng) 《機械翻訳》タイポをhash_record_extended(). (Man Zeng) §

    The code failed to initialize the second isnull argument passed to FunctionCallInvoke(). This is harmless for existing in-core extended hash support functions, which will not examine that value. However, extension-provided hash functions could be affected if they inspect <literal>PG_ARGISNULL(1)</literal>. 《機械翻訳》コードは、FunctionCallInvoke()に渡された2番目のisnull引数の初期化に失敗しました。 これは、その値を検査しない既存の-コア拡張ハッシュサポート関数には問題ありません。 ただし、extension提供のハッシュ関数は、検査PG_ARGISNULL(1)

  • Author: Masahiko Sawada <msawada@postgresql.org> Branch: master [63e7a0d2c] 2026-07-28 10:39:36 -0700 Branch: REL_19_STABLE [28c995948] 2026-07-28 10:39:40 -0700 Branch: REL_18_STABLE [73d63d1c1] 2026-07-28 10:39:43 -0700 Branch: REL_17_STABLE [dcbc96685] 2026-07-28 10:39:47 -0700 Branch: REL_16_STABLE [6c760f6b6] 2026-07-28 10:39:50 -0700

    Fix <function>pg_get_publication_tables()</function> to not fail if a publishable table is dropped concurrently (Bharath Rupireddy) 《機械翻訳》pg_get_publication_tables()発行可能なテーブルが同時に削除されても失敗しないように修正しました。 (Bharath Rupireddy) §

  • Author: Robert Haas <rhaas@postgresql.org> Branch: master [e8914ec22] 2026-07-06 12:51:29 -0400 Branch: REL_19_STABLE [2ddc45662] 2026-07-06 12:31:42 -0400 Branch: REL_18_STABLE [0c06ebf12] 2026-07-06 12:24:03 -0400 Branch: REL_17_STABLE [52af6fef4] 2026-07-06 12:24:10 -0400 Branch: REL_16_STABLE [6de480156] 2026-07-06 12:24:16 -0400 Branch: REL_15_STABLE [d39b9eed0] 2026-07-06 12:24:23 -0400 Branch: REL_14_STABLE [0115650de] 2026-07-06 12:24:28 -0400

    Prevent <function>satisfies_hash_partition()</function> from crashing with <literal>VARIADIC NULL</literal> (Robert Haas) 《機械翻訳》satisfies_hash_partition()VARIADIC NULL. (Robert Haas) §

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master Release: REL_19_BR [ce6bf3cd1] 2026-06-04 12:24:51 -0400 Branch: REL_18_STABLE [c5194139c] 2026-06-04 12:24:51 -0400 Branch: REL_17_STABLE [0626fbfeb] 2026-06-04 12:24:51 -0400 Branch: REL_16_STABLE [ed5ca5828] 2026-06-04 12:24:51 -0400 Branch: REL_15_STABLE [b3a86eb6d] 2026-06-04 12:24:51 -0400 Branch: REL_14_STABLE [262cc4df2] 2026-06-04 12:24:51 -0400

    Report invalid-weight errors more cleanly and consistently in <function>tsvector_filter()</function> and allied functions (Ewan Young) 《機械翻訳》レポートが無効-ウェイトは、tsvector_filter()および関連する関数において、より明確かつ一貫してエラーを発生させる。 (Ewan Young) §

    In particular, report weight characters that are not printable ASCII in octal form (<literal>\<replaceable>nnn</replaceable></literal>), as <function>charout()</function> would render them. This avoids possibly producing an invalidly-encoded error message. 《機械翻訳》特に、\nnnのように、8進数のウェイトで表示可能なASCII文字ではないレポートフォーム文字は、charout()表示されます。 これにより、無効にエンコードされたエラーメッセージが生成される可能性がなくなります。

  • Author: Masahiko Sawada <msawada@postgresql.org> Branch: master [7575215e0] 2026-07-16 11:50:10 -0700 Branch: REL_19_STABLE [2a933deaa] 2026-07-16 11:50:16 -0700 Branch: REL_18_STABLE [c31b0fca0] 2026-07-16 11:50:13 -0700

    Reject out-of-range timestamp shift values in <function>uuidv7()</function> (Baji Shaik) 《機械翻訳》uuidv7().内のレンジ外タイムスタンプシフト値を拒否します。 (Baji Shaik) §

    The shift value must not be so large as to produce a timestamp out of the range that a v7 UUID can represent. Previously, a garbage UUID value was produced. 《機械翻訳》シフト値は、v7ラージが表現できるタイムスタンプからレンジを生成するようなUUIDであってはなりません。 以前は、ガーベッジUUID値が生成されていました。

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [8bf257aeb] 2026-06-12 10:25:45 +0900 Branch: REL_18_STABLE [4c777d6dd] 2026-06-12 10:25:49 +0900 Branch: REL_17_STABLE [6c08cbb7a] 2026-06-12 10:25:51 +0900 Branch: REL_16_STABLE [174076601] 2026-06-12 10:25:53 +0900 Branch: REL_15_STABLE [1d8c72b2e] 2026-06-12 10:25:54 +0900 Branch: REL_14_STABLE [41876c8d7] 2026-06-12 10:25:59 +0900 Branch: master Release: REL_19_BR [0b74df66f] 2026-06-12 12:37:21 +0900 Branch: REL_18_STABLE [0d145be2c] 2026-06-12 12:39:11 +0900 Branch: REL_17_STABLE [940916549] 2026-06-12 12:39:17 +0900 Branch: REL_16_STABLE [fac26fd41] 2026-06-12 12:39:22 +0900 Branch: REL_15_STABLE [9618e790c] 2026-06-12 12:39:34 +0900 Branch: REL_14_STABLE [a17f39aa2] 2026-06-12 12:39:40 +0900

    Fix mishandling of namespace nodes in <function>xpath()</function> (Michael Paquier) 《機械翻訳》xpath()でのネームスペースノードの誤った処理を修正しました。 (Michael Paquier) § §

    This fix avoids an unexpected <quote>could not copy node</quote> error. 《機械翻訳》この修正により、予期しないノードをコピーできないエラーが回避されます。

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master [7b12ae729] 2026-07-02 12:44:29 +0900 Branch: REL_19_STABLE [5bbc9b300] 2026-07-02 12:44:31 +0900 Branch: REL_18_STABLE [84001a04d] 2026-07-02 12:44:33 +0900 Branch: REL_17_STABLE [ab35b8d25] 2026-07-02 12:44:36 +0900 Branch: REL_18_STABLE [90789900b] 2026-07-02 15:06:05 +0900 Branch: REL_17_STABLE [c768637d6] 2026-07-02 15:06:12 +0900

    Fix <type>jsonpath</type>'s <function>.decimal</function> method to not throw a hard error for incorrect precision or scale (Ewan Young) 《機械翻訳》jsonpath.decimalメソッドが誤ったハードまたはエラーに対して精度位取りをスローしないように修正した。 (Ewan Young) § §

    Silent mode should suppress these errors, but failed to. 《機械翻訳》サイレントモードはこれらの誤りを抑制すべきであるが、できなかった。

  • Author: Álvaro Herrera <alvherre@kurilemu.de> Branch: master Release: REL_19_BR [7dd153259] 2026-06-11 16:17:58 +0200 Branch: REL_18_STABLE [35d9a6263] 2026-06-11 16:17:58 +0200 Branch: REL_17_STABLE [d0acd2535] 2026-06-11 16:17:58 +0200 Branch: REL_16_STABLE [60abb3c73] 2026-06-11 16:17:58 +0200

    Fix NULL-pointer crash when <literal>IS JSON</literal> or similar constructs have an argument that is of string category but lacks a cast to type <type>text</type> (Ayush Tiwari) 《機械翻訳》IS JSONまたは類似の構成に、NULLポインタのクラッシュはあるが、タイプテキストへの引数がない場合、文字列カテゴリを修正しました。 キャスト (Ayush Tiwari) §

    There are no such data types in core <productname>PostgreSQL</productname>, but the problem is reachable with some extension types. 《機械翻訳》コアにはそのようなデータタイプはありませんPostgreSQLただし、一部のextensionタイプでは問題が発生する可能性があります。

  • Author: Amit Langote <amitlan@postgresql.org> Branch: master [4c75cc786] 2026-07-07 08:27:32 +0900 Branch: REL_19_STABLE [d30bfcbdd] 2026-07-07 08:27:19 +0900 Branch: REL_18_STABLE [441e4c8d6] 2026-07-07 08:27:05 +0900 Branch: REL_17_STABLE [71cd10cd2] 2026-07-07 08:26:50 +0900

    Ensure that <literal>SQL/JSON</literal> <literal>ON EMPTY / ON ERROR DEFAULT</literal> values are coerced to the correct typmod (Ewan Young) 《機械翻訳》保証SQL/JSON ON EMPTY / ON ERROR DEFAULT値は正しいtypmodに強制されます。 (Ewan Young) §

    For example, the declared precision and scale of a <type>numeric</type> target column were not applied to the default value. 《機械翻訳》例の場合、宣言された精度と数値位取りカラムのターゲットはデフォルト値に適用されませんでした。

  • Author: David Rowley <drowley@postgresql.org> Branch: master [b4dfae2ff] 2026-08-04 17:59:13 +1200 Branch: REL_19_STABLE [7746f7492] 2026-08-04 17:59:58 +1200 Branch: REL_18_STABLE [6298a41b4] 2026-08-04 18:00:27 +1200 Branch: REL_17_STABLE [1416f304d] 2026-08-04 18:00:49 +1200 Branch: REL_16_STABLE [86f42357c] 2026-08-04 18:01:10 +1200 Branch: REL_15_STABLE [d782c97e1] 2026-08-04 18:01:31 +1200 Branch: REL_14_STABLE [fec40878c] 2026-08-04 18:01:55 +1200

    Avoid machine-dependent behavior when dividing the smallest possible <type>money</type> value by -1 (Andrey Rachitskiy) 《機械翻訳》可能な最小の金額値を-1で割るときは、マシンに依存する動作を避けてください。 (Andrey Rachitskiy) §

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [4e68b7e29] 2026-08-02 16:49:17 -0400 Branch: REL_19_STABLE [df8407d7d] 2026-08-02 16:49:18 -0400 Branch: REL_18_STABLE [81b1e7916] 2026-08-02 16:49:18 -0400 Branch: REL_17_STABLE [634a8dcb8] 2026-08-02 16:49:18 -0400 Branch: REL_16_STABLE [83336e3ed] 2026-08-02 16:49:18 -0400 Branch: REL_15_STABLE [025228104] 2026-08-02 16:49:18 -0400 Branch: REL_14_STABLE [dda622edc] 2026-08-02 16:49:18 -0400

    Fix crash after out-of-memory failure partway through creation of a cache entry for a text search dictionary (Tom Lane) 《機械翻訳》クラッシュディクショナリのメモリエントリの作成中に、キャッシュ外エラーが発生した場合にテキストサーチを修正しました。 (Tom Lane) §

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [330a72052] 2026-08-02 13:22:39 -0400 Branch: REL_19_STABLE [3fe4062cc] 2026-08-02 13:22:39 -0400 Branch: REL_18_STABLE [4689ea9ce] 2026-08-02 13:22:39 -0400 Branch: REL_17_STABLE [5fdea3aa3] 2026-08-02 13:22:39 -0400 Branch: REL_16_STABLE [444038bb7] 2026-08-02 13:22:39 -0400 Branch: REL_15_STABLE [0fb88979b] 2026-08-02 13:22:39 -0400 Branch: REL_14_STABLE [cfc720ef4] 2026-08-02 13:22:39 -0400

    Fix memory-safety bugs in processing of incorrect ispell/hunspell dictionary files (Andrey Rachitskiy) 《機械翻訳》間違ったispell/hunspellディクショナリファイルを処理する際のメモリ安全に関するバグを修正しました。 (Andrey Rachitskiy) §

  • Author: Alexander Korotkov <akorotkov@postgresql.org> Branch: master Release: REL_19_BR [ce146621f] 2026-05-14 15:01:17 +0300 Branch: REL_18_STABLE [1b0dd0815] 2026-05-14 15:06:27 +0300 Branch: REL_17_STABLE [4dfae59a1] 2026-05-14 15:07:03 +0300 Branch: master [c40819ebf] 2026-07-03 18:02:14 +0300 Branch: REL_19_STABLE [8021cdceb] 2026-07-03 18:01:25 +0300 Branch: REL_18_STABLE [3aaefe892] 2026-07-03 18:01:21 +0300 Branch: REL_17_STABLE [4e49f68b7] 2026-07-03 18:01:03 +0300 Branch: REL_16_STABLE [cc3fe7e2a] 2026-07-03 18:01:00 +0300

    Prevent access to other sessions' temporary tables (Jim Jones, Daniil Davydov, Alexander Korotkov) 《機械翻訳》他のセッションのアクセステーブルへの一時的を禁止します。 (Jim Jones, Daniil Davydov, Alexander Korotkov) § §

    Some code paths failed to prevent this, leading to silently wrong (inconsistent) results. 《機械翻訳》コード経路の中にはこれを防ぐことができず、静かに間違い(一貫性のない)結果をもたらした。

  • Author: Melanie Plageman <melanieplageman@gmail.com> Branch: master Release: REL_19_BR [da6874635] 2026-04-21 11:03:05 -0400 Branch: REL_18_STABLE [ed8050370] 2026-08-05 11:44:01 -0400

    Prevent <quote>no empty local buffer available</quote> errors during temporary table access (Melanie Plageman) 《機械翻訳》ローカルバッファアクセス時のエラー空の一時テーブルがないを防止します。 (Melanie Plageman) §

    Limit the number of local buffers that the read streaming mechanism is allowed to use. Previously, a large value of <varname>effective_io_concurrency</varname> could allow a single stream to use all the buffers, resulting in failure. 《機械翻訳》読取りローカル・ストリーミングが使用できるメカニズム・バッファの数を制限します。 以前は、ラージ値にeffective_io_concurrencyを指定すると、1つのストリームがすべてのバッファを使用できるため、エラーが発生していました。

  • Author: Nathan Bossart <nathan@postgresql.org> Branch: master [baab3268c] 2026-07-31 10:34:40 -0500 Branch: REL_19_STABLE [b3331578b] 2026-07-31 10:34:40 -0500 Branch: REL_18_STABLE [4cc49cb70] 2026-07-31 10:34:40 -0500 Branch: REL_17_STABLE [288d4e83f] 2026-07-31 10:34:40 -0500

    Fix the order in which autovacuum processes databases (Rustam Khamidullin) 《機械翻訳》自動バキュームプロセスがデータベースに登録しているオーダーを修正します。 (Rustam Khamidullin) §

    It was unintentionally processing databases from lowest to highest score, when it should be doing the reverse. 《機械翻訳》本来はその逆であるべきデータベースを、意図せずに最低スコアから最高スコアまで処理していました。

  • Author: Melanie Plageman <melanieplageman@gmail.com> Branch: master [112c26838] 2026-08-06 17:22:34 -0400 Branch: REL_19_STABLE [fd90c3221] 2026-08-06 17:24:12 -0400 Branch: REL_18_STABLE [585181e07] 2026-08-06 17:31:22 -0400 Branch: master [69800557c] 2026-08-07 10:00:26 -0400 Branch: REL_19_STABLE [55d01a10f] 2026-08-07 10:05:23 -0400 Branch: REL_18_STABLE [7c25cdb1e] 2026-08-07 10:06:41 -0400

    Restore full use of shared buffer pool in <command>VACUUM</command>'s wraparound failsafe mode (Melanie Plageman) 《機械翻訳》リストアVACUUM周回フェイルセーフモードでの共同バッファプールのフル活用 (Melanie Plageman) § §

    An ordinary <command>VACUUM</command> is limited to use just a few shared buffers, so as not to impinge too much on other processing. However, in failsafe mode we want to reclaim transaction IDs as quickly as possible, so that limit is supposed to be abandoned to allow vacuuming to proceed as fast as possible. This behavior was accidentally broken during refactoring in v18; restore it. 《機械翻訳》通常のVACUUMは、他の処理にあまり影響を与えないように、いくつかの共有バッファのみを使用するように制限されています。 ただし、フェイルセーフモードでは、できるだけ早くトランザクションIDを再要求したいので、この制限は放棄され、バキューム処理ができるだけ早く処理できるようになります。 この動作は、v18でのリファクタリング中に誤って壊れました。 リストアit。

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [b20c952ce] 2026-06-08 15:29:16 +0900 Branch: REL_18_STABLE [4154a1482] 2026-06-08 15:29:19 +0900 Branch: REL_17_STABLE [8ad414831] 2026-06-08 15:29:21 +0900

    Fix memory leak in parallel vacuum worker processes (Baji Shaik) 《機械翻訳》パラレルバキュームワーカープロセスでメモリリークを固定します。 (Baji Shaik) §

    Progress reports from a parallel worker leaked about 1kB per report, with the waste accumulating for the life of the worker process. 《機械翻訳》パラレルワーカーからの経過報告は、レポートごとに約1つのキロバイトが漏洩し、ワーカープロセスの存続期間中に廃棄物が蓄積した。

  • Author: Alexander Korotkov <akorotkov@postgresql.org> Branch: master [8a045f760] 2026-07-28 10:50:22 +0200 Branch: REL_19_STABLE [70dad584e] 2026-07-28 10:50:53 +0200 Branch: REL_18_STABLE [7becb647d] 2026-07-28 10:52:59 +0200 Branch: REL_17_STABLE [ba5e46329] 2026-07-28 10:56:27 +0200 Branch: REL_16_STABLE [006ac761e] 2026-07-28 10:56:34 +0200 Branch: REL_15_STABLE [7123abab7] 2026-07-28 10:56:38 +0200 Branch: REL_14_STABLE [15fd7a3e2] 2026-07-28 10:56:39 +0200

    Honor query cancel and vacuum delay during GIN index posting-tree cleanup (Paul Kim, Alexander Korotkov) 《機械翻訳》GINキャンセル赴任中に問い合わせインデックスとバキューム遅延に敬意を表します-ツリークリーンアップ。 (Paul Kim, Alexander Korotkov) §

    The posting tree for a common value can be large, so that this missed check could allow vacuum to run for a long time before noticing an interrupt. 《機械翻訳》共通値のための提示ツリーは、ラージとすることができ、したがって、この逃したチェックは、バキュームが中断に気づいて長い間前を実行することを可能にすることができる。

  • Author: Peter Geoghegan <pg@bowt.ie> Branch: master [c9ea37231] 2026-07-17 15:53:10 -0400 Branch: REL_19_STABLE [1d4c81ad6] 2026-07-17 15:53:07 -0400 Branch: REL_18_STABLE [959b7fa2c] 2026-07-17 15:53:05 -0400 Branch: REL_17_STABLE [355faed5a] 2026-07-17 15:53:02 -0400 Branch: REL_16_STABLE [e58192546] 2026-07-17 15:53:00 -0400 Branch: REL_15_STABLE [126141425] 2026-07-17 15:52:58 -0400 Branch: REL_14_STABLE [e4ad22eb0] 2026-07-17 15:52:56 -0400

    Fix possible mis-decoding of index tuples during GiST and SP-GiST index-only scans (Peter Geoghegan) 《機械翻訳》インデックスおよびSP-GiST GiSTのみのスキャン中に発生する可能性があったインデックスタプルのデコードミスが修正されました。 (Peter Geoghegan) §

    This error could lead to emitting corrupted data from an index-only scan plan. The only affected core opclass is GiST's range_ops, and it could only fail if the range column were not the first index column. 《機械翻訳》このエラーは、インデックスのみのスキャンプランからの汚染されたデータの排出につながる可能性があります。 影響を受ける唯一のコアopclassはGiSTのレンジ_opsであり、レンジカラムが最初のインデックスカラムでない場合にのみ失敗します。

  • Author: Melanie Plageman <melanieplageman@gmail.com> Branch: master [a2fd8d65a] 2026-07-15 15:51:05 -0400 Branch: REL_19_STABLE [7a103928a] 2026-07-15 15:52:43 -0400 Branch: REL_18_STABLE [eabc9a9dd] 2026-07-15 15:54:54 -0400 Branch: REL_17_STABLE [768ae083e] 2026-07-15 15:56:06 -0400 Branch: REL_16_STABLE [0fd5595aa] 2026-07-15 15:58:15 -0400

    Ensure that the new last block of a bulk-extended table is added to its free space map promptly (Jingtang Zhang) 《機械翻訳》バルク-拡張テーブルの新たな最後のブロックがその空き領域マップに速やかに追加される保証。 (Jingtang Zhang) §

    An off-by-one error caused the last block of a multi-block table extension to not be marked as free in the map. This would eventually get corrected by vacuum, but meanwhile the space wouldn't be used. 《機械翻訳》マルチ-ブロックテーブルextensionの最後のブロックがマップでフリーと表示されなかったのは、オフごとのエラーが原因でした。 これは最終的にバキュームによって修正されますが、その間スペースは使用されませんでした。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master Release: REL_19_BR [ef01ca6db] 2026-06-22 18:03:23 -0400 Branch: REL_18_STABLE [ac6a58a70] 2026-06-22 18:03:23 -0400 Branch: REL_17_STABLE [011eedcdc] 2026-06-22 18:03:23 -0400

    Avoid possible double-free or infinite error recovery loop in resource cleanup during transaction abort (Tom Lane) 《機械翻訳》トランザクション中断中のリソースフリーでは、二重無限またはエラーリカバリループの可能性を避けてください。 クリーンアップ (Tom Lane) §

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master Release: REL_19_BR [f25a07b2d] 2026-06-19 12:52:00 -0400 Branch: REL_18_STABLE [aa80c34c8] 2026-06-19 12:52:00 -0400 Branch: REL_17_STABLE [f0a831ef3] 2026-06-19 12:52:00 -0400 Branch: REL_16_STABLE [9951e3d38] 2026-06-19 12:52:00 -0400 Branch: REL_15_STABLE [4647ac142] 2026-06-19 12:52:00 -0400 Branch: REL_14_STABLE [4b3bc6b71] 2026-06-19 12:52:00 -0400

    When creating directories, tolerate concurrent creation of the same directory (Andrew Dunstan, Tom Lane) 《機械翻訳》ディレクトリを作成する場合、同じディレクトリの同時作成を許容します。 (Andrew Dunstan, Tom Lane) §

  • Author: David Rowley <drowley@postgresql.org> Branch: master Release: REL_19_BR [dc5116780] 2026-06-19 15:26:18 +1200 Branch: REL_18_STABLE [e9692de1d] 2026-06-19 15:26:51 +1200

    Fix JIT-compiled tuple deconstruction code to account correctly for virtual generated columns (David Rowley) 《機械翻訳》仮想的に生成された列に対して、JITコンパイルされたタプル分解コードがアカウントに正しく修正されました。 (David Rowley) §

  • Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> Branch: master Release: REL_19_BR [2fbb21170] 2026-05-27 18:41:14 +0300 Branch: REL_18_STABLE [c8cd3d697] 2026-05-27 18:36:28 +0300 Branch: REL_17_STABLE [3a9909eda] 2026-05-27 18:36:51 +0300 Branch: REL_16_STABLE [d9bc0d96c] 2026-05-27 18:37:12 +0300 Branch: REL_15_STABLE [5fa137727] 2026-05-27 18:37:32 +0300 Branch: REL_14_STABLE [5100bdbd3] 2026-05-27 18:37:56 +0300 Branch: master Release: REL_19_BR [fd93ee100] 2026-05-27 18:41:03 +0300 Branch: REL_18_STABLE [f9d5a52da] 2026-05-27 18:36:25 +0300 Branch: REL_17_STABLE [c1588f92a] 2026-05-27 18:36:46 +0300 Branch: REL_16_STABLE [d44cd4674] 2026-05-27 18:37:04 +0300 Branch: REL_15_STABLE [ef3d7b15e] 2026-05-27 18:37:27 +0300 Branch: REL_14_STABLE [36b6ed260] 2026-05-27 18:37:48 +0300

    Prevent creation of dangling object dependencies by acquiring a shared lock on any object being depended on (Bertrand Drouvot) 《機械翻訳》依存しているオブジェクトの共有ロックを取得することで、ダングリングオブジェクトの依存関係が作成されないようにします。 (Bertrand Drouvot) § §

    The shared lock will conflict with any attempt to drop the depended-on object, eliminating the race condition that formerly existed. For example, if one session drops a schema (that appears empty to it) concurrently with some other session creating a function in that schema, previously both transactions could commit, leaving an invalid function definition behind. Now, one transaction or the other will fail. 《機械翻訳》共有ロックは、以前に存在していたオブジェクトを削除して、依存していた競合条件を削除しようとする試みをコンフリクトします。 例の場合、あるセッションが(空に見える)スキーマを削除すると同時に、他のセッションがそのスキーマに関数を作成すると、以前は両方の取引がコミットする可能性があり、無効な関数定義が残されていました。 これで、どちらかのトランザクションが失敗します。

  • Author: Peter Geoghegan <pg@bowt.ie> Branch: master [ce3f19e26] 2026-07-25 12:01:35 -0400 Branch: REL_19_STABLE [2aa3c6d1f] 2026-07-25 12:01:34 -0400 Branch: REL_18_STABLE [d560e730e] 2026-07-25 12:01:32 -0400 Branch: REL_17_STABLE [8434c9385] 2026-07-25 12:01:30 -0400 Branch: REL_16_STABLE [e321faaae] 2026-07-25 12:01:28 -0400 Branch: REL_15_STABLE [5d18105ca] 2026-07-25 12:01:26 -0400 Branch: REL_14_STABLE [2fc3e1b44] 2026-07-25 12:01:24 -0400

    Fix race condition in conflict detection for <literal>SERIALIZABLE</literal> isolation mode (Peter Geoghegan) 《機械翻訳》SERIALIZABLE隔離競合条件のコンフリクト検出にモードを固定する。 (Peter Geoghegan) §

    A conflict could be missed when examining an initially-empty btree index, allowing failure of serializability due to improperly allowing conflicting transactions to commit. 《機械翻訳》最初は空であったb-treeコンフリクトを検査する際にインデックスが見落とされる可能性があり、コミットへの競合するトランザクションを不適切に許可することにより、直列化可能性の失敗を可能にする。

  • Author: Masahiko Sawada <msawada@postgresql.org> Branch: master Release: REL_19_BR [d79bf7612] 2026-05-27 16:25:56 -0700 Branch: REL_18_STABLE [1a9b1cc18] 2026-05-27 16:25:59 -0700 Branch: REL_17_STABLE [a651b8a89] 2026-05-27 16:26:02 -0700 Branch: REL_16_STABLE [cdb9b2830] 2026-05-27 16:26:05 -0700 Branch: REL_15_STABLE [159324a73] 2026-05-27 16:26:08 -0700

    Fix race condition in ProcSignalBarrier code (Masahiko Sawada) 《機械翻訳》ProcSignalBarrierコードの競合条件を修正します。 (Masahiko Sawada) §

    This error could result in processes getting stuck, typically after reporting <quote>still waiting for backend with PID <replaceable>nnnn</replaceable> to accept ProcSignalBarrier</quote>. 《機械翻訳》このエラーにより、通常はレポート後にプロセスが停止する可能性がありますnnnn ProcSignalBarrierを受け入れるためにPIDでバックエンドを待機しています

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [563104523] 2026-05-27 14:48:56 +0900 Branch: REL_18_STABLE [ae08eb168] 2026-05-27 14:48:59 +0900 Branch: REL_17_STABLE [d489c4439] 2026-05-27 14:49:01 +0900 Branch: REL_16_STABLE [65d04df60] 2026-05-27 14:49:02 +0900 Branch: REL_15_STABLE [d5cc6df60] 2026-05-27 14:49:04 +0900 Branch: REL_14_STABLE [8007d1185] 2026-05-27 14:52:31 +0900 Branch: master Release: REL_19_BR [84b9d6bce] 2026-05-27 17:19:20 +0900 Branch: REL_18_STABLE [12c9b8b42] 2026-05-27 17:19:53 +0900 Branch: REL_17_STABLE [e14b4ea4a] 2026-05-27 17:19:55 +0900 Branch: REL_16_STABLE [4e8edf53f] 2026-05-27 17:19:56 +0900 Branch: REL_15_STABLE [e786fb5aa] 2026-05-27 17:19:58 +0900 Branch: REL_14_STABLE [db4d12fc9] 2026-05-27 17:20:00 +0900

    Fix race conditions when a set of processes that belong to the same lock group exit at the same time (Vlad Lesin) 《機械翻訳》同じロックグループに属する一連のプロセスが同時に終了する場合の競合状態を修正した。 (Vlad Lesin) § §

    These errors could lead to PANIC aborts, with messages such as <quote>latch already owned</quote>. The issue does not normally arise in regular parallel query, since the leader won't exit before seeing its workers finish; but some extensions reach the problem. 《機械翻訳》これらのエラーは、パニックはすでに所有されていますのようなメッセージを表示して、ラッチの中断につながる可能性があります。 この問題は通常のパラレル問い合わせでは発生しません。 なぜなら、リーダーはワーカーが終了するのを見て前を出ることはないからです。 しかし、いくつかの拡張はこの問題に到達します。

  • Author: Melanie Plageman <melanieplageman@gmail.com> Branch: master [10911fde0] 2026-07-15 17:24:49 -0400 Branch: REL_19_STABLE [56bf5fa5d] 2026-07-15 17:32:17 -0400 Branch: REL_18_STABLE [d0fb1da21] 2026-07-15 17:37:34 -0400 Branch: REL_17_STABLE [7edec8b57] 2026-07-15 17:43:38 -0400 Branch: master [ed62d26ca] 2026-07-15 17:24:49 -0400 Branch: REL_19_STABLE [b01c31eef] 2026-07-15 17:32:17 -0400 Branch: REL_18_STABLE [f581fa729] 2026-07-15 17:37:34 -0400 Branch: REL_17_STABLE [c0d9864f5] 2026-07-15 17:43:38 -0400 Branch: master [5174d157a] 2026-07-15 17:24:49 -0400 Branch: REL_19_STABLE [9171f77db] 2026-07-15 17:32:17 -0400 Branch: REL_18_STABLE [4d7feebfb] 2026-07-15 17:37:34 -0400 Branch: REL_17_STABLE [067213430] 2026-07-15 17:43:38 -0400

    Fix WAL logging of operations that clear bits in tables' visibility maps (Melanie Plageman, Andres Freund) 《機械翻訳》ロギングがテーブルの可視マップに割り込む操作のWALクリアを修正しました。 (Melanie Plageman, Andres Freund) § § §

    Such VM changes were missed by the WAL summarizer, potentially leading to incorrect incremental backups. We also failed to log full-page images of such VM pages when needed, potentially allowing torn page writes to go uncorrected. This could lead to misbehavior later, such as wrong results from index-only scans. 《機械翻訳》このようなVMの変更はWALサマライザによって見逃され、不正な増分バックアップを引き起こす可能性がありました。 また、必要なときにこのようなVMページのフルページイメージをログすることに失敗し、引き裂かれたページ書き込みが修正されない可能性がありました。 これは、インデックスのみのスキャンからの間違い結果など、後で不正な動作を引き起こす可能性がありました。

  • Author: Robert Haas <rhaas@postgresql.org> Branch: master [3e8a0c1b0] 2026-07-31 11:55:54 -0400 Branch: REL_19_STABLE [dfb96277d] 2026-07-31 11:56:52 -0400 Branch: REL_18_STABLE [18f0de6b8] 2026-07-31 11:57:07 -0400 Branch: REL_17_STABLE [499d9eabb] 2026-07-31 11:57:44 -0400 Branch: master [8767a10cb] 2026-07-22 08:47:44 -0400 Branch: REL_19_STABLE [bdcea66f0] 2026-07-22 08:49:39 -0400 Branch: REL_18_STABLE [1d299d6ab] 2026-07-22 08:49:30 -0400 Branch: REL_17_STABLE [d28cdf46e] 2026-07-22 08:49:00 -0400

    Prevent WAL summarizer process from getting stuck at a timeline switch (Robert Haas) 《機械翻訳》WALサマライザプロセスがタイムラインスイッチで立ち往生するのを防ぎます。 (Robert Haas) § §

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [eb4e7224a] 2026-06-11 17:28:57 +0900 Branch: REL_18_STABLE [b4bd13850] 2026-06-11 17:29:38 +0900 Branch: REL_17_STABLE [16b89ff04] 2026-06-11 17:29:39 +0900 Branch: REL_16_STABLE [8cd687c44] 2026-06-11 17:29:41 +0900 Branch: REL_16_STABLE [2a04624da] 2026-06-11 14:43:07 +0900 Branch: master Release: REL_19_BR [a8ee70bd5] 2026-06-12 11:44:11 +0900 Branch: REL_18_STABLE [4bff3aa51] 2026-06-12 11:44:14 +0900 Branch: REL_17_STABLE [ab5334d8b] 2026-06-12 11:44:16 +0900 Branch: REL_16_STABLE [d9b49e5b4] 2026-06-12 11:44:19 +0900

    Fix race with timeline selection in logical decoding during standby promotion (Bertrand Drouvot) 《機械翻訳》スタンバイのプロモーション中にロジカルデコーディングのタイムライン選択とのレースを修正しました。 (Bertrand Drouvot) § §

    Logical decoding being performed on the standby could fail with a <quote>requested WAL segment has already been removed</quote> error. A repeat attempt would succeed, so there was no permanent problem but there was an availability hazard. 《機械翻訳》スタンバイで実行されるロジカルデコーディングは、要求されたWALセグメントが既に削除されているエラーで失敗する可能性がありました。 再試行は成功するため、永続的な問題はありませんでしたが、可用性の危険がありました。

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [c37b38806] 2026-05-23 08:10:07 +0900 Branch: REL_18_STABLE [b903d1792] 2026-05-23 08:10:12 +0900 Branch: REL_17_STABLE [c89499a79] 2026-05-23 08:10:14 +0900 Branch: REL_16_STABLE [e037a4199] 2026-05-23 08:10:15 +0900 Branch: REL_15_STABLE [065cbfb88] 2026-05-23 08:10:17 +0900 Branch: REL_14_STABLE [e18b77153] 2026-05-23 08:10:18 +0900

    Avoid exposing a WAL receiver's full connection string during timeline jumps (Chao Li) 《機械翻訳》タイムラインジャンプ中に、WALレシーバのコネクション文字列全体を露出させないようにします。 (Chao Li) §

    The <structname>pg_stat_wal_receiver</structname> view should show a sanitized version of the connection string, without sensitive data. But it transiently showed the full string when we re-use an existing WAL receiver. 《機械翻訳》pg_stat_wal_receiverビューはコネクション文字列の消毒されたバージョンを示し、敏感なデータは示さないはずです。 しかし、既存のWALレシーバを再利用するときに一時的に完全な文字列を示しました。

  • Author: Noah Misch <noah@leadboat.com> Branch: master Release: REL_19_BR [bf7d19be9] 2026-05-16 18:01:35 -0700 Branch: REL_18_STABLE [dc3db3a83] 2026-05-16 18:01:38 -0700 Branch: REL_17_STABLE [15f4e3d0c] 2026-05-16 18:01:39 -0700 Branch: REL_16_STABLE [59759e1a5] 2026-05-16 18:01:39 -0700 Branch: REL_15_STABLE [871d4f5b6] 2026-05-16 18:01:40 -0700 Branch: REL_14_STABLE [510a05f07] 2026-05-16 18:01:46 -0700

    Use run-time checks, not just Asserts, to verify the correct number of columns in tuples received during logical replication (Varik Matevosyan) 《機械翻訳》アサート中に受け取ったタプルの正しい列数を検証するために、論理レプリケーションだけではなく、ランタイム検査を使用してください。 (Varik Matevosyan) §

    A malicious or buggy publisher could send inconsistent numbers of columns. While we could not find a scenario in which this would have serious ill effects, extra caution seems warranted. 《機械翻訳》悪意のあるパブリッシャーやバグのあるシナリオは、矛盾した数の列を送信する可能性があります。 これが深刻な悪影響を及ぼす地域は見つかりませんでしたが、特別な注意が必要と思われます。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master Release: REL_19_BR [a75bd485b] 2026-06-15 15:35:37 -0400 Branch: REL_18_STABLE [abb582555] 2026-06-15 15:35:37 -0400 Branch: REL_17_STABLE [14810cc0d] 2026-06-15 15:35:37 -0400 Branch: REL_16_STABLE [26d6c19d0] 2026-06-15 15:35:37 -0400 Branch: REL_15_STABLE [819e5b964] 2026-06-15 15:35:37 -0400 Branch: REL_14_STABLE [2a00840e8] 2026-06-15 15:35:37 -0400

    Clean up quoting of string parameters within constructed replication commands (Tom Lane) 《機械翻訳》建設された文字列内のレプリケーションコマンドパラメータの見積もりをクリーンアップします。 (Tom Lane) §

    Various places that generate replication commands were not being adequately careful about quoting replication slot names and other parameters that need to be inserted into those commands. This could result in unexpected syntax errors in those commands. In principle, a crafted replication slot name could result in SQL injection; but such a scenario seems very unlikely to occur in practice, since replication operations can only be invoked by highly-privileged users and there is no reason for them to use a slot name coming from an untrustworthy source. 《機械翻訳》レプリケーションコマンドを生成する様々な場所で、これらのコマンドに挿入する必要があるレプリケーションスロット名やその他のパラメータの引用に十分な注意が払われていませんでした。 これにより、これらのコマンドで予期しない構文エラーが発生する可能性がありました。 原則的には、巧妙に細工されたレプリケーションスロット名前はSQLインジェクションを引き起こす可能性がありますが、実際にはそのようなシナリオは非常に起こりにくいと思われます。 なぜなら、レプリケーション操作は高度な権限を持つユーザのみが呼び出すことができ、信頼できないソースからのスロット名前を使用する理由はないからです。

  • Author: Masahiko Sawada <msawada@postgresql.org> Branch: master [acaa100f9] 2026-07-28 12:33:28 -0700 Branch: REL_19_STABLE [2289e65e1] 2026-07-28 12:33:31 -0700 Branch: REL_18_STABLE [b563fc6bd] 2026-07-28 12:33:35 -0700 Branch: REL_17_STABLE [8c4519c71] 2026-07-28 12:33:40 -0700 Branch: REL_16_STABLE [744618346] 2026-07-28 12:33:43 -0700 Branch: REL_15_STABLE [0dbfb8520] 2026-07-28 12:33:47 -0700 Branch: REL_14_STABLE [c2d34db0a] 2026-07-28 12:33:50 -0700

    Fix logical decoding of empty prepared transactions (Masahiko Sawada) 《機械翻訳》空の準備されたトランザクションのロジカルデコーディングを修正しました。 (Masahiko Sawada) §

    A prepared transaction that did not cause any decodable updates could result in sending <command>COMMIT/ROLLBACK PREPARED</command> to the output plugin with no preceding <command>PREPARE</command>. For the built-in subscriber this breaks replication, and other plugins will probably not like it either. 《機械翻訳》デコード可能な更新を引き起こさなかったプリペアードトランザクションは、先行するPREPAREがないCOMMIT/ROLLBACK PREPAREDを出力プラグインに送信する結果になる可能性があります。 組み込みのサブスクライバーでは、これはレプリケーションを壊し、他のプラグインもおそらくそれを好まないでしょう。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master [8e684ce11] 2026-06-30 08:48:47 +0900 Branch: REL_19_STABLE [22af34b98] 2026-06-30 08:50:08 +0900 Branch: REL_18_STABLE [627605713] 2026-06-30 08:50:50 +0900 Branch: REL_17_STABLE [a1ed6a9a0] 2026-06-30 08:51:22 +0900 Branch: REL_16_STABLE [913d3b610] 2026-06-30 08:51:51 +0900 Branch: REL_15_STABLE [d2980067b] 2026-06-30 08:52:50 +0900

    Fix corruption of unlogged sequences after standby promotion (Fujii Masao) 《機械翻訳》スタンバイ昇格後のログされないシーケンスの破損を修正しました。 (Fujii Masao) §

    Previously, if an unlogged sequence was created on the primary and replicated to a standby, accessing the sequence after promoting the standby could fail with <quote>bad magic number in sequence</quote> or related errors. 《機械翻訳》以前は、ログに記録されていないシーケンスがプライマリで作成され、スタンバイに複製された場合、スタンバイをプロモートした後にシーケンスをアクセスすると、シーケンスのマジックナンバーが悪いまたは関連するエラーで失敗することがありました。

  • Author: Álvaro Herrera <alvherre@kurilemu.de> Branch: master [b614de487] 2026-07-29 17:15:45 +0200 Branch: REL_19_STABLE [bef46aed3] 2026-07-29 17:15:45 +0200 Branch: REL_18_STABLE [331016322] 2026-07-29 17:15:45 +0200 Branch: REL_17_STABLE [2cf28d1b9] 2026-07-29 17:15:45 +0200 Branch: REL_16_STABLE [5dbeb69bc] 2026-07-29 17:15:45 +0200 Branch: REL_15_STABLE [8f64cc83f] 2026-07-29 17:15:45 +0200 Branch: REL_14_STABLE [5fb3c6389] 2026-07-29 17:15:45 +0200

    Fix cascading standby reconnect failure after archive fallback (Marco Nenciarini) 《機械翻訳》カスケードスタンバイ代替後のアーカイブ再接続障害を修正しました。 (Marco Nenciarini) §

    A cascading standby could fail to reconnect to its upstream standby with <quote>requested starting point ... is ahead of the WAL flush position</quote> after falling back to archive recovery. 《機械翻訳》カスケードスタンバイは、アーカイブスタンバイにフォールバックした後、要求された開始点が.WALフラッシュ位置の前にありますで上流リカバリへの再接続に失敗する可能性があります。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master [b59783502] 2026-08-08 00:09:05 +0900 Branch: REL_19_STABLE [7673dfe77] 2026-08-08 00:10:00 +0900 Branch: REL_18_STABLE [311e66df9] 2026-08-08 00:10:06 +0900

    Prevent accepting hot-standby connections before WAL replay has reached a consistent database state (Nikhil Sontakke) 《機械翻訳》ホット-スタンバイ間の接続を許可しない前WALリプレイが一貫したデータベース状態になりました。 (Nikhil Sontakke) §

  • Author: Alexander Korotkov <akorotkov@postgresql.org> Branch: master Release: REL_19_BR [bec61f593] 2026-05-27 02:27:32 +0300 Branch: REL_18_STABLE [97b5c5aaa] 2026-05-27 02:28:39 +0300 Branch: REL_17_STABLE [4a375527a] 2026-05-27 02:28:49 +0300

    Do not try to clear <structname>pg_database</structname>.<structfield>dathasloginevt</structfield> locally on a standby server (Ayush Tiwari) 《機械翻訳》トライからクリアpg_データベースには移動しないでくださいdathasloginevtスタンバイサーバでローカルに移動します。 (Ayush Tiwari) §

    Event trigger cleanup tried to perform that action on standby servers as well as the primary. That can't work on a standby, and there's no need anyway since replay of the primary's database change will soon fix it. 《機械翻訳》イベントトリガクリーンアップはプライマリだけでなくスタンバイサーバでもその行動を実行しようとしました。 それはスタンバイでは機能しませんし、プライマリのデータベース変更のリプレイがすぐにそれを修正するので、とにかくその必要はありません。

  • Author: Amit Kapila <akapila@postgresql.org> Branch: master Release: REL_19_BR [bdae2c20e] 2026-06-18 09:50:33 +0530 Branch: REL_18_STABLE [08458bcae] 2026-06-18 09:42:56 +0530 Branch: REL_17_STABLE [ea834d747] 2026-06-18 09:35:53 +0530

    Avoid race condition while dropping obsolete replication slots (Xuneng Zhou) 《機械翻訳》古い競合条件スロットを削除するときは、レプリケーションを使用しないでください。 (Xuneng Zhou) §

    An incorrect unlock and log message could occur if another session immediately re-used the dropped slot's shared-memory entry. 《機械翻訳》誤ったロック解除およびログメッセージは、別のセッションが、ドロップされたスロットの共有メモリエントリを直ちに再利用した場合に発生する可能性がある。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master Release: REL_19_BR [f2081a780] 2026-06-03 18:44:56 +0900 Branch: REL_18_STABLE [f833c9207] 2026-06-03 18:46:49 +0900 Branch: REL_17_STABLE [080d61f07] 2026-06-03 18:47:10 +0900 Branch: REL_16_STABLE [51e79222c] 2026-06-03 18:47:31 +0900 Branch: REL_15_STABLE [a4eb59d40] 2026-06-03 18:47:46 +0900 Branch: REL_14_STABLE [968c50845] 2026-06-03 18:47:52 +0900

    Avoid race condition while dropping ephemeral replication slots (Zhijie Hou) 《機械翻訳》エフェメラルレプリケーションスロットをドロップするときは、競合条件を避けてください。 (Zhijie Hou) §

    The slot-releasing code performed some additional updates to the replication slot's shared-memory entry after releasing the slot. This is unsafe since another session could immediately re-use the dropped slot's shared-memory entry. Skip those updates in the case of an ephemeral slot. 《機械翻訳》スロットをリリースするコードは、レプリケーションスロットをリリースした後に、スロットの共有メモリエントリに対していくつかの追加更新を実行しました。 これは、削除されたスロットの共有メモリエントリを別のセッションがすぐに再利用できるため、安全ではありません。 スキップは、一時的なスロットのケースでこれらの更新を行います。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master Release: REL_19_BR [422e54e30] 2026-05-13 11:44:31 +0900 Branch: REL_18_STABLE [d9cd9b4d7] 2026-05-13 11:46:08 +0900 Branch: REL_17_STABLE [f2acab534] 2026-05-13 11:46:12 +0900 Branch: REL_16_STABLE [d140237da] 2026-05-13 11:46:17 +0900 Branch: REL_15_STABLE [b5f7e7569] 2026-05-13 11:46:21 +0900 Branch: REL_14_STABLE [e3c4e3746] 2026-05-13 11:46:26 +0900

    Fix stale progress reports during logical replication table synchronization (Shinya Kato) 《機械翻訳》論理レプリケーションテーブルの同期化中に古い進行状況レポートを修正しました。 (Shinya Kato) §

    Previously, the <structname>pg_stat_progress_copy</structname> view in the subscriber would continue to show the initial <command>COPY</command> operation as active even after the data copy had finished. The stale entry remained visible until synchronization caught up with the publisher. 《機械翻訳》これまでは、サブスクライバーのpg_stat_progress_コピービューは、データコピーが終了した後も最初のCOPYオペレーションをアクティブとして表示し続けていました。 古いエントリは、同期がパブリッシャーに追いつくまで可視のままでした。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master [55f0a13e9] 2026-07-01 23:04:18 +0900 Branch: REL_19_STABLE [b70000837] 2026-07-01 23:05:04 +0900 Branch: REL_18_STABLE [e7564ee8c] 2026-07-01 23:05:12 +0900 Branch: REL_17_STABLE [e2ea6bfed] 2026-07-01 23:05:34 +0900 Branch: REL_16_STABLE [7cbd80340] 2026-07-01 23:06:43 +0900 Branch: REL_15_STABLE [cf7530cf7] 2026-07-01 23:06:49 +0900 Branch: REL_18_STABLE [e2ad214dd] 2026-07-06 09:46:15 +0900 Branch: REL_17_STABLE [a240e8cd2] 2026-07-06 09:47:56 +0900 Branch: REL_16_STABLE [fffa4d870] 2026-07-06 09:48:01 +0900 Branch: REL_15_STABLE [a8fb98b7b] 2026-07-06 09:48:06 +0900

    Clear base backup progress on backup failure (Chao Li) 《機械翻訳》バックアップの失敗に関するクリアベースバックアップの進展。 (Chao Li) § §

    Previously the <structname>pg_stat_progress_basebackup</structname> view would continue to show a stale progress entry after a failure, until the replication client disconnected. <application>pg_basebackup</application> normally disconnects immediately, but other clients might not. 《機械翻訳》以前は、pg_stat_progress_basebackupビューは、障害発生後、エントリクライアントが切断されるまで、古い進行状況レプリケーションを表示し続けましたpg_basebackup通常はすぐに切断されますが、他のクライアントは切断されない場合があります。

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [850b9218c] 2026-06-18 11:49:30 +0900 Branch: REL_18_STABLE [5cc59834b] 2026-06-18 11:49:34 +0900 Branch: REL_17_STABLE [2e0c61aed] 2026-06-18 11:49:36 +0900 Branch: REL_16_STABLE [bf4616b59] 2026-06-18 11:49:39 +0900 Branch: REL_15_STABLE [1e9e62193] 2026-06-18 11:49:41 +0900 Branch: REL_18_STABLE [8a4f389dd] 2026-06-18 14:48:37 +0900 Branch: REL_17_STABLE [39e649d44] 2026-06-18 14:48:40 +0900 Branch: REL_16_STABLE [7c457ea15] 2026-06-18 14:48:42 +0900 Branch: REL_15_STABLE [75aca8b93] 2026-06-18 14:48:43 +0900 Branch: REL_18_STABLE [fe464e9e6] 2026-06-23 07:58:04 +0900 Branch: REL_17_STABLE [afb076b29] 2026-06-23 07:59:00 +0900 Branch: REL_16_STABLE [e34b1ff5d] 2026-06-23 07:59:02 +0900 Branch: REL_15_STABLE [9e4771825] 2026-06-23 07:59:03 +0900

    Fix possible PANIC due to concurrent drop of pgstats entries when <varname>track_functions</varname> is enabled (Sami Imseih, Michael Paquier) 《機械翻訳》track_functionsが有効な場合にpgstatsエントリが同時に削除されることで発生する可能性があったパニックを修正しました。 (Sami Imseih, Michael Paquier) § § §

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master [4069df21b] 2026-08-07 14:23:28 +0900 Branch: REL_19_STABLE [89fc6a7c1] 2026-08-07 14:23:33 +0900 Branch: REL_18_STABLE [2fd8d45ec] 2026-08-07 14:23:35 +0900 Branch: REL_17_STABLE [fc9283b21] 2026-08-07 14:23:36 +0900 Branch: REL_16_STABLE [636bcd6a5] 2026-08-07 14:23:38 +0900 Branch: REL_15_STABLE [10e20e59e] 2026-08-07 14:23:39 +0900

    Clean up broken local pgstats entry after failing to obtain space for the corresponding shared hashtable entry (Niall Newman) 《機械翻訳》対応する共有ハッシュテーブルローカル用のエントリの取得に失敗した後、壊れたスペースpgstatsエントリをクリーンアップします。 (Niall Newman) §

    Failure to do this led to a null-pointer dereference the next time the local entry was used. 《機械翻訳》これを行わなかった場合、次にローカルエントリが使用されたときにNULL-ポインタ間の逆参照が発生しました。

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [3048e8130] 2026-06-17 16:05:11 +0900 Branch: REL_18_STABLE [13f940b4b] 2026-06-17 16:05:37 +0900

    Avoid recording incorrect I/O operation statistics after a failed read or write (Bertrand Drouvot) 《機械翻訳》読み取りまたは書き込みに失敗した後に、誤った入出力オペレーション統計処理を記録しないようにしてください。 (Bertrand Drouvot) §

  • Author: Richard Guo <rguo@postgresql.org> Branch: master Release: REL_19_BR [4015abe14] 2026-06-24 09:09:48 +0900 Branch: REL_18_STABLE [e430ecc59] 2026-06-24 09:11:56 +0900 Branch: REL_17_STABLE [d424d06ed] 2026-06-24 09:14:06 +0900 Branch: REL_16_STABLE [3854f4afc] 2026-06-24 09:15:08 +0900 Branch: REL_15_STABLE [9b2a6ccc4] 2026-06-24 09:16:24 +0900 Branch: REL_14_STABLE [e520ad34b] 2026-06-24 09:17:36 +0900

    In <application>PL/Perl</application>, avoid NULL pointer dereference crash when working with an invalid <type>PostgreSQL::InServer::ARRAY</type> object (Xing Guo) 《機械翻訳》では、無効なヌルポインタクラッシュ::InServer::PostgreSQLを操作するときに配列がオブジェクトを逆参照しないようにします。 PL/Perl (Xing Guo) §

  • Author: Richard Guo <rguo@postgresql.org> Branch: master Release: REL_19_BR [8612f0b7c] 2026-06-29 11:38:39 +0900 Branch: REL_18_STABLE [53482fcb9] 2026-06-29 11:39:50 +0900 Branch: REL_17_STABLE [3dc59c173] 2026-06-29 11:40:49 +0900 Branch: REL_16_STABLE [e92f23bde] 2026-06-29 11:41:50 +0900 Branch: REL_15_STABLE [12bff46ff] 2026-06-29 11:43:26 +0900 Branch: REL_14_STABLE [0b7719f74] 2026-06-29 11:44:35 +0900 Branch: REL_14_STABLE [309dc4526] 2026-06-29 14:21:15 +0900

    In <application>PL/Python</application>, properly check for errors when working with sequence and mapping objects (Richard Guo) 《機械翻訳》PL/Pythonでは、シーケンスオブジェクトとマッピングオブジェクトを使用するときのエラーが正しくチェックされるようになりました。 (Richard Guo) §

    Previously, a broken object or an unhandled exception could result in a NULL pointer dereference crash. 《機械翻訳》以前は、壊れたオブジェクトまたは処理されない例外により、ヌルポインタのクラッシュの逆参照が発生する可能性があった。

  • Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> Branch: master [ffd080d94] 2026-07-07 18:45:34 +0300 Branch: REL_19_STABLE [eeb2940ae] 2026-07-07 18:46:10 +0300 Branch: REL_18_STABLE [2167302b7] 2026-07-07 18:46:24 +0300 Branch: REL_17_STABLE [c162810a5] 2026-07-07 18:46:58 +0300 Branch: REL_16_STABLE [d3f329656] 2026-07-07 18:47:07 +0300 Branch: REL_15_STABLE [4ecba7fa3] 2026-07-07 18:53:51 +0300 Branch: REL_14_STABLE [1b018b5d1] 2026-07-07 18:54:09 +0300 Branch: master [343594a26] 2026-07-07 18:45:37 +0300 Branch: REL_19_STABLE [7f8745543] 2026-07-07 18:46:14 +0300 Branch: REL_18_STABLE [bb0a54518] 2026-07-07 18:46:33 +0300 Branch: REL_17_STABLE [177a2a2e3] 2026-07-07 18:46:58 +0300 Branch: REL_16_STABLE [477bc27a5] 2026-07-07 18:47:07 +0300 Branch: REL_15_STABLE [05908afcd] 2026-07-07 18:53:52 +0300 Branch: REL_14_STABLE [d3888c90a] 2026-07-07 18:54:09 +0300 Branch: master [d293f0345] 2026-07-09 18:34:24 +0300 Branch: REL_19_STABLE [536512f34] 2026-07-09 18:34:53 +0300 Branch: REL_18_STABLE [27761c015] 2026-07-09 18:35:12 +0300 Branch: REL_17_STABLE [0958c3ea4] 2026-07-09 18:35:24 +0300 Branch: REL_16_STABLE [6243ea6c3] 2026-07-09 18:35:37 +0300 Branch: REL_15_STABLE [21a6c69ea] 2026-07-09 18:35:47 +0300 Branch: REL_14_STABLE [f5f569713] 2026-07-09 18:36:30 +0300 Branch: master [17accbe0f] 2026-07-09 18:34:27 +0300 Branch: REL_19_STABLE [d9eb70c9c] 2026-07-09 18:34:53 +0300 Branch: REL_18_STABLE [87c3a79ea] 2026-07-09 18:35:12 +0300 Branch: REL_17_STABLE [bab0a2db7] 2026-07-09 18:35:24 +0300 Branch: REL_16_STABLE [56988064b] 2026-07-09 18:35:37 +0300 Branch: REL_15_STABLE [5ba13f8c0] 2026-07-09 18:36:18 +0300 Branch: REL_14_STABLE [7532f2117] 2026-07-09 18:36:41 +0300

    In <application>libpq</application>, always drain all pending bytes from the SSL or GSS decryption buffer during <function>pqReadData()</function> (Jacob Champion) 《機械翻訳》libpqでは、pqReadData()の間にSSLまたはGSS復号化バッファからすべての保留バイトを常に排出します。 (Jacob Champion) § § § §

    This avoids edge cases where <application>libpq</application> or its calling application waits for more data to arrive on the socket, but actually all the data has already arrived. 《機械翻訳》これにより、libpqまたはその呼び出し元のアプリケーションがソケットにさらにデータが到着するのを待っているが、実際にはすべてのデータがすでに到着しているというエッジケースが回避される。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master [676bf48e1] 2026-08-04 17:03:27 +0900 Branch: REL_19_STABLE [8380013cd] 2026-08-04 17:05:37 +0900 Branch: REL_18_STABLE [6b46a5d1b] 2026-08-04 17:05:44 +0900

    Improve <application>libpq</application>'s handling of out-of-memory conditions (Anthonin Bonnefoy) 《機械翻訳》改善libpqメモリ外の状況のハンドリング。 (Anthonin Bonnefoy) §

  • Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> Branch: master [b22b61905] 2026-07-03 14:57:35 +0300 Branch: REL_19_STABLE [0766bc57e] 2026-07-03 14:59:56 +0300 Branch: REL_18_STABLE [dd5eca055] 2026-07-03 15:00:00 +0300

    Fix <application>libpq</application>'s trace facility to print new-style BackendKeyData and CancelRequest messages correctly (Anthonin Bonnefoy) 《機械翻訳》libpqのトレース機能をプリントの新しいスタイルBackendKeyDataメッセージとCancelRequestメッセージに正しく修正した。 (Anthonin Bonnefoy) §

  • Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> Branch: master Release: REL_19_BR [e0511883c] 2026-06-15 11:28:45 +0300 Branch: REL_18_STABLE [b1ab4bc52] 2026-06-15 11:35:20 +0300 Branch: REL_17_STABLE [e4183c667] 2026-06-15 11:35:41 +0300 Branch: REL_16_STABLE [8d516d2b9] 2026-06-15 11:38:07 +0300 Branch: REL_15_STABLE [0f63b74a4] 2026-06-15 11:38:30 +0300 Branch: REL_14_STABLE [1b79c8d1a] 2026-06-15 11:38:40 +0300

    Allow <application>libpq</application> to accept ParameterDescription messages exceeding 30000 bytes (Ning Sun) 《機械翻訳》Allow libpq 30000バイトを超えるParameterDescriptionメッセージを受け入れる。 (Ning Sun) §

    Previously, this message type was not among those that <application>libpq</application>'s validity heuristics believed could be long. The limit resulted in failure for prepared queries having more than 7498 parameters, which is unlikely but supported. 《機械翻訳》以前は、このメッセージタイプは、libpq有効性のヒューリスティックスで長いと考えられていたものの中には含まれていなかった。 この制限により、7498を超えるパラメータを持つプリペアド問い合わせで失敗したが、これは起こりそうにないがサポートされている。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master Release: REL_19_BR [7f5e0b22e] 2026-06-25 16:58:29 -0400 Branch: REL_18_STABLE [917fdbc63] 2026-06-25 16:58:29 -0400

    Fix null-pointer crash in <application>ecpg</application> compiler (Jehan-Guillaume de Rorthais) 《機械翻訳》NULL-ポインタクラッシュをecpgコンパイラに固定する。 (Jehan-Guillaume de Rorthais) §

    <application>ecpg</application> failed on a <literal>DECLARE</literal> section containing a union nested inside a struct. 《機械翻訳》構造体内にネストされたセクションを含むDECLAREユニオンでecpgが失敗しました。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master Release: REL_19_BR [4484165b0] 2026-06-08 17:09:46 +0900 Branch: REL_18_STABLE [081434b0f] 2026-06-08 17:10:25 +0900 Branch: REL_17_STABLE [fe8c0a762] 2026-06-08 17:11:12 +0900 Branch: REL_16_STABLE [4d4b73cfd] 2026-06-08 17:14:10 +0900 Branch: REL_15_STABLE [bfeddcf09] 2026-06-08 17:14:15 +0900 Branch: REL_14_STABLE [9e8fd9f7a] 2026-06-08 17:14:20 +0900

    Reject multiple descriptor header items in <application>ecpg</application>'s <literal>GET/SET DESCRIPTOR</literal> statements (Masashi Kamura) 《機械翻訳》ecpgGET/SET DESCRIPTORステートメント内のマルチプルディスクリプタヘッダ項目を拒否します。 (Masashi Kamura) §

    Previously the grammar allowed this syntax, but broken C code was generated. Adjust the grammar and the documentation to allow only one header item. 《機械翻訳》以前は、文法はこの構文を許可していましたが、壊れたCコードが生成されました。 文法と文書を調整して、ヘッダアイテムを1つだけ許可するようにしてください。

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [d21604e17] 2026-06-03 08:58:26 +0900 Branch: REL_18_STABLE [1e9bc4074] 2026-06-03 08:58:29 +0900

    Fix issues with deferred errors in pipeline mode in <application>psql</application> (Michael Paquier) 《機械翻訳》psqlで、パイプラインモードの遅延エラーに関する問題を修正しました。 (Michael Paquier) §

    <application>psql</application> could get stuck or suffer an assertion failure in some scenarios where the server reports an error in response to a Sync message, such as a deferred constraint violation. 《機械翻訳》psql遅延のアサーション違反など、サーバが回答のエラーを同期メッセージに報告する一部のシナリオでは、スタックまたは制約障害が発生する可能性があります。

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [3d0d6741d] 2026-06-08 14:37:51 +0900 Branch: REL_18_STABLE [07a6c262b] 2026-06-08 14:37:56 +0900 Branch: REL_17_STABLE [efd885d05] 2026-06-08 14:37:57 +0900 Branch: REL_16_STABLE [1edbe6695] 2026-06-08 14:37:59 +0900 Branch: REL_15_STABLE [022ba5c61] 2026-06-08 14:38:00 +0900 Branch: REL_14_STABLE [a4ca91ea1] 2026-06-08 14:38:01 +0900

    Make line widths match in <application>psql</application>'s expanded aligned output format (Pavel Stehule) 《機械翻訳》make直線幅マッチin psqlの拡張に位置合わせされた出力フォーマット。 (Pavel Stehule) §

    When the table's data rows are narrower than the record header lines, widen the data rows to match the headers, avoiding unsightly output. 《機械翻訳》テーブルのデータ行がレコードのヘッダ行よりも狭い場合は、データ行をヘッダのマッチまで広げて、見苦しい出力を回避します。

  • Author: Daniel Gustafsson <dgustafsson@postgresql.org> Branch: master Release: REL_19_BR [e04910a9a] 2026-05-18 08:33:36 -0700 Branch: REL_18_STABLE [e0c641ebb] 2026-05-18 08:33:36 -0700

    Enforce the intended upper limit for <application>psql</application>'s special variable <varname>WATCH_INTERVAL</varname> (Sven Klemm, Daniel Gustafsson) 《機械翻訳》psqlの特別変数の意図された上限を実施するWATCH_INTERVAL。 (Sven Klemm, Daniel Gustafsson) §

    If a too-large value was given, <application>psql</application> reported an error but applied the setting anyway. 《機械翻訳》too-ラージ値が指定された場合、psqlはエラーを報告しましたが、設定を適用しました。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master [38afc3dcb] 2026-07-25 19:08:27 +0900 Branch: REL_19_STABLE [77aeca802] 2026-07-25 19:09:19 +0900 Branch: REL_18_STABLE [f2d6cf880] 2026-07-25 19:10:15 +0900 Branch: REL_17_STABLE [41949c6f3] 2026-07-25 19:10:22 +0900 Branch: REL_16_STABLE [844bc718a] 2026-07-25 19:10:28 +0900 Branch: REL_15_STABLE [e6e8a3078] 2026-07-25 19:10:49 +0900 Branch: REL_14_STABLE [4e19081da] 2026-07-25 19:11:34 +0900

    Fix <application>psql</application>'s privilege check for showing database size in <command>\l+</command> (Christoph Berg) 《機械翻訳》データベースサイズを見せたフィックスpsqlの権限チェック\l+。 (Christoph Berg) §

    The underlying server function permits users who have <literal>pg_read_all_stats</literal> privileges to see the sizes of all databases, even if they lack <literal>CONNECT</literal> privilege. But <application>psql</application> was unaware of that provision and would not call the function unless the user has <literal>CONNECT</literal> privilege. 《機械翻訳》基礎となるサーバ関数では、pg_read_all_stats権限を持つユーザは、すべてのデータベースのサイズを参照することができます。 これは、データベースが存在しない場合でも同様ですCONNECT権限。 しかし、psqlはこの規定を認識しておらず、ユーザがCONNECT権限を持たない限り、関数を呼び出ししませんでした。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master [6d4ca6de9] 2026-07-03 13:48:59 +0900 Branch: REL_19_STABLE [558e0de6d] 2026-07-03 13:50:01 +0900 Branch: REL_18_STABLE [598af79b1] 2026-07-03 13:50:08 +0900 Branch: REL_17_STABLE [355a4fcf9] 2026-07-03 13:50:15 +0900 Branch: REL_16_STABLE [f9afdb6d1] 2026-07-03 13:50:20 +0900 Branch: REL_15_STABLE [c25737c89] 2026-07-03 13:50:26 +0900 Branch: REL_14_STABLE [2d44bb900] 2026-07-03 13:50:51 +0900

    Fix <application>psql</application>'s tab completion for <command>\df</command> to consider procedures too (Erik Wienhold) 《機械翻訳》psqlののタブ完了\df手順も検討 (Erik Wienhold) §

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master Release: REL_19_BR [61f8a85a5] 2026-05-14 12:30:34 +0900 Branch: REL_18_STABLE [98dd6c204] 2026-05-14 12:31:14 +0900 Branch: REL_17_STABLE [52b3e7001] 2026-05-14 12:31:19 +0900 Branch: REL_16_STABLE [6432a4cd6] 2026-05-14 12:31:25 +0900 Branch: REL_15_STABLE [f18fcd9a4] 2026-05-14 12:31:43 +0900

    Fix thread-safety bug in <application>pgbench</application> (Fujii Masao) 《機械翻訳》スレッド安全バグをpgbench. (Fujii Masao) §

    When <application>pgbench</application> runs with multiple threads and the <option>&#45;-verbose-errors</option> option, different threads could attempt to use the same buffer to construct error messages, leading to corrupted log output. 《機械翻訳》pgbenchがマルチプルスレッドと--verbose-errorsオプションで実行されると、異なるスレッドが同じバッファからコンストラクトへのエラーメッセージを使用しようとする可能性があり、ログの出力が破損する可能性があります。

  • Author: Peter Eisentraut <peter@eisentraut.org> Branch: master Release: REL_19_BR [994f770a0] 2026-06-29 12:29:21 +0200 Branch: REL_18_STABLE [d36b72894] 2026-06-29 13:01:57 +0200 Branch: REL_17_STABLE [090ce6934] 2026-06-29 13:02:07 +0200

    In <application>pg_combinebackup</application>, prevent infinite loop if the source file is shorter than expected (Peter Eisentraut) 《機械翻訳》pg_combinebackupでは、無限ループが予想より短い場合はソースファイルを防止します。 (Peter Eisentraut) §

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master Release: REL_19_BR [12d000488] 2026-05-27 10:34:17 +0900 Branch: REL_18_STABLE [196b4b5ae] 2026-05-27 10:35:18 +0900 Branch: REL_17_STABLE [c03784a21] 2026-05-27 10:35:49 +0900

    Fix cleanup of publisher-side objects after errors in <application>pg_createsubscriber</application> (Nisha Moond) 《機械翻訳》pg_createsubscriberでエラーが発生した後のパブリッシャー側オブジェクトのクリーンアップを修正しました。 (Nisha Moond) §

    When <application>pg_createsubscriber</application> fails after creating logical replication objects, it should remove the publication and replication slot that it created on the publisher. Some error cases failed to do so. 《機械翻訳》論理レプリケーションオブジェクトを作成した後にpg_createsubscriberが失敗した場合は、パブリッシャーに作成したパブリケーションとレプリケーションスロットを削除する必要があります。 そうしなかったエラーのケースもあります。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master Release: REL_19_BR [263d1e6df] 2026-05-20 15:54:13 +0900 Branch: REL_18_STABLE [89b4b3ae3] 2026-05-20 15:56:58 +0900 Branch: REL_17_STABLE [ddd12d1a5] 2026-05-20 15:57:04 +0900 Branch: REL_16_STABLE [9590dcfca] 2026-05-20 15:57:09 +0900 Branch: REL_15_STABLE [ba9833a75] 2026-05-20 15:57:14 +0900 Branch: REL_14_STABLE [5552a15a3] 2026-05-20 15:57:19 +0900

    Use the source cluster's group-read file permissions for <application>pg_recvlogical</application> output files (Fujii Masao) 《機械翻訳》ソースクラスタのグループアクセス権pg_recvlogicalファイルを出力するためのファイル読み取り権限を使用します。 (Fujii Masao) §

    <application>pg_recvlogical</application> was documented to behave this way, but it never actually enabled group-read. 《機械翻訳》pg_recvlogicalはこのように動作すると説明されていましたが、実際にグループが読めるようにはなっていませんでした。

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [0dd93de69] 2026-06-16 08:21:08 +0900 Branch: REL_18_STABLE [42ffdedcf] 2026-06-16 08:22:41 +0900 Branch: master Release: REL_19_BR [ae39bd23c] 2026-06-16 15:58:12 +0900 Branch: REL_18_STABLE [477efef08] 2026-06-16 15:58:17 +0900

    Fix inconsistent behavior of <application>pg_restore</application> with <option>&#45;-statistics</option> or <option>&#45;-statistics-only</option> (Chao Li, Michael Paquier) 《機械翻訳》--statisticsまたは--statistics-onlyを持つpg_リストアの一貫性のない動作を修正しました。 (Chao Li, Michael Paquier) § §

    When combined with other selective-restore options such as <option>&#45;-schema</option>, these options failed to restore the expected items, unlike <application>pg_dump</application> with similar options. 《機械翻訳》--schemaのような他の選択的リストアオプションと組み合わせると、これらのオプションはpg_dump類似のリストアとは異なり、期待された項目をオプションすることができなかった。

  • Author: Nathan Bossart <nathan@postgresql.org> Branch: master Release: REL_19_BR [d2cea6306] 2026-06-17 09:18:39 -0500 Branch: REL_18_STABLE [7e085aabd] 2026-06-17 09:18:39 -0500

    Fix <command>vacuumdb &#45;-missing-stats-only</command> to ignore partitioned expression indexes (Baji Shaik) 《機械翻訳》vacuumdb --missing-stats-onlyパーティション化された式インデックスを無視するように修正しました。 (Baji Shaik) §

    Previously, <application>vacuumdb</application> would always attempt to <command>ANALYZE</command> the partitioned table, accomplishing nothing since statistics are never created for partitioned indexes, only for their leaf indexes. 《機械翻訳》以前は、vacuumdbは常にANALYZEパーティション化されたテーブルを試みていました。 統計処理はパーティション化されたインデックスに対して作成されることはなく、リーフインデックスに対してのみ作成されるため、何も達成されませんでした。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master Release: REL_19_BR [389bd4c5b] 2026-06-12 09:37:37 +0900 Branch: REL_18_STABLE [12c32bbc8] 2026-06-12 09:39:19 +0900

    In <filename>contrib/amcheck</filename>, fix failure to report corruption of a btree metapage's <literal>allequalimage</literal> flag (Chao Li) 《機械翻訳》contrib/amcheckbtreeメタページallequalimageレポートのフラグの破損に対する失敗を修正しました。 (Chao Li) §

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master [e939332c6] 2026-07-06 09:32:25 +0900 Branch: REL_19_STABLE [80cfd8aef] 2026-07-06 09:32:28 +0900 Branch: REL_18_STABLE [1f8ab91c1] 2026-07-06 09:32:30 +0900

    In <filename>contrib/amcheck</filename>, fix query-lifespan memory leak while verifying a GIN index (Kirill Reshke) 《機械翻訳》contrib/amcheckでは、問い合わせメモリリークを検証する際にGIN寿命インデックスを修正しました。 (Kirill Reshke) §

  • Author: Alexander Korotkov <akorotkov@postgresql.org> Branch: master Release: REL_19_BR [da1eff08a] 2026-06-14 04:04:48 +0300 Branch: REL_18_STABLE [897e79486] 2026-06-14 04:05:50 +0300 Branch: REL_17_STABLE [8abb8a155] 2026-06-14 04:07:00 +0300 Branch: REL_16_STABLE [c89a1ca01] 2026-06-14 04:07:42 +0300 Branch: REL_15_STABLE [4284476c0] 2026-06-14 04:08:00 +0300 Branch: REL_14_STABLE [af09b18cb] 2026-06-14 04:06:43 +0300

    In <filename>contrib/amcheck</filename>, handle short-header varlena datums correctly (Andrey Borodin) 《機械翻訳》contrib/amcheck,ハンドルshort-ヘッダvarlenaデータムで正しく動作するようになりました。 (Andrey Borodin) §

    This error could result in doing excess work while verifying a btree index, but seems not to have had any worse consequences. 《機械翻訳》このエラーは、btreeインデックスを検証する際に過剰な作業を行う可能性がありますが、これ以上悪い結果にはならなかったようです。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [7d3448961] 2026-07-01 13:27:22 -0400 Branch: REL_19_STABLE [a47005f0b] 2026-07-01 13:27:22 -0400 Branch: REL_18_STABLE [1e1d07792] 2026-07-01 13:27:22 -0400 Branch: REL_17_STABLE [d215d2cc2] 2026-07-01 13:27:22 -0400 Branch: REL_16_STABLE [d569ccd40] 2026-07-01 13:27:22 -0400 Branch: REL_15_STABLE [98dd4406f] 2026-07-01 13:27:22 -0400 Branch: REL_14_STABLE [255bce448] 2026-07-01 13:27:22 -0400

    In <filename>contrib/btree_gist</filename>, fix <literal>NaN</literal> handling in the <type>float4</type> and <type>float8</type> opclasses (Bill Kim, Tom Lane) 《機械翻訳》contrib/btree_GiSTで、opclass NaNfloat4float8のハンドリングを修正しました。 (Bill Kim, Tom Lane) §

    Comparisons, as well as the GiST penalty and distance functions, did not account for <literal>NaN</literal> and would give the wrong answer when handed one. It is recommended to reindex <filename>btree_gist</filename> indexes on float columns after installing this update, if there is any possibility that there are <literal>NaN</literal> entries in those columns. 《機械翻訳》比較は、GiSTペナルティ関数や遠隔関数と同様に、アカウントではありませんでしたNaNそして、渡されたときに間違いの答えを返します。 これらの列にNaNエントリがある可能性がある場合は、この更新をインストールした後にインデックス再作成btree_GiSTfloat列のインデックスを行うことをお勧めします。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [a9fa6c69e] 2026-07-03 13:11:14 -0400 Branch: REL_19_STABLE [11cb9c431] 2026-07-03 13:11:14 -0400 Branch: REL_18_STABLE [558c4ea9a] 2026-07-03 13:11:14 -0400

    In <filename>contrib/btree_gist</filename>, fix sorting of <type>bit</type>/<type>varbit</type> entries during GiST index construction (Tom Lane) 《機械翻訳》contrib/btree_GiSTでは、並べ替えインデックスの構築中にビット/varbitエントリのGiSTを修正しました。 (Tom Lane) §

    Values of bit types were sorted as though they were <type>bytea</type>s, which did not cause any obvious failure but would result in an inefficient index, since the types' representations are different. It is recommended to reindex <filename>btree_gist</filename> indexes on bit columns after installing this update. 《機械翻訳》ビット型の値はbyteaであるかのようにソートされました。 これは明らかな失敗を引き起こしませんでしたが、型の表現が異なるため、非効率的なインデックスになりました。 このインデックス再作成をインストールした後に、ビットbtree_gist更新列のインデックスを行うことをお勧めします。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [eef644e57] 2026-07-03 13:50:14 -0400 Branch: REL_19_STABLE [fc6649abe] 2026-07-03 13:50:14 -0400 Branch: REL_18_STABLE [12c519207] 2026-07-03 13:50:14 -0400 Branch: REL_17_STABLE [86992769e] 2026-07-03 13:50:14 -0400 Branch: REL_16_STABLE [0663382c9] 2026-07-03 13:50:14 -0400 Branch: REL_15_STABLE [8f2a1b3d3] 2026-07-03 13:50:14 -0400 Branch: REL_14_STABLE [286f9a3ce] 2026-07-03 13:50:14 -0400

    In <filename>contrib/btree_gist</filename>, fix searches using a not-equal operator (Ayush Tiwari) 《機械翻訳》contrib/btree_gistで、等しくない演算子を使用した検索を修正しました。 (Ayush Tiwari) §

    For variable-length data types, the code for scanning non-leaf index pages applied the wrong comparison function, leading to wrong results and potentially crashes. 《機械翻訳》変数-長さデータタイプの場合、リーフインデックス以外のページをスキャンするコードは間違い比較関数を適用していたため、間違いの結果が得られ、クラッシュする可能性がありました。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master Release: REL_19_BR [97f6fc10f] 2026-05-26 00:46:31 +0900 Branch: REL_18_STABLE [88d7748d2] 2026-05-26 00:47:43 +0900 Branch: master Release: REL_19_BR [5f5165e2f] 2026-05-26 00:51:18 +0900 Branch: REL_18_STABLE [130396e6c] 2026-05-26 00:52:38 +0900

    In <filename>contrib/dblink</filename> and <filename>contrib/postgres_fdw</filename>, ensure that a user-mapping setting for <varname>use_scram_passthrough</varname> overrides one for a foreign server (Matheus Alcantara) 《機械翻訳》contrib/dblinkおよびcontrib/postgres_fdw,保証では、ユーザ-マッピングの設定use_scram_passthroughは外部サーバの設定より優先されます。 (Matheus Alcantara) § §

    Previously the precedence went the other way, but that is inconsistent with the behavior of other foreign-table options. 《機械翻訳》以前は優先順位が逆でしたが、それは他の外国-テーブルオプションの行動と矛盾しています。

  • Author: Fujii Masao <fujii@postgresql.org> Branch: master Release: REL_19_BR [e2b881340] 2026-05-26 01:07:24 +0900 Branch: REL_18_STABLE [cd777e27e] 2026-05-26 01:08:47 +0900

    Reject setting <varname>use_scram_passthrough</varname> on <filename>contrib/dblink</filename> foreign-data wrappers (Matheus Alcantara) 《機械翻訳》contrib/dblink外部通過地点ラッパーの設定use_scram_データを拒否する。 (Matheus Alcantara) §

    This option is only meaningful on foreign servers and user mappings, but dblink incorrectly allowed it at the FDW level as well (and then ignored it). 《機械翻訳》このオプションは外部サーバとユーザのマッピングでのみ意味がありますが、dblinkは誤ってFDWレベルでもこのオプションを許可しました(そして無視しました)。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master Release: REL_19_BR [da82fbb8f] 2026-06-17 11:04:41 -0400 Branch: REL_18_STABLE [e3b7a43fa] 2026-06-17 11:04:41 -0400 Branch: REL_17_STABLE [3df0b7755] 2026-06-17 11:04:41 -0400 Branch: REL_16_STABLE [b0f3465b6] 2026-06-17 11:04:41 -0400 Branch: REL_15_STABLE [a6f23c3ad] 2026-06-17 11:04:41 -0400 Branch: REL_14_STABLE [639fff511] 2026-06-17 11:04:41 -0400 Branch: master Release: REL_19_BR [c0f17b04d] 2026-06-18 12:23:13 -0400 Branch: REL_18_STABLE [d65cf6f80] 2026-06-18 12:22:55 -0400 Branch: REL_17_STABLE [4efef9d18] 2026-06-18 12:22:55 -0400 Branch: REL_16_STABLE [60a1d712a] 2026-06-18 12:22:55 -0400 Branch: REL_15_STABLE [4fbbabb0a] 2026-06-18 12:22:55 -0400 Branch: REL_14_STABLE [1f6b2295f] 2026-06-18 12:22:55 -0400

    Fix unguarded recursion and loops in <filename>contrib/hstore_plperl</filename>, <filename>contrib/jsonb_plperl</filename>, and <filename>contrib/jsonb_plpython</filename> (Aleksander Alekseev) 《機械翻訳》contrib/hstore_plperl,contrib/jsonb_plperl,and contrib/jsonb_plpython.における無防備な再帰とループを修正しました。 (Aleksander Alekseev) § §

    Prevent stack overflow when dealing with deeply nested <type>jsonb</type> values, and allow interruption of the infinite loop caused when attempting to dereference circular chains of Perl object references. 《機械翻訳》深くネストされたスタックオーバーフロー値を処理するときのjsonbを防止し、Perl無限ループ参照の循環チェーンを逆参照しようとするときに発生するオブジェクトの中断を許可します。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master Release: REL_19_BR [524cc0f63] 2026-05-25 18:15:49 -0400 Branch: REL_18_STABLE [e7544c518] 2026-05-25 18:15:49 -0400 Branch: REL_17_STABLE [94b57ab54] 2026-05-25 18:15:49 -0400 Branch: REL_16_STABLE [273be484a] 2026-05-25 18:15:49 -0400 Branch: REL_15_STABLE [702a6d5f6] 2026-05-25 18:15:49 -0400 Branch: REL_14_STABLE [a96b051a9] 2026-05-25 18:15:49 -0400

    Fix missed release of statistics catcache entry in <filename>contrib/intarray</filename> (Man Zeng) 《機械翻訳》contrib/intarrayにある統計処理catcacheエントリの見逃しリリースを修正しました。 (Man Zeng) §

    This oversight led to warnings like <quote>resource was not closed: cache pg_statistic</quote>. 《機械翻訳》この見落としにより、resource is not閉じた:キャッシュpg_statisticのような警告が発生しました。

  • Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> Branch: master Release: REL_19_BR [3f3280491] 2026-06-16 09:29:47 +0300 Branch: REL_18_STABLE [c3e36a9a5] 2026-06-16 09:31:08 +0300 Branch: REL_17_STABLE [c391c00d9] 2026-06-16 09:31:12 +0300 Branch: REL_16_STABLE [aca944e33] 2026-06-16 09:31:17 +0300 Branch: REL_15_STABLE [1bec6b1c1] 2026-06-16 09:31:20 +0300 Branch: REL_14_STABLE [f528a5606] 2026-06-16 09:31:23 +0300

    In <filename>contrib/ltree</filename>, fix integer overflow in comparisons (Ayush Tiwari) 《機械翻訳》では、整数オーバーフローを比較して修正します。 contrib/ltree (Ayush Tiwari) §

    <type>ltree</type> values containing more than about 14,653 labels resulted in wrong comparison answers due to overflow. If a btree index contains such values, it is probably corrupt and should be reindexed after installing this update. 《機械翻訳》ltree値に約14,653を超えるラベルが含まれている場合、オーバーフローのために間違い比較の回答が得られました。 btreeインデックス包含の値の場合、おそらく破損しているため、この更新をインストールした後にインデックスを再作成する必要があります。

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master Release: REL_19_BR [80bb0ebcc] 2026-06-22 12:59:16 -0400 Branch: REL_18_STABLE [020426268] 2026-06-22 12:59:16 -0400 Branch: REL_17_STABLE [2aa6be6e6] 2026-06-22 12:59:16 -0400

    In <filename>contrib/pgcrypto</filename>, avoid double-free crash after encountering an error while using an OSSLCipher object (Yuelin Wang) 《機械翻訳》で、contrib/pgcrypto OSLSCipherフリーを使用中にクラッシュに遭遇した後は、二重エラーオブジェクトを使用しないでください。 (Yuelin Wang) §

  • Author: Tomas Vondra <tomas.vondra@postgresql.org> Branch: master Release: REL_19_BR [dac36601f] 2026-06-26 19:47:36 +0200 Branch: REL_18_STABLE [3bf2cb225] 2026-06-26 19:48:20 +0200

    Fix out-of-bounds access in <filename>contrib/pg_prewarm</filename>'s autoprewarm worker (Matheus Alcantara) 《機械翻訳》境界外のアクセスをcontrib/pg_prewarmのautoprewarmワーカーで修正します。 (Matheus Alcantara) §

    The code tried to fetch a value from one past the end of an array, risking a segfault. 《機械翻訳》コードは、配列の端を過ぎたところから値をフェッチしようとし、セグフォールトの危険を冒しました。

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [193a4ded9] 2026-06-06 08:16:36 +0900 Branch: REL_18_STABLE [2b09f8a91] 2026-06-06 08:16:40 +0900 Branch: REL_17_STABLE [0bcf19c9e] 2026-06-06 08:16:41 +0900 Branch: REL_16_STABLE [daf8bc7d4] 2026-06-06 08:16:43 +0900 Branch: REL_15_STABLE [51f63ba2b] 2026-06-06 08:16:44 +0900 Branch: REL_14_STABLE [1eda3eb07] 2026-06-06 08:16:46 +0900

    Fix array overrun in <filename>contrib/pg_surgery</filename>'s <function>heap_force_kill</function> and <function>heap_force_freeze</function> functions (Michael Paquier) 《機械翻訳》contrib/pg_surgeryheap_force_killおよびheap_force_freeze関数の配列オーバーランを修正しました。 (Michael Paquier) §

    Attempting to change a TID whose offset number equals MaxHeapTuplesPerPage wrote one byte past the end of the allocated array, potentially crashing the server. 《機械翻訳》TID番号がMaxHeapTuplePerPageに等しいオフセットを変更しようとすると、割り当てられたバイトの末尾を超えて1つの配列が書き込まれ、サーバがクラッシュする可能性がありました。

  • Author: Álvaro Herrera <alvherre@kurilemu.de> Branch: master [346fbdcc2] 2026-08-04 11:44:11 +0200 Branch: REL_19_STABLE [1f24c8237] 2026-08-04 11:44:11 +0200 Branch: REL_18_STABLE [19f0391df] 2026-08-04 11:44:11 +0200 Branch: REL_17_STABLE [1b6c99d96] 2026-08-04 11:44:11 +0200 Branch: REL_16_STABLE [eb28b6f24] 2026-08-04 11:44:11 +0200 Branch: REL_15_STABLE [395700f48] 2026-08-04 11:44:11 +0200 Branch: REL_14_STABLE [e9d53cf45] 2026-08-04 11:44:11 +0200

    In <filename>contrib/pg_surgery</filename>, avoid infinite loop with TID arrays having more than 64K elements (Andrey Rachitskiy) 《機械翻訳》では、contrib/pg_surgery 64K以上の要素を持つ無限ループ配列を持つTIDは避けてください。 (Andrey Rachitskiy) §

  • Author: Nathan Bossart <nathan@postgresql.org> Branch: master Release: REL_19_BR [611756948] 2026-05-14 13:11:49 -0500 Branch: REL_18_STABLE [ed0c4d5af] 2026-05-14 13:11:49 -0500 Branch: REL_17_STABLE [6b4de201e] 2026-05-14 13:11:49 -0500 Branch: REL_16_STABLE [eb93f10e2] 2026-05-14 13:11:49 -0500 Branch: REL_15_STABLE [77b2d18e9] 2026-05-14 13:11:49 -0500 Branch: REL_14_STABLE [1de0a711d] 2026-05-14 13:11:49 -0500

    Avoid NULL-pointer dereference in <filename>contrib/refint</filename>'s <function>check_foreign_key()</function> (Ayush Tiwari) 《機械翻訳》contrib/refintcheck_foreign_key().*でのNULL-ポインタの逆参照を避ける。 (Ayush Tiwari) §

    In the on-update-cascade case, a null value of a referenced column led to a crash. This is an oversight in the fix for CVE-2026-6637, but the code that was there before that wasn't really right either. 《機械翻訳》更新カスケードケースでは、被参照カラムのNULL値がクラッシュにつながりました。 これはCVE-2026-6637の修正における見落としですが、以前に存在していたコードも実際には正しくありませんでした。

  • Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> Branch: master Release: REL_19_BR [0e1f1ed15] 2026-06-11 12:33:48 +0300 Branch: REL_18_STABLE [0004cab4d] 2026-06-11 12:34:26 +0300 Branch: REL_17_STABLE [bcbbd070d] 2026-06-11 12:34:32 +0300 Branch: REL_16_STABLE [504ca0513] 2026-06-11 12:34:37 +0300 Branch: REL_15_STABLE [b3aa2083a] 2026-06-11 12:34:42 +0300 Branch: REL_14_STABLE [58b91fc73] 2026-06-11 12:34:45 +0300

    Fix <filename>contrib/seg</filename> to print segments with <literal>~</literal> certainty indicators correctly (Ewan Young) 《機械翻訳》contrib/segをプリントセグメントに~確実度インジケータで正しく修正した。 (Ewan Young) §

    Due to a typo, <function>seg_out()</function> did not print a <literal>~</literal> certainty indicator attached to a segment's upper boundary. Worse, if the lower boundary had <literal>~</literal> while the upper boundary had no indicator, the upper boundary was not printed at all, incorrectly converting the value into an open interval. 《機械翻訳》タイポのために、seg_out()~セグメントの上部境界にアタッチされた確実性指示子を印刷しませんでした。 さらに悪いことに、下部境界に~があり、上部境界には指示子がない場合、上部境界はまったく印刷されず、値がオープンインターバルに誤って変換されました。

  • Author: Michael Paquier <michael@paquier.xyz> Branch: master Release: REL_19_BR [9d33a5a80] 2026-06-11 14:29:18 +0900 Branch: REL_18_STABLE [91b57eade] 2026-06-11 14:29:22 +0900 Branch: REL_17_STABLE [4a49ab289] 2026-06-11 14:29:24 +0900 Branch: REL_16_STABLE [18955d412] 2026-06-11 14:29:26 +0900 Branch: REL_15_STABLE [bc5775149] 2026-06-11 14:29:28 +0900 Branch: REL_14_STABLE [f3f901a53] 2026-06-11 14:29:29 +0900

    Fix crash with namespace nodes in <filename>contrib/xml2</filename>'s <function>xpath_nodeset()</function> function (Andrey Chernyy, Michael Paquier) 《機械翻訳》contrib/xml2xpath_nodeset()関数の名前空間ノードでクラッシュを修正しました。 (Andrey Chernyy, Michael Paquier) §

  • Author: Daniel Gustafsson <dgustafsson@postgresql.org> Branch: master Release: REL_19_BR [89d243d52] 2026-05-29 21:52:35 +0200 Branch: REL_18_STABLE [27cf3b5af] 2026-06-12 13:57:22 +0200 Branch: REL_17_STABLE [8bcabfcce] 2026-06-12 13:57:22 +0200 Branch: REL_16_STABLE [fb8befa7b] 2026-06-12 13:57:22 +0200 Branch: REL_15_STABLE [c7f70fa1b] 2026-06-12 13:57:22 +0200 Branch: REL_14_STABLE [086652c02] 2026-06-12 13:57:22 +0200

    Support building <productname>PostgreSQL</productname> with OpenSSL 4 (Daniel Gustafsson) 《機械翻訳》サポートの建物PostgreSQLOpenSSL 4. (Daniel Gustafsson) §

  • Author: Tom Lane <tgl@sss.pgh.pa.us> Branch: master [6ca405938] 2026-08-02 11:26:30 -0400 Branch: REL_19_STABLE [3c16aa293] 2026-08-02 11:26:30 -0400 Branch: REL_18_STABLE [5f67124fa] 2026-08-02 11:26:30 -0400 Branch: REL_17_STABLE [669438aed] 2026-08-02 11:26:30 -0400 Branch: REL_16_STABLE [796c275a0] 2026-08-02 11:26:30 -0400 Branch: REL_15_STABLE [af7be5672] 2026-08-02 11:26:30 -0400 Branch: REL_14_STABLE [812cc1a73] 2026-08-02 11:26:30 -0400

    Update time zone data files to <application>tzdata</application> release 2026c (Tom Lane) タイムゾーンデータファイルがtzdataリリース2026cに更新されました。 (Tom Lane) §

    Alberta (America/Edmonton) will be on year-round UTC-06 (effectively, permanent DST) beginning in November 2026. This release assumes that their TZ abbreviation will be <literal>CST</literal> from that time forward. That seems likely to change, but it's unclear what new abbreviation will be used. 《機械翻訳》アルバータ(アメリカ/エドモントン)は、2026年11月から1年を通してUTC-06(事実上の恒久的なDST)になります。 このリリースでは、TZの省略形がCSTそれ以降になると想定しています。 これは変更される可能性がありますが、新しい省略形が使用されるかどうかは不明です。

    Morocco (Africa/Casablanca) will move to permanent UTC+00, without daylight saving time transitions, on 2026-09-20. 《機械翻訳》モロッコ(Africa/Casablanca)は、2026-09-20に夏時間の移行なしで恒久的なUTC+00に移行します。