pg_upgradeは、PostgreSQLのメジャーバージョンアップを支援する、PostgreSQL付属のツール(contribモジュール)です。PostgreSQLのデータファイル(DBクラスタ)は、メジャーバージョン間の互換性がありません。このため、スキーマやデータのダンプ・リストアなどにより、バージョンアップ後のDBクラスタを作り直す必要があります。pg_upgradeは、このダンプ・リストア作業をせずに、既存のDBクラスタからバージョンアップ後のDBクラスタを作ってくれます。また、移行時間の短縮にも効果があるそうです。
一方、ツールの特性上、PostgreSQL本体側の改良に合わせて常に手が入るという、サグラダ・ファミリアや横浜駅のような宿命を背負っています(サグラダ・ファミリアは、2026年に完成予定と発表されましたね)。このような宿命のためか、思い出したかのようにアップグレードに失敗するバグを出すこともあり、なかなか安定しないなぁというイメージを持っています。悲しいことに、9.3.5ではリリースノート筆頭のバグ修正となっていました。
とは言え、便利なツールなので、ぜひ使ってみたい。ということで、pg_upgradeの開発具合をソースコードのコミット数という側面から見てみました。コメント文の修正といったような実際の動作には全く影響がないものから、重大なバグの修正に関わるものまで全て一緒くたに扱っていたり、実はあまり意味がない分析かもしれません。PostgreSQLのメジャーバージョンブランチは、基本的にはバグ修正のコミットだと思っているのですが、改善系のコミットも多少混じっているかもしれません。。本当に一側面からのアプローチということで、ご承知くださればと。
各メジャーバージョンのブランチが切られてからのコミット累計数です。x.y.0リリース前のコミットは、β版やRC版に対するものです。8.4以前がないのは、pg_upgradeが付属したのが9.0からであるためです。9.4はまだβ版ですので、参考ということで。また、集計したのは2014/08の中頃です。
9.3は、β版の開発途中でコミット数の伸びが緩やかになっていますが、2014/02以降、改めてコミット数が伸びています。9.0〜9.2は、x.y.0リリース前までのコミット数の伸びが高く、リリース後の伸びは緩やかです。2013年の初夏以降落ち着いていましたが、特に9.2は、やはり2014/02以降コミット数が伸びています。
と、思わずバグ成長曲線的な見方をしてしまいましたが、一つ気づいたことが。
2013/08〜2014/02ぐらいの間、pg_upgradeの開発が停滞していたのでは...
9.2まではある程度枯れてそうだけど、9.3は微妙な感じですね... そろそろ9.4がリリースというこのご時世、9.2にバージョンアップというのもないですし。(オチなし)
ホーム
/
PostgreSQL
/
0 件のコメント:
コメントを投稿