AI, 개발 도구, 오픈소스, 보안과 인프라의 변화와 이용 조건을 설명하는 최신 기사와 해설입니다.
Alex Georgiev의 PostgreSQL 19 beta4 시험에서 병렬 autovacuum은 리더 CPU 시간을 약 30% 줄였지만, 40만 행·6개 인덱스·죽은 튜플 80만 개를 처리한 전체 시간은 평균 1.31초에서 1.25초로 약 4% 줄어 실행 간 편차 안에 머물렀습니다. 체크섬 온라인 전환은 beta4에서 철회돼 RC1에 포함되지 않았습니다. Craig Kerstiens의 별도 시험에서 REPACK (CONCURRENTLY)는 테이블 접근을 유지하는 대신 `VACUUM FULL`보다 오래 걸렸고 추가 디스크 공간이 필요했습니다.
PostgreSQL 19의 내장 `REPACK (CONCURRENTLY)`는 테이블을 새 파일로 재작성하면서 작업 중 변경을 WAL 논리 디코딩으로 반영해, 대량 작업 중에도 읽기와 쓰기를 허용합니다. Snowflake Engineering Blog의 Craig Kerstiens가 공개한 CPU 1개·메모리 512MB 환경 시험에서 100만 행이 남은 493MB 테이블을 재작성하는 데 온라인 방식은 9.4초, `VACUUM FULL`은 2.7초가 걸렸습니다. 온라인 방식은 더 오래 걸렸지만 마지막 파일 교체 단계에서만 강한 잠금을 잡았으며, 사용에는 추가 저장 공간과 스냅샷 관련 제약이 따릅니다.
PostgreSQL 커미터 Robert Haas는 LLM을 이용한 버그 탐색과 제보가 늘어 유지보수 브랜치의 수정 및 사람의 검토 부담이 커졌고, 이 때문에 PostgreSQL 19의 기능 철회와 출시 지연에 영향을 줬다고 분석했습니다. 그가 제시한 커밋 수는 브랜치에 반영된 변경 건수를 가리키며, LLM 유래 제보 건수는 따로 집계하지 않았습니다. 프로젝트는 정식판 공개 목표일을 2026년 11월 19일로 공지했습니다.
PostgreSQL 19 beta4는 autovacuum의 인덱스 정리에 병렬 작업자를 투입하는 설정을 추가합니다. 한 실험에서 autovacuum 작업자의 CPU 시간은 약 30% 줄었지만 전체 vacuum 시간은 약 4%만 짧아졌습니다. 이 결과는 heap 스캔이 병목인 작업에서는 병렬 인덱스 정리만으로 처리 시간이 줄지 않음을 보여줍니다.
PostgreSQL 19 베타 기간에 주요 기능 8~10개가 리버트된 배경을 개발자 Peter Eisentraut가 돌아봅니다. LLM 보조 코드 리뷰로 결함이 더 빨리 드러난 점과 보안 작업으로 줄어든 리뷰·테스트 시간을 원인으로 들며, 퍼징 확대와 실험적 기능 상태 도입을 개선 과제로 제안합니다.
PostgreSQL 19에는 서버를 계속 운영하면서 데이터 체크섬을 켜거나 끄는 SQL 함수가 추가됩니다. 테스트에서는 오프라인 변환보다 작업 시간이 길었지만 서비스 중단은 피했고, 체크섬을 켜면 손상된 페이지를 읽을 때 오류를 확인했습니다.