Дедлок нужно разбирать по циклу блокировок и транзакциям из логов, а не автоматически связывать с недавно созданным индексом.
У вас есть сложная база PostgreSQL с Patroni-кластером. Однажды во время пика нагрузки (15 000 RPS) в одном из приложений начались дедлоки. Откатиться на старую версию схемы нельзя — индекс уже неделю существует в продакшене. Как вы будете интерпретировать логи PostgreSQL, находить проблемный запрос и исправлять проблему без простоя?
Дедлок нужно разбирать по циклу блокировок и транзакциям из логов, а не автоматически связывать с недавно созданным индексом.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Дедлок нужно разбирать по циклу блокировок и транзакциям из логов, а не автоматически связывать с недавно созданным индексом.
Найдите SQLSTATE 40P01, участвующие PID, запросы и порядок захвата locks; текущие ожидания проверьте через pg_stat_activity и pg_locks. Сократите транзакции, унифицируйте порядок изменений, добавьте ограниченный retry всей транзакции. Исправление выкатывайте постепенно; Patroni failover не устраняет причину дедлока.