"PostgreSQL 19" 태그로 연결된 8개 게시물개의 게시물이 있습니다.

PostgreSQL 19부터 logical replication이 sequence 값을 subscriber로 동기화해요. 18까지는 테이블 데이터만 넘어가고 SERIAL/IDENTITY 뒤에 붙은 sequence는 subscriber에서 초기값에 그대로 멈춰 있어 promote 직후 첫 INSERT가 duplicate key로 터지는 사고가 흔했지만, 19는 publication에 ALL SEQUENCES 절을 들이고 ALTER SUBSCRIPTION ... REFRESH SEQUENCES 명령을 더해 이 오래된 구멍을 메웠어요.

이 글은 pgEdge의 Shaun Thomas(숀 토머스)가 쓴 "Looking Forward to Postgres 19: Logically Sequenced"를 한국어로 풀고, PostgreSQL 19 릴리스 노트와 실제 동작 데모로 사실을 교차검증합니다. DBA 관점에서 "failover 때 왜 사고가 났나", "19에서 무엇이 정확히 달라지고 무엇은 여전히 그대로인가"를 함께 봅니다.

sequence는 왜 그동안 복제 대상이 아니었나​

sequence가 logical replication에서 빠져 있던 데에는 구조적인 문제가 있었습니다. logical decoding은 WAL을 트랜잭션 단위로 재조립해 commit 순서대로 replay합니다. 철저히 트랜잭션 기반입니다.

그런데 sequence는 트랜잭션과 어울리지 않습니다. nextval()로 뽑은 값은 트랜잭션을 rollback해도 되돌아오지 않습니다. 한 번 소비된 번호는 영구히 사라집니다. 이 비트랜잭션 동작과 commit 순서 기반 decoding을 깔끔하게 화해시키기가 어려웠습니다.

실제로 Tomas Vondra(토마스 본드라)가 만든 "logical decoding of sequences" 패치가 PostgreSQL 16에 한 번 들어갔다가, 트랜잭션과 비트랜잭션 동작을 조율하는 난점 때문에 되돌려진 적이 있습니다. 그만큼 묵은 숙제였습니다. (pgEdge)

결과적으로 18 이하의 logical replication에서 sequence는 공식 문서의 제약 사항에 명시된 복제 제외 대상이었습니다. 테이블 row는 넘어가지만, 그 row의 id를 발급하는 sequence는 subscriber에서 따로 놀았습니다.

failover 때 무슨 사고가 났나​

운영 입장에서 이게 왜 문제였는지는 cutover 시나리오로 보면 분명합니다. zero-downtime upgrade나 마이그레이션에서 흔한 흐름입니다.

1. publisher(구 primary)에서 subscriber(신 primary)로 logical replication을 겁니다.
2. 테이블 데이터는 잘 넘어옵니다. row가 수백만 건 들어와 있고, id 컬럼은 publisher에서처럼 큰 값까지 차 있습니다.
3. cutover 시점에 subscriber를 promote하고 애플리케이션을 붙입니다.
4. 첫 INSERT가 떨어지는 순간 duplicate key value violates unique constraint로 터집니다.

원인은 단순합니다. 테이블의 id는 큰 값까지 차 있는데, 그 id를 발급하는 sequence는 subscriber에서 초기값(보통 1)에 그대로 멈춰 있었습니다. sequence가 복제 대상이 아니었으니 당연한 결과입니다. nextval()이 1을 돌려주는데, 그 자리는 이미 넘어온 데이터가 차지하고 있습니다.

그동안의 회피책은 cutover 직전에 손으로 sequence를 끌어올리는 것이었습니다.

-- 옛날 방식: 각 sequence를 publisher 값보다 높게 수동으로 밀어 올림
SELECT setval('public.orders_id_seq', 5000000 + 1000);

+ 1000 같은 인위적인 여유분은 cutover 도중 publisher에 추가로 들어올 write를 흡수하려는 안전 마진입니다. sequence가 수십/수백 개면 이걸 전부 스크립트로 긁어 돌려야 했고, 마진을 잘못 잡으면 번호가 비거나 충돌했습니다. failover runbook에서 늘 신경 쓰이던 자리였습니다.

PostgreSQL 19가 푸는 방식​

19는 이 작업을 logical replication 안으로 들였습니다. 릴리스 노트는 이렇게 적습니다.

Allow sequence values stored in subscribers to match the publisher (Vignesh C) — PostgreSQL 19 Release Notes

핵심은 세 조각입니다.

• publication에 ALL SEQUENCES 절이 생겼습니다.
• subscriber가 sequence 값을 publisher에서 당겨오는 시점이 세 개 정해졌습니다.
• 백그라운드에서 sequence를 배치로 당겨오는 sequencesync worker가 추가됐습니다.

publication의 ALL SEQUENCES​

publication이 sequence를 포함할 수 있습니다.

-- 테이블과 sequence를 함께 발행
CREATE PUBLICATION migration_pub FOR ALL TABLES, ALL SEQUENCES;

-- sequence만 발행도 가능
CREATE PUBLICATION pubseq FOR ALL SEQUENCES;

ALL SEQUENCES는 ALL TABLES와 함께 묶을 수 있습니다. 다만 TABLE이나 TABLES IN SCHEMA 같은 세밀한 옵션과는 함께 쓸 수 없습니다. (dbi-services)

여기서 첫 제약이 나옵니다. sequence는 개별 선택(cherry-pick)이 안 됩니다. 테이블처럼 "이 sequence만 publication에 넣겠다"가 불가능하고, 전부(ALL SEQUENCES) 아니면 전무입니다.

subscription의 동기화 시점​

subscription 쪽은 평소처럼 만듭니다.

CREATE SUBSCRIPTION migration_sub
  CONNECTION 'host=oldprimary dbname=app user=repl'
  PUBLICATION migration_pub;

sequence 값이 subscriber로 당겨지는 시점은 정확히 셋입니다. (릴리스 노트)

-- (1) CREATE SUBSCRIPTION — 최초 1회 당겨옴

-- (2) sequence 존재 여부 + 값을 publication에 맞춰 재조정
ALTER SUBSCRIPTION migration_sub REFRESH PUBLICATION;

-- (3) 값만 갱신 (membership 은 건드리지 않음)
ALTER SUBSCRIPTION migration_sub REFRESH SEQUENCES;

REFRESH PUBLICATION은 publication에서 sequence가 추가/제거된 것을 반영하면서 값도 맞춥니다. REFRESH SEQUENCES는 membership은 그대로 두고 값만 다시 당겨옵니다. 내부적으로는 pg_subscription_rel의 모든 sequence를 INIT 상태로 되돌린 뒤 sequencesync worker가 다시 채웁니다.

연속 동기화가 아닌 시점 동기화​

여기서 DBA가 반드시 머리에 둬야 할 한 가지가 있습니다. sequence 동기화는 연속이 아니라 시점 동기화입니다.

테이블 row처럼 publisher의 변경이 실시간으로 흐르지 않습니다. 위의 세 시점에만 값을 당겨오고, 그 직후부터 publisher가 새 번호를 발급하는 순간 subscriber의 값은 곧바로 낡은(stale) 값이 됩니다.

dbi-services의 데모가 이를 그대로 보여줍니다. publisher에서 sequence의 last_value가 3까지 올라가도 subscriber는 2에 머뭅니다. ALTER SUBSCRIPTION ... REFRESH SEQUENCES를 실행해야 비로소 3으로 맞춰집니다. 그 뒤 publisher에 다시 row를 넣어 sequence가 6까지 올라가도, subscriber는 또 멈춰 있고 다시 한번 refresh를 실행해야 따라옵니다. (dbi-services)

그래서 운영 원칙은 명확합니다. REFRESH SEQUENCES는 promote 직전에 실행합니다. 미리 돌려두면 그 사이 publisher가 발급한 번호만큼 다시 어긋납니다. cutover runbook에서 sequence refresh는 publisher write를 멈추고 promote로 넘어가기 바로 전 칸에 들어가야 합니다. (pgEdge)

동기화 흐름​

cutover 시점의 sequence 동기화를 단계로 그리면 이렇습니다.

worker는 INIT으로 표시된 sequence를 모아 publisher에서 현재 값과 page LSN을 가져와 subscriber에 쓰고, 끝나면 해당 항목을 READY로 바꿉니다. 배치로 처리해 빠릅니다. depesz의 테스트에서는 sequence 1만 개 동기화가 약 1초, 100ms당 약 1,200개 속도였습니다. (depesz)

상태와 모니터링​

sequence도 테이블처럼 pg_subscription_rel에서 상태를 가집니다. 동기화 전에는 INIT(i), 끝나면 READY(r)입니다.

SELECT c.relname, r.srsubstate, r.srsublsn
FROM pg_subscription AS s
JOIN pg_subscription_rel AS r ON s.oid = r.srsubid
JOIN pg_class AS c ON r.srrelid = c.oid;

  relname     | srsubstate | srsublsn
--------------+------------+------------
 orders_id_seq| r          | 0/04004780

srsubstate가 r이면 그 sequence는 READY 상태로 한 번 동기화를 마쳤다는 뜻입니다. (dbi-services)

값 자체를 확인할 때는 새로 들어온 pg_get_sequence_data() 함수를 씁니다.

SELECT last_value FROM pg_get_sequence_data('public.orders_id_seq');

오류 카운트도 새로 추적됩니다. pg_stat_subscription_stats 뷰에 sync_seq_error_count 컬럼이 추가됐고, 기존 sync_error_count는 sync_table_error_count로 이름이 바뀌었습니다. sequence 오류가 별도로 집계되기 때문입니다. 모니터링 대시보드가 sync_error_count를 직접 참조하고 있었다면 19 업그레이드 때 컬럼명을 손봐야 합니다. (릴리스 노트)

PostgreSQL 18 이하 vs 19​

운영 점검 포인트​

19로 올려 sequence 동기화를 쓰기 전에 한 번씩 확인할 자리들입니다.

cutover runbook에서는 REFRESH SEQUENCES를 publisher write 중단 후, promote 직전 칸에 둡니다. 미리 돌리면 그 사이 발급된 번호만큼 다시 어긋납니다.

publication을 설계할 때는 sequence를 개별 선택할 수 없다는 점을 고려합니다. 일부 sequence만 복제하려는 설계가 있었다면 ALL SEQUENCES 전체 발행 전제로 다시 봐야 합니다.

stale 값도 인지해야 합니다. 동기화는 연속으로 이루어지지 않으므로, 평상시 replication이 도는 동안에도 subscriber의 sequence가 따라가지 않는다는 사실을 모니터링 기준에 반영합니다.

모니터링 컬럼명도 확인합니다. pg_stat_subscription_stats의 sync_error_count를 직접 참조하던 쿼리/알람은 sync_table_error_count로 바꾸고, sync_seq_error_count도 함께 봅니다.

정리​

PostgreSQL 19의 sequence 동기화는 화려한 신기능이라기보다 logical replication에 오래 남아 있던 구멍을 메운 변화입니다. failover 직후 첫 INSERT가 duplicate key로 터지던 사고, 그리고 이를 막으려고 setval 마진 스크립트를 돌리던 수작업이 REFRESH SEQUENCES 한 줄로 정리됐습니다.

