Les migrations de schéma avec un lock_timeout court et une reprise automatique provoquent moins d'incidents au déploiement

Hypothèse

Pour un service dont les migrations s'exécutent contre une base PostgreSQL en production, encadrer chaque instruction DDL verrouillante avec SET lock_timeout = '<a few seconds>' et une boucle de reprise bornée réduit le nombre de déploiements qui provoquent des erreurs visibles par les utilisateurs ou des pics de latence, et raccourcit le pire de ces incidents, par comparaison avec l'exécution des mêmes instructions avec la valeur par défaut lock_timeout = 0. Le mécanisme découle de la documentation : ALTER TABLE acquiert un verrou ACCESS EXCLUSIVE sauf si une sous-forme indique le contraire, et ce mode entre en conflit avec des verrous de tous les modes, y compris le verrou ACCESS SHARE d'un simple SELECT. Une requête DDL qui attend derrière une transaction longue bloque donc toute requête ultérieure sur la table pendant toute la durée de cette transaction ; lock_timeout interrompt l'instruction en attente au bout du délai configuré, si bien que le blocage est borné par ce délai plutôt que par la transaction la plus longue sur le serveur.

Prédiction

Sur le même pipeline de déploiement, la part des migrations suivies dans les cinq minutes d'une alerte de taux d'erreur ou de latence en queue de distribution diminue après l'introduction de cet encadrement ; le plus long temps d'attente de verrou enregistré par log_lock_waits pendant les déploiements se rapproche de la valeur du délai configuré ; et un petit nombre de migrations épuisent leurs tentatives et sont relancées à la main, surtout sur des tables soumises à de longues requêtes de reporting.

Test proposé

1. Pendant une période fixe, enregistrer pour chaque déploiement : les migrations exécutées et leurs types d'instructions DDL, les attentes de verrou issues du journal du serveur, les alertes déclenchées dans les cinq minutes, et les interventions manuelles.
2. Introduire l'encadrement avec des paramètres fixes et documentés (délai, nombre de tentatives, backoff), sans autre changement de l'ensemble des migrations ni du calendrier de déploiement.
3. Enregistrer une période de même durée et comparer le nombre d'incidents, le plus long temps d'attente de verrou et le nombre de relances manuelles, en tenant compte du nombre et du type des instructions DDL.

Statut

Aucun résultat n'est revendiqué. L'effet devrait être absent lorsque les migrations s'exécutent déjà dans des fenêtres de maintenance, et plus faible lorsque les transactions longues sont rares du fait de l'application d'un idle_in_transaction_session_timeout ; l'hypothèse ne porte que sur les incidents survenant au moment du déploiement, pas sur la durée totale des migrations.