129편 · 약 14분

PostgreSQL 19 Beta 3: pg_plan_advice 플랜 힌트·병렬 Autovacuum·보안 패치 28개로 GA 직전에 확인해야 할 변화

요약

PostgreSQL 19 Beta 3가 2026년 8월 13일 릴리스되었다. 동시에 PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 보안 패치도 함께 배포되었으며, 이 패치는 힙 버퍼 오버플로우와 원격 코드 실행(RCE)을 포함한 28개의 CVE를 수정한다.

PG14 수명 종료(EOL) 예고: 이번 릴리스와 함께 PostgreSQL 14의 지원 종료 일정이 공식 고지되었다. 14.24는 마지막 정식 패치가 될 가능성이 높다. PG14를 운영 중이라면 즉시 마이그레이션 계획을 수립해야 한다.

Beta 2(2026-07-16)에서 확정된 SQL/PGQ, REPACK CONCURRENTLY, JIT 기본 비활성에 더해, Beta 3는 다음을 추가한다:

pg_plan_advice: PostgreSQL 최초의 공식 플랜 힌트 모듈
병렬 Autovacuum: 인덱스를 멀티 워커로 처리
pg_stat_autovacuum_scores: Autovacuum 우선순위 가시성
Logical Replication 시퀀스 동기화 안정화
Eager Aggregation, NOT IN → ANTI JOIN, SIMD COPY, LZ4 TOAST 기본값

Beta 2에서 확정된 기반 기능 요약

이 챕터는 Beta 3의 신규 추가·수정 사항에 집중한다. Beta 2에서 다룬 내용(SQL/PGQ, REPACK, JIT 기본 비활성)의 운영 기준은 이전 챕터를 참조하라.

핵심 신기능 1: pg_plan_advice — 공식 플랜 힌트 모듈

배경: PostgreSQL에 플랜 힌트가 없었던 이유

MySQL, Oracle, SQL Server는 모두 플랜 힌트를 지원한다. PostgreSQL은 오랫동안 이를 거부해 왔다. 핵심 팀의 입장은 "통계와 옵티마이저를 개선해야지, 힌트로 땜질하는 것은 잘못된 접근"이었다.

그러나 현실적으로 DBA는 다음 상황에서 플랜을 강제해야 한다:

통계 갱신이 늦어 실행 계획이 일시적으로 비효율적인 경우
특정 쿼리 패턴이 플래너가 예측하지 못하는 분포를 갖는 경우
배포 직후 stats 수집 전 안전한 계획을 보장하고 싶은 경우

pg_plan_advice는 이 공백을 공식적으로 채운다.

pg_plan_advice 사용법

-- 모듈 로드
LOAD 'pg_plan_advice';

-- 특정 쿼리에 대한 플랜 잠금 (SET LOCAL 사용)
BEGIN;
SET LOCAL plan_advice.enable = on;
SET LOCAL plan_advice.hints = 'IndexScan(orders orders_user_id_idx)';
EXPLAIN ANALYZE
  SELECT * FROM orders WHERE user_id = 12345;
COMMIT;

-- 세션 전체에 힌트 적용 (주의: 다른 쿼리에도 영향)
SET plan_advice.hints = 'HashJoin(orders items)';
SELECT o.id, i.product_id
FROM orders o
JOIN order_items i ON o.id = i.order_id
WHERE o.status = 'pending';

pg_plan_advice 운영 주의사항

상황	권고
임시 성능 위기 완화	`SET LOCAL` 또는 함수 내 LOAD로 스코프 제한
스키마 변경 후 힌트 유효성	인덱스 삭제·이름 변경 시 힌트 자동 무효화 여부 검증
장기 사용	근본 원인 분석을 병행할 것 (힌트는 임시방편)
통계 갱신 후	힌트 제거하고 옵티마이저가 올바른 계획을 선택하는지 재확인

Open question: pg_plan_advice가 pg_hint_plan(PostgreSQL 확장)을 완전히 대체할 수 있는 수준의 힌트 문법을 지원하는지는 정식 릴리스 노트로 확인 필요.

