共計 1805 個字符，預計需要花費 5 分鐘才能閱讀完成。
這篇文章主要介紹“怎么理解 PostgreSQL 中 session hang 情況”，在日常操作中，相信很多人在怎么理解 PostgreSQL 中 session hang 情況問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么理解 PostgreSQL 中 session hang 情況”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！
在執(zhí)行 SQL 的時候可能會碰到 session hang 的情況，這時候我們其實不知道是因為 SQL 本身執(zhí)行很慢還是因為 lock 導致 hang，因此一般情況下需要通過查詢 pg_stat_activity、pg_locks 等系統(tǒng)表來確認。除之之外，PG 還提供了通過 statement timeout 的超時機制來處理這種情況。
session 1
創(chuàng)建數(shù)據(jù)表，啟動事務，執(zhí)行查詢
testdb=# create table t_timeout(id int);
CREATE TABLE
testdb=#
testdb=# begin;
BEGIN
testdb=#
testdb=# select count(*) from t_timeout;
count
-------
0
(1 row)
testdb=# select * from pg_locks where pid = pg_backend_pid();
locktype | database | relation | page | tuple | virtualxid | transactionid | classid | ob
jid | objsubid | virtualtransaction | pid | mode | granted | fastpath
------------+----------+----------+------+-------+------------+---------------+---------+---
----+----------+--------------------+------+-----------------+---------+----------
relation | 16384 | 11645 | | | | | |
| | 3/94 | 1719 | AccessShareLock | t | t
virtualxid | | | | | 3/94 | | |
| | 3/94 | 1719 | ExclusiveLock | t | t
relation | 16384 | 286770 | | | | | |
| | 3/94 | 1719 | AccessShareLock | t | f
(3 rows)
testdb=#session 2
執(zhí)行 alter table 命令，hang 住
testdb=# -- session 2
testdb=# alter table t_timeout add column c1 int;
-- 掛起 設置 50ms 超時，SQL 返回超時錯誤
testdb=# begin;
BEGIN
testdb=# SET statement_timeout = 50;
testdb=# alter table t_timeout add column c1 int;
ERROR: canceling statement due to statement timeout
testdb=#不過這樣的設置，需要 DBA 對 SQL 的執(zhí)行時長有初步的估算，比如增加列操作，正常應在 10ms 內(nèi)返回，那設置超時 50ms 是沒有問題，但對于 vacuum full 這樣的操作來說，設置為 50ms 就很不合適了。
testdb=# SET statement_timeout = 50;
testdb=# vacuum full;
ERROR: canceling statement due to statement timeout
testdb=#也就是說，設置超時會存在誤傷，需謹慎使用。
到此，關于“怎么理解 PostgreSQL 中 session hang 情況”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注丸趣 TV 網(wǎng)站，丸趣 TV 小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
