본문으로 건너뛰기
피드

pg_background: PostgreSQL 안에서 비동기 SQL 실행을 가능하게 하는 확장

backend 약 6분
vote
0
댓글
북마크

pg_background는 PostgreSQL 백그라운드 워커에서 SQL을 비동기 실행하는 확장으로, 클라이언트 커넥션 점유 없이 장시간 쿼리나 자율 트랜잭션을 처리할 수 있음. v1.6~v1.8을 거치며 v2 API, 보안 강화, 운영 제어 GUC 등이 추가되어 프로덕션 레벨로 성숙함.

  • 1

    클라이언트 세션 블로킹 없이 PostgreSQL 내부에서 비동기 SQL 실행 가능

  • 2

    v2 API는 (pid, cookie) 핸들로 PID 재사용 문제 방지

  • 3

    v1.8에서 max_workers, worker_timeout 등 운영 제어용 GUC 추가

  • 4

    detach와 cancel의 의미 차이가 운영상 핵심 — detach는 추적 중단이지 실행 중단이 아님

pg_background: PostgreSQL 안에서 비동기 SQL 실행을 가능하게 하는 확장

  • pg_background는 PostgreSQL 내부의 백그라운드 워커 프로세스에서 SQL을 비동기로 실행할 수 있게 해주는 확장임
  • 클라이언트 세션을 점유하지 않고 무거운 쿼리를 실행할 수 있어서, 별도의 외부 잡 시스템 없이도 Postgres 네이티브하게 비동기 처리가 가능함

핵심 기능

  • 장시간 실행 쿼리를 클라이언트 커넥션 점유 없이 실행 가능
  • 호출자의 트랜잭션과 독립적으로 commit/rollback하는 "자율 트랜잭션(autonomous transaction)" 스타일 지원
  • 워커를 모니터링, 대기, 분리(detach), 취소(cancel)할 수 있는 명시적 제어 제공
  • 스케줄러나 큐잉 플랫폼이 아님 — "이 SQL을 저쪽에서 실행해라"에 집중하는 날카로운 도구임

v2 API — 운영 환경에서는 필수

  • (pid, cookie) 핸들 기반으로 PID 재사용 문제를 방지함 — 장기 운영 시스템에서 실제로 발생하는 문제임
  • cookie 기반 신원 확인, 명시적 취소 vs 분리 구분, 동기 대기, 리스트 함수를 통한 모니터링 지원
  • 신규 배포라면 v2 API 사용이 강력히 권장됨

릴리스 히스토리 (v1.6 ~ v1.8)

v1.6 (2026년 2월 5일)

  • 프로덕션 안정화 릴리스로 v2 API가 공식 권장 API로 등장
  • PostgreSQL 12~18 호환
  • DSM 라이프사이클 처리 개선, NULL 안전성, 레이스 컨디션 수정, 메모리 컨텍스트 누수 수정 포함

v1.7 (2026년 2월 13일)

  • 보안 강화: cookie 생성에 pg_strong_random() 사용 (암호학적으로 안전)
  • 전용 WorkerInfoMemoryContext 도입으로 장기 세션의 메모리 비대화 방지
  • wait/cancel 루프에 지수 백오프(exponential backoff) 폴링 적용으로 CPU 부하 감소

v1.8 (2026년 2월 13일)

  • PostgreSQL 14+가 최소 지원 버전으로 변경됨
  • 새 GUC 설정 추가: pg_background.max_workers, worker_timeout, default_queue_size
  • pg_background_stats_v2(), pg_background_progress() 등 통계/진행률 함수 추가
  • Docker 기반 CI 리팩토링 및 패키징 개선

실전 활용 사례

  • 백그라운드 VACUUM / ANALYZE / REINDEX: DBA 작업을 세션 블로킹 없이 실행
  • 비동기 백필/데이터 보정: 대량 데이터 작업을 백그라운드로 위임
  • Fire-and-forget 감사 로그/Outbox 기록: 트랜잭션 결과와 무관하게 사이드 이펙트 기록
  • "비싼 작업은 나중에" 패턴: OLTP 중심 앱에서 무거운 처리를 분리

운영 시 반드시 알아야 할 점

  • 백그라운드 워커는 max_worker_processes를 소비함 — 용량 버짓으로 관리해야 함
  • detach는 cancel이 아님: detach는 "추적 중단"이지 "실행 중단"이 아님. 이 구분이 핵심임
  • 결과는 한 번만 소비 가능 — 재사용이 필요하면 별도 저장해야 함
  • v1.8의 max_workers, timeout, queue_size GUC로 세션당 워커 수와 리소스를 제한하는 것이 권장됨

정리

  • 외부 잡 큐(Celery, Sidekiq 등)를 도입하기 전에, PostgreSQL 자체의 비동기 실행이 충분한지 먼저 검토해볼 만한 도구임
  • 특히 "커넥션 풀 고갈 없이 무거운 쿼리를 돌리고 싶다"는 요구사항에 정확히 부합함
  • v1.6~v1.8의 빠른 릴리스 사이클을 보면 프로덕션 환경에서의 실전 피드백이 적극 반영되고 있음이 느껴짐

원문 링크

외부 잡 큐를 도입하기 전에 PostgreSQL 자체의 비동기 실행 능력을 먼저 검토해볼 만한 실용적 도구. 커넥션 풀 고갈 문제를 서버 내부에서 해결하는 접근이 인상적임.

댓글

댓글

댓글을 불러오는 중...

backend

클릭하우스가 PgBouncer 처리량을 4배로 끌어올린 방법

ClickHouse Managed Postgres 팀은 단일 스레드인 PgBouncer를 여러 프로세스로 띄우고 `so_reuseport`와 피어링(peering)을 조합해 16 vCPU 머신을 제대로 쓰게 만들었다. 동일한 AWS 환경에서 단일 프로세스는 약 8.7만 TPS 근처에서 막혔지만, 16개 프로세스 구성은 약 33.6만 TPS까지 올라갔다.

backend

SQLite 쓸 거면 STRICT 테이블을 기본값으로 보자는 주장

SQLite의 STRICT 테이블은 INTEGER 컬럼에 문자열이 들어가는 식의 타입 실수를 막아주는 기능이다. 글쓴이는 SQLite 특유의 유연한 타입 시스템보다, 실수는 빨리 터뜨리는 쪽이 실무에서 낫다고 주장한다. 다만 기존 테이블을 바로 STRICT로 바꾸기 어렵고, SQLite 3.37.0 이상에서만 쓸 수 있다는 제약도 있다.

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.