[pgsql-jp: 26103] Re: コンカレントバキュームについて
Jun Kitamura
kitamura @ zoozee.jp
2002年 5月 24日 (金) 03:19:29 JST
北村@zoozee です。
杉田さん、色々とありがとうございます。
> ;;; PostgreSQL は、 2^31トランザクションまで実行可能(vacuum をかけない場合)と
> ;;; いうことですね?
>
> 約 20 億トランザクションを越えて連続実行しない内に VACUUM をかけましょうとい
> う運用ですね。カレントトランザクションより約 15 億古いトランザクションが発生し
> たあたりで VACUUM をかければ、さらに 5 億のトランザクションが発生する内には
> VACUUM が終るだろうと。
>
> ;;; ちょっと微妙に勘違いしてるかもしれないのですが、22億(2^31より大きい)レコー
(略)
>
> ;;; 22億ループを begin,commit で囲んでも、「22億(+1)トランザクション」ですよ
> ;;; ね?(+1)は begin,commit分です。
>
> begin〜commit で 1 です。
うーむ・・・。ということは、22億レコードを 1行1行 更新していく場合でも、
begin-commit で囲んであれば、wraparround 防止のために途中で vacuum をかけ
る必要は無い、ということなんですね。
begin-commmit の中の update は暗黙の begin-commit がネストされており、見
た目(アプリケーションレベルから見れば) 1トランザクションだけど、
PostgreSQL 内で XID はインクリメントされており、22億だと wraparound が発
生するのでは・・と思っていたのです。
私が トランザクション = XID と捉えて、1トランザクションとか表現しいている
のが間違いなのかな?という気もしないでもないですが・・・。
というのも、5レコードくらいで試したところ、begin-commit で囲まれた 1行1行
の update では、xmax の値が変化していたためです(その他 xmin,cmax,cmin も
変化してましたが)。xmax,xmin,cmax,cmin の理解やソースハッキングは分散トラ
ンザクション分科会の方でも行なう予定(ですよね?>永安さん)なので、改めて
レポートできればと思います。
重ね重ね、ありがとうございます。
# トランザクション処理に興味のある方、JPUG の分散トランザクション分科会へ
# どうぞ(と宣伝してみたりする)
pgsql-jp メーリングリストの案内