[pgsql-jp: 30429] Re: VACUUMされない?

sugita @ sra.co.jp sugita @ sra.co.jp
2003年 7月 11日 (金) 21:05:11 JST


  杉田です。

From: 小野 心 <shin-ono @ mdsnet.co.jp>
Subject: [pgsql-jp: 30386] Re: VACUUMされない?
Date: Fri, 4 Jul 2003 17:42:29 +0900

;;;  気になるのですが、トランザクションが関係して、異なるDB/Userで接続している
;;; のに、影響をおよぼすのは、仕様なのでしょうか?

  以下のように仕様ではありませんが、修正される可能性はなさそうです。

    From: Tom Lane <tgl @ sss.pgh.pa.us>
    To: Tatsuo Ishii <t-ishii @ sra.co.jp>
    Cc: pgsql-hackers @ postgresql.org
    Date: Sat, 05 Jul 2003 21:51:16 -0400
    >From sugita  Sun Jul  6 10:51:36 2003
    Comments: In-reply-to Tatsuo Ishii <t-ishii @ sra.co.jp>  message dated "Sun, 06 Jul 2003 00:00:39 +0900"

    Tatsuo Ishii <t-ishii @ sra.co.jp> writes:
    > but after that it checks proc->xmin, where xmin may not be running on
    > the same database. I wonder if this is correct or not. Maybe we should
    > make sure that xmin is running on the same database

    How would you know?  (At the time you are looking, it's quite possible
    the other guy's xmin doesn't exist anymore.)  In any case you can't just
    arbitrarily ignore the other guy's xmin, since it's a proxy for
    subsequent transaction IDs as well, and those might be in any database.

    It might be possible to do something by having each proc store both
    a "local" and a "global" xmin computed as of its current xid start,
    but I haven't really thought through the details.  In any case, that
    would be extra bookkeeping needed during every transaction start,
    so I'd want to see proof of a generally-useful improvement in return.

    On the whole I'm against changing this logic ... I think the odds
    of breaking something are high, and the odds of making a useful
    improvement low ...

			    regards, tom lane
			


Kenji Sugita                                      
Senior Manager                     Tel: +81-45-948-1622
Open Source Solution Division      Fax: +81-45-948-1620
Software Research Associates, Inc. 



pgsql-jp メーリングリストの案内