HN 日本語サマリー

← 一覧へ戻る
プログラミング

Postgres 19 のリリースが遅延、原因は AI にあり

Postgres 19 is late, and it's AI's fault (rhaas.blogspot.com)

94 pointsby soheilpro67 コメント

要約

PostgreSQL のメジャーリリースは通常9月中旬から10月中旬にかけて行われますが、Postgres 19 はAIによるバグ発見の増加により、11月以降にずれ込む見込みです。LLMがコードベースのバグを容易に発見するようになったことで、修正とレビューに時間がかかり、リリースプロセスに影響が出ています。これは開発者にとって課題であると同時に、品質向上の機会でもあります。

全文翻訳

過去10年間、PostgreSQL のメジャーリリース時期は非常に予測可能でした。9月中旬より早くなく、10月中旬より遅くない、という具合です。今年は異なります。PostgreSQL 19 は、おそらく11月までリリースされないでしょう。プロジェクトがさらにリリースを延期することを決定する可能性も否定できません。

さらに、今年はベータ期間のかなり遅い段階で、UPDATE/DELETE FOR PORTION OF、SQL Property Graph Queries (SQL/PGQ)、ALTER TABLE … MERGE PARTITION/SPLIT PARTITION といった、かなり大規模な機能がいくつかリバートされました。これらはすべて8月27日から9月15日の間に行われました。機能フリーズ直後に大規模な機能リバートが発生することは珍しくありませんが(機能フリーズは毎年4月8日に行われます)、これほど遅い時期に複数の主要機能がリリースから除外されるのは異例です。では、何が起こったのでしょうか?

短い答えは、LLM(大規模言語モデル)です。すべてのソフトウェアにはバグが含まれており、PostgreSQL のコードベースは大きく、複雑で、古いです。CVS から変換された私たちの git の履歴は、30年以上前に遡り、最初のコードはそれより10年前に書かれました。コード量は膨大で、そのコードには膨大な数のバグが含まれています。これは常にそうでしたが、PostgreSQL が人気を博したり成功したりするのを妨げるものではありませんでした。今違うのは、それらのバグを見つけることがはるかに容易になったことです。修正も容易になりましたが、それほどではありません。

2025年4月8日から2025年9月25日の間に、PostgreSQL の master ブランチに1037件のコミットがあり、REL_18_STABLE には724件のコミットがありました。2026年の同じ期間には、master ブランチに1443件、REL_19_STABLE には1169件のコミットがありました。つまり、機能フリーズから9月25日までの master ブランチへのコミット数だけを見ると、昨年からわずかに減少していますが、バックポートされたコミット数は60%以上増加しています。

この増加の一部は、コミッターが昨年よりも今年多くのミスを犯した結果である可能性もありますが、プロジェクトに関わっている誰もが、それが主な原因だと信じているとは思いません。むしろ、PostgreSQL のコミッターは、過去の年に比べて2026年も同様に保守的であった可能性が高いですが、彼らが犯したミスの多くが LLM によって迅速に見つけられたようです。

そして、これは最新リリースにおけるミスだけではありません。同じ期間の2025年には REL_17_STABLE に248件のコミットがあり、2026年には REL_18_STABLE に433件のコミットがありました。つまり、進行中のリリースだけでなく、少なくとも1つ前のリリースにもバックポートされているコミットの数が、1年間で74%以上増加しました。この理由は単純で、インターネット上の非常に多くの人々が LLM を使用して発見した PostgreSQL のバグを報告しており、PostgreSQL のコミッターはそれらを修正するのに非常に、非常に忙しくなっているからです。

そして、これが多くの遅延リバートが発生し、リリース自体が遅延した理由でもあると思います。ここには2つの要因が働いています。

第一に、現在発見されるバグがはるかに多いため、それらを修正するのに時間がかかります。LLM は修正案を作成できますが、それらの修正案が常に正しい、または PostgreSQL の標準に準拠しているとは限りません。そのため、依然として人間によるレビューとコミットが必要であり、その人間たちは2025年から2026年の間に賢くなったわけではありません。

第二に、リリースに含まれるものに対するレビューに費やされるはずだった時間が、バックブランチにおけるセキュリティ問題やその他のバグへの対応に転用されたため、v19 を出荷する前に何をリバートする必要があるかを判断するのに時間がかかりました。

最終的に、PostgreSQL 19 の出荷遅延は、それほど懸念すべきことではないと思います。全体から見れば長い遅延ではなく、プロジェクトの品質への配慮から直接生じたものです。

長期的な見通しは不明瞭で、ある意味ではより懸念されます。人間が見つけられなかった40年分のバグを LLM が発見できるようになった今、私たちはどのようにして追いつき、PostgreSQL はどのようにイノベーションを続けられるのでしょうか?現時点では、私にはわかりません。私が知っているのは、私自身と他の多くの人々が、その解決策を見つけようと本当に一生懸命取り組んでいるということです。

私が PostgreSQL 開発者になったのは、PostgreSQL のコードベースが、私がこれまでに携わった中で最もクリーンで高品質なコードの一部であるからです。そのコードベースにおける AI の最近のバグ発見の成功は、それに対する私の高い評価を変えるものではありません。完璧ではありませんが(どのソフトウェア製品も完璧ではありません)、人間の目にも見える欠陥がもっと多かったとしたら、LLM によって発見されるものの数はさらに大きかったでしょう。

LLM は、すべての PostgreSQL 開発者、そしてある程度は地球上のすべてのソフトウェア開発者に、自身のレベルを引き上げることを要求するという事実に、逃れることはできません。これから私たちのキャリアが終わるまで書くすべての機能は、AI によって精査されるでしょう。そして、以前の時代には永遠に気づかれずに済んだであろうことが、今や数時間で見つけられるかもしれません。それは課題であると同時に機会でもあります。

[このブログ記事は元々 https://neon.com/blog/postgres-19-is-late-and-its-ais-fault に掲載されました]