大きなテーブルの最初以外のセグメントを削除できない問題を修正しました。 (Tom Lane)

PostgreSQLは大きなテーブルを複数のファイル(通常は1ファイルごとに1ギガバイト)に分割します。 テーブルを削除するためのロジックが破損しており、一時テーブルの削除と通常のテーブルのWAL再生の削除の2つの場合で最初のファイル以外を削除できませんでした。 数ギガバイトの一時テーブルを日常的に作成するアプリケーションでは、重大なディスクスペースリークが発生する可能性があります。

孤立した一時テーブルファイルは、postmasterの起動時に削除されますので、15.1への更新だけで、リークされた一時テーブルのストレージをクリアすることができます。 ただし、15.0の使用中にデータベースのクラッシュが発生し、クラッシュの直前にラージテーブルがドロップされた可能性がある場合は、データベースディレクトリにパターンNNNN.NNに従ったファイル名をチェックすることをお勧めします。 一致したファイル名がNNNNだけ(.NNサフィックスなし)存在しない場合は、これらのファイルを手動で削除する必要があります。

更新可能ビューのINSERTの複数行VALUES句に存在するDEFAULTトークンの処理を修正しました。 (Tom Lane)

この見落としは、「cache lookup failed for type」エラーにつながる可能性があり、古いブランチではクラッシュにつながる可能性さえありました。

ON SELECTではない_RETURNという名前のルールを禁止しました。 (Tom Lane)

これにより、ビューのON SELECTルールとその他のルールとの間の混乱が回避されます。

一定の初期値でSEARCH BREADTH FIRSTを使用する問い合わせのEXPLAIN VERBOSEが失敗しないようにしました。 (Tom Lane)

外部テーブルパーティションを含むパーティションテーブルでMERGEの使用を禁止しました。 (Álvaro Herrera)

このケースはサポートされておらず、以前は理解できないエラーが発生していました。

ALTER TABLE ATTACH PARTITIONの実行中のパーティションごとの外部キー制約の構築を修正しました。 (Jehan-Guillaume de Rorthais, Álvaro Herrera)

これまでは、新しく追加されたパーティションに対して、不正確または重複した制約が作成される可能性がありました。

パーティションテーブルまたは継承されたテーブルの拡張統計でのプランナの失敗を修正しました。 (Richard Guo, Justin Pryzby)

「cache lookup failed for statistics object」で失敗したケースもあります。

GINインデックスの高速挿入パスにおけるWAL操作の順序の誤りを修正しました。 (Matthias van de Meent, Zhang Mingli)

この間違いがPostgreSQLコア内で悪影響を及ぼすことは知られていませんが、一部の拡張機能では問題が発生しました。

トランザクションの開始とそのサブトランザクションの開始の間のポイントからリプレイが開始される場合の論理デコードのバグを修正しました。 (Masahiko Sawada, Kuroda Hayato)

これらのエラーは、デバッグビルドのアサーションエラーにつながる可能性があり、メモリリークにつながる可能性がありました。

論理デコード中に、より多くの場所で割り込みを受け付けるようにしました。 (Amit Kapila, Masahiko Sawada)

これにより、レプリケーションワーカーのシャットダウンが遅いという問題が改善されます。

レプリケーションワーカーで外部テーブルのパーティションへのレプリケーションの試みを防止しました。 (Shi Yu, Tom Lane)

パーティションテーブルは外部テーブルをパーティションとして含めることができますが、そのようなパーティションへのレプリケーションは現在サポートされていません。 それを試みた場合、論理レプリケーションワーカープロセスはこれまでクラッシュしましたが、今はエラーを出すようになりました。

レプリケーションワーカーの関数構文エラー後のクラッシュを回避するようにしました。 (Maxim Orlov, Anton Melnikov, Masahiko Sawada, Tom Lane)

論理レプリケーションワーカーで実行されたSQL言語またはPL/pgSQL言語のCREATE FUNCTIONまたはDOコマンドで構文エラーが発生した場合、ワーカープロセスはnullポインタの逆参照またはアサーション失敗でクラッシュしていました。

アーカイバモジュールのシャットダウンコールバックの二重呼び出しを回避しました。 (Nathan Bossart, Bharath Rupireddy)

テーブルアクセスメソッドを持たないテーブルへのアクセス試行に対するプラン作成時のチェックを追加しました。 (Tom Lane)

これにより、例えばON SELECTルールが欠落しているビューの使用など、一部のカタログ破損シナリオでのクラッシュが防止されます。

共有メモリ状態が破損したときのpostmasterクラッシュを防止します。 (Tom Lane)

postmasterプロセスは、共有メモリが破損した場合にも存続してデータベース再起動をすることになっていましたが、コードの一部でそれに対する注意が不十分でした。

libpqがパイプラインで単一行モードを正しく処理するよう修正しました。 (Denis Laxalde)

パイプラインモードも有効である場合、単独行フラグは正しいタイミングでリセットされませんでした。

