■排他ロックの特徴を簡単にまとめてみた

排他ロック(Access Exclusive Lock)は 業務処理を停めてしまうので要注意

主なものを下記に記載する。
①VACUUM FULL/CLUSTER
テーブルの物理圧縮/物理再編成
物理サイズの圧縮をしたい時によく使う
テーブルに排他ロックを取る処理

②REINDEX
インデックスの再作成
断片化したインデックスのリフレッシュに使う
インデックスに排他ロックを取る処理
システムカタログにロックを取るため、プランナー処理でロック待ちになる

他にもいろいろあるけど、そのうち加筆します。

■VACUUMの特徴についてまとめてみた

[VACUUMの動き]
最初に実行されるVACUUMはテーブルのフルスキャンを行いVisibility Mapを作成する。
2回目以降のVACUUMは部分スキャンを行い、Visibility Mapを最新化する。
Visibility Mapは更新処理(UPDATE/DELETE)で更新される。
以降は、Visibility Mapを見て必要なところだけVACUUMを行い、回収領域はFreeSpaceMapに登録する。

[実行結果]
テーブルやインデックスデータのread/write負荷が多少なりともかかる。
Visibility Mapの最新化に伴うIndex-Only-Scan※の性能が向上する。
※Index-Only-ScanはVisibility Mapのビットが立って入れば、テーブルは見ない。
→Select文の検索項目がインデックスのキーのみの場合、テーブルデータへのアクセスを省略してくれる。Index-Only-ScanはVer9.2からサポート。
ページ内のデータ変更が実施されるため、ガベージ回収に伴いWALが出力される。

こんな感じです。

■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文については確かにロックによる待ちが発生。

以上。