Ensure cached plans are marked as dependent on the calling role when RLS applies to a non-top-level table reference (Nathan Bossart) 最上位レベル以外のテーブル参照にRLSが適用される場合、キャッシュされた実行計画が呼び出し元のロールに依存するものとしてマークされるようになりました。 (Nathan Bossart) §

If a CTE, subquery, sublink, security invoker view, or coercion projection in a query references a table with row-level security policies, we neglected to mark the resulting plan as potentially dependent on which role is executing it. This could lead to later query executions in the same session using the wrong plan, and then returning or hiding rows that should have been hidden or returned instead. 問い合わせ内のCTE、サブクエリ、サブリンク、セキュリティ呼び出し元ビュー、または強制射影が行レベルセキュリティポリシーを持つテーブルを参照する場合、結果の実行計画がどのロールで実行しているかに依存する可能性があるとマークされていませんでした。 これにより、同じセッションで後に実行された問い合わせが間違った実行計画で実行され、本来非表示にする必要があった行が返されたり、返すべき行が非表示になったりする可能性がありました。

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

Make <application>libpq</application> discard error messages received during SSL or GSS protocol negotiation (Jacob Champion) libpqがSSLまたはGSSプロトコルのネゴシエーション中に受信したエラーメッセージを廃棄するように修正されました。 (Jacob Champion) §

An error message received before encryption negotiation is completed might have been injected by a man-in-the-middle, rather than being real server output. Reporting it opens the door to various security hazards; for example, the message might spoof a query result that a careless user could mistake for correct output. The best answer seems to be to discard such data and rely only on <application>libpq</application>'s own report of the connection failure. 暗号化ネゴシエーションが完了する前に受け取ったエラーメッセージは、実際のサーバの出力ではなく、中間者攻撃によって挿入された可能性があります。 これを報告すると、さまざまなセキュリティ上の危険が生じる可能性があります。 例えば、このメッセージによって問い合わせの結果を偽装して、不注意なユーザが正しい出力と勘違いする可能性があります。 最良の解決策は、このようなデータを破棄し、libpq自身の接続失敗の報告のみに頼ることです。

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

Fix unintended interactions between <command>SET SESSION AUTHORIZATION</command> and <command>SET ROLE</command> (Tom Lane) SET SESSION AUTHORIZATIONとSET ROLEの間の意図しない相互作用が修正されました。 (Tom Lane) § §

The SQL standard mandates that <command>SET SESSION AUTHORIZATION</command> have a side-effect of doing <command>SET ROLE NONE</command>. Our implementation of that was flawed, creating more interaction between the two settings than intended. Notably, rolling back a transaction that had done <command>SET SESSION AUTHORIZATION</command> would revert <literal>ROLE</literal> to <literal>NONE</literal> even if that had not been the previous state, so that the effective user ID might now be different from what it had been before the transaction. Transiently setting <varname>session_authorization</varname> in a function <literal>SET</literal> clause had a similar effect. A related bug was that if a parallel worker inspected <literal>current_setting('role')</literal>, it saw <literal>none</literal> even when it should see something else. 標準SQLでは、SET SESSION AUTHORIZATIONが副作用としてSET ROLE NONEを実行することを義務付けています。 この実装には欠陥があり、2つの設定間に意図した以上の相互作用が発生していました。 特に、SET SESSION AUTHORIZATIONを実行したトランザクションをロールバックすると、以前の状態ではなかったとしてもROLEがNONEに戻ってしまうことがありました。そのため実効ユーザIDがトランザクションの前とは異なる場合がありました。 関数のSET句でsession_authorizationを一時的に設定しても、同様の影響がありました。 関連するバグとして、パラレルワーカーがcurrent_setting('role')を検査した場合、他の値を参照すべきときでもnoneと認識される問題がありました。

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

Prevent trusted PL/Perl code from changing environment variables (Andrew Dunstan, Noah Misch) 信頼されたPL/Perlコードが環境変数を変更できないように修正されました。 (Andrew Dunstan, Noah Misch) § § §

