지난 편에서 파티셔닝의 확실한 이득은 프루닝보다 데이터를 파티션째 버리는 데 있다고 썼다. 이번 편은 그 운영 이야기다. 시간으로 나눈 파티션을 어떻게 만들고, 어떻게 떼어내고, 어디서 사고가 나는지. 파티션은 미리 있어야 한다 행이 들어올 때 그 값에 맞는 파티션이 없으면 실패한다. ERROR: no partition of relation "orders" found for row DETAIL: Partition key of the failing row contains (created_at) = (2026-10-01 00:00:00+00). 10월 1일 자정에 10월 파티션이 없으면 그 순간부터 모든 INSERT가 이 에러다. 월 초 자정에 장애 나는 전형적인 경로다. ...
컬럼 하나 추가하는 ALTER TABLE을 돌렸는데 서비스가 멈췄다는 이야기는 흔하다. 원인은 대개 ALTER 자체가 아니다. ALTER가 잠금을 기다리는 동안 그 뒤로 줄이 생기는 구조 때문이다. 잠금은 줄을 선다 PostgreSQL의 테이블 잠금은 여덟 단계가 있고, 서로 충돌하는 조합이 정해져 있다. 실무에서 기억할 건 두 가지면 된다. SELECT는 ACCESS SHARE를 잡는다. 거의 아무것과도 충돌하지 않는다. 대부분의 ALTER TABLE은 ACCESS EXCLUSIVE를 잡는다. 모든 것과 충돌한다. SELECT와도. 문제는 잠금 요청이 도착 순서대로 처리된다는 점이다. 앞의 요청이 못 받고 있으면 뒤의 요청도 기다린다. 뒤의 요청이 앞의 것과 충돌하는 종류라면 그렇다. ...
앞선 두 편에서 VACUUM이 공간을 반환하지 않는다는 것과 autovacuum 발동 조건을 다뤘다. 이번 편은 성격이 다르다. 설정을 아무리 만져도 해결되지 않는 경우가 있다. autovacuum은 정상적으로 돌고, 실행 기록도 계속 갱신되는데, 죽은 튜플만 계속 늘어난다. 이건 VACUUM이 게을러서가 아니라 지울 권한이 없어서다. 정리 기준선 VACUUM은 아무 죽은 튜플이나 지우지 않는다. 지워도 되는지 판단하는 기준선이 있다. 기준은 단순하다. 지금 실행 중이거나 앞으로 시작할 어떤 트랜잭션도 이 튜플을 볼 수 없는가. 하나라도 볼 가능성이 있으면 못 지운다. 지웠다가는 그 트랜잭션이 읽어야 할 데이터가 사라진다. ...
지난 편에서 죽은 튜플 비율이 계속 올라가고 있다면 설정을 봐야 한다고 썼다. 그 설정 이야기다. 결론부터 말하면, autovacuum의 기본값은 작은 테이블에 맞춰져 있다. 테이블이 커질수록 늦게 돌고, 늦게 도는 만큼 한 번에 할 일이 많아진다. 발동 조건 공식 autovacuum은 테이블마다 임계값을 계산해서, 죽은 튜플 수가 그 값을 넘으면 대상으로 잡는다. 발동 임계값 = autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor × 테이블 행 수 기본값은 이렇다. 파라미터 기본값 autovacuum_vacuum_threshold 50 autovacuum_vacuum_scale_factor 0.2 (20%) 지배적인 건 뒤쪽 항이다. 행 수에 곱해지기 때문이다. ...
VACUUM을 돌렸는데 디스크가 그대로라는 이야기를 종종 듣는다. 정상 동작이다. VACUUM은 공간을 운영체제에 돌려주는 명령이 아니다. VACUUM이 실제로 무엇을 하는지, bloat가 왜 쌓이고 어떻게 재는지까지 정리한다. 죽은 튜플은 어떻게 생기는가 PostgreSQL은 MVCC를 쓰기 때문에 UPDATE가 제자리 수정이 아니다. 기존 행을 고치는 게 아니라 새 버전을 하나 더 쓰고, 예전 버전에 “이 시점 이후로는 무효"라는 표시를 남긴다. DELETE도 마찬가지로 즉시 지우지 않고 무효 표시만 한다. 예전 버전을 바로 못 지우는 이유는 아직 그걸 봐야 하는 트랜잭션이 있을 수 있어서다. 먼저 시작된 트랜잭션에게는 여전히 그 버전이 유효한 데이터다. ...