day-log

지난주에 우리 팀 리포팅 DB — Postgres 18로 올린 지 두 달째다 — 에 async I/O를 본격적으로 켜보자고 결심했다. Postgres 18에서 들어온 AIO가 sequential scan, bitmap heap scan, vacuum 같은 read-heavy 작업에서 최대 2~3배까지 빨라진다는 얘기가 릴리스 노트부터 pganalyze 벤치까지 여기저기 도배돼 있었고, 우리 리포팅 워크로드는 딱 그 형태였다. NVMe 붙은 i4i 계열, 대형 seq scan이 하루에도 수백 번 도는 그런 곳.결과부터 말하면 결국 io_method = worker로 되돌렸고, io_uring은 우리 환경에서 못 썼다. 왜 그렇게 됐는지 시간 순서대로 남겨둔다.첫 번째 삽질: `io_method=io_uri..

RDS PostgreSQL 16→17 업그레이드 새벽 작업기 — replication slot에 또 당했다지난주 토요일 새벽 2시. RDS PostgreSQL 16에서 17로 메이저 업그레이드를 돌렸다. 작업 자체는 한 시간 안에 끝날 줄 알았는데, 결국 새벽 6시까지 책상에 앉아있었다. 또 replication slot이었다.분명히 사전 점검 체크리스트에 "logical replication slot 확인" 항목을 넣어뒀다. 그런데도 당했다. 어떻게 당했는지, 그리고 이번에 알게 된 게 뭔지 적어둔다. 다음에 또 같은 데서 미끄러지지 않으려고.사전 점검은 했는데작업 전 점검은 평소대로 돌렸다.SELECT slot_name, plugin, slot_type, database, active, restart..

지난주 화요일 오후, 모니터링 알람이 울렸다. PgBouncer 앞단의 connection 사용량이 평소 대비 3배 가까이 튀어 있었고, 어플리케이션 쪽 P99 레이턴시는 슬슬 200ms를 넘기고 있었다. 트래픽은 평소 수준. 이상한 점은 RDS Postgres의 active connection 수가 거의 변동이 없다는 거였다. 즉, 클라이언트 → PgBouncer 사이에서 뭔가 막혀 있다는 뜻이다.이번 글은 그날 밤 새벽 2시까지 잡고 있던 이 문제를 어떻게 추적했는지, 그리고 결국 prepared statement와 transaction pooling이 충돌하던 지점을 어떻게 풀어냈는지에 대한 기록이다. 결론부터 말하면, 우리가 두 달 전에 한 PgBouncer 버전 업그레이드가 진짜 원인이었다.처음..