The ability to manipulate process environment variables such as <literal>PATH</literal> gives an attacker opportunities to execute arbitrary code. Therefore, <quote>trusted</quote> PLs must not offer the ability to do that. To fix <literal>plperl</literal>, replace <varname>%ENV</varname> with a tied hash that rejects any modification attempt with a warning. Untrusted <literal>plperlu</literal> retains the ability to change the environment. PATHなどのプロセス環境変数を操作する機能は、攻撃者に任意のコードを実行する機会を与えます。 したがって、「信頼された」PLはそれを行う機能を提供してはなりません。 plperlは、%ENVを、変更の試みを警告で拒否する結びつけられたハッシュに置き換えるよう修正されました。 信頼されていないplperluは、環境を変更する機能を保持します。

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

Fix updates of catalog state for foreign-key constraints when attaching or detaching table partitions (Jehan-Guillaume de Rorthais, Tender Wang, Álvaro Herrera) テーブルパーティションをアタッチまたはデタッチする際の、外部キーの制約のカタログ状態の更新が修正されました。 (Jehan-Guillaume de Rorthais, Tender Wang, Álvaro Herrera) § §

If the referenced table is partitioned, then different catalog entries are needed for a referencing table that is stand-alone versus one that is a partition. <literal>ATTACH/DETACH PARTITION</literal> commands failed to perform this conversion correctly. In particular, after <literal>DETACH</literal> the now stand-alone table would be missing foreign-key enforcement triggers, which could result in the table later containing rows that fail the foreign-key constraint. A subsequent re-<literal>ATTACH</literal> could fail with surprising errors, too. 参照先テーブルがパーティションテーブルの場合、参照元テーブルがスタンドアローンの場合とパーティションの場合で、異なるカタログエントリが必要になります。 ATTACH/DETACH PARTITIONコマンドはこの変換を正しく実行できませんでした。 特に、DETACH後、スタンドアローンになったテーブルには、外部キー強制トリガが欠落するため、その結果、外部キー制約に違反する行がテーブルに含まれる可能性がありました。 その後の再ATTACHも、予期しないエラーで失敗する可能性がありました。

The way to fix this is to do <command>ALTER TABLE DROP CONSTRAINT</command> on the now stand-alone table for each faulty constraint, and then re-add the constraint. If re-adding the constraint fails, then some erroneous data has crept in. You will need to manually re-establish consistency between the referencing and referenced tables, then re-add the constraint. この問題を解決するには、スタンドアローンになったテーブルで問題のある制約ごとにALTER TABLE DROP CONSTRAINTを実行し、その後制約を再度追加します。 制約の再追加に失敗した場合は、誤ったデータが入り込んでいます。 参照元テーブルと参照先テーブル間の整合性を手動で再確立し、制約を再度追加する必要があります。

This query can be used to identify broken constraints and construct the commands needed to recreate them: このクエリを使用して、破損した制約を識別し、それらを再作成するために必要なコマンドを作成することができます。

SELECT conrelid::pg_catalog.regclass AS "constrained table",
       conname AS constraint,
       confrelid::pg_catalog.regclass AS "references",
       pg_catalog.format('ALTER TABLE %s DROP CONSTRAINT %I;',
                         conrelid::pg_catalog.regclass, conname) AS "drop",
       pg_catalog.format('ALTER TABLE %s ADD CONSTRAINT %I %s;',
                         conrelid::pg_catalog.regclass, conname,
                         pg_catalog.pg_get_constraintdef(oid)) AS "add"
FROM pg_catalog.pg_constraint c
WHERE contype = 'f' AND conparentid = 0 AND
   (SELECT count(*) FROM pg_catalog.pg_constraint c2
    WHERE c2.conparentid = c.oid) <>
   (SELECT count(*) FROM pg_catalog.pg_inherits i
    WHERE (i.inhparent = c.conrelid OR i.inhparent = c.confrelid) AND
      EXISTS (SELECT 1 FROM pg_catalog.pg_partitioned_table
              WHERE partrelid = i.inhparent));