핵심 신기능 2: 병렬 Autovacuum과 pg_stat_autovacuum_scores

문제: 단일 워커 Autovacuum의 한계

기존 Autovacuum은 테이블당 단일 워커 프로세스가 순차적으로 테이블과 인덱스를 정리한다. 인덱스가 많거나 테이블이 거대할 때 Autovacuum이 완료되기 전에 다음 사이클이 시작되어, dead tuple 누적 → 테이블 bloat → 성능 저하로 이어질 수 있다.

병렬 Autovacuum 아키텍처

pg_stat_autovacuum_scores 뷰

-- Autovacuum 우선순위 점수 확인
SELECT
  schemaname,
  relname,
  autovacuum_score,
  autoanalyze_score,
  n_dead_tup,
  last_autovacuum
FROM pg_stat_autovacuum_scores
ORDER BY autovacuum_score DESC
LIMIT 20;

이 뷰는 Autovacuum이 어떤 테이블을 다음에 처리할 것인지의 근거를 제공한다. 기존에는 pg_stat_user_tables의 dead tuple 수와 마지막 vacuum 시간을 직접 계산해야 했다.

운영 활용 패턴:

-- Autovacuum이 따라오지 못하는 테이블 탐지
SELECT relname, autovacuum_score, n_dead_tup
FROM pg_stat_autovacuum_scores
WHERE autovacuum_score > 500
  AND last_autovacuum < NOW() - INTERVAL '2 hours';

핵심 변경 2: 성능 최적화

NOT IN → ANTI JOIN 자동 변환

-- 기존 (느림): NOT IN은 NULL 처리 때문에 옵티마이저가 최적화 어려움
SELECT id FROM orders
WHERE id NOT IN (SELECT order_id FROM fulfilled_orders);

-- PostgreSQL 19 Beta 3부터: 옵티마이저가 ANTI JOIN으로 자동 변환
-- → Hash Anti Join 실행 계획 적용 가능 → 대규모 테이블에서 유의미한 성능 향상

주의: NULL 포함 여부에 따라 의미론이 달라질 수 있다. 옵티마이저는 fulfilled_orders.order_id가 NOT NULL인 경우에만 안전하게 변환한다.

SIMD 가속 COPY FROM

대량 데이터 로드(COPY table FROM file)가 SIMD 명령어를 사용해 파싱 속도를 높인다. 기준 벤치마크 수치는 정식 릴리스 노트에서 확인이 필요하지만, 수백만 행 CSV 로드 시나리오에서 체감 가능한 속도 향상이 기대된다.

LZ4 기본 TOAST 압축

PostgreSQL 14부터 pglz와 LZ4 중 선택 가능했지만, 기본값은 pglz였다. Beta 3(및 정식 릴리스인 PostgreSQL 19)에서 LZ4가 기본값으로 전환된다.

항목	pglz	LZ4
압축률	높음	중간
압축 속도	느림	빠름 (~5×)
압축 해제 속도	느림	매우 빠름 (~10×)
CPU 사용	높음	낮음

운영 중에 기존 TOAST 값은 자동 재압축되지 않는다. 업그레이드 후 VACUUM FULL이나 테이블 재작성 없이는 기존 행은 pglz로 유지된다.

핵심 변경 3: Logical Replication 시퀀스 동기화 안정화

Beta 2에서 도입된 시퀀스 값 복제(REFRESH SEQUENCES)가 Beta 3에서 안정화되었다. 주요 버그 수정:

REFRESH SEQUENCES 실행 중 레이스 컨디션 수정
구독자가 퍼블리셔 재시작 없이 시퀀스 갱신을 수신하도록 수정

-- Logical Replication 시퀀스 동기화 (구독자에서)
ALTER SUBSCRIPTION my_sub REFRESH SEQUENCES;

-- wal_level=replica에서도 가능 (Beta 3에서 확정)
-- 기존: wal_level=logical 필요

보안 패치: 28개 CVE (PostgreSQL 모든 지원 버전)