다만 연속 동기화가 아니라는 점이 이 기능의 성격을 결정하며, 평상시 흐르는 게 아니라 cutover 시점에 한 번 맞추는 도구예요. 그래서 진짜 가치는 zero-downtime upgrade와 마이그레이션 cutover에서 나와요. runbook의 정해진 칸에 한 줄을 넣고 promote 직전에 실행하면, sequence가 더 이상 사고의 출처가 아니게 돼요.

참고 자료​

• Looking Forward to Postgres 19: Logically Sequenced (pgEdge, Shaun Thomas)
• PostgreSQL 19 Release Notes
• PostgreSQL 19: Logical replication of sequences (dbi-services)
• Waiting for PostgreSQL 19 – Sequence synchronization in logical replication (depesz)
• Logical Replication Restrictions (PostgreSQL 18 Documentation)
• PostgreSQL 19의 wal_level: 고정값에서 동적 floor 값으로 (이 블로그)
• PostgreSQL 19 새 기능 총정리 (이 블로그)

PostgreSQL 19에서 data_checksums가 또 하나의 재시작 파라미터에서 벗어났어요. 이제 실행 중인 클러스터에서 재시작도 정지도 없이 page checksum을 켜고 끌 수 있어요. SQL 함수 하나를 실행하면 background worker가 모든 page를 다시 쓰면서 checksum을 입히고, 그동안 클러스터는 평소처럼 트래픽을 받아요.

이 글은 The Build의 Christophe Pettus(크리스토프 페투스)가 정리한 "All Your GUCs in a Row: data_checksums"를 한국어로 풀고, 13년에 걸친 data_checksums의 진화사와 PostgreSQL 19가 정확히 무엇을 바꿨는지를 DBA 시선으로 봅니다. 그리고 "온라인"이라는 단어가 "공짜"나 "즉시"를 뜻하지 않는다는 점까지 함께 짚습니다.

dbalog에는 PostgreSQL 19의 "재시작 없이 바꾼다" 계열 글이 이미 두 편 있습니다. wal_level이 고정값에서 동적 floor로 바뀐 이야기와 autovacuum_worker_slots로 worker 수를 재시작 없이 조절하는 이야기입니다. data_checksums의 온라인 전환은 그 흐름 위에 올라가는 또 한 칸입니다.

data_checksums가 무엇을 막아주나​

data_checksums는 page 단위 checksum 기능을 켜는 read-only GUC입니다. 켜져 있으면 PostgreSQL은 data page를 디스크에 쓸 때마다 checksum을 계산해 page 안에 함께 적고, 그 page를 다시 읽어 올릴 때 checksum을 검증합니다.

값이 맞지 않으면 PostgreSQL은 깨진 데이터를 그대로 돌려주지 않고 error를 냅니다. 여기서 막아주는 대상은 silent data corruption, 즉 조용히 번지는 손상입니다.

• bit rot, 디스크 위 데이터가 시간이 지나며 미세하게 망가지는 현상
• 고장 직전의 디스크가 슬그머니 잘못된 비트를 돌려주는 경우
• "썼다"고 응답해 놓고 실제로는 쓰지 않은 storage layer의 거짓말

이런 손상은 error 없이 흘러갑니다. checksum이 없으면 PostgreSQL은 깨진 page를 멀쩡한 데이터로 믿고 그대로 읽어 들이고, 그 위에 연산을 쌓습니다. 문제를 알아챌 무렵엔 이미 backup에까지 손상이 번진 뒤입니다.

검증에 실패하면 PostgreSQL은 pg_stat_database의 checksum_failures 카운터를 올립니다. DBA는 이 값을 모니터링해 손상이 처음 감지된 시점을 잡아낼 수 있습니다.

비용은 어떻습니까. 2013년 도입 당시엔 checksum 계산 부담이 켤 가치가 없을 만큼 크다고 봤습니다. 그래서 기본값이 off였습니다. 그 뒤로 하드웨어가 좋아지면서 오버헤드는 한 자릿수 퍼센트 초반대까지 내려왔고, 손상을 조기에 잡는 가치에 비하면 충분히 감당할 만한 수준이 됐습니다.

과거엔 켜기가 왜 고통이었나​

문제는 비용이 아니라 켜는 방법이었습니다. PostgreSQL 18까지 data_checksums를 켜는 길은 둘뿐이었고, 둘 다 운영 클러스터에는 무겁습니다.

첫째, initdb 시점에 정하는 것입니다. 클러스터를 처음 만들 때 checksum을 켜두면 그 클러스터는 평생 켜진 상태로 삽니다. 깔끔하지만 시점이 고약합니다. 이미 몇 년째 돌고 있는 운영 클러스터에는 적용할 길이 없습니다. "처음부터 켰어야 했다"는 후회만 남습니다.

둘째, pg_checksums로 오프라인 전환하는 것입니다. PostgreSQL 12에서 추가된 이 명령은 멈춰 있는 클러스터의 checksum 설정을 바꿔줍니다. 강조점은 "멈춰 있는"입니다.

# 반드시 클러스터를 먼저 정지한 상태에서 실행
pg_ctl -D /var/lib/pgsql/data stop
pg_checksums --enable -D /var/lib/pgsql/data
pg_ctl -D /var/lib/pgsql/data start

pg_checksums는 모든 heap과 index page를 한 장씩 읽어 checksum을 계산해 다시 씁니다. 멀티 테라바이트 클러스터라면 이 작업만 몇 시간이 걸립니다. 그리고 그 몇 시간 내내 클러스터는 내려가 있어야 합니다.

DBA에게 이건 사실상 "큰맘 먹고 잡는 점검 시간"입니다. 서비스 중단 공지를 내고, 새벽 시간을 확보하고, 작업이 예상보다 길어질 경우까지 대비해야 합니다. 그래서 많은 운영 클러스터가 checksum의 가치를 알면서도 "지금 켜기엔 다운타임이 부담"이라는 이유로 off인 채 남았습니다.

PostgreSQL 18에서 한 발 나아가긴 했습니다. initdb의 기본값이 checksum 켜짐으로 바뀌어, 새로 만드는 클러스터는 별도 조치 없이 checksum을 켠 채 출발합니다. 하지만 이는 새 클러스터 이야기입니다. 이미 돌고 있는 클러스터의 고민은 그대로였습니다.

PostgreSQL 19의 온라인 전환​

PostgreSQL 19는 마지막 매듭을 풉니다. 클러스터를 멈추지 않고 재시작도 없이 SQL 함수 호출만으로 checksum을 켜고 끕니다. 새로 들어온 함수는 둘입니다.

pg_enable_data_checksums(cost_delay integer DEFAULT 0, cost_limit integer DEFAULT 100)
pg_disable_data_checksums()

켜는 동작은 이렇게 실행합니다.

SELECT pg_enable_data_checksums();

이 함수는 곧바로 반환됩니다. 밀리초 단위입니다. 하지만 그 시점에 checksum이 다 입혀진 것은 아닙니다. 실제 작업은 background에서 비동기로 흐릅니다.

내부 동작은 이렇습니다. background worker launcher가 데이터베이스마다 per-database worker를 띄웁니다. 이 worker는 storage를 가진 모든 relation의 buffer를 dirty로 표시합니다. dirty page는 디스크로 다시 쓰일 때 checksum을 계산해 함께 적게 됩니다. 모든 데이터베이스의 모든 relation이 처리되고 나면, 그제야 data_checksums 상태가 on으로 넘어갑니다.

OS의 process 목록에서도 이 launcher와 worker가 보입니다.

postgres: datachecksum launcher
postgres: datachecksum worker

진행 중에 data_checksums가 가질 수 있는 상태는 다음과 같습니다.

SHOW로 현재 상태를 확인합니다.

SHOW data_checksums;
-- 진행 중:  inprogress-on
-- 완료 후:  on

끄는 동작도 같은 방식입니다.

SELECT pg_disable_data_checksums();

이 모든 과정에서 클러스터는 멈추지 않습니다. 읽기도 쓰기도 평소처럼 받습니다. PostgreSQL 19에서는 다운타임이 사라졌습니다.

전환 흐름 비교​

오프라인 전환과 온라인 전환의 차이를 한눈에 보면 이렇습니다.

PostgreSQL 18 이하의 경로는 정지-작업-재기동이라는 다운타임 구간을 통과해야 합니다. PostgreSQL 19는 그 구간 자체가 없습니다. 작업은 가동 중인 클러스터 위에서 background로 흐릅니다.

상태 전이로 보면 켜는 과정은 다음과 같이 움직입니다.

여기서 DBA가 기억할 점이 하나 있습니다. inprogress-on은 "켜지는 중"이지 "켜짐"이 아닙니다. 모든 page가 처리되기 전까지는 on으로 넘어가지 않습니다.

DBA 관점에서 보는 온라인 전환의 시간과 비용​

함수가 밀리초 만에 반환된다고 해서 작업이 끝난 것은 아닙니다. 이 지점에서 운영 실수가 갈립니다. Christophe Pettus는 이 작업의 무게를 "minor version 업그레이드와 전체 클러스터 VACUUM FULL 사이 어디쯤"으로 보고 계획하라고 권합니다.

기억할 점을 정리하면 이렇습니다.

진짜 작업은 background에서 진행됩니다. 함수 반환은 시작 신호일 뿐이며, 멀티 테라바이트 클러스터에서 모든 page를 재작성하려면 몇 시간이 걸립니다.

이 작업은 다른 작업과 자원을 다툽니다. page 재작성은 autovacuum, 평상시 워크로드, backup 작업과 디스크 I/O를 두고 경쟁합니다. burst IOPS를 쓰는 클라우드 인스턴스라면 burst 예산을 일찍 소진하고 throttle 구간에 들어갑니다.

중간에 끊으면 일부 page에는 checksum이 입혀지고 일부에는 입혀지지 않은 mixed state로 남습니다. 이 상태 자체는 안전하지만, 작업이 끝나기 전까지 data_checksums는 on으로 넘어가지 않습니다. 오래 머물 상태는 아닙니다.

그래서 켜는 함수에는 throttle 제어가 붙어 있습니다. cost_delay와 cost_limit은 autovacuum의 vacuum cost 의미를 그대로 따릅니다. worker가 cost_limit만큼 작업 단위를 쌓을 때마다 cost_delay 밀리초씩 쉬게 해서, 평상시 워크로드에 주는 압박을 낮춥니다.

-- worker가 자원을 덜 차지하도록 천천히 진행
SELECT pg_enable_data_checksums(cost_delay => 1, cost_limit => 3000);

운영 현장에서 잡을 체크리스트는 단순합니다.

• 트래픽이 한가한 시간대를 골라 시작합니다.
• autovacuum이 급한 작업을 들고 있지 않은지 확인합니다.
• backup window와 겹치지 않게 합니다.
• 진행 중에는 pg_stat_io로 I/O 부하를, replication을 쓴다면 replica lag을 함께 봅니다.