Since it is possible that one or more of the <literal>ADD CONSTRAINT</literal> steps will fail, you should save the query's output in a file and then attempt to perform each step. ADD CONSTRAINTの1つ以上のステップが失敗する可能性があるため、問い合わせの出力をファイルに保存してから、各ステップの実行を試行する必要があります。

Fix test for <literal>C</literal> locale when <varname>LC_COLLATE</varname> is different from <varname>LC_CTYPE</varname> (Jeff Davis) LC_COLLATEがLC_CTYPEと異なる場合のCロケールのテストが修正されました。 (Jeff Davis) §

When using <literal>libc</literal> as the default collation provider, the test to see if <literal>C</literal> locale is in use for collation accidentally checked <varname>LC_CTYPE</varname> not <varname>LC_COLLATE</varname>. This has no impact in the typical case where those settings are the same, nor if both are not <literal>C</literal> (nor its alias <literal>POSIX</literal>). However, if <varname>LC_CTYPE</varname> is <literal>C</literal> while <varname>LC_COLLATE</varname> is some other locale, wrong query answers could ensue, and corruption of indexes on strings was possible. Users of databases with such settings should reindex affected indexes after installing this update. The converse case with <varname>LC_COLLATE</varname> being <literal>C</literal> while <varname>LC_CTYPE</varname> is some other locale would cause performance degradation, but no actual errors. デフォルトの照合順序プロバイダとしてlibcを使用している場合、照合順序にCロケールが使用されているかどうかを確認するテストが、誤ってLC_COLLATEではなくLC_CTYPEをチェックしていました。 これらの設定が同じである一般的なケース、または両方がC（またはその別名であるPOSIX）でない場合は、この問題は発生しません。 ただし、LC_CTYPEがCで、LC_COLLATEが他のロケールである場合、問い合わせの応答が間違っていたり、文字列のインデックスが破損する可能性がありました。 このような設定を持つデータベースのユーザは、この更新をインストールした後に、影響を受けるインデックスを再作成する必要があります。 逆にLC_COLLATEがCでLC_CTYPEが他のロケールである場合は、パフォーマンスは低下しますが、実際のエラーは発生しません。

Don't use partitionwise joins or grouping if the query's collation for the key column doesn't match the partition key's collation (Jian He, Webbo Han) キー列の問い合わせの照合順序がパーティションキーの照合順序と一致しない場合は、パーティション同士の結合またはグループ化を使用しないようになりました。 (Jian He, Webbo Han) § §

Such plans could produce incorrect results. このような計画は、間違った結果を生成する可能性がありました。

Avoid planner failure after converting an <literal>IS NULL</literal> test on a <literal>NOT NULL</literal> column to constant <literal>FALSE</literal> (Richard Guo) NOT NULL列のIS NULLテストをFALSE定数に変換した後のプランナ失敗が回避されました。 (Richard Guo) §

This bug typically led to errors such as <quote>variable not found in subplan target lists</quote>. このバグは典型的には、「variable not found in subplan target lists」などのエラーを引き起こしました。

Avoid possible planner crash while inlining a SQL function whose arguments contain certain array-related constructs (Tom Lane, Nathan Bossart) 引数に特定の配列関連の構成が含まれるSQL関数をインライン化する際に、プランナがクラッシュする可能性が回避されました。 (Tom Lane, Nathan Bossart) §

Fix possible wrong answers or <quote>wrong varnullingrels</quote> planner errors for <literal>MERGE ... WHEN NOT MATCHED BY SOURCE</literal> actions (Dean Rasheed) MERGE ... WHEN NOT MATCHED BY SOURCEアクションで発生する可能性のある、間違った応答または「wrong varnullingrels」プランナエラーが修正されました。 (Dean Rasheed) § §

