■pg_xlogdumpを利用してみる

pg_xlogdumpはバイナリ形式のファイルであるWALファイルをテキスト形式で可視化するツールであり、contribモジュールの追加で利用できる。とのこと。


１．contribモジュールのインストール確認
    $ rpm -aq | grep postgres
　　→contribパッケージがインストールされていることを確認。いつ入れたのか分らないが導入していたらしい。

２．WALファイルを確認
    $ cd $PGDATA/xlog
    $ ls -l

   









３．pg_xlogdumpの利用
　　$ pg_xlogdump 000000010000000000000006

何やら色々表示されたが、テキスト形式で可視化することはできた。

■VACUUM FULLを実行してみた

vacuum fullを実行したことがほとんどないので、動きを確認

マニュアルとか見ると下記のような特徴があるらしい。
・不要領域を回収
・実行中は読み書き不可
・中間ファイルを作成し、新たなタプルID（TID）を作成する
上記の上２つを確認してみる

■vacuum full前
①テスト用テーブル(test3)の作成
testdb=# create table test3 as select generate_series(1,999999) col1;

②いくつかdelete文、update文を実施
testdb=# delete from test3 where col1=XXXX;
testdb=# update test3 set col1=XXXXXXXXX where col1=XXXX;
→テーブル件数は99701


③サイズの確認



④不要領域の確認

⑤select 文の結果

⑥baseのサイズ
[postgres@11:00:47 ~/9.6/data {8}]$ du -sk base
250016  base

■vacuum full実行時
①vacuum full実行
testdb=# vacuum full verbose;
→test3テーブルだけでなく、ついでに全テーブルを対象とする


②select 文の結果
→vacuum full完了まで待ち
　→割とあっという間に処理が進んだので、チョイ待機かなぐらいしか感じませんでした。
testdb=# select count(*) from test3;
 count
--------
 999701
(1 行)


③ディスクサイズの推移

 
→サイズが一時的に282592に増えたことが分かります。

■vacuum full後
①サイズの確認

→減っているね



②不要領域の確認

→dead_tupが0に。



③ディスクサイズ
[postgres@11:07:39 ~/9.6/data {10}]$ du -sk base
248760  base
→baseの容量も減っているね

以上でおしまい。

■select ~ for update;の挙動を確かめてみた
select文で選択したレコードに対して排他ロックをかけるのだが、実際に試したことがないので、検証してみた。

排他ロックとは、一方が操作している間、もう一方の「update,delete,select for update」とかを実行しようとするとブロックされること。
以下はブロックされる
update
delete
insert
for update
for share

・トランザクションA

・トランザクションB

select文はOKなんだね。
ただし、delete文については確かにロックによる待ちが発生。

以上。