PostgreSQL 19의 이번 변화를 앞선 두 글과 나란히 놓으면 방향이 또렷합니다. wal_level은 재시작 파라미터에서 동적 floor로, autovacuum worker 수는 재시작 없이 조절 가능하게, 그리고 이제 data_checksums는 클러스터를 멈추지 않고 켜고 끄는 대상이 됐습니다. "운영 중에 바꾸려면 재시작/정지가 필요하던 설정"의 목록이 한 칸씩 줄고 있습니다.

다만 방향이 같다고 비용까지 같진 않습니다. wal_level의 effective level 전환은 다음 checkpoint면 끝나지만, data_checksums의 온라인 전환은 디스크 위 모든 page를 다시 쓰는 무거운 작업입니다. "재시작이 사라졌다"와 "부담 없이 켤 수 있다"는 다른 말입니다. 다운타임은 없앴지만, I/O 비용과 소요 시간은 그대로 DBA의 계획표 위에 남습니다.

정리​

• data_checksums는 page 단위 checksum으로 silent data corruption을 조기에 잡아주는 기능입니다. 실패는 pg_stat_database.checksum_failures로 드러납니다.
• PostgreSQL 18까지는 initdb 시점에 고정하거나, 클러스터를 정지하고 pg_checksums로 오프라인 전환해야 했습니다. 운영 클러스터엔 다운타임이 부담이었습니다.
• PostgreSQL 18부터 initdb 기본값이 켜짐으로 바뀌어, 새 클러스터는 별도 조치 없이 checksum을 켠 채 출발합니다.
• PostgreSQL 19는 pg_enable_data_checksums() / pg_disable_data_checksums()로 가동 중인 클러스터에서 재시작 없이 켜고 끌 수 있게 했습니다. background worker가 모든 page를 다시 쓰며, 진행 중 상태는 inprogress-on / inprogress-off로 보입니다.
• 다운타임은 사라졌지만 작업 자체는 무거워요. 멀티 테라바이트 클러스터에서 몇 시간이 걸리고 다른 I/O와 경쟁하므로, cost_delay / cost_limit throttle과 한가한 시간대 시작이 필요해요.

출처​

• All Your GUCs in a Row: data_checksums — The Build
• Online Checksums Are Not Instant — The Build
• Waiting for PostgreSQL 19 – Online enabling and disabling of data checksums — depesz
• PostgreSQL 19: Online enabling of data checksums — dbi services
• PostgreSQL Documentation: Data Checksums
• PostgreSQL Documentation: pg_checksums

Big 4를 한눈에​

Christophe Pettus가 The Build에서 정리한 PostgreSQL 19 Beta Big 4에는 공통점이 있어요. 넷 다 피처 노트로 끝나지 않고 운영 시나리오를 바꾼다는 점이에요. 신규 syntax 한 줄에 그치지 않고, DBA의 메모리 계산식, 장애 시나리오, 튜닝 기본값을 다시 그리게 만들어요.

업데이트 (2026-06-04): PostgreSQL 19 Beta 1이 공식 릴리스됐습니다. 이 글이 예고한 Big 4는 모두 Beta 1에 그대로 담겼습니다: 64bit MultiXact members(Make multixid members 64-bit), 병렬 autovacuum worker(autovacuum_max_parallel_workers), UPDATE/DELETE FOR PORTION OF, JIT 기본 비활성화입니다. 정식 출시는 9월~10월 예정이며, 그사이 release candidate가 한 차례 이상 나옵니다.

PostgreSQL 19는 9월 정식 출시 예정입니다. 이번 글은 Pettus의 Big 4 큐레이션을 출발점으로 삼아, 거기에 DBA 점검 항목, 메모리 계산식, SQL 예시, 업그레이드 체크리스트를 보탠 글입니다. 네 가지 선정은 Pettus의 시각이고, 운영 점검, 메커니즘 해설, 업그레이드 절차는 기존 PG19 시리즈 5편이 다루지 않은 부분을 채우는 보완/확장입니다.

왜 이 Big 4인가​

PostgreSQL 19의 변경 목록은 CommitFest 5회분의 수백 건입니다. 그중 DBA가 실제로 체감하는 변화는 보통 둘 중 하나입니다.

• 장애 회피: 지금까지 운영 매뉴얼에 "이거 터지면 끝"으로 적혀 있던 시나리오가 사라집니다.
• 튜닝 기본값 변경: 업그레이드 직후 워크로드 성격에 따라 plan 시간, 메모리, 비상 상황이 달라집니다.

Pettus가 꼽은 Big 4는 정확히 그 두 축에 들어갑니다. 새 syntax나 새 알고리즘이라기보다, 기존 운영 매뉴얼을 손보게 만드는 변경들입니다.

1. 64bit MultiXact members가 없앤 긴급 vacuum 시나리오​

무엇이 바뀌었나​

MultiXact 멤버 카운터가 32bit에서 64bit로 확장됐습니다. 4 billion(약 40억) 멤버 공간 고갈 시나리오가 사실상 사라집니다.

DBA가 왜 체감하나​

PostgreSQL에는 DBA 사이에서 "이게 터지면 끝"으로 통하는 시나리오가 몇 개 있습니다. MultiXact wraparound는 거기 한참 머물러 있었습니다.

SELECT ... FOR SHARE, foreign-key check 같은 공유 row lock이 같은 행에 여러 트랜잭션에서 동시에 걸리면, PostgreSQL은 그 잠금 정보를 묶어서 MultiXact라는 별도 구조에 기록합니다. 각 MultiXact는 멤버 슬롯을 소비합니다. 그 멤버 카운터의 자료형이 PostgreSQL 19에서 처음으로 확장됐습니다.

42억은 운영 부하가 큰 워크로드(공유 lock + FK check 누적)에서 실제로 도달할 수 있는 수치입니다. 1844경은 사실상 도달이 불가능한 영역으로 넘어갑니다.

주의: XID/mxid wraparound는 그대로다​

DBA가 흔히 "wraparound"라고 묶어 부르는 경우는 사실 셋입니다. 이번 변경은 그중 하나에 한정됩니다.

PostgreSQL의 오래된 숙제인 XID wraparound와 mxid wraparound는 PostgreSQL 19에서도 살아 있습니다. autovacuum이 주기적으로 freeze를 수행해야 하는 이유가 정확히 이것입니다. 이번 글이 다루는 "해결된 wraparound"는 MultiXact members 카운터 하나뿐임을 분명히 해 둡니다.

64bit XID 확장은 2018년부터 PostgreSQL hackers 메일링 리스트에서 논의돼 왔습니다. Postgres Pro가 PostgreSQL 15 시기에 실험적 패치 시리즈로 동작 확인까지 갔지만, tuple 헤더 크기 증가, 모든 index format 재설계, WAL format 변경 같은 광범위한 ripple effect 때문에 main 브랜치 commit으로 이어지지 않았습니다. PostgreSQL 19에서도 같은 상태입니다. PostgreSQL의 가장 오래된 숙제 중 하나가 한 라운드 더 미뤄졌고, 그 사이 DBA는 autovacuum freeze 튜닝과 pg_visibility/pg_class.relfrozenxid 모니터링을 손에서 놓을 수 없습니다.

운영 영향은 이렇게 정리됩니다.

42억 한계에 도달하면 DBA가 마주하는 그림은 단순했습니다. 새 트랜잭션이 거부되고, 복구 경로는 offline emergency VACUUM 하나. Pettus의 한 줄이 이를 짚습니다.

"When exhausted, the system would refuse new transactions, and the only recovery path was an emergency VACUUM."

이론적으로 wraparound 수학은 2^64에서도 여전히 존재합니다. 다만 같은 워크로드를 우주의 나이만큼 굴려도 도달이 어렵습니다. 32bit 공간 도달 사례는 운영 사고 보고서들에 종종 등장했지만, 64bit는 실무 카탈로그에서 제외할 수 있습니다.

DBA가 할 일​

• 운영 매뉴얼/런북에서 "MultiXact wraparound" 비상 절차 항목을 "PG 19부터는 도달 불가"로 갱신
• 단, PostgreSQL 18 이하 운영 중인 클러스터는 그대로 이 시나리오가 살아 있으니 모니터링 대시보드를 유지

Beta 1에는 이 부분을 보강하는 변경도 함께 들어왔습니다. multixact 활동을 보여 주는 pg_get_multixact_stats() 함수가 추가됐고, xid/multixact wraparound 경고 임계값이 기존 4천만에서 1억 건 남았을 때로 올라갔습니다(클라이언트와 서버 로그 양쪽에 경고). 여전히 살아 있는 xid/mxid wraparound를 그만큼 더 일찍 알아챌 수 있습니다.

2. 병렬 autovacuum 인덱스 worker와 메모리 계산식​

무엇이 바뀌었나​

새 GUC autovacuum_max_parallel_workers가 추가됩니다. autovacuum이 단일 테이블의 인덱스 정리를 여러 worker로 병렬 처리합니다. PostgreSQL 17에서 도입된 manual VACUUM의 병렬 인덱스 정리가 autovacuum 경로까지 확장됐습니다.

DBA가 왜 체감하나​

인덱스가 많이 붙은 wide table을 운영해 본 사람은 압니다. autovacuum이 돌면 heap 정리는 빠른데 인덱스 정리 단계에서 한참 멈춰 있습니다. 단일 worker가 인덱스 N개를 순차로 도는 구조였기 때문입니다.

PostgreSQL 19에서는 같은 단계에 worker가 동시에 들어갑니다. wide-and-many-indexes 테이블의 autovacuum 시간이 줄어들고, vacuum 누적 부담이 풀립니다.

-- 새 GUC (값은 예시)
ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;
SELECT pg_reload_conf();

주의: 최악 메모리 식이 달라진다​

같은 변경이 운영 부담을 새로 만드는 지점도 있습니다. 각 병렬 worker는 자기 몫의 maintenance_work_mem을 따로 잡습니다.

autovacuum_max_workers=3, autovacuum_max_parallel_workers=4, maintenance_work_mem=1GB인 환경에서 최악 메모리 사용량은 3 × 4 × 1GB = 12GB가 됩니다. PostgreSQL 18까지의 3GB와 4배 차입니다.

DBA는 PostgreSQL 19 업그레이드 전에 세 가지를 확인합니다.

1. maintenance_work_mem 현재 값
2. autovacuum_max_workers 현재 값
3. 위 두 곱에 새 GUC 곱을 더한 값이 시스템 메모리에 맞는가

maintenance_work_mem을 1GB 이상으로 키워 놓은 운영 환경(분석 워크로드/큰 인덱스 재정렬 빈도가 잦은 곳)은 특히 다시 계산해야 합니다.

"명백한 이득"이 보이는 경우는 한정적입니다. serial 인덱스 정리가 vacuum의 병목이던 wide table에서 가장 큰 폭으로 줄어듭니다.

DBA가 할 일​

• 업그레이드 전 메모리 식 재계산. RAM이 빠듯하면 autovacuum_max_parallel_workers를 기본보다 낮춰 시작
• wide table/인덱스 다수 테이블에서 autovacuum 지속 시간 모니터링 (pg_stat_progress_vacuum)
• 한꺼번에 너무 많은 worker가 깨어나 I/O 포화되지 않도록 autovacuum_vacuum_cost_limit 검토

