# PostgreSQL 락(blocking) 상황 정리 해결방법

1. 락 확인 쿼리

SELECT t.relname,
       l.locktype,
       page,
       virtualtransaction,
       pid,
       mode,
       granted
FROM pg_locks l,
     pg_stat_all_tables t
WHERE l.relation = t.relid
ORDER BY relation ASC;

어떤 테이블에 어떤 PID가 락 걸었는지 확인 가능

 

현재 활동중인 세션 보기 (pg_stat_activity도 같이보면서 확인)

SELECT pid, state, query, wait_event_type, wait_event
FROM pg_stat_activity
WHERE state != 'idle';

 

2. 누가 누구를 막고 있는지 확인

SELECT pid,
       pg_blocking_pids(pid) AS blocked_by
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;

현재 실행중이거나 대기중인 쿼리들 확인 가능

 

누가 누구를 막고 있는지  (blocker 정보까지 확인)

SELECT blocked.pid     AS blocked_pid,
       blocked.query   AS blocked_query,
       blocking.pid    AS blocking_pid,
       blocking.query  AS blocking_query
FROM pg_stat_activity blocked
JOIN pg_stat_activity blocking
  ON blocking.pid = ANY(pg_blocking_pids(blocked.pid));

 

3. blocker인지 victim인지 확인 후 terminate > 문제 있는 세션 강제 종료 (락 해제)

SELECT pg_terminate_backend(12345); -- PID 넣기

해당 PID가 점유하고 있는 세션을 강제로 종료함

락이 해제됨 ( 종료되면서 롤백도 같이 감 )

 

Blocker vs Victim

구분	설명	예시
Blocker	락을 먼저 잡고 있는 세션. 다른 트랜잭션이 기다리는 원인	트랜잭션 시작 후 UPDATE 했지만 커밋/롤백 안 한 상태
Victim	락이 풀리길 기다리는 세션. 막힌 쪽	다른 세션이 같은 row를 UPDATE 하려고 시도함 → 대기 상태 됨

 

예: 
1. 세션 A가 row를 UPDATE 후 커밋 안함 → Blocker
2. 세션 B가 같은 row UPDATE 시도 → Victim (대기상태)

 

주의할 점

상황	설명
세션이 비정상적	트랜잭션이 오래 열려 있고 아무 작업도 안 하면 종료해도 됨
중요한 작업 중	예: 배치, 마이그레이션, 사용자 DML 등이면 절대 함부로 종료하면 안 됨
운영 DB	무작정 terminate 하면 데이터 손실, 장애 유발 가능함
Deadlock 상태	pg_stat_activity, pg_locks, pg_blocking_pids() 같이 확인 후 판단해야 함