Fix possible <quote>could not find pathkey item to sort</quote> error when the output of a <literal>UNION ALL</literal> member query needs to be sorted, and the sort column is an expression (Andrei Lepikhov, Tom Lane) UNION ALLメンバ問い合わせの出力をソートする必要があり、ソート列が式である場合に発生する可能性のある「could not find pathkey item to sort」エラーが修正されました。 (Andrei Lepikhov, Tom Lane) §

Fix edge case in B-tree ScalarArrayOp index scans (Peter Geoghegan) B-treeのScalarArrayOpを使うインデックススキャンの稀な不具合が修正されました。 (Peter Geoghegan) §

When a scrollable cursor with a plan of this kind was backed up to its starting point and then run forward again, wrong answers were possible. この種のプランを持つスクロール可能なカーソルを開始点まで巻き戻した後、再び前方に実行した場合、誤った問い合わせ結果が生じる可能性がありました。

Fix assertion failure or confusing error message for <literal>COPY (<replaceable>query</replaceable>) TO ...</literal>, when the <replaceable>query</replaceable> is rewritten by a <literal>DO INSTEAD NOTIFY</literal> rule (Tender Wang, Tom Lane) 問い合わせがDO INSTEAD NOTIFYの規則によって書き換えられた場合に発生する、COPY (query) TO ...のアサーションエラーまたは紛らわしいエラーメッセージが修正されました。 (Tender Wang, Tom Lane) §

Fix validation of <command>COPY</command>'s <literal>FORCE_NOT_NULL</literal> and <literal>FORCE_NULL</literal> options (Joel Jacobson) COPYのFORCE_NOT_NULLオプションとFORCE_NULLオプションの検証が修正されました。 (Joel Jacobson) §

Some incorrect usages are now rejected as they should be. 一部の誤った使用法は、適切に拒否されるようになりました。

Fix server crash when a <function>json_objectagg()</function> call contains a volatile function (Amit Langote) json_objectagg()呼び出しにVOLATILE関数が含まれている場合に発生するサーバクラッシュが修正されました。 (Amit Langote) §

Fix detection of skewed data during parallel hash join (Thomas Munro) パラレルハッシュ結合中の偏ったデータ検出が修正されました。 (Thomas Munro) §

After repartitioning the inner side of a hash join because one partition has accumulated too many tuples, we check to see if all the partition's tuples went into the same child partition, which suggests that they all have the same hash value and further repartitioning cannot improve matters. This check malfunctioned in some cases, allowing repeated futile repartitioning which would eventually end in a resource-exhaustion error. 1つのパーティションにタプルが蓄積されすぎたため、ハッシュ結合の内側を再分割した後、すべてのパーティションのタプルが同じ子パーティションに入ったかどうかを確認します。これは、すべてのタプルが同じハッシュ値を持つため、さらに再分割しても改善は問題にならないことを示唆しています。 このチェックは場合によっては誤動作し、無駄な再分割が繰り返され、最終的にはリソース不足のエラーになることがありました。

Avoid crash when <command>ALTER DATABASE SET</command> is used to set a server parameter that requires search-path-based lookup, such as <varname>default_text_search_config</varname> (Jeff Davis) ALTER DATABASE SETを使用して、default_text_search_configなどのサーチパスベースの検索を必要とするパラメータを設定した場合のクラッシュが回避されました。 (Jeff Davis) §

Avoid repeated lookups of opclasses and collations while creating a new index on a partitioned table (Tom Lane) パーティションテーブルに新しいインデックスを作成する際の、opclassesと照合順序の繰り返し検索が回避されました。 (Tom Lane) §

This was problematic mainly because some of the lookups would be done with a restricted <varname>search_path</varname>, leading to unexpected failures if the <command>CREATE INDEX</command> command referenced objects outside <literal>pg_catalog</literal>. これは主に一部の検索が制限されたsearch_pathで実行されるため、CREATE INDEXコマンドがpg_catalog外のオブジェクトを参照した場合に予期せぬエラーが発生する問題がありました。

This fix also prevents comments on the parent partitioned index from being copied to child indexes. この修正により、親パーティションインデックスのコメントが子インデックスにコピーされるのも防止されます。