3. UPDATE ... FOR PORTION OF, SQL:2011 시간 범위가 PostgreSQL로​

무엇이 바뀌었나​

시간 범위(period) 컬럼을 가진 테이블에서 부분 범위만 UPDATE 또는 DELETE할 수 있게 됐습니다. SQL:2011 표준 syntax입니다.

-- 가격 이력 테이블 (period 컬럼 사용 가정)
CREATE TABLE price_history (
    product_id int,
    price numeric,
    valid_period daterange,
    PERIOD FOR valid_period (valid_from, valid_to)
);

-- 2026-06-01 ~ 2026-06-15 구간만 가격 변경
UPDATE price_history
FOR PORTION OF valid_period
FROM DATE '2026-06-01' TO DATE '2026-06-15'
SET price = price * 0.9
WHERE product_id = 42;

이전에는 DBA가 직접 row를 자르고 새 row를 끼워 넣는 SQL을 손으로 썼습니다. PostgreSQL 19부터는 한 문장으로 끝납니다. 건드리지 않은 범위의 row는 자동으로 보존됩니다.

DBA가 왜 체감하나​

가격 이력, 직원 직책 이력, 권한 이력, 보험료 이력처럼 시간 범위 컬럼을 두는 모델은 흔합니다. 매번 손으로 자르는 SQL을 짜는 대신 syntax 한 줄로 정리되는 경우가 늘어납니다.

다만 새 운영 사각지대도 함께 생깁니다.

주의: row trigger/cascading FK​

Pettus가 직접 짚습니다.

"a FOR PORTION OF update can fire row triggers on rows that did not exist when the statement started."

(FOR PORTION OF UPDATE는 문이 시작될 때 존재하지 않던 row에 대해서도 row trigger를 발화시킬 수 있다.)

내부적으로 FOR PORTION OF는 원본 row를 잘라 새 row 두 개(또는 세 개)로 분리하고, 그중 하나에 UPDATE를 적용합니다. 그 결과 DELETE 트리거가 원본 row에, INSERT 트리거가 새 보존 row 둘에, UPDATE 트리거가 갱신된 부분 row에 각각 발화합니다.

cascading foreign-key 동작은 한 단계 더 복잡해집니다. parent 행의 시간 범위가 잘리면 child의 FK 동작이 어떻게 따라가는지 production에서 테스트하지 않고 올리면 사고 가능성이 큽니다. parent의 부분 UPDATE가 child를 DELETE해야 하는가, CASCADE해야 하는가, RESTRICT해야 하는가. 이런 운영 정책 결정이 SQL 한 줄 안에 묻혀 들어갑니다.

DBA가 할 일​

• FOR PORTION OF를 production에 올리기 전에 row trigger, FK, audit trigger 동작을 staging에서 전부 확인
• 트리거가 row 단위로 카운트를 세는 코드(예: audit row 개수 검증)는 PostgreSQL 19에서 결과가 다를 수 있으니 재검토

4. jit = off 기본값, PostgreSQL 12 이후 처음의 방향 전환​

무엇이 바뀌었나​

Just-in-time compilation 기본값이 off로 바뀝니다. PostgreSQL 12에서 jit = on이 기본값으로 들어온 이후 처음 있는 방향 전환입니다.

DBA가 왜 체감하나​

이 변경은 워크로드 성격에 따라 정반대 결과를 만듭니다.

Pettus는 OLAP 회귀의 크기를 한 줄로 묘사합니다.

"a six-minute report now takes nineteen."

(6분짜리 리포트가 19분 걸리게 된다.)

3배 회귀 사례를 예고하는 대목입니다. OLAP 클러스터를 PostgreSQL 19로 올리면서 jit = on을 명시 설정하지 않으면, 출시 직후 가장 먼저 받는 분기 보고서가 평소보다 한참 늦게 도착합니다.

DBA가 할 일​

OLTP 클러스터는 그대로 두면 자연스럽게 plan 효율 개선합니다. 별도 설정 불필요. OLAP/분석 클러스터는 업그레이드 직후 ALTER SYSTEM SET jit = on; 실행합니다. 또는 분석 사용자의 ALTER ROLE ... SET jit = on;으로 user-level 지정. 혼합 워크로드는 pgBouncer 등의 connection pool에서 분석 트래픽 분리한 뒤 그쪽만 jit = on 적용

왜 방향이 바뀌었는가​

PostgreSQL 12에서 JIT를 기본 활성화한 동기는 "분석 쿼리에서 측정 가능한 가속이 있다"였습니다. 하지만 운영 통계가 쌓이면서, OLTP가 절대 다수인 PostgreSQL 운영 현실에서 plan 시간 오버헤드 손실이 컴파일 가속 이득을 자주 초과한다는 점이 드러났습니다. 6년 만에 측정에 근거해 기본값을 되돌린 것입니다.

PostgreSQL 19 업그레이드 체크리스트 (이번 Big 4)​

업그레이드 전 다음을 점검합니다.

업그레이드 직후에는 다음을 즉시 확인합니다.

-- 1. autovacuum 동작 확인
SELECT * FROM pg_stat_progress_vacuum;

-- 2. JIT 설정 확인 (OLAP면 명시 on)
SHOW jit;

-- 3. 새 GUC 확인
SHOW autovacuum_max_parallel_workers;

정리​

앞의 표에서 정리했듯 64bit MultiXact members는 최악 wraparound 시나리오를 제거하지만 PG 18 이하 클러스터 모니터링은 유지해야 하고, 병렬 autovacuum 인덱스 worker는 wide table autovacuum 시간을 단축하지만 최악 메모리 사용량 식이 달라집니다. UPDATE/DELETE FOR PORTION OF는 시간 범위 SQL을 한 줄로 정리하는 대신 row trigger/cascading FK 동작을 재검증해야 하고, 기본 jit = off는 OLTP plan 시간을 단축하지만 OLAP는 명시 활성화 안 하면 회귀합니다.

PostgreSQL 19는 화려한 신기능보다 운영 매뉴얼을 다시 쓰게 만드는 쪽에 가까운 릴리스예요. DBA 입장에서 이번 Big 4는 9월 정식 출시 전에 staging에서 한 번 돌려 보고, 메모리 식, 튜닝 기본값, 운영 매뉴얼 세 가지를 같이 갱신해야 해요.

기존 PostgreSQL 19 새 기능 총정리와 PostgreSQL 19 시리즈 4편이 "어떤 기능이 들어오는가"를 봤다면, 이번 글은 "어떤 운영이 달라지는가"를 봐요. 두 글을 같이 두면 PostgreSQL 19를 올리기 전 점검할 항목이 한곳에 모여요.

참고​

• PostgreSQL News — PostgreSQL 19 Beta 1 Released! (2026-06-04)
• PostgreSQL Docs — Release 19
• The Build — PostgreSQL 19 Beta: The Four Features You'll Actually Feel
• PostgreSQL 19 Open Items (PostgreSQL Wiki)
• JIT Compilation (PostgreSQL Docs)
• autovacuum (PostgreSQL Docs)
• PostgreSQL 19 새 기능 총정리 (본 블로그)
• PostgreSQL 19 EXPLAIN ANALYZE RDTSC (본 블로그), 파티션 MERGE/SPLIT, SQL/PGQ, wal_level 동적화

PostgreSQL 19에서 wal_level이 의미를 바꿨어요: 더 이상 "이 서버가 항상 쓰는 WAL 레벨"이 아니라 하한값이며, 실제 effective level은 그 위에서 slot 상태에 따라 자동으로 움직여요. logical replication slot이 하나 생기면 effective level이 logical로 올라가고, 마지막 slot이 사라지면 다음 checkpoint에서 내려가요.

이 글에서는 The Build의 Christophe Pettus가 다룬 "The wal_level You Set Is Not the wal_level You Get"을 한국어로 풀고, cascading standby와 archived WAL에서 운영자가 한 번은 부딪힐 자리들을 함께 살펴봅니다.

보험성 wal_level=logical 의 비용​

기존 PostgreSQL에서 wal_level은 셋 중 하나로 못 박혀 있었습니다 — minimal, replica, logical. 변경하려면 서버를 재시작해야 했습니다.

운영 패턴이 자연스럽게 굳어졌습니다. 지금 당장 logical replication을 쓰지 않더라도, 나중에 쓸 가능성이 조금이라도 있으면 일단 logical로 잡아둡니다. 그래야 그날 새벽에 슬롯 하나 만들면서 재시작을 잡을 일이 없습니다. "혹시 모르니까" 라는 안전망입니다.

이 안전망에는 비용이 붙습니다.

• wal_level = logical은 모든 변경에 대해 추가 메타데이터를 WAL에 적습니다. row의 이전 이미지, replica identity 정보, 다중행 변경의 stream 표식 등입니다.
• 실제로 logical replication slot이 단 하나도 없어도 적힙니다. "지금 안 쓰는데 적어두는 값"이 분 단위로 디스크에 흐릅니다.
• 운영 환경에 따라 다르지만, replica 대비 WAL 볼륨이 10~30% 더 늘어나는 케이스가 흔히 보고됩니다.
• WAL 볼륨이 늘면 archive 비용, streaming replication 대역폭, PITR 복구 시간이 같이 늘어납니다.

"The right thing has corners." — Christophe Pettus, The Build

PostgreSQL 19는 이 안전망의 비용을 덜기 위해 wal_level을 "고정 레벨"에서 "최소 보장"으로 바꿨습니다.

PG19의 configured wal_level과 effective wal_level​

PostgreSQL 19에서 서버는 두 개의 WAL level을 가집니다.

configured wal_level은 postgresql.conf에 적힌 값입니다. 여전히 재시작 파라미터이며, "이 서버가 어떤 경우에도 떨어지지 않을 하한값"을 뜻합니다. effective wal_level은 서버가 실제로 지금 WAL에 쓰는 레벨이며, configured 값보다 위로 올라갈 수 있습니다.

규칙은 단순합니다.

즉, configured를 replica로 잡아두고도 logical replication slot을 만드는 순간 서버가 알아서 logical로 올라갑니다. 마지막 slot이 사라지면 다음 checkpoint에서 다시 내려갑니다.

상태 전이도​

중요한 지점은 두 군데입니다 — logical 진입 시점은 forced checkpoint 직후이고, 다시 내려가는 시점은 그다음 일반 checkpoint입니다. 두 시점은 비대칭입니다.

동작 단계​

올라갈 때와 내려갈 때를 따로 봅니다.

올라갈 때: logical로의 전이

1. 운영자(또는 publication 생성 시 PostgreSQL)가 첫 logical replication slot 생성을 요청합니다.
2. 서버는 effective level이 logical 미만이면 즉시 forced checkpoint를 돕니다.
3. 이 checkpoint 직후의 LSN을 "guaranteed LSN"으로 기록하고, slot은 그 지점부터 시작합니다.
4. 그 LSN 이후의 WAL은 logical 레벨 메타데이터를 함께 적기 시작합니다.

내려갈 때: replica로의 하강

