PostgreSQL 19：REPACK、WAIT、そしてようやく説得できるプランナ

PostgreSQL 19 のドキュメントはまだ流動的ですが（リリースノートの日付は保留のままです）、「概要」は固まりました。日常運用を本当に変えるものを挙げます。

REPACK：VACUUM FULL と CLUSTER が一つに

ディスク容量の回収は VACUUM FULL、インデックス順への物理的な並べ替えは CLUSTER。どちらも排他ロックを取ります。19 はこれを単一の REPACK に統合し、さらに CONCURRENTLY オプションで読み書きを止めずに再編成できます。

要点は構文が短くなったことではありません。大きなテーブルの再編成が停止必須から好きな時間に予約へ変わることです。数百 GB のテーブルを CLUSTER するのは、事実上メンテナンスウィンドウの宣言でした。

WAIT：レプリカ上で自分の書き込みを読む

プライマリ／レプリカ構成には昔からの気まずさがあります。プライマリに書いてすぐレプリカを読むと、その行が無いことがある。新しい WAIT は、スタンバイが指定した地点まで変更を再生し終えるまで待ちます。つまりスタンバイ上での read-your-writes です。

「200ms 待って再試行」よりはるかにましで、全ての読み取りをプライマリに流すより安上がりです。

プランナを固定できる

新しい拡張が二つ。pg_plan_advice はクエリプランナの決定を安定化・制御し、pg_stash_advice はクエリに応じてその助言を自動適用します。

実行計画の漂流は古い傷です。同じ SQL が昨日は快調で、夜に統計情報が更新されたら今日は壊滅的な計画を選ぶ。従来の答えは pg_hint_plan のような第三拡張か、SQL の書き換えでした。今はコアが公式の手段を提供します。

レプリケーションと vacuum

• 論理レプリケーションがシーケンス値を複製できるようになり、wal_level = replica ならサーバ再起動なしで有効化できる
• autovacuum が並列ワーカーでインデックスを処理できるようになり、どのテーブルを優先すべきかを決める新しいスコアリングが入った
• I/O ワーカー数が自動でスケールし、外部キー検査も速くなった

「再起動不要」は見た目以上に効きます。論理レプリケーションの有効化は wal_level の変更と再起動を意味し、稼働中のプライマリでは予定を立てる作業でした。

噛みつく非互換三点

アップグレード前に必ず：

1. RADIUS サポートの削除。 理由は率直です。UDP 上の RADIUS しか対応しておらず、それは「修正不可能なほど安全でない」。認証経路に RADIUS があるなら代替を計画してください。
2. standard_conforming_strings がサーバ側で常時オンに。 19 より前の pg_dump で、standard_conforming_strings = off の状態で作ったダンプは、19 以降へ正しくロードできません。19 以降のツールでダンプしてください。
3. データベース名・ロール名・テーブルスペース名で CR と LF が禁止されます。pg_upgrade が検査します。

小さめの変更が二つ。password_expiration_warning_threshold（既定は 7 日前）が追加され、MD5 パスワード認証の成功後に警告が出ます（md5_password_warnings で無効化可能）。MD5 パスワードは 18 で非推奨とされていました。

私の結論

四点のうち、運用の形を変えるのは REPACK ... CONCURRENTLY と WAIT です。プランナ助言の拡張は、何年も自前で足してきたものへの領収書です。

本当のリスクは互換性の三点にあります。RADIUS が消えたのは安全でないからであり、PostgreSQL は多くのプロジェクトより一貫して「正しさのために機能を消す」ことを選んできました。認証経路に RADIUS があるなら、このアップグレードは「いつかやる」項目ではありません。