[pgsql-jp: 40772] 【質問】baseフォルダ配下のファイル削除について

m.murakami m.murakami @ lightcafe.co.jp
2011年 5月 13日 (金) 20:44:34 JST


はじめまして。村上と申します。
以下、長文となってしまいますが、ご容赦願います。

PostgreSQLを使用していて、base配下に作成されているデータ(ファイル)の
削除について確認があります。

OS:linux
Postgreバージョン:8.3.5

■問題点
オブジェクトの削除(Drop tableなど)は正常に完了して
vacuumフルを実行しましたが、base配下に作成されているデータ(ファイル)が
削除されません。(27GBほど)

■実行した内容
・50GB中、30GB弱のデータが保存されているディレクトリ(NFS)に、合計50GB以上の
 データを作成。(5/11 13:00以降に実施)
 →サイズが足りないと途中でエラーとなる。
  クライアントのDBユーザ(例:user)にてインサート実施した。

・サイズが足りなかったせいか、あるテーブル、インデックスがロック状態となる

・実行中のセッションがないことを確認し、DBインスタンスを再起動し、ロック状態
を解除。

・元々あった30GBのデータも、データ移行テストで不要になったため、DBユーザ
(user)にて
 すべてのオブジェクトを削除(Drop table, indexなど)し、vacuumフルを実行。
  →使用サイズが50GBから27GBになった(5/11と5/13に実施)
 ★本来であれば、ここでpg_catalogなど管理系のデータファイル以外は削除される
認識です。
    (DBユーザ(user)が作成した、baseディレクトリ配下のデータファイルが削除さ
れる認識)

・テーブルのなどのオブジェクト、ロックテーブル、セッションがないことを確認。

・DBユーザ側から、DB管理者(例:admin)でvacummフルとreindexをかけて、データ
ファイルが
 削除されないか打診があり、上記を実行。正常終了。(5/13 17:31に実施)
  →27GBから使用サイズは変わらず。

■教えていただきたいこと
 1.上記を実行したあと、下記のファイルが残っていることを確認しました。
  5/11にインサートされたデータが残っているようにみえますが、
 これらをvacuum以外で削除する方法ございますでしょうか?(DBインスタンスの再
作成にならないよう)
 (開発環境なのでDBインスタンス停止は可能です)

 2.このように、ファイルが残ってしまうような事象がありますでしょうか?


■base配下のサイズ使用量
4.3M    1
4.3M    11510
4.4M    11511
27G     16384
4.0K    pgsql_tmp

■base/16384ディレクトリ配下のファイル
==============================================
 サイズ   日時   ファイル名(数字は例です)
1073741824  5月 11 13:21 0000
1073741824  5月 11 13:21 0000.1
1066500096  5月 11 13:24 0000.10
         0  5月 11 13:24 0000.11
         0  5月 11 13:24 0000.12
 603185152  5月 11 13:25 0000.13
1073741824  5月 11 13:21 0000.2
1073741824  5月 11 13:22 0000.3
1073741824  5月 11 13:22 0000.4
1073741824  5月 11 13:23 0000.5
1073741824  5月 11 13:23 0000.6
1073741824  5月 11 13:23 0000.7
1073741824  5月 11 13:24 0000.8
1073741824  5月 11 13:24 0000.9
         0  5月 11 13:18 00001
      8192  5月 11 13:18 00003
         0  5月 11 13:37 00004
         0  5月 11 13:37 00007
      8192  5月 11 13:37 00009
1073741824  5月 11 14:21 00008
1073741824  5月 11 14:22 00008.1
1073741824  5月 11 14:35 00008.10
1073741824  5月 11 14:36 00008.11
1073741824  5月 11 14:37 00008.12
1073741824  5月 11 14:39 00008.13
1073741824  5月 11 14:40 00008.14
 962134016  5月 11 14:49 00008.15
1073741824  5月 11 14:24 00008.2
1073741824  5月 11 14:25 00008.3
1073741824  5月 11 14:26 00008.4
1073741824  5月 11 14:28 00008.5
1073741824  5月 11 14:29 00008.6
1073741824  5月 11 14:31 00008.7
1073741824  5月 11 14:32 00008.8
1073741824  5月 11 14:33 00008.9
         0  5月 11 14:17 00006
      8192  5月 11 14:17 00005
     16384  5月 13 17:35 1111
     40960  5月 13 17:35 1112
      8192  5月 13 17:31 1113
      8192  5月 13 17:31 1114
     16384  5月 13 17:31 1115
      8192  5月 13 17:31 1116
      8192  5月 13 17:31 1117
      8192  5月 13 17:31 1118
      8192  5月 13 17:31 1119
      8192  5月 13 17:31 1120
      8192  5月 13 17:31 1121
     16384  5月 13 17:31 1122
     16384  5月 13 17:31 1123
     32768  5月 13 17:31 1124
     16384  5月 13 17:31 1125
     16384  5月 13 17:31 1126
     16384  5月 13 17:31 1127
     16384  5月 13 17:31 1128
     16384  5月 13 17:31 1129
         4  9月 10  2009 PG_VERSION
     93800  5月 13 17:35 pg_internal.init
================================================

以上、よろしくお願い致します。




__________ Information from ESET NOD32 Antivirus, version of virus signature
database 6118 (20110513) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com




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