Postgresql
pg_class 鎖的原因除了 DROP TABLE
我確實在 PostgreSQL 11 上遇到過以下情況:
- 帶有未知語句的事務會
ACCESS SHARE
在pg_class
.- 另一個連接想要執行
DROP TABLE
,導致ACCESS EXCLUSIVE
鎖定pg_class
。此操作被阻止,因為操作 #1 仍然持有鎖。- 此後,任何與數據庫的新連接都將永遠等待,因為它也需要訪問
pg_class
。繼續進行的唯一方法是終止操作#1 或#2。
雖然我可以通過手動鎖定表來重現這種情況,但我找不到導致
pg_class
操作 #1 鎖定的原因的解釋。也就是說,pg_stats_activity
僅將 a 顯示SELECT
為目前查詢,即idle in transaction
. 但是,我懷疑這不是創建鎖的語句。因此,非常感謝任何有關可能導致
ACCESS SHARE
鎖定異常的pg_class
輸入。DROP TABLE
更新atm 也不清楚為什麼
DROP TABLE
要鎖定pg_class
。
這種情況是由一個長時間執行的事務引起的,該事務
SELECT
首先執行pg_class
。這會導致ACCESS SHARE
鎖定。通常,
DROP TABLE
不會導致ACCESS EXCLUSIVE
鎖定,但在這種情況下,會載入一個使用更多限制性鎖定的 PG 擴展。目前情況的解決方案是將長期執行的事務移出
SELECT
。pg_class