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.