PostgreSQL wartet auf eine Sperre. Wie findet man die blockierende Transaktion?

Bestätigen Sie zuerst das Warten auf eine Sperre

Für einen ersten Überblick verwenden Sie die lesende Abfrage: SELECT pid, pg_blocking_pids(pid) AS blockers FROM pg_stat_activity WHERE wait_event_type = 'Lock'; Sie zeigt die betreffenden wartenden PIDs und ihre blockierenden Vorgänger. Ist das Ergebnis leer, erzwingen Sie keine Erklärung durch Sperren. Notieren Sie den Beobachtungszeitpunkt und vergleichen Sie ihn mit einer konkreten fehlgeschlagenen Anfrage.

Erfassen Sie auch den Anwendungsnamen und die betroffene Datenbank. Beschränken Sie weitergegebene Diagnoseausgaben auf die benötigten Angaben; Abfragetext kann sensible Werte enthalten. Trennen Sie vor dem Eingriff die Beobachtung von der Änderung. Ein Überblick allein ist kein Grund, massenhaft Abfragen abzubrechen oder Clients zu trennen.

Verfolgen Sie die Kette bis zur ursprünglichen Blockierung

pg_blocking_pids() kann den Halter einer widersprüchlichen Sperre oder eine zuvor eingereihte wartende Sitzung zurückgeben. Prüfen Sie deshalb für gefundene PIDs, ob diese selbst blockiert sind. Der erste Vorgänger muss nicht der Ausgangspunkt sein. Wählen Sie das Ziel eines Eingriffs nicht allein nach der am längsten wartenden Benutzeranfrage; sie kann ein weiteres Opfer in der Kette sein.

Der Zustand idle in transaction bedeutet eine offene Transaktion ohne gerade laufende Abfrage. Vergleichen Sie xact_start, application_name und den Sitzungsinhaber. Für fremde Sitzungsdetails kann pg_read_all_stats erforderlich sein. Klären Sie, ob eine geplante Stapelverarbeitung, eine Bereitstellung oder ein vergessener Vorgang vorliegt. Bewerten Sie das Transaktionsalter anhand von Zweck und Auswirkungen statt anhand eines pauschalen Grenzwerts.

Wählen Sie den Eingriff nach dem Sitzungszustand

pg_cancel_backend(pid) bricht die aktuelle Abfrage ab; pg_terminate_backend(pid) beendet die gesamte Sitzung. Bei einer untätigen offenen Transaktion läuft keine Abfrage, die sich abbrechen ließe. Stimmen Sie mit dem Verantwortlichen ab, wie die Transaktion beendet wird; ROLLBACK in ihrer ursprünglichen Verbindung verwirft unbestätigte Änderungen. Verwenden Sie COMMIT nicht allein, um andere Anfragen freizugeben, wenn unklar ist, was Sie damit bestätigen.

Prüfen Sie vor einer möglichen Sitzungsbeendigung erneut deren Identität und die Auswirkungen auf den laufenden Vorgang. Diese Funktionen erfordern entsprechende Berechtigungen. Ein true von pg_terminate_backend(pid) ohne Timeout bestätigt das Senden des Signals, nicht den Abschluss der Beendigung. Kontrollieren Sie danach Sitzung, Blockierungskette und Anwendungsergebnis. Ein erfolgreicher Verwaltungsbefehl allein beendet den Vorfall nicht.

Begrenzen Sie das Warten und prüfen Sie das Benutzerergebnis

lock_timeout begrenzt jeden Versuch, eine Sperre zu erwerben; statement_timeout begrenzt die Dauer einer Anweisung. Bei Verwendung beider Werte ermöglicht ein kürzerer lock_timeout die gesonderte Erkennung des Wartens auf Sperren. SET LOCAL gilt nur in der aktuellen Transaktion. Wählen Sie Werte passend zum Vorgang und testen Sie auch die Fehlerbehandlung der Anwendung. Ein Timeout begrenzt das Warten, behebt aber nicht den blockierenden Vorgang.

Zeilen- und Tabellensperren bleiben normalerweise bis zum Transaktionsende bestehen. Verkürzen Sie deshalb den Teil des Vorgangs, der sie benötigt, und greifen Sie auf mehrere Objekte in einheitlicher Reihenfolge zu. Testen Sie die Änderung mit parallelen Vorgängen in einer getrennten Umgebung. Vergleichen Sie anschließend in Produktion Wartezeiten und Fehlerraten und wiederholen Sie das zuvor fehlgeschlagene Speichern der Bestellung. Eine erfolgreich geladene Startseite prüft diesen Schreibvorgang nicht.

• Erfassen Sie wartende PIDs, Zeitpunkt und betroffenen Vorgang.
• Verfolgen Sie die Vorgängerkette und ermitteln Sie den Verantwortlichen.
• Unterscheiden Sie Abfrageabbruch, Rollback und Sitzungsbeendigung.
• Prüfen Sie das Ende des Wartens und den tatsächlichen Schreibvorgang.