Важен порядок элементов в параметре типа список в SELECT чтобы избежать дедлока?

Question

[vi0]

Задаете ли вы порядок параметра типа список чтобы избежать дедлоков в выборке с блокировкой? Например в постгрес.
Допускаете ли вы разный порядок в разных сессиях?

Сессия 1:

select * from table1 
where code in (1, 2, 3)
for update

Сессия 2:

select * from table1 
where code in (3, 2, 1) 
for update

Comments

[historydev]

Разве они сами не решают проблему дедлоков в параллельных запросах?
Странно звучит..

[Everything_is_bad]

1. почему вдруг тут будет дедлок?
2. почему бы этот простой пример не проверить самому?

[Akina]

Не влияет. Если показанный набор запросов способен привести к дедлоку, то никакая сортировка не сможет обнулить вероятность такого дедлока. Или хотя бы значимо понизить вероятность его возникновения.
Ну хотя бы потому, что сервер может принять решение сначала отсортировать список, и только потом выполнять запрос. Имеет полное право, кстати, ибо язык-то декларативный - и если поле code индексировано и/или список длинный, то вероятность проведения такой сортировки гораздо выше.
Так что чем заниматься онанизмом с сортировкой списка, лучше использовать соответствующий уровень изоляции на сервере и/или обработку ошибок на клиенте.

Answer 1

[Сергей Соловьев]

Да, в этом случае может быть дедлок. Общая рекомендация - сортировать такие списки переменных (еще и = ANY или in values).

Comments

[Everything_is_bad]

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

[Сергей Соловьев]

Everything_is_bad, по одной, если мы говорим о Postgres. если нужна блокировка, то он создает узел плана, который накладывает блокировку.