1. 마지막 logical slot이 사라집니다.
2. 서버는 다음 일반 checkpoint까지 그대로 logical을 유지합니다. 즉시 내리지 않습니다.
3. 그 checkpoint가 돌고 나면 effective level이 configured 값으로 복귀합니다.
4. 이후 WAL은 다시 replica 메타데이터로 가벼워집니다.

이 비대칭은 의도된 설계입니다. 올라갈 때는 slot이 막 만들어진 WAL을 읽지 못하면 안 되므로 checkpoint를 즉시 실행합니다. 내려갈 때는 별도 checkpoint를 잡아 운영 영향을 만들 이유가 없습니다.

운영 영향​

가장 큰 효과는 WAL 볼륨 절감입니다.

• "혹시 모르니까 logical"로 잡아둔 클러스터는, configured를 replica로 내리고 PG19로 올리면 그대로 WAL이 줄어듭니다. 실제로 logical을 쓸 일이 생기면 그 순간 자동으로 올라가니 운영 부담은 늘지 않습니다.
• archive 비용, streaming replication 대역폭, PITR 복구 시간이 모두 따라 줄어듭니다.
• 클라우드 관리형 PostgreSQL에서는 archive 저장 비용이 매월 청구되는 항목이라 체감이 큽니다.

부차 효과는 logical replication을 사용 중인 동안에만 그 비용을 낸다는 점입니다. 일회성 마이그레이션을 위해 logical을 켰다가 작업을 마치면 비용이 자동으로 사라집니다.

함정과 주의사항​

네 가지를 짚습니다.

첫째, cascading standby의 비대칭입니다. primary와 standby는 각자 effective level을 따로 가집니다. primary의 마지막 logical slot이 사라져도 standby는 자신의 슬롯이 살아있는 한 effective logical을 유지합니다. primary가 보내는 WAL은 그새 replica로 내려갈 수 있지만, standby는 자기 슬롯을 위해 그 WAL을 logical로 받아야 합니다. 이 경계는 운영자에게 보이지 않는 곳에서 정렬됩니다. PG19가 알아서 잘 처리하지만, replication lag를 분석할 때 헷갈리지 않으려면 "두 노드의 effective level은 따로 움직인다"는 사실을 머리에 둬야 합니다.

둘째, archive에 mixed-level WAL이 섞입니다. 같은 archive 디렉토리에 replica 시기의 WAL과 logical 시기의 WAL이 함께 쌓입니다. PostgreSQL은 segment마다 metadata로 어떤 레벨인지 표시해두지만, "이 archive는 통째로 logical이다" 같은 가정을 두고 작성한 PITR script가 있다면 다시 봐야 합니다.

셋째, prepared transaction입니다. 2-phase commit 자체의 동작은 변하지 않습니다. 다만 prepared transaction이 많은 환경에서는 logical 전이 시점의 forced checkpoint가 의외로 오래 걸릴 수 있습니다. 테스트 환경에서 한 번은 의도적으로 재현해 보고 timeout 설정을 검토하는 편이 좋습니다.

넷째, 첫 slot 생성 시 checkpoint 대기입니다. 새로 만든 publication이 logical slot을 생성하면 그 호출이 forced checkpoint를 기다립니다. 평소 checkpoint 부담이 큰 시스템에서는 수십 초가 걸릴 수도 있습니다. 자동화 script가 CREATE SUBSCRIPTION 호출에 짧은 timeout을 걸어뒀다면 PG19 업그레이드 직후 한 번 흔들릴 가능성이 있습니다.

PITR / archive script 점검 포인트​

PostgreSQL 19로 올라가기 전에 한 번씩 확인할 자리들입니다.

archive level과 관련해서는 script가 "이 archive는 logical 레벨"임을 전제로 메타데이터를 파싱하지 않는지 확인합니다. slot 생성 timeout은 자동화 도구의 CREATE SUBSCRIPTION / pg_create_logical_replication_slot 호출에 30초 미만으로 설정되어 있지 않은지 살펴봅니다.

WAL 볼륨 모니터링에서는 PG19로 올린 직후 WAL 생성률이 줄어드는 변화를 정상으로 인식하는지 확인합니다. 감소를 장애로 판단해 알람을 보내지 않도록 해야 합니다. cascading 구성에서는 primary, intermediate, leaf의 effective level이 각각 어떻게 정렬되는지 그림으로 한 번 그려두는 편이 좋습니다.

"혹시 모르니까"라는 비용​

logical replication을 본격적으로 쓰기 시작한 계기는 zero-downtime upgrade와 CDC 파이프라인입니다. 한 번 켜놓으면 끝나는 것이 아니라 "혹시 다음 마이그레이션 때 또 쓸지 모르니까" wal_level = logical 그대로 두는 패턴이 굳어졌습니다. 그 사이 WAL 볼륨이 10~30% 더 흐르고, archive 비용과 streaming replication 대역폭이 같이 늘어납니다 — 평소에는 의식하지 못하지만 PITR 복구 시간을 재 보면 한 번씩 보여요. PostgreSQL 19의 동적 wal_level은 이 "보험 비용"을 시점성 비용으로 바꿉니다. 일회성 마이그레이션이 끝나면 slot만 정리해도 effective level이 자동으로 내려가고 WAL이 가벼워집니다. 운영자가 wal_level을 내릴지 말지 회의에 올릴 일이 없어진다는 점이 PG19가 일상에 주는 가장 큰 차이입니다.

정리​

PostgreSQL 19는 운영자가 "혹시 모르니까"라는 이유로 영구히 짊어졌던 비용을 시점성 비용으로 바꿔, logical replication이 필요한 그 순간에만 그 비용을 내게 해요. 기본 동작이 더 똑똑해진 변화지만, cascading standby와 archive처럼 effective level이 노드별로 따로 움직이는 곳에서는 모서리가 한 번씩 보여요.

참고 자료​

• The wal_level You Set Is Not the wal_level You Get: The Build
• PostgreSQL 19 Release Notes
• WAL Configuration: PostgreSQL Documentation
• Logical Replication: PostgreSQL Documentation
• PostgreSQL 19 새 기능 총정리: 이 블로그
• pgBackRest의 종료, 그리고 Barman/CNPG로 이어지는 길: 이 블로그
• PostgreSQL 18의 autovacuum_worker_slots: 이 블로그
• Barman 시작하기, 5개 명령어로 첫 백업과 PITR 복구까지: 이 블로그

들어가며​

PostgreSQL 19는 SQL/PGQ(SQL Property Graph Queries) 를 코어에 들였어요. ISO/IEC 9075-16:2023, 즉 SQL:2023 Part 16으로 표준화된 기능이에요.

그래프 워크로드를 다루려면 Neo4j나 ArangoDB 같은 전용 DB를 띄우거나, PostgreSQL 위에 Apache AGE 확장을 올리는 길이 대표적이었습니다. 데이터는 멀쩡히 관계형 테이블에 들어 있는데 권한, 조직도, 추천 같은 일부 쿼리만 그래프 모양으로 풀고 싶을 때는, 그 절반쯤만 필요한 인프라를 들이는 셈이라 늘 어색했습니다.

SQL/PGQ는 그 회색 지대를 노립니다. 기존 테이블 위에 그래프 뷰를 얹고, 표준 SQL 안에서 그래프 패턴 매칭을 그대로 씁니다.

이 글은 PostgreSQL 19 베타 직전 기준으로 작성되었으며, 정식 출시 전까지 일부 문법이 조정될 수 있습니다. 앞선 PostgreSQL 19 새 기능 총정리의 후속편으로 읽으면 좋습니다.

SQL/PGQ가 푸는 문제​

"아이유를 팔로우하는 사용자가 좋아요를 누른 게시물의 작성자"를 표준 SQL로 풀려면 어떻게 써야 할까요. users, follows, liked, posts, authored 다섯 테이블을 차례로 조인해야 합니다.

SELECT DISTINCT author.handle, p.content
FROM users iu
JOIN follows  f        ON f.followee_id = iu.id
JOIN users    follower ON follower.id = f.follower_id
JOIN liked    l        ON l.user_id = follower.id
JOIN posts    p        ON p.id = l.post_id
JOIN authored a        ON a.post_id = p.id
JOIN users    author   ON author.id = a.user_id
WHERE iu.handle = '아이유';

동작은 합니다. 그러나 한눈에 들어오지 않습니다. 어느 컬럼이 출발이고 어느 컬럼이 도착인지, 팔로우의 방향이 어디로 향하는지 매번 머릿속에서 다시 짚어야 합니다. 한 홉만 더 늘려도 조인이 두 줄씩 붙습니다.

SQL/PGQ는 이 코드를 시각적 패턴으로 옮깁니다. 정점은 괄호 (), 간선은 꺾쇠 -[]->. 의도가 그대로 보입니다.

다만 PostgreSQL 19의 첫 구현은 고정 깊이 패턴까지입니다. 정량 패턴(+, *, {2,5})과 가변 길이 경로는 다음 릴리스로 미뤄졌습니다. 이 글에서 다루는 범위는 그 첫 구현입니다.

CREATE PROPERTY GRAPH로 그래프 뷰 정의하기​

먼저 그래프를 선언합니다. 데이터는 옮기지 않습니다. 기존 정점 테이블과 간선 테이블을 그래프로 어떻게 볼지를 카탈로그에 기록할 뿐입니다.

아래는 소셜 서비스 도메인을 그래프로 노출하는 예시입니다. 사용자와 게시물을 정점으로, 팔로우, 작성, 좋아요를 간선으로 잡습니다.

CREATE PROPERTY GRAPH social
  VERTEX TABLES (
    users LABEL person PROPERTIES (id, handle, joined_at),
    posts LABEL post   PROPERTIES (id, content, posted_at)
  )
  EDGE TABLES (
    follows
      SOURCE      KEY (follower_id) REFERENCES users (id)
      DESTINATION KEY (followee_id) REFERENCES users (id)
      LABEL follows PROPERTIES (followed_at),
    authored
      SOURCE      KEY (user_id) REFERENCES users (id)
      DESTINATION KEY (post_id) REFERENCES posts (id)
      LABEL authored,
    liked
      SOURCE      KEY (user_id) REFERENCES users (id)
      DESTINATION KEY (post_id) REFERENCES posts (id)
      LABEL liked PROPERTIES (liked_at)
  );

세 가지만 짚으면 충분합니다. VERTEX TABLES는 정점 데이터를 들고 있는 실제 테이블이고, LABEL로 그래프상 노드 이름을 지정합니다. 정점 테이블은 여러 개 둘 수 있어서 여기서는 users와 posts 두 종류를 잡았습니다. EDGE TABLES는 간선 데이터를 들고 있는 실제 테이블인데, SOURCE KEY와 DESTINATION KEY가 화살표의 출발과 도착을 결정합니다. 같은 정점을 잇는 follows와 서로 다른 정점을 잇는 authored/liked가 한 그래프 안에 공존합니다. 마지막으로 PROPERTIES는 그래프 패턴에서 노출할 컬럼만 골라 잡습니다. 모든 컬럼을 자동으로 끌어오지는 않습니다.

