ShareLock и ExclusiveLock с базой данных postgres

Question

Я проверял блокировку в журналах одного приложения, которое работает в 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

Я думаю, что этоне нормальная блокировка, есть ли способ исправить такую ​​блокировку?

Answer 1

Я не знаю, что вы считаете «нормальным» типом блокировки.Это обычный тип блокировки, которую вы получаете, когда несколько транзакций пытаются обновить (или до select for update) в одном и том же кортеже в одно и то же время.

Но почему транзакции, которые принимают эти блокировки, держатся заих хотя бы на секунду?Являются ли транзакции по своей сути медленными или они отвлекаются?