ShareLock 和 ExclusiveLock 与 postgres 数据库答案

【问题标题】：ShareLock and ExclusiveLock with postgres databaseShareLock 和 ExclusiveLock 与 postgres 数据库
【发布时间】：2018-11-13 04:28:15
【问题描述】：

我正在检查一个在 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 ruby-on-rails postgresql auto-increment delayed-job

【解决方案1】：

我不知道您认为“正常”的锁是什么。这是当多个事务尝试同时在同一个元组上更新（或更新到select for update）时获得的正常类型的锁。

但是为什么占用这些锁的事务至少会持有一秒钟呢？交易本身是缓慢的，还是分心？

【讨论】：

谢谢@jjanes，这个 increment_counter 方法会有问题吗？因为在一个地方我可以看到它花了很多时间来更新，因为在我的应用程序中这种增量发生了很多次
对不起，我不知道 increment_counter 方法是什么。您的描述和日志文件的 sn-ps 并不能真正解释您要做什么。
increment_counter函数会自动加1
嗨@jjanes，关于如何解决“当多个事务尝试同时更新同一个元组时你得到的普通锁”的任何想法？在我的例子中，我们在表 1 中运行触发器以使用元组更新“报告”表 2，因此，如果我们为表 2 中的同一个元组更新表 1 中的多个记录，则会出现锁定错误。非常感谢您的关注和参与。
@leompeters 该锁仅在事务期间持有。从获得锁到事务提交的每一步都尽可能快地完成，或者重新排序缓慢的步骤，以便它们在可能的情况下在获得锁之前发生。在不知道这些步骤是什么的情况下，很难提供具体的建议。或者也许重新考虑您的报告表系统的设计。它本质上会限制并发性。