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

sugita @ sra.co.jp sugita @ sra.co.jp
2003年 7月 5日 (土) 03:06:28 JST


  杉田です。

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

;;;  あれから更にテストをしたのですが、結果として移行したDBのデータ自体
;;; には、問題が無いことが分かりました。結果としては、一緒に動かしていた
;;; WebApplicationのコネクションプール機能に原因が有るようです。その結果
;;; 再現方法も判明しました。
;;; 
;;;  構成としては、
;;; 
;;; <DB1>
;;; UserName = test_user1
;;; DBName   = test_db1
;;; 
;;; <DB2>
;;; UserName = test_user2
;;; DBName   = test_db2
;;; 
;;;  と2個のDBとユーザーを作成して、DB1に先日のデータ書き込みを行った後に、
;;; 削除してDB2に対してJDBCで接続を行い
;;; 
;;; BEGIN
;;; SET TRANSACTION ISOLATION LEVEL READ COMMITTED
;;; 
;;;  を実行後に接続を開きっぱなしにします。
;;;  この状態で
;;; 
;;; vacuumdb -a -f
;;; 
;;;  を行っても領域が開放されません。しかし、DB2への接続を切った後に、バキュー
;;; ムを行うと領域が開放されます。

  psql でのクエリー発行でも再現しました。SET TRANSACTION ISOLATION LEVEL READ
COMMITTED なしでも再現します。

  vacuumdb -a -f でなく、DB1 で VACUUM FULL でも再現します。VERBOSE を付けてみ
ると以下のようになります。

====  DB2 が開きっぱなしで、DB1 で VACUUM FULL VERBOSE
INFO:  --Relation public.statementtest--
INFO:  Pages 1770: Changed 0, reaped 0, Empty 0, New 0; Tup 200000: Vac 0, Keep/VTL 200000/0, UnUsed 0, MinLen 68, MaxLen 68; Re-using: Free/Avail. Space 64440/756; EndEmpty/Avail. Pages 0/1.
        CPU 0.10s/0.03u sec elapsed 0.12 sec.
INFO:  Rel statementtest: Pages: 1770 --> 1770; Tuple(s) moved: 0.

====  DB2 でのトランザクションをコミットし、DB1 でVACUUM FULL VERBOSE
INFO:  --Relation public.statementtest--
INFO:  Pages 1770: Changed 0, reaped 1770, Empty 0, New 0; Tup 0: Vac 200000, Keep/VTL 0/0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 13664440/0; EndEmpty/Avail. Pages 1770/0.
        CPU 0.11s/0.04u sec elapsed 0.14 sec.
INFO:  Rel statementtest: Pages: 1770 --> 0.

  7.4devel でも同じ結果でした。

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

  私には分かりません。複数のデータベースに同時に接続できる訳ではないので、この
振舞を仕様とするのはおかしいという気がします。


Kenji Sugita                                      




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