Add missing dependency from a partitioned table to a non-built-in access method specified in <literal>CREATE TABLE ... USING</literal> (Michael Paquier) パーティションテーブルからCREATE TABLE ... USINGで指定された非組み込みアクセスメソッドへの欠落した依存性が追加されました。 (Michael Paquier) §

Dropping the access method should be blocked when a table exists that depends on it, but it was not, allowing subsequent odd behavior. Note that this fix only prevents problems for partitioned tables created after this update. アクセスメソッドに依存するテーブルが存在する場合は、アクセスメソッドの削除はブロックされる必要がありますが、そうではなかっため、その後に異常な動作が発生する可能性がありました。 この修正は、この更新の後に作成されたパーティションテーブルの問題のみを防止することに注意してください。

Disallow locale names containing non-ASCII characters (Thomas Munro) 非ASCII文字を含むロケール名が許可されなくなりました。 (Thomas Munro) §

This is only an issue on Windows, as such locale names are not used elsewhere. They are problematic because it's quite unclear what encoding such names are represented in (since the locale itself defines the encoding to use). In recent <productname>PostgreSQL</productname> releases, an abort in the Windows runtime library could occur because of confusion about that. このようなロケール名は他の場所では使用されていないため、これはWindowsだけの問題です。 このような名前がどのエンコーディングで表現されるのかが非常に不明確であるため、問題があります（ロケール自体が使用するエンコーディングを定義するため）。 最近のPostgreSQLリリースでは、その混乱によりWindowsランタイムライブラリのアボートが発生する可能性がありました。

Anyone who encounters the new error message should either create a new duplicated locale with an ASCII-only name using Windows Locale Builder, or consider using BCP 47-compliant locale names like <literal>tr-TR</literal>. 新しいエラーメッセージに遭遇した場合は、Windows Locale Builderを使用してASCII文字のみの名前で新しい複製ロケールを作成するか、tr-TRのようなBCP 47準拠のロケール名の使用を検討してください。

Fix race condition in committing a serializable transaction (Heikki Linnakangas) シリアライザブルトランザクションをコミットする際の競合状態が修正されました。 (Heikki Linnakangas) §

Mis-processing of a recently committed transaction could lead to an assertion failure or a <quote>could not access status of transaction</quote> error. 最近コミットされたトランザクションの処理を誤って、アサーションエラーまたは「could not access status of transaction」エラーにつながる可能性がありました。

Fix race condition in <command>COMMIT PREPARED</command> that resulted in orphaned 2PC files (wuchengwen) 孤立した二相コミット(2PC)ファイルが生成されていたCOMMIT PREPAREDで競合条件が修正されました。 (wuchengwen) §

A concurrent <command>PREPARE TRANSACTION</command> could cause <command>COMMIT PREPARED</command> to not remove the on-disk two-phase state file for the completed transaction. There was no immediate ill effect, but a subsequent crash-and-recovery could fail with <quote>could not access status of transaction</quote>, requiring manual removal of the orphaned file to restore service. 同時実行のPREPARE TRANSACTIONにより、COMMIT PREPAREDが完了したトランザクションのディスク上の二相状態ファイルが削除されない原因となる可能性がありました。 すぐに悪影響はありませんでしたが、その後のクラッシュとリカバリが「could not access status of transaction」というエラーで、サービス復旧には孤立したファイルを手動で削除する必要がありました。

Avoid invalid memory accesses after skipping an invalid toast index during <command>VACUUM FULL</command> (Tender Wang) VACUUM FULL中に無効なTOASTインデックスをスキップした後の無効なメモリアクセスが回避されました。 (Tender Wang) §

A list tracking yet-to-be-rebuilt indexes was not properly updated in this code path, risking assertion failures or crashes later on. このコードパスでは、まだ再構築されていないインデックスを追跡しているリストが適切に更新されず、後でアサーションエラーやクラッシュが発生する危険性がありました。

