我正在检查在heroku中运行的一个应用程序的日志中的锁定，它显示了来自delayed_jobs和increment_counter的大量锁定，而且这次我也遇到了很多超时
sql_error_code = 00000 LOG: process 129728 still waiting for ShareLock on
transaction 1296511670 after 1000.149 ms
2017-06-02T16:24:58+00:00 app
postgres.129728 - - [TEST] [7-2] sql_error_code = 00000 DETAIL: Process
holding the lock: 129457. Wait queue: 129728.
02 Jun 2017 20:24:58.338198 <134>1 2017-06-02T16:24:58+00:00 app
postgres.129728 - - [TEST] [7-3] sql_error_code = 00000 CONTEXT: while
locking tuple (75,2) in relation "delayed_jobs"
LOG: process 129429 acquired ExclusiveLock on tuple (878044,83) of relation
16953 of database 16385 after 3220.356 ms
02 Jun 2017 20:24:58.338591 <134>1 2017-06-02T16:24:58+00:00 app
postgres.129728 - - [TEST] [7-4] sql_error_code = 00000 STATEMENT: UPDATE
"delayed_jobs" SET locked_at = '2017-06-02 16:24:57.033870', locked_by =
'host:a96aff72dae123123e pid:4' WHERE id IN (SELECT id FROM
"delayed_jobs" WHERE ((run_at <= '2017-06-02 16:24:57.032776' AND (locked_at
IS NULL OR locked_at < '2017-06-02 12:24:57.032817') OR locked_by =
'host:a96aff72dae123123e pid:4') AND failed_at IS NULL)
ORDER BY priority ASC, run_at ASC LIMIT 1 FOR UPDATE) RETURNING *
sql_error_code = 00000 DETAIL: Process holding the lock: 129495. Wait queue:
3276.
02 Jun 2017 20:25:09.279197 <134>1 2017-06-02T16:25:08+00:00 app
postgres.3276
- - [TEST] [7-3] sql_error_code = 00000 CONTEXT: while updating tuple
(878034,120) in relation "messages"
02 Jun 2017 20:25:09.279248 <134>1 2017-06-02T16:25:08+00:00 app
postgres.3276
- - [TEST] [7-4] sql_error_code = 00000
STATEMENT: UPDATE "messages" SET
"item_no" = COALESCE("item_no", 0) + 1 WHERE "messages"."id" =
48290879
我认为这不是普通的锁，有什么办法可以修复这种锁吗？
最佳答案
我不知道您认为“正常”的锁是什么。这是当多个事务尝试同时更新(或选择更新)同一个元组时获得的正常类型的锁定。
但是为什么获取这些锁的事务至少要保留一秒钟呢？交易本质上是缓慢的，还是他们分散了注意力？
关于sql - postgres 数据库的 ShareLock 和 ExclusiveLock，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50670370/