[pgsql-jp: 25834] Re: コンカレントバキュームについて

[Jun Kitamura]

北村＠zoozee です。

>   [pgsql-jp: 25827] にも書いたとおり、昨日InterBaseのポーティングを
> された小山海平さんとお話をしていた時に、「PostgreSQLのコンカレント
> バキュームってどういう方法で実現されているのでしょうね？」という話
> になりました。
> 
> 　「データベースが稼動中の状態で、コンカレントバキュームを行うとル
> ープしてしまうのではないかと」いう話でしたが、私はPostgreSQLの内部
> 構造を良く知らないので答えられませんでした^^;;
> 
>   私も興味を持ったので、じっくりしらべてみたいと思うのですが、どこ
> かに良い資料は無いでしょうか？
> 
> 　当然、PostgreSQL7.2の英文ドキュメントをじっくり読むのが一番良い
> とはわかっているのですが^^;

PostgreSQL 7.2.1 Administrator's Guide の 8.2. Routine Vacuuming がそれで
すね。

VACUUM 中でも SELECT,UPDATE等が可能ということから、MVCC の恩恵を受けてい
ると想像できるのですが、トランザクションID(XID)の食いつぶしにどう対処した
か、が問題ですね。(どう対処するか、じゃないところが情けないですが・・・)
(PostgreSQL のトランザクション処理では、現在のトランザクションID(XID)より
低い XID 値を持つ行(古い行)は可視、高い値(新しい行(別トランザクションで更
新/削除中など))は不可視なので、最大値になった後 0に戻ってしまい(食いつぶ
し)、ほとんど全ての行が不可視になってしまう。旧来の VACUUM ではテーブルに
ロックをかけて XID を整理していた(と思う))。

新しく、特殊な XID(BootstrapXID=1と FrozenXID=2)を導入し、対処しているよ
うです。VACUUM が実行されると現在の XID より 1 billion (10億(*))以前のも
のは、 XIDが 2 (FrozenXID)になります。
そのため、XID が食いつぶされても(たぶん) 3 から始まって、FrozenXID(=2) と
BootstrapXID(=1) は 可視 なのです。
((*)英国では billion は 兆 ということですが、1兆ってのは無いですよね)。

明示的に XID を FrozenXID(=2) にする(現在のトランザクションより前のトラン
ザクションを XID=2 にする)ためには、 VACUUM FREEZE を行なえとありますが、
一日一回 VACUUM すれば問題無いような。

今まで VACUUM を領域開放に使っていたとしたならば、VACUUM FULL をする必要
があるのですが、どうせまた UPDATE や DELETE なので領域が広がるので意味な
いですね。
今度の VACUUM は、使われなくなった領域を再利用するのでテーブルのサイズが
適切な大きさに保たれるようです。(もちろん利用内容によりますが)。

# 先日重い腰を上げて 7.2 を入れたのですがまだ検証段階です。
# かなり便利になっているのですが、以前と挙動が違う部分もあり・・・。