...
| Code Block |
|---|
SELECT relation, transaction, pid, mode, granted, relname FROM pg_locks INNER JOIN pg_stat_user_tables ON pg_locks.relation = pg_stat_user_tables.relid WHERE pg_locks.pid='[pid]'; |
...
For example, this is an output from the above query:
| Code Block |
|---|
relation | transaction | pid | mode | granted | relname relname ----------+-------------+------+-----------------+---------+---------------------- 18034 | | 4909 | AccessShareLock | t | group2groupcache 18113 | | 4909 | AccessShareLock | t | metadatavalue 18046 | | 4909 | AccessShareLock | t | item 18008 | | 4909 | AccessShareLock | t | eperson 18248 | | 4909 | AccessShareLock | t | handle 18235 | | 4909 | AccessShareLock | t | epersongroup2eperson |
So process 4909 has AccessShareLocks on 6 tables, and these 6 tables should help us identify where to look for the bug. In this case it is particularly unclear, but a process which uses groups, epersons, items handles and metadata is probably a deposit process.
...
| Code Block |
|---|
/usr/bin/test `/usr/bin/pgrep -f 'idle in transaction' | \ /usr/bin/wc -l ` -gt 20 && /usr/bin/pkill -o -f 'idle in transaction' |
...
| Code Block |
|---|
/bin/test `/usr/local/bin/pgrep -f '127.0.0.1' | \ /usr/bin/wc -l ` -gt 20 && /usr/local/bin/pkill -n -f '127.0.0.1' |
...