CREATE PROPERTY GRAPH는 새 테이블을 만들지 않습니다. users, posts, follows, authored, liked는 그대로 남고, 그 위에 social이라는 그래프 객체 하나가 더 생깁니다. DROP PROPERTY GRAPH social로 언제든 떼어낼 수 있습니다.

GRAPH_TABLE과 MATCH로 패턴 매칭하기​

쿼리 쪽 핵심은 GRAPH_TABLE입니다. 그래프 패턴을 받아 관계형 행 집합으로 돌려줍니다. 즉 결과를 다시 일반 SQL의 FROM 절에서 받아 쓸 수 있습니다.

1홉: 아이유를 팔로우하는 사용자​

SELECT handle
FROM GRAPH_TABLE (social
  MATCH (iu IS person WHERE iu.handle = '아이유')
        <-[f IS follows]-
        (follower IS person)
  COLUMNS (follower.handle AS handle)
);

화살표가 왼쪽으로 향합니다. "아이유를 팔로우하는 사람들"을 찾는다는 뜻입니다. 같은 의도를 오른쪽 방향으로 쓰려면 패턴의 시작점을 팔로워로 바꾸면 됩니다. 의미는 같지만 가독성은 사람에 따라 갈립니다.

COLUMNS (...) 절은 패턴 안에서 잡은 값을 일반 컬럼으로 투영합니다. 이름이 곧 결과 컬럼명이 됩니다.

3홉: 팔로워가 좋아요 누른 게시물의 작성자​

SELECT DISTINCT author.handle, p.content
FROM GRAPH_TABLE (social
  MATCH (iu IS person WHERE iu.handle = '아이유')
        <-[IS follows]-
        (follower IS person)
        -[IS liked]->
        (p IS post)
        <-[IS authored]-
        (author IS person)
  COLUMNS (author.handle, p.content)
);

앞서 일곱 번 조인으로 풀던 쿼리가 패턴 한 덩어리로 줄었습니다. 화살표 방향이 의도와 그대로 일치합니다.

간선 변수 이름은 본문에서 쓰지 않으면 생략해 -[IS liked]->처럼 적을 수 있습니다. 간선 속성을 다시 꺼내야 할 때만 -[l IS liked]->처럼 이름을 붙이면 됩니다.

양방향 매칭은 <-[e]->로 씁니다. 다만 PostgreSQL 19에서는 양방향 자유 매칭이 일부 제한되며, 단방향 두 번으로 풀어쓰는 편이 안전합니다.

내부 동작과 rewriter의 역할​

SQL/PGQ는 새 실행 엔진을 들고 오지 않습니다. 파서가 GRAPH_TABLE을 만나면 rewriter가 그래프 패턴을 표준 관계형 트리로 풀어 씁니다. 정점은 RangeTblEntry가 되고, 간선은 출발 테이블, 간선 테이블, 도착 테이블 사이의 3-way 조인이 됩니다. 그 결과 트리는 일반 플래너로 그대로 흘러갑니다.

이 설계가 가져오는 결과는 셋입니다. 우선 기존 인덱스를 그대로 씁니다. 간선 테이블의 (follower_id, followee_id)나 (user_id, post_id) 같은 복합 인덱스가 그래프 쿼리에서도 그대로 활용됩니다. MVCC와 트랜잭션도 자동으로 따라오니, 별도 그래프 엔진이라면 따로 신경 써야 했을 부분이 사라집니다. EXPLAIN도 여전히 의미가 있어서, 결국 보이는 건 일반 조인 플랜이고 평소 쓰던 튜닝 도구가 다 통합니다.

대신 그래프 쿼리의 성능은 결국 조인 최적화에 종속됩니다. 간선이 많고 선택도가 낮은 패턴은 대량 조인이 될 수 있습니다. 인덱스와 통계 정보가 평소처럼 중요합니다.

PostgreSQL 19에 들어간 것 vs 빠진 것​

정리하면 이렇습니다. 모양이 정해진 그래프 질의는 PostgreSQL 19에서 곧장 풀 수 있고, 모양이 가변인 그래프 질의는 여전히 재귀 CTE의 영역에 남습니다.

가변 길이 지원은 다음 메이저 릴리스의 1차 후보로 거론됩니다. rewriter가 재귀 CTE 또는 자기조인 반복으로 펴는 형태가 유력합니다.

다른 옵션과 비교​

선택지가 늘었으니 정리해 둘 만합니다.

이미 PostgreSQL에 든 데이터를 가볍게 그래프로 보고 싶다면 SQL/PGQ가 첫 후보입니다. 그래프 자체가 1급 워크로드라면 여전히 Apache AGE나 Neo4j가 더 멀리 갑니다.

언제 쓰면 좋은가​

쓰기 좋은 쪽부터 짚습니다. 가장 자연스러운 건 권한/조직도 탐색입니다. "이 사용자의 상위 N단계 관리자"처럼 깊이가 정해진 질의가 여기 들어갑니다. "내가 산 상품을 산 사람이 산 다른 상품" 같은 가벼운 추천, 친구의 친구 정도로 얕은 소셜 그래프, 기존 BI 쿼리에 그래프 패턴을 끼워 넣는 분석 워크로드도 잘 맞습니다.

반대로 적합하지 않은 경우는 분명합니다. 트리 루트까지 N단계를 거슬러 오르거나 도달 가능한 모든 노드를 훑는 것처럼 깊이가 가변인 traversal, PageRank, 중심성, 커뮤니티 탐지 같은 본격 그래프 알고리즘은 이 범위를 벗어납니다. 수억 노드급 그래프도 마찬가지인데, 이쪽은 네이티브 그래프 저장소의 인덱스/캐시 구조가 더 유리합니다.

선택 기준 자체는 단순합니다. 그래프 모양 질의가 늘면 SQL/PGQ로 옮기고, 그래프 워크로드가 본진이 되는 순간 전용 엔진으로 갑니다.

마무리​

PostgreSQL 19의 SQL/PGQ는 화려한 신기능이라기보다 관계형 DB가 그래프 워크로드를 흡수하는 첫 발판에 가깝습니다. 첫 릴리스는 의도적으로 좁습니다. 고정 깊이부터 안정적으로 굳히고, 가변 길이는 다음으로 미루는 그림입니다.

제가 주목하는 지점은 몇 가지예요. 표준이 코어로 들어와 Apache AGE와 SQL/PGQ가 한 데이터베이스 안에서 공존할 수 있게 됐고, 새 엔진을 들이지 않고 기존 플래너에 얹은 rewriter 기반 설계라 운영 부담도 최소이며, 가변 길이를 일단 빼고 출시한 절제 역시 신기능 폭주 대신 표준 추종을 우선한 결정으로 읽혀요.

9월 정식 출시 전 베타 단계에서 한 번쯤 만져볼 만한 기능으로, 같은 시리즈의 PostgreSQL 19 새 기능 총정리, EXPLAIN ANALYZE RDTSC, 파티션 MERGE/SPLIT도 함께 참고할 수 있어요.

참고 자료​

• PostgreSQL 19 Release Notes (devel)
• Representing graphs in PostgreSQL with SQL/PGQ — EnterpriseDB
• SQL/PGQ Property Graph Queries — DeepWiki
• Graph Databases, SQL/PGQ, And PostgreSQL — PGConf.in 2025 발표 자료
• Exploring property graphs with SQL/PGQ in PostgreSQL — POSETTE 2026
• PostgreSQL 19 새 기능 총정리

PostgreSQL 파티셔닝의 짧은 역사​

PostgreSQL의 파티셔닝은 10 버전에서 선언적(declarative) 문법이 들어온 이후 꾸준히 성숙해왔어요. 13에서 UPDATE로 파티션 간 row 이동이 가능해졌고, 14에서 DETACH PARTITION CONCURRENTLY가 추가됐어요. 그리고 PostgreSQL 19에서 마침내 파티션 자체를 병합하고 분할하는 DDL이 들어와요.

ALTER TABLE ... SPLIT PARTITION ...
ALTER TABLE ... MERGE PARTITIONS ...

익숙한 문법입니다. Oracle을 써본 사람이라면 20년 넘게 봐온 구문과 거의 판박입니다. 다만 자세히 보면 문법과 제약에서 결정적인 차이들이 있습니다.

이전까지 PostgreSQL에서는 어떻게 했나​

PostgreSQL 18 이하에서 파티션을 병합하려면 이런 절차를 거쳤습니다.

1. 새로운 합쳐진 파티션 테이블을 생성
2. 기존 파티션에서 INSERT SELECT로 데이터 이동
3. 기존 파티션 DETACH
4. 새 파티션 ATTACH
5. 기존 파티션 DROP

한 번에 트랜잭션으로 묶기도 까다롭고, 데이터 이동 중 ACCESS EXCLUSIVE LOCK이 걸려 서비스 가용성에도 영향을 줍니다. 분할도 마찬가지로 귀찮았습니다. Oracle에서는 한 줄이면 끝나는 작업이었습니다.

PostgreSQL 19의 새 문법​

SPLIT과 MERGE를 각각 예제로 살펴보겠습니다.

SPLIT PARTITION​

-- 원본 파티션 테이블
CREATE TABLE sales (
    id bigint generated always as identity,
    region text not null,
    amount numeric
) PARTITION BY LIST (region);

CREATE TABLE sales_all PARTITION OF sales
    FOR VALUES IN ('KR', 'JP', 'CN', 'US', 'UK');

-- 하나의 파티션을 셋으로 분할
ALTER TABLE sales SPLIT PARTITION sales_all INTO (
    PARTITION sales_asia FOR VALUES IN ('KR', 'JP', 'CN'),
    PARTITION sales_us   FOR VALUES IN ('US'),
    PARTITION sales_uk   FOR VALUES IN ('UK')
);

MERGE PARTITIONS​

-- 세 파티션을 하나로 합치기
ALTER TABLE sales MERGE PARTITIONS
    (sales_asia, sales_us, sales_uk)
    INTO sales_all;

문법에서 눈여겨볼 점은 다음과 같습니다.

• 지원 타입: RANGE, LIST (HASH는 지원하지 않음)
• RANGE 파티션은 인접(adjacent) 해야 병합 가능
• LIST는 인접 제약 없음
• 소스 파티션들은 괄호 (...)로 감싼다
• 대상 파티션에 PARTITION 키워드를 붙이지 않는다

Oracle의 문법​

같은 일을 Oracle에서 하면 이렇게 됩니다. Oracle 쪽은 8i 시절부터 존재해온 문법이라 변주가 많습니다.

SPLIT PARTITION​

-- RANGE 파티션 분할 (AT 값 기준)
ALTER TABLE sales SPLIT PARTITION sales_2026 AT (DATE '2026-07-01')
    INTO (
        PARTITION sales_2026_h1 TABLESPACE ts1,
        PARTITION sales_2026_h2 TABLESPACE ts2
    );

-- LIST 파티션 분할 (VALUES 기준)
ALTER TABLE sales SPLIT PARTITION sales_all
    VALUES ('KR', 'JP', 'CN')
    INTO (
        PARTITION sales_asia,
        PARTITION sales_rest
    );

MERGE PARTITIONS​