Fix ways in which an <quote>in place</quote> catalog update could be lost (Noah Misch) 「インプレース」でのカタログ更新が失われる可能性のある方法が修正されました。 (Noah Misch) § § § § § § §

Normal row updates write a new version of the row to preserve rollback-ability of the transaction. However, certain system catalog updates are intentionally non-transactional and are done with an in-place update of the row. These patches fix race conditions that could cause the effects of an in-place update to be lost. As an example, it was possible to forget having set <structname>pg_class</structname>.<structfield>relhasindex</structfield> to true, preventing updates of the new index and thus causing index corruption. 通常の行更新では、トランザクションのロールバック可能性を維持するために行の新しいバージョンが書き込まれます。 ただし、一部のシステムカタログ更新は意図的にトランザクションではなく、行のインプレース更新で行われます。 これらのパッチは、インプレース更新の効果が失われる原因となる競合状態を修正します。 例えば、pg_class.relhasindexをtrueに設定し忘れると、新しいインデックスの更新が妨げられ、インデックスの破損を引き起こす可能性がありました。

Reset catalog caches at end of recovery (Noah Misch) リカバリの終了時にカタログキャッシュをリセットするようになりました。 (Noah Misch) §

This prevents scenarios wherein an in-place catalog update could be lost due to using stale data from a catalog cache. これにより、カタログキャッシュからの古いデータを使用することで、インプレイスカタログ更新が失われるシナリオが回避されます。

Avoid using parallel query while holding off interrupts (Francesco Degrassi, Noah Misch, Tom Lane) 割り込みを保留している間は、パラレルクエリを使用しないようになりました。 (Francesco Degrassi, Noah Misch, Tom Lane) § §

This situation cannot arise normally, but it can be reached with test scenarios such as using a SQL-language function as B-tree support (which would be far too slow for production usage). If it did occur it would result in an indefinite wait. この状況は通常は発生しませんが、SQL言語関数をB-treeサポートとして使用するなどのテストシナリオでは発生する可能性があります（これは実稼働環境での使用には遅すぎます）。 このような状況が発生した場合、無期限の待機が発生しました。

Ignore not-yet-defined Portals in the <structname>pg_cursors</structname> view (Tom Lane) pg_cursorsビューで未定義のポータルを無視するようになりました。 (Tom Lane) §

It is possible for user-defined code that inspects this view to be called while a new cursor is being set up, and if that happens a null pointer dereference would ensue. Avoid the problem by defining the view to exclude incompletely-set-up cursors. 新しいカーソルの設定中に、このビューを検査するユーザ定義コードが呼び出される可能性があり、その場合NULLポインタ間接参照が発生します。 設定が不完全なカーソルを除外するようにビューを定義することでこの問題が回避されます。

Avoid <quote>unexpected table_index_fetch_tuple call during logical decoding</quote> error while decoding a transaction involving insertion of a column default value (Takeshi Ideriha, Hou Zhijie) 列のデフォルト値の挿入を含むトランザクションのデコード中に、「unexpected table_index_fetch_tuple call during logical decoding」エラーが発生しなくなりました。 (Takeshi Ideriha, Hou Zhijie) § §

Reduce memory consumption of logical decoding (Masahiko Sawada) ロジカルデコーディングのメモリ使用量が削減されました。 (Masahiko Sawada) §

Use a smaller default block size to store tuple data received during logical replication. This reduces memory wastage, which has been reported to be severe while processing long-running transactions, even leading to out-of-memory failures. 論理レプリケーション中に受信したタプルデータを格納するために、より小さいデフォルトブロックサイズを使用するようになりました。 これにより、メモリ不足の障害につながることもあると報告されている、長時間実行されるトランザクション処理中の深刻なメモリ浪費が削減されます。

Fix behavior of stable functions called from a <command>CALL</command> statement's argument list, when the <command>CALL</command> is within a PL/pgSQL <literal>EXCEPTION</literal> block (Tom Lane) PL/pgSQLのEXCEPTIONブロック内でCALL文の引数リストから呼び出されるSTABLE関数の動作が修正されました。 (Tom Lane) §

