Autovacuum Postgres, démystifié — le tuning qui prévient la panique de wraparound à 3 h

Le wraparound de transaction ID est en tête de ma liste des modes de défaillance Postgres qui m'ont personnellement coûté du sommeil. Le matin est toujours le même : la Postgres d'un client est passée read-only à 2 h, chaque write rejeté avec « database is not accepting commands to avoid wraparound data loss », et la seule voie est un VACUUM FREEZE contre une table de 300 Go qui va prendre six heures.

L'autovacuum existe depuis 2005. Les valeurs par défaut sont calibrées pour « petite DB, petit serveur » et sont fausses sur toute base significativement grande, de façon prévisible.

Tuning par table pour les tables grandes et turnoverées

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
);

Toute table au-delà de 10 Go ou 10 M de lignes reçoit un tuning par table. Les défauts de 20 % de scale factor et 200 M d'âge XID rendent les autovacuums trop rares et trop gros sur les grosses tables.

L'article complet couvre :

• Ce que fait réellement l'autovacuum (nettoyage des dead tuples vs gel XID)
• Les trois métriques à surveiller (dead_ratio, last_autovacuum, xid_age)
• Pourquoi le autovacuum_vacuum_cost_limit = 200 par défaut est risiblement bas sur SSD
• Le gel proactif pour prévenir les autovacuums anti-wraparound pendant les heures ouvrables
• Le bloat d'index et REINDEX CONCURRENTLY planifié
• pg_repack pour les tables qui doivent rendre de l'espace disque à l'OS

Nous livrons ce baseline sur chaque base Postgres managée.