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