As with a similar fix in our previous quarterly releases, this case allowed such functions to be passed the wrong snapshot, causing them to see stale values of rows modified since the start of the outer transaction. 以前の四半期リリースでの同様の修正と同様に、今回のケースでは、このような関数に間違ったスナップショットが渡され、外部トランザクションの開始以降に変更された行の古い値を参照する可能性がありました。

Parse <application>libpq</application>'s <literal>keepalives</literal> connection option in the same way as other integer-valued options (Yuto Sasaki) libpqのkeepalives接続オプションを、他の整数値オプションと同様に解析するようになりました。 (Yuto Sasaki) §

The coding used here rejected trailing whitespace in the option value, unlike other cases. This turns out to be problematic in <application>ecpg</application>'s usage, for example. ここで使用されたコーディングでは、他の場合とは異なり、オプション値の末尾の空白文字が拒否されていました。 これは、例えばecpgの使用時に問題となることが判明しました。

In <application>ecpglib</application>, fix out-of-bounds read when parsing incorrect datetime input (Bruce Momjian, Pavel Nekrasov) ecpglibが、不正なdatetime入力を解析する際に範囲外の読み取りをしないよう修正されました。 (Bruce Momjian, Pavel Nekrasov) §

It was possible to try to read the location just before the start of a constant array. Real-world consequences seem minimal, though. 定数配列の開始直前の位置を読み取ろうとする可能性がありました。 しかしながら、実世界での影響は最小限にとどまると思われます。

Fix <application>psql</application>'s describe commands to again work with pre-9.4 servers (Tom Lane) psqlのdescribeコマンドが9.4以前のサーバで再び動作するように修正されました。 (Tom Lane) §

Commands involving display of an ACL (permissions) column failed with very old <productname>PostgreSQL</productname> servers, due to use of a function not present in those versions. ACL（権限）列の表示を含むコマンドは、非常に古いPostgreSQLサーバでこれらのバージョンには存在しない関数を使用していたため失敗していました。

Avoid hanging if an interval less than 1ms is specified in <application>psql</application>'s <literal>\watch</literal> command (Andrey Borodin, Michael Paquier) psqlの\watchコマンドで1ミリ秒未満の間隔が指定された場合のハングアップが回避されました。 (Andrey Borodin, Michael Paquier) §

Instead, treat this the same as an interval of zero (no wait between executions). 代わりに、間隔ゼロ（実行間の待ち時間なし）と同じように扱われます。

Fix failure to find replication password in <filename>~/.pgpass</filename> (Tom Lane) ~/.pgpassでレプリケーションパスワードが見つからない問題が修正されました。 (Tom Lane) §

<application>pg_basebackup</application> and <application>pg_receivewal</application> failed to match an entry in <filename>~/.pgpass</filename> that had <literal>replication</literal> in the database name field, if no <option>-d</option> or <option>&#45;-dbname</option> switch was supplied. This resulted in an unexpected prompt for password. pg_basebackupとpg_receivewalは、-dまたは--dbnameスイッチが指定されていない場合、データベース名フィールドにreplicationを含む~/.pgpassのエントリとの一致に失敗していました。 その結果、予期しないパスワードプロンプトが表示されていました。

In <application>pg_combinebackup</application>, throw an error if an incremental backup file is present in a directory that is supposed to contain a full backup (Robert Haas) pg_combinebackupで、フルバックアップが格納されているディレクトリに増分バックアップファイルが存在する場合、エラーを発生するよう修正されました。 (Robert Haas) §

In <application>pg_combinebackup</application>, don't construct filenames containing double slashes (Robert Haas) pg_combinebackupで、二重スラッシュを含むファイル名を作成しなくなりました。 (Robert Haas) §

This caused no functional problems, but the duplicate slashes were visible in error messages, which could create confusion. これにより機能的な問題は発生しませんでしたが、重複したスラッシュがエラーメッセージに表示されるため、混乱が生じる可能性がありました。