-- 기본 문법
ALTER TABLE sales MERGE PARTITIONS
    sales_q1_2026, sales_q2_2026, sales_q3_2026, sales_q4_2026
    INTO PARTITION sales_2026;

-- RANGE 전용 TO 단축 문법
ALTER TABLE sales MERGE PARTITIONS
    sales_q1_2026 TO sales_q4_2026
    INTO PARTITION sales_2026;

나란히 비교​

문법 차이​

기능/제약 차이​

실전에서 갈리는 락과 온라인 실행​

문법은 거의 맞춰졌습니다. 하지만 운영에서 진짜 갈리는 것은 락과 온라인 실행 여부입니다.

PostgreSQL 19​

공식 커밋 메시지와 depesz의 벤치(1천만 행 LIST 파티션 기준)에서 확인된 내용은 다음과 같습니다.

• 작업 전체 구간에서 ACCESS EXCLUSIVE LOCK 유지
• 단일 프로세스에서 순차 실행
• 대규모 파티션에서는 실질적 다운타임이 발생할 수 있음

쓸모 있는 평가는 이렇습니다. "편의성은 크게 좋아졌지만, 온라인성은 Oracle을 따라잡지 못했습니다." 한 줄 SQL로 간단히 표현할 수 있게 된 것만으로도 의미가 크지만, 수백 GB 파티션을 무중단으로 합칠 수 있는 수준은 아닙니다.

Oracle​

Oracle Enterprise Edition 12.2부터 ONLINE 키워드로 DML 블로킹 없이 파티션을 합치거나 쪼갤 수 있습니다.

ALTER TABLE sales MERGE PARTITIONS
    sales_q1_2026, sales_q2_2026
    INTO PARTITION sales_h1_2026
    ONLINE;

내부적으로는 shadow 구조를 만들고 점진적으로 데이터를 이관하는 방식이라, 배타 락 보유 시간이 거의 없습니다. Enterprise Edition 라이선스가 전제라는 게 큰 단서지만, 대형 운영 환경에서 체감되는 차이는 큽니다.

어디까지 따라왔고, 어디까지 아직인가​

따라잡은 것

• SPLIT/MERGE DDL 자체의 존재: SQL 한 줄로 끝납니다
• 지원 파티션 타입 (RANGE, LIST)
• 인접 조건 정책 (RANGE는 인접 필요, LIST는 무관)
• 다중 분할(한 파티션 → N개)과 다중 병합(N개 → 하나)

아직 못 따라온 것

• 온라인(ONLINE) 실행: 대형 파티션은 실질적 다운타임이 남음
• 병렬 실행: 단일 프로세스로만 처리
• RANGE 범위 병합 단축 문법(p1 TO p4) 없음

PostgreSQL의 역사적 약점 중 하나가 "큰 파티션 테이블의 유지보수가 DDL 한 줄로 안 끝난다"였습니다. PostgreSQL 19는 그 거리를 눈에 띄게 좁혔습니다. 다만 운영에서 가장 아픈 "락을 오래 붙잡는다"는 문제는 남아 있어서, 대형 테이블은 여전히 DETACH CONCURRENTLY + 수동 작업 전략을 병용해야 할 수 있습니다.

Oracle에서 PostgreSQL로 넘어올 때 "제가 쓰던 그 문법, PostgreSQL에도 있어요?"라는 질문의 목록이 하나씩 채워지고 있어요. 이번은 파티션 병합/분할 차례였어요.

참고

• Waiting for PostgreSQL 19 – Implement ALTER TABLE … MERGE/SPLIT PARTITIONS — depesz
• PostgreSQL devel — ALTER TABLE 문서
• Oracle Database VLDB Guide — Merging Multiple Partitions
• Oracle Base — Partition Maintenance Operations in 12c Release 1

EXPLAIN ANALYZE의 불편한 진실​

EXPLAIN ANALYZE는 PostgreSQL에서 쿼리 성능을 분석할 때 가장 먼저 쓰는 도구예요. 실제로 쿼리를 실행하면서 각 노드의 실행 시간, 행 수, 루프 횟수를 보여줘요.

그런데 한 가지 문제가 있습니다. EXPLAIN ANALYZE를 붙이는 것 자체가 쿼리를 느리게 만듭니다.

이건 버그가 아니라 구조적인 문제입니다. 공식 문서에서도 이렇게 경고합니다.

"The measurement overhead added by EXPLAIN ANALYZE can be significant, especially on machines with slow gettimeofday() operating-system calls."

왜 느려지나​

EXPLAIN ANALYZE는 실행 계획의 각 노드를 통과할 때마다 시간을 측정합니다. 구체적으로는 InstrStartNode(시작)과 InstrStopNode(종료)에서 시스템 시계를 읽습니다.

핵심은 이 시계를 읽는 함수가 clock_gettime()이라는 것입니다.

쿼리 실행 흐름:

  SeqScan (100만 행)
    ├─ 행 1: clock_gettime() → 처리 → clock_gettime()
    ├─ 행 2: clock_gettime() → 처리 → clock_gettime()
    ├─ 행 3: clock_gettime() → 처리 → clock_gettime()
    │  ...
    └─ 행 1,000,000: clock_gettime() → 처리 → clock_gettime()

  → clock_gettime() 호출 횟수: 200만 번

100만 행을 스캔하면 clock_gettime()이 200만 번 호출됩니다. 중첩된 노드가 있으면 더 늘어납니다. 각 호출이 약 20ns라고 해도, 200만 번이면 40ms의 순수 오버헤드가 발생합니다.

프로파일링을 해보면 InstrStartNode/InstrStopNode의 실행 시간 대부분이 clock_gettime()에서 소비됩니다. 실제 쿼리 로직이 아니라 시간 측정에 시간을 쓰고 있는 것입니다.

clock_gettime()이 뭔데​

clock_gettime()은 Linux에서 고해상도 시간을 가져오는 시스템 콜입니다. 정확하고 안정적이지만, 호출할 때마다 비용이 듭니다.

현대 Linux에서는 VDSO (Virtual Dynamic Shared Object)를 통해 커널 진입 없이 호출할 수 있도록 최적화되어 있습니다. 그래도 호출당 약 18~20ns의 오버헤드가 있습니다. 플랫폼에 따라 20~100ns까지 달라질 수 있습니다.

clock_gettime() 호출 경로:

  사용자 공간 → VDSO → TSC 레지스터 읽기 → 보정 → 반환
                ↑
                커널 진입 없이 실행되지만
                보정 로직 때문에 여전히 비용 발생

매번 이 경로를 거치는 게 문제입니다. 쿼리 노드 처리 시간이 수십 ns 수준이면, 시간 측정 비용이 실제 처리 비용보다 클 수도 있습니다.

TIMING FALSE라는 우회로​

사실 PostgreSQL 9.4부터 이 문제의 우회 방법은 있었습니다.

EXPLAIN (ANALYZE, TIMING FALSE) SELECT * FROM large_table;

TIMING FALSE를 쓰면 시간 측정을 건너뜁니다. 실제 행 수와 루프 횟수만 보여줍니다. 오버헤드가 거의 사라집니다.

하지만 타이밍이 없으면 어느 노드가 병목인지 알 수 없습니다. 그래서 실무에서는 결국 TIMING TRUE(기본값)를 쓰게 됩니다.

pg_test_timing 유틸리티로 현재 시스템의 타이밍 오버헤드를 확인할 수 있습니다.

$ pg_test_timing
Testing timing overhead for 3 seconds.
Per loop time including overhead: 18.80 ns

PostgreSQL 19의 해결책: RDTSC​

PostgreSQL 19에서는 x86-64 CPU의 RDTSC (Read Time-Stamp Counter) 명령어를 활용합니다.

RDTSC란​

CPU에는 TSC(Time Stamp Counter)라는 카운터가 있습니다. CPU 클럭마다 1씩 증가하는 레지스터입니다. RDTSC 명령어는 이 카운터 값을 직접 읽습니다.

clock_gettime():  사용자 공간 → VDSO → 보정 로직 → 반환
RDTSC:            CPU 레지스터 직접 읽기 → 반환

시스템 콜도, VDSO 경유도, 보정 로직도 없습니다. CPU 명령어 하나로 끝납니다.

성능 비교​

pg_test_timing으로 측정한 결과:

200만 번 호출 기준으로 환산하면:

단일 쿼리에서 14ms라면 크지 않아 보이지만, 중첩 노드가 있거나 행 수가 더 많으면 오버헤드는 기하급수적으로 늘어납니다.

RDTSC vs RDTSCP​

두 명령어의 차이를 알아두면 좋습니다.

RDTSC는 CPU의 비순차 실행(out-of-order execution)으로 인해 측정 순서가 살짝 뒤바뀔 수 있습니다. 하지만 EXPLAIN ANALYZE에서는 상대적인 시간 차이만 보면 되므로, 약간의 부정확함은 문제가 되지 않습니다.

PostgreSQL 19는 EXPLAIN ANALYZE에는 빠른 RDTSC를, 높은 정밀도가 필요한 다른 경우에는 RDTSCP를 사용합니다.

timing_clock_source 설정​

새로운 timing_clock_source 파라미터로 클럭 소스를 제어할 수 있습니다.

-- 현재 설정 확인
SHOW timing_clock_source;

-- 변경 (postgresql.conf 또는 SET)
SET timing_clock_source = 'rdtsc';      -- 빠름, 약간 낮은 정밀도
SET timing_clock_source = 'rdtscp';     -- 높은 정밀도
SET timing_clock_source = 'system';     -- 기존 clock_gettime()

x86-64 CPU에서 해당 명령어를 지원하면 자동으로 RDTSC를 사용합니다. ARM 등 다른 아키텍처에서는 기존 방식이 유지됩니다.

주의사항​

x86-64 전용​

이번 최적화는 x86-64 아키텍처 전용입니다. ARM 기반 서버(AWS Graviton 등)에서는 적용되지 않습니다. 향후 ARM용 최적화도 추가될 수 있지만, 초기 릴리즈에는 포함되지 않았습니다.

TSC 신뢰성​

모든 x86-64 CPU에서 TSC가 동일하게 동작하지는 않습니다. 오래된 CPU나 가상화 환경에서는 TSC가 불안정할 수 있습니다. PostgreSQL은 TSC 지원 여부를 확인한 후 자동으로 적절한 클럭 소스를 선택합니다.

변화의 체감​

일상적인 EXPLAIN ANALYZE 사용에서 이 변화를 극적으로 체감하기는 어려울 수 있습니다. 하지만 대량 행을 처리하는 복잡한 쿼리에서는 측정 오버헤드 감소가 실행 시간 측정의 정확도를 높여준다는 점이 핵심입니다.

역사: 6년간의 논의​

이 아이디어가 처음 나온 건 2020년입니다. Andres Freund가 PostgreSQL Hackers 메일링 리스트에 "Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?" 라는 제목으로 제안했습니다.

6년 동안 논의와 구현이 이어진 끝에 PostgreSQL 19에 드디어 포함되었습니다. 아이디어 자체는 단순하지만, TSC 안정성 검증, 다양한 CPU/VM 환경 호환성, 정밀도 트레이드오프 같은 세부 사항을 해결하는 데 시간이 걸렸습니다.

