PostgreSQL에서 간헐적으로 deadlock이 납니다 — 같은 두 테이블

Question

주문 처리에서 가끔 이 에러가 납니다. ERROR: deadlock detected DETAIL: Process A waits for ShareLock on transaction ...; Process B waits for ... 두 트랜잭션 모두 orders와 inventory 테이블을 업데이트합니다. 평소엔 괜찮은데 동시 요청이 몰릴 때만 발생합니다. 어떻게 잡나요? 환경: PostgreSQL 16, 동시 트랜잭션 다수

김영삼 · Accepted Answer

거의 100% 잠금 순서(lock ordering) 불일치입니다. 트랜잭션 A는 orders→inventory 순으로 잠그고, B는 inventory→orders 순으로 잠그면 서로 상대가 쥔 잠금을 기다리며 교착됩니다. 해결: 모든 트랜잭션이 항상 같은 순서로 잠그게 강제하세요. 예를 들어 "항상 id 오름차순" 또는 "항상 orders 먼저". -- 여러 행을 잠글 땐 정렬해서 SELECT * FROM inventory WHERE id = ANY($1) ORDER BY id -- 항상 동일 순서로 잠금 획득 FOR UPDATE; 점검 방법 — 에러 로그에 어떤 두 쿼리가 엉켰는지 나옵니다. log_lock_waits = on으로 켜면 어디서 대기하는지 보입니다. 그리고 deadlock은 완전 제거가 어렵습니다. 순서를 통일해 빈도를 크게 낮추되, 남는 건 재시도(retry)로 처리하세요 — deadlock은 한쪽이 롤백되니 짧게 후 재시도하면 대부분 성공합니다.

db_현우 · Answer

코드를 보니 정말 한 곳은 orders 먼저, 다른 곳은 inventory 먼저였습니다. 순서 통일했는데, 재시도는 어느 에러일 때만 해야 하나요? 무조건 재시도하면 위험할 것 같아서요.

김영삼 · Answer

좋은 질문입니다. SQLSTATE로 구분하세요. deadlock은 40P01, 직렬화 실패는 40001입니다. 이 둘만 짧은 백오프 후 재시도하고, 그 외 에러는 재시도하지 마세요(중복 부작용 위험). if (['40P01','40001'].includes(err.code)) { /* backoff 후 재시도(최대 3회) */ } else throw err 재시도하는 트랜잭션은 멱등하게 설계하는 것도 잊지 마세요.

db_현우 · Answer

40P01/40001만 재시도하도록 했더니 에러 알림이 뚝 끊겼습니다. 잠금 순서 통일이 핵심이었네요. 감사합니다!

댓글 0