TRUNCATE應該是快速的,除非它無法獲取對象的AccessExclusiveLock,在這種情況下,它可以無限期地等待。
上面提到的應該顯示阻塞會話的查詢沒有標識對象級鎖,這是TRUNCATE獲取的鎖的種類。
它在這裏提到的,這是我想在那裏這個查詢摘自:
https://wiki.postgresql.org/wiki/Lock_Monitoring
下面的查詢可能會有所幫助,看看哪些進程正在阻止 SQL語句(這些只能找到行級鎖,而不是對象級鎖)。
下面是與PG 9問題的演示。1:
會話#1:
test=> create table footable(id int);
CREATE TABLE
test=> begin;
BEGIN
test=> insert into footable values(1);
INSERT 0 1
test=>
(左未提交)
會話#2
test=> truncate table footable;
(由會話#1阻擋)
會話#3
test=> SELECT bl.pid AS blocked_pid,
a.usename AS blocked_user,
kl.pid AS blocking_pid,
ka.usename AS blocking_user,
a.current_query AS blocked_statement
FROM pg_catalog.pg_locks bl
JOIN pg_catalog.pg_stat_activity a ON a.procpid = bl.pid
JOIN pg_catalog.pg_locks kl ON kl.transactionid = bl.transactionid AND kl.pid != bl.pid
JOIN pg_catalog.pg_stat_activity ka ON ka.procpid = kl.pid
WHERE NOT bl.GRANTED;
blocked_pid | blocked_user | blocking_pid | blocking_user | blocked_statement
-------------+--------------+--------------+---------------+-------------------
(0 rows)
根據這個查詢,沒有會話被阻塞,所以它顯然是錯誤的。
我建議你試試這個其他查詢,在這裏: https://wiki.postgresql.org/wiki/Find_Locks
在這個例子中,產生這樣的輸出:
-[ RECORD 1 ]------+--------------------
locktype | relation
database | 113270
relation | 2660062
page |
tuple |
virtualxid |
transactionid |
classid |
objid |
objsubid |
virtualtransaction | 5/2548
pid | 4419
mode | AccessExclusiveLock
granted | f
virtualtransaction | 4/2031
pid | 31775
mode | RowExclusiveLock
granted | t