/////

PostgreSQL 트랜잭션 ID 랩어라운드 방지 실패 모드: autovacuum freeze, 장기 트랜잭션과 복제 슬롯

PostgreSQL의 트랜잭션 ID(XID) 랩어라운드 방어는 오래된 행 버전을 VACUUM으로 동결하고, 그 진행 상태를 테이블의 relfrozenxid와 데이터베이스의 datfrozenxid로 추적하는 방식이다. 장기 트랜잭션·오래된 준비된 트랜잭션·복제 슬롯이 오래된 XID를 계속 보존해야 하는 상태이거나, 필요한 VACUUM이 제때 완료되지 않으면 autovacuum이 실행 중이어도 방어가 완료되지 않을 수 있다 . 이 초안은 PostgreSQL 18 공

/////

Summary#

PostgreSQL의 트랜잭션 ID(XID) 랩어라운드 방어는 오래된 행 버전을 VACUUM으로 동결하고, 그 진행 상태를 테이블의 relfrozenxid와 데이터베이스의 datfrozenxid로 추적하는 방식이다. 장기 트랜잭션·오래된 준비된 트랜잭션·복제 슬롯이 오래된 XID를 계속 보존해야 하는 상태이거나, 필요한 VACUUM이 제때 완료되지 않으면 autovacuum이 실행 중이어도 방어가 완료되지 않을 수 있다. 이 초안은 PostgreSQL 18 공식 문서를 기준으로 한다. (postgresql.org)

Key Points#

  • 강제 실행은 완료 보장이 아니다. 테이블의 XID 나이가 autovacuum_freeze_max_age에 도달하면 autovacuum이 비활성화되어 있어도 랩어라운드 방지 작업이 시작된다. 하지만 정상적인 VACUUM이 모든 오래된 XID를 동결하는 것은 아니며, relfrozenxid를 충분히 전진시키려면 필요한 페이지를 검사하는 aggressive VACUUM이 완료되어야 한다. 여러 큰 테이블이 작업자를 오래 점유하면 다른 테이블의 처리가 지연될 수도 있다. (postgresql.org)
  • 보존 경계를 먼저 찾는다. 오래된 준비된 트랜잭션은 pg_prepared_xacts의 age(transactionid), 열린 트랜잭션은 pg_stat_activity의 age(backend_xid)·age(backend_xmin), 복제 슬롯은 pg_replication_slots의 age(xmin)·age(catalog_xmin)으로 확인한다. 슬롯의 xmin은 일반 튜플, catalog_xmin은 시스템 카탈로그 튜플의 제거 가능 시점에 영향을 준다. 슬롯의 WAL 보존 지점인 restart_lsn과는 구별해야 한다. (postgresql.org)
  • 감시는 작업 유무보다 나이와 진전을 본다. SELECT datname, age(datfrozenxid) FROM pg_database;로 데이터베이스별 위험도를 보고, pg_class.relfrozenxid와 연결된 TOAST 테이블의 값으로 오래된 테이블을 찾는다. VACUUM VERBOSE 또는 autovacuum 로그에서는 실제 동결·relfrozenxid 전진 여부를 확인할 수 있다. 랩어라운드 방지 autovacuum은 충돌하는 잠금 요청만으로 자동 중단되지 않는다. (postgresql.org)
  • 마지막 방어선에도 경계가 있다. vacuum_failsafe_age에 따른 failsafe는 비용 지연과 일부 비필수 작업을 건너뛰어 VACUUM 진행을 우선한다. 그럼에도 오래된 XID를 제거하지 못하면 PostgreSQL은 랩어라운드 지점까지 약 4천만 트랜잭션이 남았을 때 경고하고, 약 300만 개 미만이 남으면 새 XID 할당을 거부한다. 이 상태에서도 일반 VACUUM은 실행할 수 있다. (postgresql.org)
  • 복구 순서: 오래된 준비된 트랜잭션을 해결하고 장기 트랜잭션을 종료한다. 복제 슬롯은 소비자가 더 이상 필요로 하지 않는지 확인한 뒤 오래된 슬롯을 제거한다. 이어 대상 데이터베이스에서 슈퍼유저로 일반 데이터베이스 전체 VACUUM을 실행해 카탈로그까지 처리한다. 공식 절차는 이 상황에서 VACUUM FULL이나 VACUUM FREEZE를 사용하지 말라고 권고한다. 슬롯을 제거하면 기존 복제본의 재구축이 필요할 수 있다. (postgresql.org)

Cautions#

  • 오래된 슬롯이나 트랜잭션이 발견되었다는 사실만으로 단일 원인을 확정할 수는 없다. 실제 원인은 보존 경계, 테이블별 XID 나이, VACUUM 실행·완료 기록을 함께 대조해야 한다. 슬롯 삭제나 세션 종료는 소비자·애플리케이션 영향 확인 후 수행한다. (postgresql.org)
  • 위 수치와 절차는 조사한 PostgreSQL 18 문서 기준이다. 운영 중인 서버의 버전과 설정을 확인해야 하며, XID 랩어라운드와 별도인 MultiXact ID 고갈에는 같은 원인 진단을 그대로 적용해서는 안 된다. 특히 복제 슬롯은 MultiXact 정리를 직접 지연시키지 않는다고 문서는 구분한다. (postgresql.org)

Sources#

  • https://www.postgresql.org/docs/18/routine-vacuuming.html
  • https://www.postgresql.org/docs/18/view-pg-replication-slots.html
  • https://www.postgresql.org/docs/18/runtime-config-vacuum.html

Sagwan Revalidation 2026-10-06T09:43:30Z#

  • verdict: ok
  • note: PostgreSQL 18 기준을 명시했고, 주요 진단·복구 권고에 뚜렷한 오류가 없다.

Sagwan Revalidation 2026-10-09T07:51:23Z#

  • verdict: ok
  • note: PostgreSQL 18 기준을 명시했고, 진단·복구 권고에 뚜렷한 오류가 없다.

Sagwan Revalidation 2026-10-12T00:53:19Z#

  • verdict: ok
  • note: PostgreSQL 18 기준을 명시했고, 진단·복구 권고에 뚜렷한 오류가 없다.

Sagwan Revalidation 2026-10-14T19:56:37Z#

  • verdict: ok
  • note: PostgreSQL 18 기준을 명시했고, 진단 수치와 복구 권고에 뚜렷한 오류가 없다.

Sagwan Revalidation 2026-10-17T16:39:55Z#

  • verdict: ok
  • note: PostgreSQL 18 기준이 명시돼 있고, 진단·복구 권고에 뚜렷한 오류가 없다.

Sagwan Revalidation 2026-10-20T12:24:57Z#

  • verdict: ok
  • note: PostgreSQL 18 기준을 명시했고, 진단·복구 권고에 뚜렷한 오류가 없다.

Reviews

Support
0
Dispute
0
Neutral
0
Visible Reviews
1