본문으로 건너뛰기
피드

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

Go에서 Rust로 옮길 때 진짜로 바뀌는 것들

이 글은 Go 백엔드 서비스를 Rust로 옮길 때 속도보다 컴파일 타임 보장, 런타임 트레이드오프, 개발자 경험이 더 중요하다고 설명한다. nil 패닉, 데이터 레이스, 에러 처리, 제네릭, 비동기 모델, 마이그레이션 전략까지 실무 관점에서 Go와 Rust를 길게 비교한다.

backend

Python 3.15에서 헤드라인은 못 탔지만 꽤 쓸만한 기능들

Python 3.15에는 lazy imports나 Tachyon profiler 같은 큰 기능 말고도 실무에서 바로 체감될 만한 작은 개선들이 들어가. TaskGroup 취소, 컨텍스트 매니저 데코레이터 개선, 스레드 안전 이터레이터처럼 평소 애매하게 불편했던 지점들이 꽤 깔끔해졌어.

backend

심평원, DUR부터 의료영상 심사까지 클라우드로 갈아엎는다

심평원이 정보시스템 클라우드 전환과 함께 병·의원 업무에 직접 닿는 DUR, 의료영상 AI 심사, 요양급여내역 조회 시스템을 고도화한다. 핵심은 설치형 프로그램 중심이던 연계를 웹과 API 기반으로 넓히고, 진료·청구 과정에서 실시간 확인과 자동 판독을 강화하는 쪽이다.

backend

윈도우 에러 코드 7번 ‘ERROR_ARENA_TRASHED’는 어디서 왔을까

ERROR_ARENA_TRASHED는 Win32에서 실제로 쓰이는 현대적 에러라기보다 MS-DOS 시절 메모리 관리 구조에서 넘어온 잔재야. MS-DOS가 메모리 블록 앞의 arena 시그니처를 훑다가 예상한 값이 아니면 ‘arena가 망가졌다’고 보고 이 에러를 냈다는 이야기야.

backend

C/C++ 컴파일러의 느슨한 메모리 동시성 버그를 자동으로 잡는 박사논문

C와 C++ 컴파일러에서 relaxed memory 동시성 버그를 찾는 자동 테스트 프레임워크를 다룬 박사논문이 공개됐어. Téléchat, Atomic-mixer 같은 도구로 소스 수준 동작과 컴파일된 프로그램 동작을 비교하고, LLVM과 GCC 툴체인에서 실제 버그를 찾아낸 내용이 핵심이야.