2025년에 제가 개발한 새로운 PostgreSQL 기능

발행: 1주 전 (2025년 12월 26일 오전 08:00 GMT+9)

10 min read

Source: Dev.to

번역을 진행하려면 번역이 필요한 전체 텍스트를 제공해 주시겠어요? 텍스트를 알려주시면 요청하신 대로 한국어로 번역해 드리겠습니다.

Overview

나는 2020년경부터 PostgreSQL에 기여하기 시작했습니다. 2025년에 더 열심히 일하고 싶어서, 올해 내가 개발하고 커밋한 PostgreSQL 기능들을 설명하겠습니다.

다른 패치도 몇 개 커밋했지만, 그것들은 버그 수정이나 작은 문서 변경에 불과했습니다. 아래는 가장 유용해 보이는 것들입니다.

Note: These are mainly features in PostgreSQL 19, now in development. They may be reverted before the final release. (※ 이 문장은 원문 그대로 유지했습니다)

1. `pg_dump` 백업 복원 시 기본 `psql` 설정 권장

Title: Doc: pg_dump 스크립트 복원을 위해 “psql ‑X” 사용을 권장
Committer: Tom Lane
Date: Sat, 25 Jan 2025

pg_dump 로 만든 덤프 파일을 psql 로 복원할 때, psql 이 기본이 아닌 설정(예: AUTOCOMMIT=off)을 사용하고 있으면 오류가 발생할 수 있습니다. 이번 변경은 문서에만 적용되며, psqlrc 설정 파일을 읽지 않도록 psql 옵션 -X (--no-psqlrc) 사용을 권장합니다.

과거에 작성한 psqlrc 파일에 관한 블로그는 다음을 참고하세요:

Example

# create a test database
createdb test1

# dump all databases to an SQL script file
# -c issues DROP for databases, roles, and tablespaces before recreating them
pg_dumpall -c -f test1.sql

# restore with psql (without -X)
psql -f test1.sql
# → errors:
# psql:test1.sql:14: ERROR:  DROP DATABASE cannot run inside a transaction block
# psql:test1.sql:23: ERROR:  current transaction is aborted, commands ignored until end of transaction block
# …

-c 로 생성된 DROP DATABASE 문은 트랜잭션 블록 안에서 실행될 수 없으므로 위와 같은 오류가 나타납니다. 트랜잭션 블록 안에서 문이 실패하면 전체 트랜잭션이 중단되어 이후 문들도 실패하게 됩니다. psql -X 를 사용하면 이 문제를 피할 수 있습니다.

2. `pg_stat_progress_basebackup` 뷰에 `backup_type` 열 추가

Title: Add backup_type column to pg_stat_progress_basebackup
Committer: Masahiko Sawada
Date: 2025년 8월 5일 화요일

PostgreSQL 17은 pg_basebackup에 증분 백업 지원을 추가했지만, pg_stat_progress_basebackup 뷰에는 백업이 전체인지 증분인지 표시할 열이 없었습니다. 새로 추가된 backup_type 열은 full 또는 incremental을 보여줍니다.

Demonstration

# Full backup
pg_basebackup -D full

SELECT * FROM pg_stat_progress_basebackup;

-[ RECORD 1 ]--------+-------------------------
pid                  | 853626
phase                | streaming database files
backup_total         | 1592460800
backup_streamed      | 622124544
tablespaces_total    | 1
tablespaces_streamed | 0
backup_type          | full                     -- new!

# Incremental backup
pg_basebackup -i full/backup_manifest -D incl

SELECT * FROM pg_stat_progress_basebackup;

-[ RECORD 1 ]--------+-------------------------
pid                  | 854435
phase                | streaming database files
backup_total         | 1613615104
backup_streamed      | 726617088
tablespaces_total    | 1
tablespaces_streamed | 0
backup_type          | incremental              -- new!

Source: …

3. `COPY FROM` 이제 다중 행 헤더가 있는 파일을 지원합니다

제목: COPY FROM 명령에서 다중 행 헤더 지원
커미터: Fujii Masao
날짜: 2025년 7월 3일 목요일

COPY 명령의 HEADER 옵션은 헤더 처리를 제어합니다. 이전에는 COPY FROM이 단일 헤더 라인(불리언)만 건너뛸 수 있었습니다. 이제 정수를 받아 원하는 만큼의 헤더 라인을 건너뛸 수 있습니다.

예시

\! cat /tmp/copy.csv
first header
second header
1,one
2,two
3,three

