postgresql “idle in transaction” with all locks granted

谁说我不能喝 提交于 2019-12-10 16:39:08

问题


A very simple delete (by key) on a small table (700 rows) every now and then stays "idle in transaction" for minutes (takes milliseconds usually) even though all the locks are marked as "granted".

What can I do to pinpoint what causes it? I'm using this select:

  SELECT a.datname,
     c.relname,
     l.transactionid,
     l.mode,
     l.GRANTED,
     a.usename,
     a.waiting,
     a.query, 
     a.query_start,
     age(now(), a.query_start) AS "age", 
     a.pid 
FROM  pg_stat_activity a
 JOIN pg_locks         l ON l.pid = a.pid
 JOIN pg_class         c ON c.oid = l.relation
ORDER BY a.query_start;

which shows a lot of "RowExclusiveLock"s but all are granted... so I don't see what is causing this spikes of delays.


回答1:


This is a problem of the application server.

Sessions are in state "idle in transaction" when the application does not end the transaction with COMMIT or ROLLBACK. This is to be considered a bug in the application.

The locks remain (and are of course granted, otherwise the session could not be idle) until the transaction ends.

From PostgreSQL 9.6 on, you can set the parameter idle_in_transaction_session_timeout to terminate such transactions automatically with a ROLLBACK, but that is a band-aid to avoid problems on the database rather than a solution.



来源:https://stackoverflow.com/questions/44908010/postgresql-idle-in-transaction-with-all-locks-granted

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!