Да, точно в этом дело. Т.е. реально есть возможность что в одно и тоже время в разных потоках одни и теже tx строки в базе пытаются обновляться. Вот только кто именно придумал тут делать DeadLock. Мне как раз ничего лочить не надо, обновите по принципу кто последний тот и прав.
Но это уже скорее всего не алхимия. Это или сама PostgreSQL не дает такие длительные апдейты делать, или же psycopg2.
Да, точно в этом дело. Т.е. реально есть возможность что в одно и тоже время в разных потоках одни и теже tx строки в базе пытаются обновляться. Вот только кто именно придумал тут делать DeadLock. Мне как раз ничего лочить не надо, обновите по принципу кто последний тот и прав.
Но это уже скорее всего не алхимия. Это или сама PostgreSQL не дает такие длительные апдейты делать, или же psycopg2.
В моем случае мне можно этот метод просто аннотировать как @synchronized, т..е. просто сделать чтобы такой ситуации и не было. В этом моем случае мне просто не важно что если два запроса пройдут не параллельно, а чуть подождут в очереди.
Ну а если нужна реально параллельность, то надо просто избегать туплов в postgresql в таких запросах. Т.е. заменить этот один запрос с IN () на балк запросы на апдейт.