COPY t FROM '/tmp/copy.csv' WITH (HEADER 2, FORMAT csv);
-- COPY 3

TABLE t;
 id | data
----+------
  1 | one
  2 | two
  3 | three
(3 rows)

다른 RDBMS에서의 유사 기능

RDBMS	구문
MySQL	`LOAD DATA ... IGNORE N LINES`
SQL Server	`BULK INSERT … WITH (FIRSTROW = N)`
Oracle SQL*Loader	`sqlldr … SKIP=N`

4. `VACUUM`와 `ANALYZE`에 대한 autovacuum 로그 설정 분리

Title: log_autoanalyze_min_duration 추가
Committer: Peter Eisentraut
Date: Wed, 15 Oct 2025

우리는 이미 log_autovacuum_min_duration을 가지고 있었으며, 이는 autovacuum에 의해 수행된 VACUUM과 ANALYZE가 설정된 기간(기본 단위: ms)을 초과했을 때 로그에 기록했습니다. 이번 변경으로 별도의 설정인 log_autoanalyze_min_duration이 도입되어 ANALYZE에 대한 로그를 VACUUM과 독립적으로 제어할 수 있게 되었습니다.

(설명문의 나머지는 원래 커밋 메시지에 그대로 이어집니다.)

ANALYZE vs. VACUUM Logging

ANALYZE는 주로 샘플링된 행을 읽는 반면, VACUUM은 테이블 및 인덱스 페이지를 읽고 쓰기 때문에 VACUUM이 더 오래 걸리는 경우가 많습니다(테이블 설계, 데이터 양, 통계 목표, 워크로드, 확장 통계 등에 따라 다름). 이전에는 로그‑기간 파라미터를 별도로 설정할 수 없었습니다.

이제 log_autovacuum_min_duration은 VACUUM 전용이고, 새로 추가된 log_autoanalyze_min_duration은 ANALYZE 전용입니다.
처음에는 일관성을 위해 log_autovacuum_vacuum_min_duration와 log_autovacuum_analyze_min_duration을 제안했지만, 기존 이름을 변경하면 하위 호환성이 깨지고 pg_dump/pg_upgrade에 영향을 미치므로 진행을 중단했습니다.

=# CREATE TABLE t (i int, d text) WITH (
  -- autoanalyze settings
  autovacuum_analyze_threshold = 1,
  autovacuum_analyze_scale_factor = 0,
  log_autoanalyze_min_duration = 0,
  -- autovacuum settings
  autovacuum_vacuum_threshold = 1,
  autovacuum_vacuum_scale_factor = 0,
  log_autovacuum_min_duration = 100_000_000
);
=# INSERT INTO t VALUES (1, 'a');
=# DELETE FROM t WHERE i = 1;

2025-12-03 15:15:39.608 JST [401368] LOG:  automatic analyze of table "postgres.public.t"
avg read rate: 18.229 MB/s, avg write rate: 0.000 MB/s
buffer usage: 155 hits, 7 reads, 0 dirtied
WAL usage: 1 records, 0 full page images, 530 bytes, 0 buffers full
system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s

Show compressed full‑page image size in `pg_stat_wal`

Title: Add wal_fpi_bytes to pg_stat_wal and pg_stat_get_backend_wal()
Committer: Michael Paquier
Date: Tue, 28 Oct 2025

wal_compression이 활성화되면 WAL에 포함된 전체 페이지 이미지(FPI)가 압축됩니다.
이전에는 효과를 측정하기 위해 다음과 같은 방법이 필요했습니다:

압축을 켜고 끈 상태로 동일한 벤치마크를 실행하고 pg_stat_wal의 wal_bytes를 비교합니다. 이는 전체 WAL을 측정하는 것이며 FPI만을 대상으로 하지 않기 때문에 압축 비율이 대략적으로만 나옵니다.
서버에서 pg_waldump --fullpage를 실행해 압축된 WAL 크기를 확인하고 비율을 계산합니다. 이 방법은 WAL 파일과 서버 접근이 필요하므로 많은 클라우드 환경에서는 실현하기 어렵습니다.

이 패치에서는 pg_stat_wal에 wal_fpi_bytes를 추가했습니다:

=# SELECT * FROM pg_stat_wal;
-[ RECORD 1 ]----+-----------------------------
wal_records      | 2031667
wal_fpi          | 288581
wal_bytes        | 6346674376
wal_fpi_bytes    | 1932610356   -- new!
wal_buffers_full | 424447
stats_reset      | 2025-12-02 19:31:44.16184+09

