PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Vermeiden Sie exklusive Zugriffssperren auf referenzierte Tabellen beim DROPping in PostgreSQL

Für alle, die googeln und versuchen zu verstehen, warum ihre Drop-Tabelle (oder Fremdschlüssel löschen oder Fremdschlüssel hinzufügen) für lange Zeit hängen geblieben ist:

PostgreSQL (Ich habe mir die Versionen 9.4 bis 13 angesehen) Fremdschlüsselbeschränkungen werden tatsächlich mithilfe von Triggern an beiden Enden des Fremdschlüssels implementiert .

Wenn Sie eine Unternehmenstabelle (ID als Primärschlüssel) und eine Bank_Konto-Tabelle (ID als Primärschlüssel, Unternehmens_ID als Fremdschlüssel, die auf Unternehmen Tabelle.

table_name Zeitpunkt trigger_name Funktionsname
Bankkonto NACH DER AKTUALISIERUNG RI_ConstraintTrigger_c_1515961 RI_FKey_check_upd
Bankkonto NACH EINFÜGEN RI_ConstraintTrigger_c_1515960 RI_FKey_check_ins
Unternehmen NACH DER AKTUALISIERUNG RI_ConstraintTrigger_a_1515959 RI_FKey_noaction_upd
Unternehmen NACH LÖSCHEN RI_ConstraintTrigger_a_1515958 RI_FKey_noaction_del

Die anfängliche Erstellung dieser Trigger (beim Erstellen des Foreing-Schlüssels) erfordert eine SHARE ROW EXCLUSIVE-Sperre für diese Tabellen (in Version 9.4 und früher war dies eine ACCESS EXCLUSIVE-Sperre). Diese Sperre kollidiert nicht mit "Datenlesesperren", kollidiert jedoch mit allen anderen Sperren, zum Beispiel einem einfachen INSERT/UPDATE/DELETE in der Firmentabelle.

Das Löschen dieser Trigger (beim Löschen des Fremdschlüssels oder der gesamten Tabelle) erfordert eine ACCESS EXCLUSIVE-Sperre für diese Tabellen. Diese Sperre kollidiert mit jeder anderen Sperre!

Stellen Sie sich also ein Szenario vor, in dem Sie eine Transaktion A ausführen, die zuerst ein einfaches SELECT aus der Firmentabelle durchgeführt hat (wodurch sie eine ACCESS SHARE-Sperre für die Firmentabelle hält, bis die Transaktion festgeschrieben oder zurückgesetzt wird) und jetzt andere Aufgaben erledigt 3 Minuten. Sie versuchen, die bank_account-Tabelle in Transaktion B zu löschen. Dies erfordert eine ACCESS EXCLUSIVE-Sperre, die warten muss, bis die ACCESS SHARE-Sperre zuerst aufgehoben wird. Außerdem alle anderen Transaktionen, die auf die Firmentabelle zugreifen möchten (nur SELECT, oder vielleicht INSERT/UPDATE/DELETE), wird in die Warteschlange gestellt, um auf die ACCESS EXCLUSIVE-Sperre zu warten, die auf die ACCESS SHARE-Sperre wartet.

Lang andauernde Transaktionen und DDL-Änderungen erfordern eine sorgfältige Handhabung.