Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Lock:transactionid

Das Lock:transactionid-Ereignis tritt ein, wenn eine Transaktion auf eine Sperre auf Zeilenebene wartet.

Unterstützte Engine-Versionen

Diese Warteereignisinformationen werden für alle Versionen von RDS für PostgreSQL unterstützt.

Context

Das Ereignis Lock:transactionid tritt ein, wenn eine Transaktion versucht, eine Sperre auf Zeilenebene zu erlangen, die bereits einer gleichzeitig laufenden Transaktion gewährt wurde. Die Sitzung, die das Lock:transactionid-Wait-Ereignis anzeigt, ist aufgrund dieser Sperre blockiert. Nachdem die blockierende Transaktion entweder in einer COMMIT- oder ROLLBACK-Anweisung endet, kann die blockierte Transaktion fortgesetzt werden.

Die Semantik der Multiversions-Parallelität von RDS für PostgreSQL garantiert, dass Leser keine Autoren blockieren und Autoren Leser nicht blockieren. Damit Konflikte auf Zeilenebene auftreten können, müssen blockierende und blockierte Transaktionen widersprüchliche Anweisungen der folgenden Typen ausgeben:

Die Anweisung SELECT … FOR KEY SHARE ist ein Sonderfall. Die Datenbank verwendet die Klausel FOR KEY SHARE, um die Leistung der referenziellen Integrität zu optimieren. Eine Sperre auf Zeilenebene für eine Zeile kann INSERT-, UPDATE- und DELETE-Befehle für andere Tabellen blockieren, die auf die Zeile verweisen.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Wenn dieses Ereignis mehr als normal auftritt, sind die Ursache normalerweise UPDATE-, SELECT … FOR UPDATE-, SELECT … FOR KEY SHARE-Anweisungen in Kombination mit den folgenden Bedingungen.

Hohe Gleichzeitigkeit

RDS für PostgreSQL kann eine körnige Sperrsemantik auf Zeilenebene verwenden. Die Wahrscheinlichkeit von Konflikten auf Zeilenebene steigt, wenn die folgenden Bedingungen erfüllt sind:

Leerlauf in Transaktion

Manchmal zeigt die Spalte pg_stat_activity.state den Wert idle in transaction an. Dieser Wert wird für Sitzungen angezeigt, die eine Transaktion gestartet, aber noch kein COMMIT oder ROLLBACK ausgegeben haben. Wenn der pg_stat_activity.state-Wert nicht active ist, ist die in pg_stat_activity angezeigte Abfrage die letzte, die ausgeführt wurde. Die blockierende Sitzung verarbeitet eine Abfrage nicht aktiv, da eine offene Transaktion eine Sperre hält.

Wenn eine Leerlauf-Transaktion eine Sperre auf Zeilenebene erworben hat, kann dies verhindern, dass andere Sitzungen sie erwerben. Diese Bedingung führt zu einem häufigen Auftreten des Warteereignisses Lock:transactionid. Um das Problem zu diagnostizieren, überprüfen Sie die Ausgabe von pg_stat_activity und pg_locks.

Lang laufende Transaktionen

Transaktionen, die lange laufen, erhalten lange Zeit Sperren. Diese langjährigen Sperren können die Ausführung anderer Transaktionen verhindern.

Aktionen

Zeilensperre ist ein Konflikt zwischen UPDATE-, SELECT … FOR UPDATE- oder SELECT … FOR KEY SHARE-Anweisungen. Bevor Sie eine Lösung versuchen, sollten Sie herausfinden, wann diese Anweisungen in derselben Zeile ausgeführt werden. Wählen Sie mit diesen Informationen eine in den folgenden Abschnitten beschriebene Strategie aus.

Reagieren auf hohe Parallelbetrieb

Wenn Parallelität das Problem darstellt, versuchen Sie eine der folgenden Techniken:

Reagieren Sie auf ungenutzte Transaktionen

Wenn pg_stat_activity.state idle in transaction anzeigt, verwenden Sie die folgenden Strategien:

Reagieren Sie auf lang andauernde Transaktionen

Wenn Transaktionen mit langer Laufzeit das häufige Auftreten von Lock:transactionid verursachen, versuchen Sie die folgenden Strategien: