잠금 시리즈 마지막 편이다. 앞의 두 편이 잠금 때문에 멈추는 이야기였다면, 이번엔 잠금을 이용해서 일을 나누는 이야기다. 문제 작업 테이블이 있다. 워커 여러 대가 여기서 하나씩 집어가서 처리한다. CREATE TABLE jobs ( id bigserial PRIMARY KEY, status text NOT NULL DEFAULT 'pending', payload jsonb, created_at timestamptz NOT NULL DEFAULT now() ); 순진하게 짜면 이렇게 된다. SELECT * FROM jobs WHERE status = 'pending' ORDER BY id LIMIT 1; UPDATE jobs SET status = 'running' WHERE id = ?; 워커 둘이 동시에 SELECT하면 같은 행을 본다. 둘 다 UPDATE하고 둘 다 처리한다. 중복이다. ...
지난 편이 한 줄로 늘어선 대기였다면, 이번 편은 대기가 원을 그리는 경우다. 서로를 기다리면 끝나지 않는다 트랜잭션 A가 행 1을 잠그고 행 2를 기다린다. 트랜잭션 B는 행 2를 잠그고 행 1을 기다린다. 둘 다 상대가 끝나야 진행할 수 있고, 상대는 내가 끝나야 진행할 수 있다. A: UPDATE accounts SET ... WHERE id = 1; -- 행 1 잠금 B: UPDATE accounts SET ... WHERE id = 2; -- 행 2 잠금 A: UPDATE accounts SET ... WHERE id = 2; -- B가 끝나길 대기 B: UPDATE accounts SET ... WHERE id = 1; -- A가 끝나길 대기 → 데드락 PostgreSQL은 이걸 막지 않는다. 대신 감지한다. 잠금 대기가 deadlock_timeout(기본 1초)을 넘으면 대기 그래프를 검사하고, 순환이 있으면 그중 하나를 끊는다. ...
컬럼 하나 추가하는 ALTER TABLE을 돌렸는데 서비스가 멈췄다는 이야기는 흔하다. 원인은 대개 ALTER 자체가 아니다. ALTER가 잠금을 기다리는 동안 그 뒤로 줄이 생기는 구조 때문이다. 잠금은 줄을 선다 PostgreSQL의 테이블 잠금은 여덟 단계가 있고, 서로 충돌하는 조합이 정해져 있다. 실무에서 기억할 건 두 가지면 된다. SELECT는 ACCESS SHARE를 잡는다. 거의 아무것과도 충돌하지 않는다. 대부분의 ALTER TABLE은 ACCESS EXCLUSIVE를 잡는다. 모든 것과 충돌한다. SELECT와도. 문제는 잠금 요청이 도착 순서대로 처리된다는 점이다. 앞의 요청이 못 받고 있으면 뒤의 요청도 기다린다. 뒤의 요청이 앞의 것과 충돌하는 종류라면 그렇다. ...