on transaction 25241071; blocked by process 2377527.
Process 2377527 waits for ShareLock on transaction 25241069; blocked by process 2377508.
Process 2377508: UPDATE bfg.user SET user_bonus=user_bonus-1 WHERE user_bonus >= 1
Process 2377527: UPDATE bfg.user SET user_energy=user_energy+1 WHERE user_energy < 10
Читал что использовать FOR UPDATE/FOR NO KEY UPDATE, но не совсем понял как, повставлял в запросы где берутся эти данные, но ничего не помогает.
Это вы вовремя зашли. Прямо про это дискуссия. В следующим за вашым сообщением — ссылка на объяснение того, как оно можэт падать и как от этого поможэт for update, в начале дискуссии по ссылкам — запрос, в котором это нормально написано.
А зачем бороться-то? Часто случается / производительность не устраивает? Если да — нужно разбираться, почему (да и когда / как часто) они происходят, а потом менять запросы или добавлять индексы.
Ну, раз в 5-6 часов я заметил эту тенденцию. А не нравиться потому-что когда это случается у меня бот выключается на пару, а мне такое не надо так как таймеры которые в коде прописаны сбрасываются
Так ошибку в коде бота надо исправить — чтобы он не выключался, а обрабатывал deadlocks (и другие исключения) нормально, для начала. А обходить ошибки в приложениях путём внесения изменений в БД / запросы — это какой-то не тот метод. ;)
Так вроде ловит, ошибки ловит, как только ловит deadlocks сразу вырубается, могу показать обработчик, очень простой в пару строк, может дополните если знаете😅
> как только ловит deadlocks сразу вырубается Стандартное поведение при deadlocks (и вообще всех исключениях из "Class 40 — Transaction Rollback", см. https://www.postgresql.org/docs/current/errcodes-appendix.html ) — откатить и повторить транзакцию, почему он "вырубается"-то?
Обсуждают сегодня