정리​

EXPLAIN ANALYZE를 프로덕션에서 쓰는 건 여전히 주의가 필요해요. 하지만 PostgreSQL 19부터는 측정 때문에 발생하는 노이즈가 줄어들어, 더 정확한 성능 분석이 가능해져요.

참고 자료​

• Reduced timing overhead for EXPLAIN ANALYZE with RDTSC — pganalyze
• Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? — PostgreSQL Hackers
• EXPLAIN ANALYZE may be lying to you — OnGres
• A Systems Engineer's Guide to Benchmarking with RDTSC
• Time, but Faster — ACM Queue
• PostgreSQL Documentation: EXPLAIN

PostgreSQL 19 개요​

PostgreSQL 19는 2026년 9월 출시 예정이에요. 기능 동결(Feature Freeze)은 4월 8일에 완료되었고, 5월에 첫 번째 베타가 나올 예정이에요.

PostgreSQL 18이 비동기 I/O, UUIDv7, 가상 생성 컬럼 같은 굵직한 기능을 가져왔다면, PostgreSQL 19는 기존 기능의 실질적 개선과 성능 최적화에 집중하는 릴리즈입니다. 화려하진 않지만 실무에서 체감할 수 있는 변화가 많습니다.

이 글은 2026년 4월 기준으로 작성되었으며, 정식 출시 전까지 일부 내용이 변경될 수 있습니다.

쿼리 플래너 & 실행​

GROUP BY ALL​

SELECT department, role, COUNT(*)
FROM employees
GROUP BY ALL;

GROUP BY ALL을 쓰면 집계 함수가 아닌 SELECT 표현식을 자동으로 GROUP BY에 포함합니다. 컬럼 5개를 일일이 나열할 필요가 없어졌습니다.

Eager Aggregation​

대용량 테이블을 조인하기 전에 먼저 집계하는 최적화입니다. enable_eager_aggregate 파라미터로 제어합니다.

-- 플래너가 자동으로 orders를 먼저 집계한 후 customers와 조인
SELECT c.name, SUM(o.amount)
FROM customers c JOIN orders o ON c.id = o.customer_id
GROUP BY c.name;

조인 대상 행 수가 줄어들기 때문에 대용량 분석 쿼리에서 성능이 크게 개선될 수 있습니다.

COUNT() 자동 최적화​

COUNT(1), COUNT(not_null_col)을 자동으로 COUNT(*)로 변환합니다. 습관적으로 COUNT(1)을 쓰던 사람들에게는 반가운 변화입니다.

병렬 TID Range Scan​

TID Range Scan이 병렬 실행을 지원합니다. 대규모 테이블에서 특정 범위의 물리적 행을 빠르게 스캔할 수 있습니다.

Incremental Sort 확장​

Append/MergeAppend 노드 내에서도 Incremental Sort가 가능해졌습니다. 파티션 테이블의 정렬 성능이 개선됩니다.

EXPLAIN ANALYZE 타이밍 오버헤드 감소​

x86-64 CPU에서 RDTSC 명령어를 활용해 시간 측정 오버헤드를 약 38% 줄였습니다. 이 주제는 별도 포스트에서 상세히 다룹니다.

윈도우 함수 개선​

IGNORE NULLS / RESPECT NULLS​

lag, lead, first_value, last_value, nth_value에서 NULL 처리 방식을 지정할 수 있습니다.

SELECT
  ts,
  value,
  last_value(value) IGNORE NULLS OVER (ORDER BY ts) AS last_non_null
FROM sensor_data;

시계열 데이터에서 NULL 값을 건너뛰고 마지막 유효 값을 가져오는 패턴이 훨씬 간결해졌습니다. 이전에는 서브쿼리나 래터럴 조인이 필요했습니다.

파티셔닝​

MERGE / SPLIT PARTITIONS​

-- 파티션 병합
ALTER TABLE bookings MERGE PARTITIONS (p_2024_q1, p_2024_q2) INTO p_2024_h1;

-- 파티션 분할
ALTER TABLE bookings SPLIT PARTITION p_2024 INTO
  (PARTITION p_2024_h1 FOR VALUES FROM ('2024-01-01') TO ('2024-07-01'),
   PARTITION p_2024_h2 FOR VALUES FROM ('2024-07-01') TO ('2025-01-01'));

파티션을 병합하거나 분할하는 DDL이 추가되었습니다. 기존에는 새 파티션을 만들고 데이터를 이동한 뒤 기존 파티션을 삭제해야 했습니다.

COPY TO with Partitioned Tables​

파티션 테이블에서 직접 COPY TO가 가능해졌습니다. 이전에는 각 파티션을 개별적으로 복사해야 했습니다.

논리 복제 (Logical Replication)​

WAL 레벨 동적 조정​

서버 재시작 없이 WAL 레벨을 변경할 수 있습니다. effective_wal_level 읽기 전용 파라미터로 현재 상태를 확인합니다.

이전에는 wal_level = logical 설정 변경 후 반드시 재시작이 필요했습니다. 운영 중인 시스템에서 논리 복제를 활성화할 때 다운타임을 줄일 수 있습니다.

시퀀스 복제​

논리 복제에서 시퀀스 값을 동기화할 수 있습니다.

ALTER SUBSCRIPTION my_sub REFRESH SEQUENCES;

WAIT FOR LSN​

레플리카가 특정 LSN까지 동기화될 때까지 대기하는 메커니즘입니다. 읽기 일관성이 필요한 경우에 유용합니다.

동기화 모니터링​

pg_replication_slots에 slotsync_skip_reason 컬럼이 추가되어 슬롯 동기화 지연 원인을 파악할 수 있습니다.

성능 최적화​

jsonb_agg 성능 향상​

jsonb_agg 함수의 성능이 50% 이상 개선되었습니다. JSON 집계가 많은 API 백엔드에는 반가운 변화입니다.

LISTEN/NOTIFY 최적화​

채널별 해시 테이블 기반으로 처리 방식이 변경되어, 많은 채널을 사용하는 환경에서 성능이 개선됩니다.

ICU 문자 변환 최적화​

UTF-8 데이터베이스에서 ICU 문자 변환 함수의 성능이 향상되었습니다.

Buffer Cache 알고리즘 변경​

Free buffer list를 Clock-sweep 알고리즘으로 교체했습니다.

Temporary Table 트렁케이션 고속화​

임시 테이블 truncation 처리가 빨라졌습니다.

모니터링 & 관찰성​

pg_stat_statements 확장​

• Generic/Custom 플랜별 호출 횟수 추적
• FETCH 명령어 정규화
• IN 절 파라미터 리스트 정규화

VACUUM / ANALYZE 진행 상황​

• mode, started_by 컬럼 추가로 수동/자동 실행 구분 가능
• VACUUM VERBOSE에서 메모리 사용량 표시
• vacuumdb --dry-run 옵션 추가
• log_autoanalyze_min_duration 신규 파라미터로 ANALYZE 로깅 분리

pg_buffercache 확장​

pg_buffercache_os_pages로 OS 페이지 분포를 확인할 수 있습니다.

WAL 모니터링​

wal_fpi_bytes로 Full Page Image 바이트를 추적합니다.

멀티트랜잭션 통계​

pg_get_multixact_stats() 함수로 멀티트랜잭션 사용 현황을 확인할 수 있습니다.

SQL & 함수​

random() 날짜/시간 생성​

SELECT random('2024-01-01'::date, '2024-12-31'::date);

지정 범위 내 랜덤 날짜/시간을 생성할 수 있습니다. 테스트 데이터 생성이 간편해졌습니다.

base64url 인코딩​

encode/decode 함수에서 URL-safe한 base64url 포맷을 지원합니다.

error_on_null()​

NULL 값 검증 함수가 추가되었습니다. NULL이 들어오면 에러를 발생시킵니다.

SRF(Set-Returning Function) 인라인​

Set-returning 함수의 인라인 최적화가 지원됩니다.

관리 & 도구​

regdatabase 타입​

데이터베이스 이름과 OID를 상호 변환하는 새 객체 식별자 타입입니다.

CHECKPOINT 개선​

FLUSH_UNLOGGED, MODE 파라미터가 추가되었습니다.

pg_upgrade 대용량 객체 최적화​

대용량 객체(Large Object) 마이그레이션이 빨라졌습니다.

psql 개선​

• %S 프롬프트 옵션으로 검색 경로 표시
• boolean 값 표시 커스터마이징 (\pset display_true)

pgbench​

--continue-on-error 옵션으로 에러 발생 시에도 벤치마크를 계속 진행할 수 있습니다.

그래프 쿼리 (SQL/PGQ)​

PostgreSQL 19는 SQL:2023 Part 16(SQL/PGQ) 을 코어에 들였습니다. 관계형 테이블 위에 프로퍼티 그래프 뷰를 얹고, GRAPH_TABLE과 MATCH 구문으로 그래프 패턴 매칭을 표준 SQL 안에서 풉니다. 별도 그래프 DB나 확장 없이 PostgreSQL만으로 일부 그래프 워크로드를 받아낼 수 있게 되었습니다.

첫 구현은 고정 깊이 패턴까지입니다. 가변 길이 경로는 다음 릴리스의 1차 후보입니다. 이 주제는 분량이 커서 별도 포스트에서 상세히 다룹니다.

호환성 주의​

standard_conforming_strings 비활성화 불가​

이제 standard_conforming_strings를 off로 설정할 수 없습니다. 비표준 문자열 리터럴(\' 등)은 에러를 발생시킵니다. escape_string_warning 파라미터도 제거되었습니다.

기존에 E'...' 없이 역슬래시 이스케이프를 쓰던 레거시 코드가 있다면 확인이 필요합니다.

log_lock_waits 기본값 변경​

log_lock_waits가 기본적으로 활성화됩니다. 잠금 대기 로그가 자동으로 남습니다.

마무리​

PostgreSQL 19는 눈에 띄는 신기능보다는 기존 기능의 완성도를 높이는 릴리즈입니다.

제가 개인적으로 주목하는 기능은 매일 쓰게 될 편의 기능인 GROUP BY ALL, 분석 쿼리 성능에 직접 영향을 주는 Eager Aggregation, 운영 중 논리 복제 활성화를 편하게 해주는 WAL 레벨 동적 조정이에요. IGNORE NULLS는 시계열 처리를 깔끔하게 해주고, 표준 그래프 쿼리를 코어에 들인 SQL/PGQ도 눈에 들어와요. EXPLAIN ANALYZE RDTSC는 다음 글에서, SQL/PGQ는 후속편에서 상세히 다룹니다.

2026년 9월 정식 출시가 기대되고, 5월 베타부터 미리 테스트해볼 수 있어요.

참고 자료​

• PostgreSQL 19: What's Coming — VersionLog
• PostgreSQL 19: CommitFest 2025-07 — Postgres Professional
• PostgreSQL 19: CommitFest 2025-09 — Postgres Professional
• PostgreSQL 19: CommitFest 2025-11 — Postgres Professional
• PostgreSQL 19: CommitFest 2026-01 — Postgres Professional
• PostgreSQL Roadmap