Schemamigrationen mit kurzem lock_timeout und automatischem Retry verursachen weniger Vorfälle beim Deployment als Migrationen ohne

Hypothese

Für einen Dienst, dessen Migrationen gegen eine laufende PostgreSQL-Datenbank ausgeführt werden, verringert das Einbetten jeder sperrenden DDL-Anweisung in SET lock_timeout = '<a few seconds>' mit einer begrenzten Retry-Schleife die Zahl der Deployments, die nutzersichtbare Fehler oder Latenzspitzen verursachen, und verkürzt den schlimmsten derartigen Vorfall, verglichen mit der Ausführung derselben Anweisungen mit dem standardmässigen lock_timeout = 0. Der Mechanismus folgt aus der Dokumentation: ALTER TABLE erwirbt eine ACCESS EXCLUSIVE-Sperre, sofern keine Unterform etwas anderes vorsieht, und dieser Modus steht im Konflikt mit Sperren jeden Modus, einschliesslich der ACCESS SHARE-Sperre eines einfachen SELECT. Eine DDL-Anfrage, die hinter einer langen Transaktion wartet, blockiert daher jede spätere Abfrage auf der Tabelle, solange diese Transaktion läuft; lock_timeout bricht die wartende Anweisung nach der konfigurierten Zeit ab, sodass die Blockade durch das Timeout begrenzt ist statt durch die längste Transaktion auf dem Server.

Vorhersage

In derselben Deploy-Pipeline sinkt nach Einführung des Wrappers der Anteil der Migrationen, auf die innerhalb von fünf Minuten ein Alarm wegen Fehlerrate oder Tail-Latenz folgt; die längste von log_lock_waits während Deployments erfasste Sperrwartezeit sinkt auf ungefähr den Timeout-Wert; und eine kleine Zahl von Migrationen schöpft ihre Retries aus und wird von Hand erneut ausgeführt, meist bei Tabellen mit langen Reporting-Abfragen.

Vorgeschlagener Test

1. Für einen festen Zeitraum pro Deployment festhalten: ausgeführte Migrationen und ihre DDL-Arten, Sperrwartezeiten aus dem Server-Log, innerhalb von fünf Minuten ausgelöste Alarme und manuelle Eingriffe.
2. Den Wrapper mit festen, dokumentierten Parametern einführen (Timeout, Versuche, Backoff) und sonst nichts an der Menge der Migrationen oder am Deployment-Zeitplan ändern.
3. Einen gleich langen Zeitraum erfassen und Vorfallzahl, längste Sperrwartezeit und Anzahl manueller Wiederholungen vergleichen, dabei die Anzahl und Art der DDL-Anweisungen kontrollieren.

Status

Es wird kein Ergebnis behauptet. Der Effekt sollte ausbleiben, wo Migrationen bereits in Wartungsfenstern laufen, und schwächer sein, wo lange Transaktionen selten sind, weil idle_in_transaction_session_timeout durchgesetzt wird; die Hypothese betrifft nur Vorfälle zur Deployment-Zeit, nicht die Gesamtdauer der Migrationen.