#4 - PostgreSQL WAL · INSERT · SELECT · 디스크 관계 정리

PostgreSQL WAL · INSERT · SELECT · 디스크 관계 정리

이 문서는 PostgreSQL 내부에서 INSERT, SELECT, WAL, 디스크가 어떻게 상호작용하는지를 흐름 중심으로 정리한 자료다.

1. PostgreSQL의 핵심 구성 요소

PostgreSQL에서 데이터 흐름을 이해하려면 아래 3가지를 반드시 구분해야 한다.

1️⃣ Shared Buffer (메모리)

실제 쿼리가 읽고 쓰는 대상
INSERT / UPDATE / DELETE / SELECT 모두 여기서 수행됨
디스크 데이터 파일의 캐시 역할

2️⃣ Data File (디스크)

테이블의 실제 물리 파일
즉시 쓰이지 않음 (비동기)
Checkpoint 시점에 반영

3️⃣ WAL (Write-Ahead Log)

"무슨 변경을 할지" 기록하는 로그
데이터 자체가 아닌 변경 내역 기록
복구, 복제, 안정성의 핵심
조회용으로 사용되지 않음

2. INSERT 한 번의 정확한 내부 흐름

아래 순서는 PostgreSQL의 가장 중요한 내부 동작 흐름이다.

① INSERT 실행
② Shared Buffer 변경
③ WAL 생성
④ WAL 디스크 기록 (fsync)
⑤ COMMIT 완료
⑥ (나중에) 데이터 파일 디스크 반영

① INSERT 실행

sql

INSERT INTO orders VALUES (...);

SQL 파싱
실행 계획 생성

② Shared Buffer만 변경됨 (중요)

실제 테이블 파일(Data File)은 아직 건드리지 않음
Shared Buffer에 로드된 페이지가 수정됨
이 페이지는 dirty page 상태

👉 이 시점까지 디스크 I/O 없음

③ WAL 생성

PostgreSQL은 다음 정보를 WAL에 기록한다.

어떤 테이블의
어떤 페이지의
어떤 위치를
어떻게 변경했는지

즉,

❌ 데이터 값 자체
✅ 데이터 변경 기록

④ WAL을 디스크에 기록 (fsync)

WAL 로그가 pg_wal/ 디렉터리에 저장됨
이 단계가 끝나야 COMMIT 가능

COMMIT = "이 변경 로그는 디스크에 안전하게 기록되었다"

⑤ COMMIT 완료 응답

클라이언트 입장에서는:

"INSERT 완료"

하지만 실제 상태는:

WAL ✅ 디스크 기록 완료
Data File ❌ 아직 미반영
Shared Buffer ✅ 변경 상태 유지

⑥ 데이터 파일 디스크 반영 (언제?)

아래 시점 중 하나에서 비동기적으로 수행된다.

Checkpoint 발생 시
Shared Buffer 부족으로 eviction 발생 시
서버 정상 종료 시

👉 COMMIT 시점과 무관

3. SELECT는 어디서 데이터를 읽는가?

SELECT의 읽기 경로는 항상 동일하다.

SELECT
 ↓
Shared Buffer 확인
 ↓
(없으면) Data File 디스크 읽기

WAL ❌ 사용하지 않음
pg_wal ❌ 조회 대상 아님

4. INSERT 직후 SELECT가 가능한 이유

타임라인

INSERT
→ Shared Buffer 변경
→ WAL 디스크 기록
→ COMMIT
→ SELECT

이 시점에서:

Shared Buffer에 변경된 데이터가 존재
SELECT는 이를 그대로 조회

👉 디스크 반영 여부는 전혀 중요하지 않음

5. WAL은 왜 SELECT에 사용되지 않는가?

WAL의 목적은 오직 다음 3가지다.

장애 복구 (Crash Recovery)
복제 (Replication)
데이터 안정성 보장

WAL은:

로그
재현용 기록
재생(replay) 대상

❌ 조회용 저장소가 아님

6. Replica(Slave)에서 SELECT가 늦는 이유

Replica는 SQL을 실행하지 않는다.

MASTER
 → WAL 생성
 → WAL 전송
 → WAL replay
 → Shared Buffer 반영
 → SELECT 가능

즉,

WAL이 적용(replay) 되기 전에는
Shared Buffer에 데이터가 없음
SELECT 결과도 없음

👉 이것이 Replication Lag

7. Master vs Slave 내부 차이 요약

구분	Master	Slave
INSERT 실행	O	X
WAL 생성	O	X
WAL 적용	X	O
SELECT 읽기	Shared Buffer	Shared Buffer
WAL 직접 조회	불가	불가

8. 핵심 오해 정리

❌ COMMIT = 디스크 반영 완료
❌ SELECT는 WAL에서 읽음

✅ COMMIT = WAL 디스크 기록 완료
✅ SELECT는 Shared Buffer / Data File에서 읽음

9. 한 문장으로 정리

PostgreSQL에서 데이터의 진실은
WAL이 아니라 Shared Buffer에 있고,
WAL은 그 진실을 되살리기 위한 기록이다.

이 흐름을 이해하면

Replication Lag
Read After Write 문제
Master / Slave 라우팅
장애 복구
가 하나의 그림으로 연결된다.