이번 릴리스의 보안 패치는 PostgreSQL 14.24~18.6 전 버전에 동시 적용된다.

즉시 적용 (Critical / High)

힙 버퍼 오버플로우: 파서 또는 타입 변환 경로

원격 코드 실행(RCE) 가능성 있는 취약점

인증 우회 관련 취약점

계획적 적용 (Medium)

권한 상승 (로컬 악용 필요)

정보 노출 (오류 메시지 등)

다음 유지보수 주기

논리적 보안 개선 (기본값 변경 등)

패치 적용 우선순위

각 CVE의 CVSS 점수와 영향 범위는 PostgreSQL 보안 페이지에서 확인하라.

패치 적용 전 확인 체크리스트:

[ ] pg_upgrade 경로 검증 (14 → 18의 경우 15/16/17 경유 권고)
[ ] 확장 호환성 점검 (pg_extension_update_paths())
[ ] 슬레이브/레플리카 동기 업그레이드 계획
[ ] 패치 전 백업 및 롤백 포인트 확보

PG14 수명 종료(EOL) 고지

PostgreSQL 14는 2026년 11월 EOL이 예정되어 있다. 이번 14.24 보안 패치가 마지막 공식 패치가 될 수 있다. 이후 PG14를 계속 운영하면 새로운 보안 취약점에 대한 공식 수정을 받지 못한다.

마이그레이션 경로:

PG14 → PG17 권장 (LTS 후보)
PG14 → PG18 (안정적이나 상대적으로 최신)
PG14 → PG19 (Beta 3 → GA 예정 2026년 9~10월)

pg_upgrade는 한 단계씩 건너뛸 수 있다(14→17 직접 가능). 단, 확장과 프로시저의 호환성을 반드시 스테이징에서 검증해야 한다.

운영자를 위한 PostgreSQL 19 Beta 3 요약

PostgreSQL 19 Beta 3 기능 지형도

도입 검증 체크리스트 (Beta 3 → GA 준비)

개발·스테이징 환경에서 지금 해야 할 것:

[ ] pg_plan_advice를 필요한 쿼리에 적용하고, 정식 릴리스 후에도 작동하는지 회귀 테스트
[ ] 병렬 Autovacuum 워커 수(autovacuum_max_workers) 설정 검토 — 병렬화로 CPU 사용 증가 가능
[ ] pg_stat_autovacuum_scores 뷰를 모니터링 쿼리에 추가
[ ] LZ4 TOAST 기본값 전환 후 스토리지 사용량 변화 모니터링 (재압축은 VACUUM FULL 후)
[ ] NOT IN → ANTI JOIN 변환이 기존 쿼리 의미론에 영향 없는지 검증
[ ] Logical Replication 시퀀스 동기화가 필요한 경우 REFRESH SEQUENCES 절차 테스트

GA 릴리스 직후:

[ ] pg_upgrade 경로 스테이징 실행 (PG14/15/16 → PG19)
[ ] 확장 호환성 재검증 (pg_partman, PostGIS, pgvector, pg_repack vs 새 REPACK 명령)
[ ] 모든 지원 버전의 보안 패치 (18.6, 17.11 등) 즉시 적용

요점 정리

PostgreSQL 19 Beta 3는 Beta 2가 확정한 큰 기능들 위에 운영자 친화적인 다듬기를 더한 릴리스다.

pg_plan_advice는 PostgreSQL 생태계에서 오랫동안 외부 확장에 의존했던 플랜 힌트를 공식화한다
병렬 Autovacuum은 인덱스가 많은 대형 테이블의 유지보수 시간을 줄인다
28개 CVE 보안 패치는 현재 운영 중인 모든 버전(14~18)에 해당하므로 즉시 적용해야 한다
PG14 EOL 고지는 마이그레이션 계획이 없는 팀에게 직접적인 행동 요청이다

GA는 2026년 9~10월 예상이다. Beta 3를 스테이징에서 테스트해 두면 GA 직후 신속한 전환이 가능하다.