PostgreSQL 19 후보판은 운영 기능을 늘리고 검증을 요구한다

PostgreSQL 19 첫 번째 릴리스 후보가 공개되면서 테이블 재구성, 쿼리 계획 조언, autovacuum 개선, 논리 복제의 시퀀스 동기화 등을 시험할 수 있게 됐다. EnterpriseDB의 톰 킨케이드(Tom Kincaid)는 실제 운영 환경을 반영한 비프로덕션 환경에서 기능과 업그레이드 절차를 검증해야 한다고 강조한다.

PostgreSQL 19 첫 번째 릴리스 후보는 10월 15일 공개됐다. 두 번째 후보판은 11월 12일, 정식 버전은 11월 19일 공개할 계획이지만 추가 수정이 필요하면 일정이 바뀔 수 있다. 정식 출시 전까지 프로덕션 환경의 기준 버전은 PostgreSQL 18로 유지하고, PostgreSQL 19는 비프로덕션 환경에서 시험하라는 게 킨케이드의 권고다.

이번 주기에 일부 주요 기능은 이전 베타에서 빠졌다. PostgreSQL 19 Beta 4 릴리스 노트에는 SQL 속성 그래프 쿼리, 파티션 병합·분할, 서버 실행 중 데이터 체크섬 활성화·비활성화 기능의 철회가 기록됐다. 커뮤니티 추적 자료에는 GROUP BY ALL과 UPDATE/DELETE ... FOR PORTION OF도 포함됐다. 커뮤니티는 신뢰성과 예측 가능한 출시 일정을 우선했으며, 일부 기능은 이번 주기 안에 개발과 검토를 마치기 어려웠다고 설명했다.

EnterpriseDB의 피터 아이젠트라우트(Peter Eisentraut)는 회고 글에서 일부 기능의 구조적 문제, AI 보조 검토로 더 많은 예외 사례가 발견된 점, 보안 수정에 투입된 선임 개발자의 시간 등을 철회 배경으로 들었다. 그는 AI 보조 검토로 문제가 더 빨리 발견된다는 사실과 문제가 된 코드를 AI가 작성했다는 주장은 구분했다. 2026년 8월 PostgreSQL 18 패치 릴리스에서는 CVE 28건을 처리했다. 킨케이드는 문제를 빨리 찾는 것만으로는 충분하지 않으며 조사·수정·검토 역량도 뒷받침돼야 한다고 짚었다.

PostgreSQL 19의 REPACK 명령은 테이블을 다시 작성해 사용하지 않는 디스크 공간을 회수하고, 인덱스를 이용해 행을 재구성한다. REPACK CONCURRENTLY를 사용하면 작업 대부분이 진행되는 동안 읽기와 쓰기를 계속할 수 있다. 테이블 재구성 중 발생한 변경은 논리 디코딩으로 포착해 작업이 끝나기 전에 적용한다. 다만 마지막 테이블·인덱스 교체에는 ACCESS EXCLUSIVE 잠금이 필요하고, 임시 디스크 공간도 든다. 재구성 전에 스냅샷을 만든 트랜잭션의 가시성에도 유의해야 한다.

킨케이드는 업데이트와 삭제가 잦은 대표 테이블을 골라 실제 쓰기 부하와 장기 실행 트랜잭션이 있는 상태에서 시험하라고 권한다. 완료 시간뿐 아니라 회수한 공간, 임시 저장 공간, 애플리케이션 지연 시간, 마지막 잠금도 살펴야 한다. 이 기능의 개발에는 EDB의 알바로 에레라(Álvaro Herrera), 안토닌 하우스카(Antonin Houska), 미하일 니칼라예우(Mihail Nikalayeu)가 참여했다. 에레라는 EDB 블로그에서 관련 내용을 소개했다.

pg_plan_advice는 조인 순서와 스캔 방식 등 플래너의 특정 선택을 설명하고 재현하거나 제한하는 기능이다. 모듈을 불러온 뒤 EXPLAIN (PLAN_ADVICE)를 실행하면 선택 내용을 나타내는 조언 문자열을 만들 수 있다. 함께 제공되는 pg_stash_advice 확장은 쿼리 식별자별로 조언을 저장해 자동 적용할 수 있다. 자세한 내용은 PostgreSQL 문서에 나와 있다.

이 기능은 성능을 보편적으로 높이는 스위치가 아니며, 플래너를 대체하거나 모든 상황에서 같은 실행 계획을 보장하지도 않는다. 데이터가 바뀌면 이전에 유용했던 제한이 더 나은 계획을 막을 수 있다. 따라서 과거에 계획 변경으로 문제가 생긴 쿼리부터 대표적인 데이터와 매개변수로 시험하고, 조언을 필요한 범위로 좁혀 적용해야 한다. pg_plan_advice는 EDB 재직 당시 로버트 하스(Robert Haas)가 구현했다.

autovacuum은 인덱스 진공 작업과 정리에 병렬 작업자를 사용할 수 있게 되고, 진공·분석 작업의 우선순위를 정하는 점수 체계도 도입한다. pg_stat_autovacuum_scores 뷰에서 우선순위 점수를 확인할 수 있다. 진공의 모든 단계가 병렬로 실행되는 것은 아니다. 진공 작업 관련 문서를 참고해 자주 업데이트되는 테이블과 크지만 덜 바쁜 테이블을 함께 시험하고, 작업 우선순위와 유지보수 시간, 애플리케이션 지연, 자원 사용량을 비교할 수 있다.

논리 복제에서는 게시자에서 구독자로 시퀀스 값을 동기화할 수 있다. 구독 생성 시 초기 동기화를 수행할 수 있고, ALTER SUBSCRIPTION ... REFRESH SEQUENCES로 알려진 시퀀스를 다시 동기화할 수도 있다. 이 기능을 쓰려면 게시자가 PostgreSQL 19 이상이어야 하므로 구독자만 업그레이드해서는 이전 버전 게시자의 기능을 활성화할 수 없다. 게시자에서 시퀀스가 계속 증가하면 값이 다시 어긋날 수 있어, 지속적인 동기화로 전환 절차를 대체하는 기능은 아니다. 시퀀스 동기화 문서를 확인하고, 마이그레이션이나 전환 절차에서 시퀀스 정의와 동기화 완료 여부, 이후 애플리케이션이 생성할 값을 점검해야 한다.

기능 시험 외에도 호환성과 기본값 변경을 확인해야 한다. PostgreSQL 19에서는 JIT 컴파일이 기본적으로 비활성화되므로, 분석 작업에서 JIT의 이점을 얻는 팀은 기존 동작이 유지된다고 가정하지 말고 설정을 별도로 평가해야 한다. 실제 배포 환경의 쿼리, 확장, 드라이버, 데이터 분포, 유지보수 루틴을 반영한 비프로덕션 환경을 만들고 업그레이드와 복구도 연습하는 것이 좋다. 릴리스 후보는 테스트용이지 프로덕션 권고 버전이 아니며, 대표 작업 부하를 이용한 시험과 재현 가능한 버그 보고가 정식 출시 준비에 도움이 된다.