Avoid trying to reindex temporary tables and indexes in <application>vacuumdb</application> and in parallel <application>reindexdb</application> (VaibhaveS, Michael Paquier, Fujii Masao, Nathan Bossart) vacuumdbおよびパラレルreindexdbにおいて、一時テーブルとインデックスのインデックス再構築を試みないようになりました。 (VaibhaveS, Michael Paquier, Fujii Masao, Nathan Bossart) § § §

Reindexing other sessions' temporary tables cannot work, but the check to skip them was missing in some code paths, leading to unwanted failures. 他のセッションの一時テーブルのインデックス再構築は機能しませんが、一部のコードパスでそれらをスキップするチェックが欠落していたため、不要な障害が発生していました。

Fix incorrect LLVM-generated code on ARM64 platforms (Thomas Munro, Anthonin Bonnefoy) ARM64プラットフォームでLLVMが生成するコードの誤りが修正されました。 (Thomas Munro, Anthonin Bonnefoy) §

When using JIT compilation on ARM platforms, the generated code could not support relocation distances exceeding 32 bits, allowing unlucky placement of generated code to cause server crashes on large-memory systems. ARMプラットフォームでJITコンパイルを使用する場合、生成されたコードは32ビットを超える再配置距離をサポートできず、生成されたコードの配置ミスにより、大容量メモリシステムでサーバクラッシュが発生する可能性がありました。

Fix a few places that assumed that process start time (represented as a <type>time_t</type>) will fit into a <type>long</type> value (Max Johnson, Nathan Bossart) time_tとして表現されるプロセス開始時刻がlong値に収まると想定していたいくつかの個所が修正されました。 (Max Johnson, Nathan Bossart) §

On platforms where <type>long</type> is 32 bits (notably Windows), this coding would fail after Y2038. Most of the failures appear only cosmetic, but notably <literal>pg_ctl start</literal> would hang. longが32ビットのプラットフォーム（特にWindows）では、このコーディングは2038年以降で失敗します。 ほとんどの失敗は表面的な問題にすぎませんが、特にpg_ctl startがハングする可能性がありました。

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

This <application>tzdata</application> release changes the old System-V-compatibility zone names to duplicate the corresponding geographic zones; for example <literal>PST8PDT</literal> is now an alias for <literal>America/Los_Angeles</literal>. The main visible consequence is that for timestamps before the introduction of standardized time zones, the zone is considered to represent local mean solar time for the named location. For example, in <literal>PST8PDT</literal>, <type>timestamptz</type> input such as <literal>1801-01-01 00:00</literal> would previously have been rendered as <literal>1801-01-01 00:00:00-08</literal>, but now it is rendered as <literal>1801-01-01 00:00:00-07:52:58</literal>. このtzdataリリースでは、古いSystem-V互換性ゾーン名を変更して、対応する地理的ゾーンを複製します。 例えばPST8PDTはAmerica/Los_Angelesの別名になります。 目に見える主な結果は、標準化されたタイムゾーンが導入される前のタイムスタンプの場合、そのゾーンは指定された場所のローカル平均太陽時を表すと見なされることです。 例えばPST8PDTでは、timestamptzの入力値1801-01-01 00:00は、以前は1801-01-01 00:00:00-08としてレンダリングされていましたが、現在は1801-01-01 00:00:00-07:52:58としてレンダリングされます。

Also, historical corrections for Mexico, Mongolia, and Portugal. Notably, <literal>Asia/Choibalsan</literal> is now an alias for <literal>Asia/Ulaanbaatar</literal> rather than being a separate zone, mainly because the differences between those zones were found to be based on untrustworthy data. また、メキシコ、モンゴル、ポルトガルの歴史的修正がおこなわれています。 特に、Asia/Choibalsanは現在、独立したゾーンではなく、Asia/Ulaanbaatarの別名となっています。 これは主に、これらのゾーン間の違いが信頼できないデータに基づいていることが判明したためです。