リバートは士気が向上するまで続く

リバートは士気が向上するまで続く

多くの読者は、PostgreSQL 19ブランチでベータ期間開始後に異常に多くの機能がリバートされたことに気づいているだろう。いくつかのリバートは珍しいことではなく、サイクルごとに1つ程度は予想されるかもしれない。しかし今回は、数え方にもよるが、8〜10個もの主要な機能がリバートされ、中にはベータ期間のかなり遅い段階でのものもあった。私は、それらの機能の開発者またはコミッターとして、その一部の受け手となり、それについていくつかの質問を受けたので、ここで少し振り返ってみたい。私が直接関与していなかった同様に影響を受けた作業についても、少し推測を試みるが、これらは現時点での私の意見に過ぎない。

では、何が起こったのか？

影響を受けた開発者全員が、これらすべてを完全に振り返るのに十分な時間を取れていないと思う。しかし、いくつか考えを述べたい。これらは複合的な要因であり、リバートされた機能ごとにその組み合わせは異なるだろう。

• 私たちは十分な仕事ができなかったのかもしれない。コードが十分ではなかったのかもしれない。私たちは学び、改善するだろう。おそらくその一部であり、他の要因だけが原因であるという印象を与えないために、ここに言及している。

• coincidences（偶然の一致）である可能性もある。私たちは非常に順調に進んでいたため、いくつかの機能に挑戦したが、それらが非常に困難であることが判明した、あるいは少なくとも時間内に完了するには困難すぎたのかもしれない。

• リバートされた機能の一部には、ベータ期間中に迅速に修正するのが困難な、重大なアーキテクチャ上の欠陥があった。しかし、さまざまなエッジケースに関わる、比較的無害な問題の長いリストもあった。過去であれば、これらの多くはもっと後になってから表面化し、その後5年間かけて少しずつ修正していっただろう。しかし、LLM支援のコードレビューにより、このような問題ははるかに速く見つかるようになり、その結果、40件もの不具合レポートのリストを突きつけられることになる。そして、それぞれが平均して3行の修正しか必要としないとしても、それぞれに対処するには固定的なオーバーヘッドがあり、時間切れとなる。影響を受けたリバートされた機能のほとんどすべては、LLM支援のコードレビューが現在ほど有用ではなかった時代に書かれたものであり、これは機能が書かれコミットされた時点以降、実質的な品質基準が引き上げられたことを意味する。LLM支援のコードレビューの能力が現在のペースで向上し続けない限り、この状況は将来の開発サイクルでは自然に解決するはずだ。

• その帰結として、少なくとも大部分においては、私の知る限り、この状況は「バイブコーディング」によるものではない。このコードは、それが可能になるずっと前に書かれたものだ。

• Vulnpocalypse（脆弱性の大発生）のため、多くのシニア開発者は、4月（PostgreSQL 19のフィーチャーフリーズ開始、およびVulnpocalypseの開始）から8月（直近のPostgreSQLセキュリティリリース）にかけて、セキュリティ問題の修正作業に忙殺されていた。そのため、ベータ期間中に通常行われる追加のレビューとテストが削減され、8月に再び引き継がれた。これが、多くの新しい問題がベータ期間のかなり遅い段階で発見され、多くのリバートが非常に遅い段階で発生した理由かもしれない。これもまた、いくつかの問題はより根本的だったが、より小さな問題の長いリストもあり、もし2ヶ月のような十分な時間があれば、これらは対処できた（十分な焦点が当てられれば、ただしVulnpocalypseは進行中であることに注意）。しかし、コミュニティは、修正を増やすためにリリースを遅らせるよりも、リリーススケジュールに固執することを好んだ。（そして、長いリストがどれほど長いかは決して分からない。）

• システムの複雑さは、一部の種類の機能を正しく実装するのを非常に複雑にしており、コードにはそれをサポートするための十分な足場がない。抽象的な例として、SQLレベルのクエリ言語機能について考えてみよう。ドメインで機能するか？複合型のドメインの場合はどうなるか？そのフィールドの1つがドメインでもある場合？そしてそのドメインにはNOT NULL制約がある場合？そして、列の1つが削除されて再追加された場合？そして、これは異なる列順序でデタッチおよびリアタッチされたテーブルパーティションの一部である場合？そして、これはセキュリティ定義関数からトリガーから呼び出されるビューの一部である場合？などだ。誰もこれを手動でテストしたり、これらのテストケースを列挙したりすることさえできない。しかし、LLM支援のファジングは、この種の問題を非常に迅速に見つけることができる。したがって、これは将来の機能開発の一部となる必要があるだろう。しかし、各異なるコンテキストの組み合わせが多くの新しい相互作用の可能性を開かないように、内部インターフェースをより堅牢にすることについても考えるべきだ。

PostgreSQLでは、「すべてがすべてと連携する」と言うのが好きだ。これは魅力の一部であり、このようなケースを構築して機能することを期待できるということだ。私はこれをまったく諦めたくない。しかし、それは機能開発に大きなペナルティを課すものであり、誰もがそれを認識する必要がある。

• 最後の点として、PostgreSQL開発コミュニティは、ある種の「実験的」ステータスを持つ機能をコミットし、その後メインツリーで成熟させる可能性をしばらく検討している。これもまた、前述の点を解決するための一つの可能性となるだろう。これは、少なくともリバートされた機能の一部にとって役立つツールになっただろうが、私たちはまだその方法を完全に理解しておらず、一部の作業はこれに関連する誤解によって損なわれた。これは取り組むべき具体的な点だ。

次に何が起こるか？

まず、個人的な視点から、直接またはオンラインでサポートと励ましを表明してくれたすべての人に感謝したい。それが最も重要なことだ。リバートされた機能の多くは、そう遠くないうちに復活すると確信している。

PostgreSQL 19は依然として素晴らしいリリースになるだろう。REPACK CONCURRENTLY、シーケンスの論理レプリケーション（それ自体が以前リバートされた機能）、そしてpg_plan_adviceによるプランナーヒントなど、いくつかの主要な項目を挙げれば、このリリースは非常に魅力的になるだろう。そして、すべての追加の精査の後、それは非常に堅牢になるだろう。

現時点では予測は難しい。数ヶ月前、PostgreSQL 20には新機能がなく、バグ修正のみになるだろうと言った。実際には、事態はさらに速く進み、PostgreSQL 19は、当時予想されていた主要機能の半数しか持たないようになったが、PostgreSQL 20のために、すでに80%完了したいくつかの素晴らしい機能がキューに入っており、残りの20%を完了させるだけだ！