3장. MVCC — PostgreSQL 동시성의 비밀

읽기가 쓰기를 막지 않고, 쓰기가 읽기를 막지 않는 마법. 그 대가로 생기는 Bloat와 VACUUM까지 — PostgreSQL 운영의 심장을 그림으로 이해합니다.

3.1 왜 MVCC인가 — "읽기는 쓰기를 막지 않는다"

전통적인 Two-Phase Locking(2PL) 방식에서는 읽기(shared lock)와 쓰기(exclusive lock)가 서로를 막습니다. 한 트랜잭션이 행을 읽는 동안 다른 트랜잭션의 UPDATE는 줄을 서서 기다려야 합니다.

PostgreSQL의 선택은 다릅니다. 데이터를 덮어쓰는 대신, 새 버전(version)을 만듭니다. 각 트랜잭션은 자신만의 일관된 스냅샷(snapshot)을 보기 때문에 락 경합 없이 동시에 일할 수 있습니다.

그 결과:

• SELECT는 락을 잡지 않습니다 (FOR UPDATE를 명시하지 않는 한).
• UPDATE는 새 버전을 씁니다 → 이전 버전은 "dead tuple"로 남습니다.
• 대가: Bloat, XID 관리, VACUUM 운영 오버헤드 (8장에서 자세히).

3.2 튜플 헤더 — 버전은 어디에 기록되는가

MVCC를 떠받치는 것은 모든 heap 튜플 앞에 붙는 23바이트 헤더입니다. 이 중 버전 판단의 핵심은 네 가지입니다.

실제로 눈으로 확인해 봅시다. 숨겨진 시스템 컬럼을 SELECT하면 됩니다.

-- xmin, xmax는 모든 테이블에 숨어있는 시스템 컬럼이다
SELECT xmin, xmax, ctid, * FROM users;

 xmin | xmax | ctid  | id | name
------+------+-------+----+-------
  100 |    0 | (0,1) |  1 | Alice   ← xmax=0: 아무도 안 지움 (살아있음)

이제 INSERT → UPDATE → DELETE가 헤더를 어떻게 바꾸는지 애니메이션으로 봅시다. PostgreSQL은 절대 제자리에서 덮어쓰지 않는다는 것이 포인트입니다.

3.3 스냅샷 — "내게 보이는 버전"을 고르는 법

버전이 여러 개라면, 각 트랜잭션은 어떤 버전을 봐야 할까요? 트랜잭션은 시작 시점(READ COMMITTED에서는 쿼리 시작 시점)에 스냅샷을 찍습니다. 스냅샷은 세 가지 정보로 구성됩니다.

-- 현재 스냅샷 보기: xmin:xmax:xip_list 형식
SELECT pg_current_snapshot();

 pg_current_snapshot
---------------------
 100:105:101,103      ← xmin=100, xmax=105, 진행 중=101,103

• xmin = 100 : 100 미만의 XID는 모두 결과 확정 (커밋됐으면 보임)
• xmax = 105 : 105 이상의 XID는 스냅샷 이후 시작 → 무조건 안 보임
• xip_list = 101,103 : 스냅샷 시점에 아직 진행 중이던 트랜잭션 → 안 보임

3.4 직접 실험 — 두 세션으로 MVCC 관찰하기

터미널 두 개를 열고 직접 눈으로 확인해 보세요. MVCC는 실험으로 배우는 것이 가장 빠릅니다.

-- [세션 A]
CREATE TABLE t (id int, name text);
INSERT INTO t VALUES (1, 'Alice');
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT xmin, xmax, name FROM t;   -- Alice가 보인다. 스냅샷 고정!

-- [세션 B] : A가 트랜잭션을 연 채로 실행
UPDATE t SET name = 'Alicia' WHERE id = 1;   -- 블로킹 없이 즉시 성공!
SELECT xmin, xmax, name FROM t;   -- B에게는 Alicia (새 버전)

-- [세션 A] : 다시 조회
SELECT xmin, xmax, name FROM t;   -- 여전히 Alice! (내 스냅샷의 세상)
COMMIT;
SELECT name FROM t;               -- 이제 Alicia가 보인다

3.5 MVCC의 청구서 — Bloat와 XID Wraparound

공짜 점심은 없습니다. MVCC의 대가는 두 가지이며, 둘 다 PostgreSQL 운영 사고의 단골 원인입니다.

✍️ 이해도 체크