SQL—2025-11-20

Activer hot_standby_feedback pour les requêtes longues sur un réplica

💡 Sujet

Lorsqu’on exécute des requêtes longues (ex. : modèles dbt, analytique, exports) sur une base de données read-only (standby), il arrive que la requête soit interrompue brutalement par le moteur.

L'objectif est de configurer le réplica pour qu'il informe le primaire de ses transactions en cours, empêchant ainsi le nettoyage prématuré des données.

⚙️ Le problème : conflit de récupération

Sur une architecture Maître/Esclave (Primary/Standby), le primaire nettoie régulièrement les anciennes versions de lignes (via VACUUM) pour libérer de l'espace.

Si une requête longue tourne sur le standby et lit des données que le primaire vient de supprimer ou mettre à jour, une incohérence se crée. Le standby est alors forcé d'annuler la requête de lecture pour rester synchronisé avec le primaire.

❌ Erreur typique rencontrée

ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed.

Cela est très fréquent avec dbt ou des outils de BI qui scannent de larges volumes de données sur un réplica.

✅ La solution : hot_standby_feedback

Pour éviter cela, il faut activer le paramètre hot_standby_feedback sur le serveur secondaire (standby).

Cela permet au standby d'envoyer des informations au primaire sur les requêtes en cours d'exécution. Le primaire retardera alors le VACUUM sur les lignes concernées tant que la requête du standby n'est pas terminée.

🛠️ Configuration

Dans le fichier de configuration postgresql.conf du serveur standby :

hot_standby_feedback = on

Puis recharger la configuration (reload, pas besoin de restart complet généralement) :

SELECT pg_reload_conf();

⚠️ Point de vigilance

Activer cette option a un coût : si une transaction reste ouverte très longtemps sur le standby, elle empêche le nettoyage (VACUUM) sur le primaire.

👉 Cela peut entraîner une augmentation de la taille de la base (bloat) sur le primaire. Il est donc conseillé de surveiller la durée des transactions sur le réplica.

🧩 Résumé

❌ Les requêtes longues sur un réplica peuvent échouer avec l'erreur "conflict with recovery".
✅ hot_standby_feedback = on permet au réplica de signaler au primaire de ne pas supprimer les données qu'il est en train de lire.
💡 Indispensable pour faire tourner dbt ou de la BI sur une instance en lecture seule.
⚠️ Attention au risque de "bloat" sur le primaire si les requêtes sont infinies.

🔗 Références