コマンドライン問い合わせがキャンセルされた場合のpsqlの終了ステータスを修正しました。 (Peter Eisentraut)

psql -c queryは、問い合わせがキャンセルされた場合に正常に終了していました。 他のエラーの場合と同様に、非ゼロステータスで終了するように修正します。

pg_basebackupでクロスプラットフォームのテーブル空間の再配置を許可します。 (Robert Haas)

--tablespace-mappingのリモートパスは、UnixスタイルまたはWindowsスタイルの絶対パスのいずれかにできるようになりました。 これは、ソースサーバがローカルシステムとは異なるOS上にある可能性があるためです。

一部のCHECK制約に付加されたコメントをpg_dumpがダンプ出来ない問題を修正しました。 (Tom Lane)

CREATE DATABASEのoidパラメータが2³¹を超えることができるように修正しました。 (Tom Lane)

この見落としにより、ソースインストールにそれよりも大きなOIDを持つデータベースが含まれていた場合、pg_upgradeが成功しませんでした。

pg_stat_statementsで既に解放されたメモリへのアクセスを修正しました。 (zhaoqigui)

これは、pg_stat_statementsが拡張問い合わせプロトコル経由で発行されたROLLBACKコマンドを追跡した場合に発生しました。 デバッグビルドでは、一貫してアサーション失敗につながりました。 稼働ビルドでは、目立った悪影響はほとんどありません。 しかし、解放されたメモリがすでに再利用されていた場合、結果として問い合わせ文字列のためにごみデータを格納することになります。

LLVM 15との非互換性を修正しました。 (Thomas Munro, Andres Freund)

どのようなマシンであってもスピンロックのために__sync_lock_test_and_set()を使用できるようにしました。 (Tom Lane)

これにより、少なくともこのGCCビルトイン関数をサポートするコンパイラを使用している場合には、新しいマシンアーキテクチャへの移植が容易になります。

最近のmacOSでのコンパイル障害を回避するために、シンボルREFをREF_Pに変更しました。 (Tom Lane)

コンパイル時の非推奨警告を回避するため、sprintfの使用を避けました。 (Tom Lane)

タイムゾーンデータファイルがtzdataリリース2022fに更新されました。チリ、フィジー、イラン、ヨルダン、メキシコ、パレスチナ、シリアでの夏時間法の変更と、チリ、クリミア、イラン、メキシコの歴史的な修正が含まれます。

また、Europe/KievゾーンはEurope/Kyivに名前が変更されました。 また、Antarctica/Vostok、Asia/Brunei、Asia/Kuala_Lumpur、Atlantic/Reykjavik、Europe/Amsterdam、Europe/Copenhagen、Europe/Luxembourg、Europe/Monaco、Europe/Oslo、Europe/Stockholm、Indian/Christmas、Indian/Cocos、Indian/Kerguelen、Indian/Mahe、Indian/Reunion、Pacific/Chuuk、Pacific/Funafuti、Pacific/Majuro、Pacific/Pohnpei、Pacific/Wake、Pacific/Wallisの各ゾーンは、1970年以降、より人口の多い近隣のゾーンに統合され、時計が一致するようになりました。 (これは、すでにこれらのゾーンのいずれかにリンクされていたゾーンに間接的に影響します:Arctic/Longyearbyen、Atlantic/Jan_Mayen、Iceland、Pacific/Ponape、Pacific/Truk、Pacific/Yap) America/Nipigon、America/Rainy_River、America/Thunder_Bay、Europe/Uzhgorod、Europe/Zaporozhyeも、1970年以降にこれらのゾーンとの間で主張された違いが誤りであったことが判明した後、近隣のゾーンに統合されました。 これらのすべての場合において、以前のゾーン名はエイリアスとして残ります。ただし実際のデータは統合されたゾーンのものです。

これらのゾーンの合併により、合併されたゾーンの1970年以前のタイムゾーン歴史が失われます。 これは、timestamptz表示の一貫性を期待するアプリケーションにとって厄介な問題になる可能性があります。 例として、格納された値1944-06-01 12:00 UTCは、Europe/Stockholmゾーンが選択された場合、以前は1944-06-01 13:00:00+01として表示されていましたが、現在は1944-06-01 14:00:00+02として読み取られます。

古いゾーンデータをビルドするオプションでタイムゾーンデータファイルをリストアすることは可能ですが、その選択は他の多くの古い(そして一般的にあまり証明されていない)ゾーンデータを挿入し、これらのアップストリームの変更を受け入れるよりも、以前のリリースからのより多くの総変更をもたらします。 PostgreSQLは推奨されるようにtzdbデータを出荷することを選択しました。 私たちが知っている限り、ほとんどのメジャーオペレーティングシステムディストリビューションは同様に行っています。 しかし、これらの変更があなたのアプリケーションに重大な問題を引き起こす場合、可能な解決策は、tzdbの後方互換性オプションを使用してタイムゾーンデータファイルのローカルビルドをインストールすることです(PACKRATDATAとPACKRATLISTオプションを参照してください)。