또한 EXPLAIN (WAL) 및 VACUUM 로그에 이 정보를 노출하는 패치도 포함되어 있습니다. [4][5]

`pg_stat_progress_vacuum` 뷰에 `mode` 및 `started_by` 컬럼 추가

제목: pg_stat_progress_vacuum 뷰에 mode와 started_by 컬럼을 추가합니다.
커미터: Masahiko Sawada
날짜: 2025년 12월 9일 화요일

VACUUM은 여러 이유(자동, 수동, 래핑 어라운드)로 시작될 수 있으며, 서로 다른 모드(normal, aggressive, failsafe)로 실행될 수 있습니다. 기존 진행 뷰에서는 이러한 정보를 제공하지 않았습니다.

새로운 컬럼은 다음과 같습니다:

Column	Values (example)
`mode`	`normal`, `aggressive`, `failsafe`
`started_by`	`manual`, `autovacuum`, `autovacuum_wraparound`

예시 출력

=# SELECT * FROM pg_stat_progress_vacuum;
-[ RECORD 1 ]--------+--------------
pid                  | 362895
datid                | 5
datname              | postgres
relid                | 24602
phase                | scanning heap
heap_blks_total      | 8850
heap_blks_scanned    | 5327
heap_blks_vacuumed   | 0
index_vacuum_count   | 0
max_dead_tuple_bytes| 67108864
dead_tuple_bytes    | 0
num_dead_item_ids   | 0
indexes_total       | 0
indexes_processed   | 0
delay_time          | 0
mode                | normal       -- new!
started_by          | autovacuum   -- new!

유사한 패치는 pg_stat_progress_analyze에 started_by 컬럼(manual, autovacuum)을 추가합니다. [6]

결론

2025년에 개발한 PostgreSQL 기능을 소개하고 아직 논의 중인 여러 추가 패치를 제안했습니다. 내년에 더 많은 내용을 공유할 수 있기를 바랍니다.

2025년에 제가 개발한 새로운 PostgreSQL 기능

Overview

1. `pg_dump` 백업 복원 시 기본 `psql` 설정 권장

Example

2. `pg_stat_progress_basebackup` 뷰에 `backup_type` 열 추가

Demonstration

3. `COPY FROM` 이제 다중 행 헤더가 있는 파일을 지원합니다

예시

다른 RDBMS에서의 유사 기능

4. `VACUUM`와 `ANALYZE`에 대한 autovacuum 로그 설정 분리

ANALYZE vs. VACUUM Logging

Show compressed full‑page image size in `pg_stat_wal`

`pg_stat_progress_vacuum` 뷰에 `mode` 및 `started_by` 컬럼 추가

예시 출력

결론

참고 문헌

관련 글

SQL과 함께하는 3일 차: 데이터 삽입, 스마트하게 쿼리하기, 실제 데이터셋 작업

이 문서 인프라에 대하여

이번 주 상위 7개 Featured DEV 포스트

비하인드 스토리: CRAFT Solo 구축

Overview

1. pg_dump 백업 복원 시 기본 psql 설정 권장

Example

2. pg_stat_progress_basebackup 뷰에 backup_type 열 추가

Demonstration

3. COPY FROM 이제 다중 행 헤더가 있는 파일을 지원합니다

예시

다른 RDBMS에서의 유사 기능

4. VACUUM와 ANALYZE에 대한 autovacuum 로그 설정 분리

ANALYZE vs. VACUUM Logging

Show compressed full‑page image size in pg_stat_wal

pg_stat_progress_vacuum 뷰에 mode 및 started_by 컬럼 추가

예시 출력

결론

참고 문헌

관련 글

SQL과 함께하는 3일 차: 데이터 삽입, 스마트하게 쿼리하기, 실제 데이터셋 작업

이 문서 인프라에 대하여

이번 주 상위 7개 Featured DEV 포스트

비하인드 스토리: CRAFT Solo 구축

1. `pg_dump` 백업 복원 시 기본 `psql` 설정 권장

2. `pg_stat_progress_basebackup` 뷰에 `backup_type` 열 추가

3. `COPY FROM` 이제 다중 행 헤더가 있는 파일을 지원합니다

4. `VACUUM`와 `ANALYZE`에 대한 autovacuum 로그 설정 분리

Show compressed full‑page image size in `pg_stat_wal`

`pg_stat_progress_vacuum` 뷰에 `mode` 및 `started_by` 컬럼 추가