[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 メーリングリストの案内