Autovacuum do Postgres, desmistificado — o tuning que evita o pânico de wraparound às 3 da manhã

Wraparound de transaction ID lidera minha lista de modos de falha do Postgres que pessoalmente me custaram sono. A manhã é sempre a mesma: o Postgres de um cliente entrou em read-only às 2 da manhã, toda escrita rejeitada com «database is not accepting commands to avoid wraparound data loss», e o único caminho à frente é um VACUUM FREEZE contra uma tabela de 300 GB que vai levar seis horas.

Autovacuum existe desde 2005. Os defaults estão calibrados para «DB pequena, servidor pequeno» e estão errados em qualquer base significativamente grande, de forma previsível.

Tuning por tabela para tabelas grandes e com churn

ALTER TABLE orders SET (
  autovacuum_vacuum_scale_factor = 0.02,
  autovacuum_vacuum_threshold = 1000,
  autovacuum_analyze_scale_factor = 0.01,
  autovacuum_freeze_max_age = 100000000,
  autovacuum_vacuum_cost_limit = 2000
);

Qualquer tabela acima de 10 GB ou 10 M de linhas recebe tuning por tabela. Os defaults de 20 % de scale factor e 200 M de idade XID tornam autovacuums raros demais e grandes demais em tabelas grandes.

O artigo completo cobre:

• O que o autovacuum realmente faz (limpeza de dead tuples vs congelamento XID)
• As três métricas a vigiar (dead_ratio, last_autovacuum, xid_age)
• Por que o autovacuum_vacuum_cost_limit = 200 default é ridiculamente baixo em SSD
• Congelamento proativo para evitar autovacuums anti-wraparound em horário comercial
• Bloat de índices e REINDEX CONCURRENTLY programado
• pg_repack para tabelas que precisam devolver espaço em disco ao SO

Entregamos este baseline em cada base Postgres gerenciada.