http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex><\/p>\n<\/p>\n
Schauen wir uns das an. Die Transaktionsnummer ist rot hervorgehoben. Hier wird die Funktion SELECT pg_back angezeigt. Sie gibt meine Transaktion und die ID dieser Transaktion zur\u00fcck. <\/p>\n
<\/p>\n
Ein weiterer Punkt: Wenn Ihnen diese Pr\u00e4sentation gef\u00e4llt und Sie sie in Ihrer Datenbank ausf\u00fchren m\u00f6chten, k\u00f6nnen Sie auf den mit Rosa hervorgehobenen Link klicken und das SQL f\u00fcr diese Pr\u00e4sentation herunterladen. Sie k\u00f6nnen es einfach in Ihrem PSQL ausf\u00fchren, und die gesamte Pr\u00e4sentation wird sofort auf Ihrem Bildschirm angezeigt. Sie enth\u00e4lt keine Farben, aber zumindest k\u00f6nnen wir sie sehen.<\/p>\n
<\/p>\n
<\/p>\n
In diesem Fall sehen wir die Transaktions-ID. Dies ist die Nummer, die wir ihr zugewiesen haben. Es gibt auch einen anderen Typ der Transaktions-ID in Postgres, der als virtuelle Transaktions-ID bezeichnet wird.<\/p>\n
<\/p>\n
Und wir m\u00fcssen das verstehen. Das ist sehr wichtig, sonst k\u00f6nnen wir die Sperrung in Postgres nicht nachvollziehen.<\/p>\n
<\/p>\n
Eine virtuelle Transaktions-ID ist eine Transaktions-ID, die keine festen Werte enth\u00e4lt. Wenn ich beispielsweise einen SELECT-Befehl ausf\u00fchre, werde ich wahrscheinlich die Datenbank nicht \u00e4ndern und nichts blockieren. Daher geben wir dieser Transaktion bei einem einfachen SELECT keine feste ID. Wir geben ihr nur eine virtuelle ID.<\/p>\n
<\/p>\n
Das erh\u00f6ht die Leistung von Postgres und verbessert die M\u00f6glichkeiten zur Bereinigung, daher besteht die virtuelle Transaktions-ID aus zwei Zahlen. Die erste Zahl vor dem Schr\u00e4gstrich ist die Backend-ID. Rechts sehen wir einfach einen Z\u00e4hler.<\/p>\n
<\/p>\n
<\/p>\n
Wenn ich also eine Abfrage starte, sagt er, dass die Backend-ID \u2013 2 ist. <\/p>\n
<\/p>\n
<\/p>\n
Und wenn ich eine Reihe solcher Transaktionen starte, sehen wir, dass der Z\u00e4hler jedes Mal erh\u00f6ht wird, wenn ich eine Abfrage starte. Zum Beispiel, wenn ich die Abfragen 2\/10, 2\/11, 2\/12 usw. starte. <\/p>\n
<\/p>\n
<\/p>\n
Bitte beachten Sie, dass es hier zwei Spalten gibt. Links sehen wir die virtuelle Transaktions-ID \u2013 2\/12. Rechts haben wir die permanente Transaktions-ID. Und dieses Feld ist leer. Diese Transaktion ver\u00e4ndert also die Datenbank nicht. Daher weise ich ihr keine permanente Transaktions-ID zu.<\/p>\n
<\/p>\n
<\/p>\n
Sobald ich den Befehl ANALYZE ausf\u00fchre, gibt mir dieselbe Abfrage die permanente Transaktions-ID. Sehen Sie, wie sich das ge\u00e4ndert hat. Fr\u00fcher hatte ich diese ID nicht, jetzt ist sie da.<\/p>\n
<\/p>\n
<\/p>\n
Hier ist also eine weitere Abfrage, eine weitere Transaktion. Die virtuelle Transaktionsnummer ist \u2013 2\/13. Und wenn ich um die permanente Transaktions-ID bitte, erhalte ich sie, wenn ich die Abfrage starte. <\/p>\n
<\/p>\n
<\/p>\n
Also, noch einmal: Wir haben eine virtuelle Transaktions-ID und eine permanente Transaktions-ID. Verstehen Sie diesen Punkt, um das Verhalten von Postgres zu begreifen.<\/p>\n
<\/p>\n
<\/p>\n
Wir kommen zum dritten Abschnitt. Hier werden wir einfach die verschiedenen Arten von Sperren in Postgres durchgehen. Das ist nicht besonders spannend. Der letzte Abschnitt wird viel interessanter sein. Aber wir m\u00fcssen die Grundlagen behandeln, denn sonst werden wir nicht verstehen, was als N\u00e4chstes kommt. <\/p>\n
<\/p>\n
Wir werden diesen Abschnitt durchgehen und uns jeden Typ von Sperren ansehen. Ich werde Ihnen Beispiele zeigen, wie sie gesetzt werden, wie sie funktionieren, und ich zeige Ihnen einige Abfragen, die Sie verwenden k\u00f6nnen, um zu sehen, wie die Sperren in Postgres arbeiten.<\/p>\n
<\/p>\n
<\/p>\n
Um eine Abfrage zu erstellen und zu sehen, was in Postgres passiert, m\u00fcssen wir eine Abfrage in der Systemansicht ausf\u00fchren. In diesem Fall ist pg_lock in Rot hervorgehoben. Pg_lock ist eine Systemtabelle, die uns sagt, welche Sperren derzeit in Postgres verwendet werden.<\/p>\n
<\/p>\n
Dennoch f\u00e4llt es mir sehr schwer, Ihnen pg_lock allein zu zeigen, da es ziemlich kompliziert ist. Daher habe ich eine Ansicht erstellt, die pg_locks anzeigt. Und sie erledigt auch f\u00fcr mich einige Aufgaben, die mir helfen, es besser zu verstehen. Das hei\u00dft, sie schlie\u00dft meine Sperren, meine eigene Sitzung usw. aus. Es ist einfach Standard-SQL und hilft mir, besser zu zeigen, was passiert. <\/p>\n
<\/p>\n
<\/p>\n
Ein weiteres Problem ist, dass diese Ansicht sehr umfangreich ist, weshalb ich eine zweite \u2013 lockview2 \u2013 erstellen musste.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Also haben wir eine Tabelle erstellt, die Lockdemo hei\u00dft. Und wir haben dort eine Zeile angelegt. Das ist unsere Beispiel-Tabelle. Und wir werden Abschnitte erstellen, um Ihnen einfach Beispiele f\u00fcr Sperren zu zeigen. <\/p>\n
<\/p>\n
<\/p>\n
Also eine Zeile, eine Spalte. Der erste Sperrtyp hei\u00dft ACCESS SHARE. Das ist die am wenigsten einschr\u00e4nkende Sperre. Das bedeutet, dass sie praktisch nicht mit anderen Sperren in Konflikt steht.<\/p>\n
<\/p>\n
Wenn wir die Sperrung explizit definieren wollen, f\u00fchren wir den Befehl \u201elock table\u201c aus. Dies wird die Tabelle eindeutig sperren, d.h. im ACCESS SHARE-Modus f\u00fchren wir lock table aus. Und wenn ich PSQL im Hintergrund starte, starte ich somit eine zweite Sitzung aus meiner ersten Sitzung. Was mache ich hier? Ich wechsle zu einer anderen Sitzung und sage ihr: \u201eZeig mir die lockview f\u00fcr diese Anfrage\u201c. Und hier habe ich AccessShareLock in dieser Tabelle. Genau das habe ich angefordert. Und es zeigt, dass die Sperre zugewiesen wurde. Ganz einfach. <\/p>\n
<\/p>\n
<\/p>\n
Wenn wir uns die zweite Spalte ansehen, ist dort nichts. Sie sind leer. <\/p>\n
<\/p>\n
<\/p>\n
Wenn ich den Befehl \u201eSELECT\u201c ausf\u00fchre, ist das eine implizite (einfache) M\u00f6glichkeit, ein AccessShareLock anzufordern. Also gebe ich meine Tabelle frei und f\u00fchre die Anfrage aus, die mehrere Zeilen zur\u00fcckgibt. Und in einer der Zeilen sehen wir AccessShareLock. Somit ruft SELECT AccessShareLock in der Tabelle auf. Und es konfliktiert praktisch mit nichts, da dies eine Lock auf niedriger Ebene ist. <\/p>\n
<\/p>\n
<\/p>\n
Was passiert, wenn ich SELECT ausf\u00fchre und drei verschiedene Tabellen habe? Fr\u00fcher habe ich nur eine Tabelle ausgef\u00fchrt, jetzt f\u00fchre ich drei aus: pg_class, pg_namespace und pg_attribute.<\/p>\n
<\/p>\n
<\/p>\n
Und jetzt, wenn ich die Anfrage anschaue, sehe ich 9 AccessShareLocks in drei Tabellen. Warum? Die drei Tabellen sind in Blau hervorgehoben: pg_attribute, pg_class, pg_namespace. Aber Sie k\u00f6nnen auch sehen, dass alle Indizes, die \u00fcber diese Tabellen definiert sind, ebenfalls einen AccessShareLock haben.<\/p>\n
<\/p>\n
Und dies ist eine Sperre, die praktisch nicht mit anderen in Konflikt steht. Alles, was sie tut, ist, dass sie uns einfach daran hindert, die Tabelle zur\u00fcckzusetzen, w\u00e4hrend wir sie abfragen. Das macht Sinn. D. h. wenn wir die Tabelle abfragen und sie in diesem Moment verschwindet, ist das nicht korrekt, also AccessShare \u2013 \u044d\u0442\u043e \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043a\u0430 \u043d\u0438\u0437\u043a\u043e\u0433\u043e \u0443\u0440\u043e\u0432\u043d\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c "\u043d\u0435 \u0443\u0434\u0430\u043b\u044f\u0439\u0442\u0435 \u044d\u0442\u0443 \u0442\u0430\u0431\u043b\u0438\u0446\u0443, \u043f\u043e\u043a\u0430 \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e"<\/strong>. Im Wesentlichen ist das alles, was sie tut. <\/p>\n<\/p>\n
<\/p>\n
ROW SHARE ist eine Sperre, die sich etwas unterscheidet. <\/p>\n
<\/p>\n
<\/p>\n
Lassen Sie uns ein Beispiel nehmen. SELECT ROW SHARE ist eine Methode zur Sperrung jeder Zeile einzeln<\/strong>. So kann niemand sie l\u00f6schen oder \u00e4ndern, w\u00e4hrend wir sie betrachten. <\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
Hier sagen wir, dass die Sperre von uns verwendet wird.<\/p>\n
<\/p>\n
<\/p>\n
Die exklusive Sperre besagt ausdr\u00fccklich, dass sie exklusiv ist. Und auch wenn Sie eine Zeile in dieser Tabelle l\u00f6schen, passiert genau das, wie Sie sehen k\u00f6nnen. <\/p>\n
<\/p>\n
<\/p>\n
SHARE EXCLUSIVE ist eine l\u00e4ngere Sperre.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Das ist der (ANALYZE) Befehl des Analysators, der verwendet wird.<\/p>\n
<\/p>\n
<\/p>\n
SHARE LOCK \u2013 Sie k\u00f6nnen ausdr\u00fccklich im Freigabemodus sperren.<\/p>\n
<\/p>\n
<\/p>\n
Sie k\u00f6nnen auch einen eindeutigen Index erstellen. Und dort k\u00f6nnen Sie SHARE LOCK sehen, das Teil davon ist. Es sperrt die Tabelle und setzt eine SHARE LOCK auf.<\/p>\n
<\/p>\n
Standardm\u00e4\u00dfig bedeutet SHARE LOCK auf einer Tabelle, dass andere Personen die Tabelle lesen k\u00f6nnen, aber niemand sie modifizieren kann. Und genau das passiert, wenn Sie einen eindeutigen Index erstellen.<\/strong><\/p>\n<\/p>\n
Wenn ich einen eindeutigen Index concurrently erstelle, habe ich eine andere Art der Sperrung, denn wie Sie sich erinnern, verringert die Verwendung von concurrently Indizes die Anforderungen an die Sperrung. Und wenn ich eine normale Sperrung mit einem normalen Index verwende, werde ich damit das Schreiben in den Index der Tabelle w\u00e4hrend seiner Erstellung verhindern. Wenn ich einen concurrently Index verwende, muss ich einen anderen Sperrtyp verwenden. <\/p>\n
<\/p>\n
<\/p>\n
SHARE ROW EXCLUSIVE \u2013 auch hier kann sie explizit (eindeutig) festgelegt werden.<\/p>\n
<\/p>\n
<\/p>\n
Oder wir k\u00f6nnen eine Regel erstellen, d.h. einen bestimmten Fall festlegen, in dem sie verwendet wird.<\/p>\n
<\/p>\n
<\/p>\n
EXCLUSIVE-Sperre bedeutet, dass niemand sonst die Tabelle \u00e4ndern kann. <\/p>\n
<\/p>\n
<\/p>\n
Hier sehen wir verschiedene Arten von Sperren. <\/p>\n
<\/p>\n
<\/p>\n
ACCESS EXCLUSIVE, zum Beispiel, ist ein Sperrbefehl. Wenn Sie zum Beispiel CLUSTER table<\/code>, bedeutet das, dass niemand dort schreiben kann. Und es sperrt nicht nur die Tabelle selbst, sondern auch die Indizes.<\/p>\n<\/p>\n
<\/p>\n
Dies ist die zweite Seite der ACCESS EXCLUSIVE-Sperre, auf der wir genau sehen, was sie in der Tabelle sperrt. Sie sperrt einzelne Zeilen der Tabelle, was ziemlich interessant ist.<\/p>\n
<\/p>\n
Das ist die gesamte grundlegende Information, die ich geben wollte. Wir haben \u00fcber Sperren gesprochen, \u00fcber Transaktions-IDs, \u00fcber virtuelle Transaktions-IDs und \u00fcber permanente Transaktions-IDs. <\/p>\n
<\/p>\n
<\/p>\n
Jetzt werden wir zu den Beispielen von Sperren \u00fcbergehen. Das ist der interessanteste Teil. Wir werden uns sehr interessante F\u00e4lle ansehen. Mein Ziel in dieser Pr\u00e4sentation ist es, Ihnen ein besseres Verst\u00e4ndnis daf\u00fcr zu geben, was Postgres tats\u00e4chlich tut, wenn es versucht, bestimmte Dinge zu sperren. Ich denke, es kann sehr gut einzelne Teile sperren. <\/p>\n
<\/p>\n
Lassen Sie uns bestimmte Beispiele betrachten.<\/p>\n
<\/p>\n
<\/p>\n
Wir beginnen mit Tabellen und einer Zeile in der Tabelle. Wenn ich etwas einf\u00fcge, wird mir der ExclusiveLock angezeigt, die Transaktions-ID und der ExclusiveLock auf der Tabelle. <\/p>\n
<\/p>\n
<\/p>\n
Was passiert, wenn ich noch zwei Zeilen einf\u00fcge? Jetzt haben wir drei Zeilen in unserer Tabelle. Ich habe eine Zeile hinzugef\u00fcgt und das ist das Ergebnis. Und wenn ich noch zwei Zeilen einf\u00fcge, was ist hier seltsam? Es gibt eine Eigenart, denn ich habe drei Zeilen zu dieser Tabelle hinzugef\u00fcgt, aber ich habe immer noch zwei Zeilen in der Sperrtabelle. Das ist im Grunde genommen das grundlegende Verhalten von Postgres.<\/p>\n
<\/p>\n
Viele denken, dass wenn Sie in der Datenbank 100 Zeilen sperren, Sie 100 Sperrdatens\u00e4tze erstellen m\u00fcssen. Wenn ich gleichzeitig 1.000 Zeilen sperre, ben\u00f6tige ich 1.000 solcher Anfragen. Und wenn ich eine Million oder eine Milliarde sperren muss? Aber wenn wir es so machen, wird es nicht gut funktionieren. Wenn Sie ein System verwendet haben, das Sperrdatens\u00e4tze f\u00fcr jede einzelne Zeile erstellt, merken Sie, dass das kompliziert ist. Denn Sie m\u00fcssen die Sperrtabelle sofort definieren, die \u00fcberlaufen kann, aber Postgres macht das nicht. <\/p>\n
<\/p>\n
Auf dieser Folie ist es sehr wichtig, dass hier eindeutig dargestellt wird, dass es ein weiteres System gibt, das innerhalb von MVCC arbeitet und einzelne Zeilen sperrt. Daher erstellt Postgres, wenn Sie Milliarden von Zeilen sperren, nicht eine Milliarde separater Sperrbefehle. Das hat sich sehr positiv auf die Leistung ausgewirkt. <\/p>\n
<\/p>\n
<\/p>\n
Wie sieht es mit dem Update aus? Ich aktualisiere gerade eine Zeile und Sie k\u00f6nnen sehen, dass es sofort zwei verschiedene Operationen durchgef\u00fchrt hat. Es hat gleichzeitig die Tabelle gesperrt, aber auch den Index. Und es musste den Index sperren, weil es auf dieser Tabelle einzigartige Einschr\u00e4nkungen gibt. Wir m\u00f6chten sicherstellen, dass niemand ihn ver\u00e4ndert, also sperren wir ihn.<\/p>\n
<\/p>\n
<\/p>\n
Was passiert, wenn ich zwei Zeilen aktualisieren m\u00f6chte? Und wir sehen, dass es sich \u00e4hnlich verh\u00e4lt. Wir f\u00fchren doppelt so viele Updates durch, aber die Anzahl der gesperrten Zeilen bleibt genau gleich. <\/p>\n
<\/p>\n
Wenn Sie sich fragen, wie Postgres das macht, m\u00fcssen Sie meine Vortr\u00e4ge \u00fcber MVCC h\u00f6ren, um zu erfahren, wie Postgres intern diese Zeilen markiert, die es \u00e4ndert. Postgres hat einen Weg, wie es das macht, aber es tut dies nicht auf der Ebene von Tabellenverriegelungen, sondern auf einer niedrigeren und effizienteren Ebene.<\/p>\n
<\/p>\n
<\/p>\n
Und was ist, wenn ich etwas l\u00f6schen m\u00f6chte? Wenn ich beispielsweise eine Zeile l\u00f6sche und meine zwei Eins\u00e4tze mit der Sperrung immer noch vorhanden sind, selbst wenn ich alle l\u00f6schen m\u00f6chte, sind sie immer noch vorhanden.<\/p>\n
<\/p>\n
<\/p>\n
Und sagen wir, ich m\u00f6chte 1.000 Zeilen einf\u00fcgen und danach entweder 1.000 Zeilen l\u00f6schen oder hinzuf\u00fcgen. Die einzelnen Zeilen, die ich hinzuf\u00fcge oder \u00e4ndere, werden hier nicht aufgezeichnet. Sie werden auf einer niedrigeren Ebene innerhalb der Zeile selbst aufgezeichnet. Und w\u00e4hrend meines Vortrags \u00fcber MVCC habe ich dies im Detail erkl\u00e4rt. Es ist jedoch sehr wichtig, dass Sie beim Analysieren von Sperren sicherstellen, dass Sie eine Sperre auf Tabellenebene haben und hier nicht sehen, wie die einzelnen Zeilen aufgezeichnet werden. <\/p>\n
<\/p>\n
<\/p>\n
Und wie sieht es mit expliziten Sperren aus?<\/p>\n
<\/p>\n
<\/p>\n
Wenn ich auf \u201eAktualisieren\u201c klicke, habe ich zwei gesperrte Zeilen. Und wenn ich sie alle ausw\u00e4hle und auf \u201e\u00dcberall aktualisieren\u201c klicke, bleiben mir trotzdem zwei Sperrposten. <\/p>\n
<\/p>\n
<\/p>\n
Wir erstellen keine separaten Eintr\u00e4ge f\u00fcr jede einzelne Zeile. Denn dann leidet die Leistung, da k\u00f6nnte es zu viel davon geben. Und wir k\u00f6nnten in einer unangenehmen Situation enden. <\/p>\n
<\/p>\n
<\/p>\n
Und das Gleiche gilt, wenn wir Shared verwenden, wir k\u00f6nnen es f\u00fcr alle 30 machen. <\/p>\n
<\/p>\n
<\/p>\n
Wir stellen unsere Tabelle wieder her, l\u00f6schen alles und f\u00fcgen dann eine Zeile erneut ein.<\/p>\n
<\/p>\n
<\/p>\n
Eine weitere Verhaltensweise, die Sie in Postgres sehen, ist ein sehr bekanntes und gew\u00fcnschtes Verhalten \u2013 dass Sie Update oder Select durchf\u00fchren k\u00f6nnen. Und Sie k\u00f6nnen dies gleichzeitig tun. Und Select blockiert nicht das Update, und umgekehrt. Wir sagen dem Lesenden, dass er den Schreibenden nicht blockiert, und der Schreibende blockiert den Lesenden nicht. <\/p>\n
<\/p>\n
Ich zeige Ihnen ein Beispiel daf\u00fcr. Ich werde jetzt eine Auswahl treffen. Dann werden wir ein INSERT durchf\u00fchren. Und Sie werden dann sehen k\u00f6nnen \u2013 694. Sie werden die ID der Transaktion sehen, die diesen Insert durchgef\u00fchrt hat. Und so funktioniert das. <\/p>\n
<\/p>\n
<\/p>\n
Und wenn ich jetzt auf meine Backend-ID schaue, dann ist sie \u2013 695. <\/p>\n
<\/p>\n
<\/p>\n
Und ich kann sehen, dass 695 in meiner Tabelle erscheint. <\/p>\n
<\/p>\n
<\/p>\n
Und wenn ich hier ein Update so durchf\u00fchre, erhalte ich einen anderen Fall. In diesem Fall ist 695 eine exklusive Sperre, und das Update hat ein \u00e4hnliches Verhalten, aber zwischen ihnen entsteht kein Konflikt, was ziemlich ungew\u00f6hnlich ist. <\/p>\n
<\/p>\n
Und Sie k\u00f6nnen feststellen, dass oben \u2013 dies ist ein ShareLock, und unten \u2013 dies ist ein ExclusiveLock. Und beide Transaktionen haben stattgefunden.<\/p>\n
<\/p>\n
Und man muss sich meinen Vortrag \u00fcber MVCC anh\u00f6ren, um zu verstehen, wie das funktioniert. Aber dies ist eine Illustration daf\u00fcr, dass man dies gleichzeitig machen kann, also SELECT und UPDATE gleichzeitig durchf\u00fchren kann.<\/p>\n
<\/p>\n
<\/p>\n
Lass uns zur\u00fccksetzen und noch einmal eine Operation durchf\u00fchren. <\/p>\n
<\/p>\n
<\/p>\n
Wenn Sie versuchen, gleichzeitig zwei Updates auf derselben Zeile auszuf\u00fchren, wird es gesperrt. Und denken Sie daran, dass ich gesagt habe, dass ein Leser einen Schreiber nicht sperrt, aber ein Schreiber einen Leser sperrt, aber ein Schreiber blockiert einen anderen Schreiber. Das bedeutet, dass wir nicht zwei Personen gleichzeitig dasselbe Update auf derselben Zeile durchf\u00fchren k\u00f6nnen. Einer muss warten, bis der andere fertig ist. <\/p>\n
<\/p>\n
<\/p>\n
Und um dies zu veranschaulichen, schaue ich mir die Lockdemo-Tabelle an. Und wir werden eine Zeile betrachten. Bei der Transaktion 698.<\/p>\n
<\/p>\n
Wir haben es auf 2 aktualisiert. 699 ist das erste Update. Und es war erfolgreich oder es befindet sich in einer ausstehenden Transaktion und wartet darauf, dass wir best\u00e4tigen oder stornieren. <\/p>\n
<\/p>\n
<\/p>\n
Aber schauen Sie sich das andere an \u2013 2\/51 \u2013 das ist unsere erste Transaktion, unsere erste Sitzung. 3\/112 \u2013 das ist die zweite Anfrage, die oben erschien und diesen Wert auf 3 \u00e4nderte. Und wenn Sie bemerken, hat sich die obere Anfrage selbst blockiert, die 699 ist. Aber 3\/112 hat keine Sperre bereitgestellt. In der Spalte Lock_mode steht, dass es wartet. Es wartet auf 699. Und wenn Sie sehen, wo 699 ist, ist es h\u00f6her. Und was hat die erste Sitzung gemacht? Sie hat eine exklusive Sperre auf ihrer eigenen Transaktions-ID erstellt. So funktioniert Postgres. Es sperrt die eigene Transaktions-ID. Und wenn Sie warten m\u00f6chten, bis jemand best\u00e4tigt oder stornert, m\u00fcssen Sie warten, bis eine ausstehende Transaktion vorhanden ist. Und deshalb k\u00f6nnen wir eine merkw\u00fcrdige Zeile sehen. <\/p>\n
<\/p>\n
Schauen wir uns das noch einmal an. Auf der linken Seite sehen wir unsere Verarbeitungs-ID. In der zweiten Spalte sehen wir unsere virtuelle Transaktions-ID, und in der dritten sehen wir den lock_type. Was bedeutet das? Im Grunde genommen besagt sie, dass sie die Transaktions-ID blockiert. Aber beachten Sie, dass in allen Zeilen unten 'relation' steht. Deshalb haben Sie zwei Arten von Sperren in der Tabelle. Es gibt die Sperre 'relation'. Und es gibt auch die Sperre 'transactionid', bei der Sie selbst blockieren, genau das passiert in der ersten Zeile oder ganz unten, wo transationid steht, wo wir erwarten, dass 699 seine Operation abschlie\u00dft. <\/p>\n
<\/p>\n
Ich sehe, was hier passiert. Gleichzeitig geschehen hier zwei Dinge. Sie betrachten die Sperre nach Transaktions-ID in der ersten Zeile, die sich selbst sperrt. Und sie sperrt sich selbst, um die Leute warten zu lassen. <\/p>\n
<\/p>\n
Wenn Sie sich die 6. Zeile ansehen, ist das dieselbe Aufzeichnung wie die erste. Daher wird die Transaktion 699 blockiert. 700 sperrt sich ebenfalls selbst. Und dann sehen Sie in der unteren Reihe, dass wir warten, bis 699 seine Operation abschlie\u00dft.<\/p>\n
<\/p>\n
<\/p>\n
Und in lock_type, tuple sehen Sie Zahlen. <\/p>\n
<\/p>\n
<\/p>\n
Sie k\u00f6nnen sehen, dass es 0\/10 ist. Und das ist die Seitennummer sowie der Offset dieser bestimmten Zeile. <\/p>\n
<\/p>\n
<\/p>\n
Und Sie sehen, dass es 0\/11 wird, wenn wir aktualisieren. <\/p>\n
<\/p>\n
<\/p>\n
Aber in Wirklichkeit sind es 0\/10, weil ich auf diesen Vorgang warte. Wir haben die M\u00f6glichkeit zu sehen, dass dies die Zeile ist, auf die ich warte, um zu best\u00e4tigen. <\/p>\n
<\/p>\n
<\/p>\n
Sobald wir es best\u00e4tigt und auf Commit gedr\u00fcckt haben und wenn das Update abgeschlossen ist, ist das, was wir wieder erhalten. Transaktion 700 ist die einzige Sperre, sie wartet auf niemanden mehr, weil sie bereits committet wurde. Sie wartet lediglich darauf, dass die Transaktion abgeschlossen wird. Sobald 699 endet, warten wir auf nichts mehr. Und jetzt sagt Transaktion 700, dass alles in Ordnung ist, dass sie alle ben\u00f6tigten Sperren in den genehmigten Tabellen hat. <\/p>\n
<\/p>\n
<\/p>\n
Und um das Ganze noch komplizierter zu machen, erstellen wir eine weitere Ansicht, die uns diesmal eine Hierarchie bereitstellt. Ich erwarte nicht, dass Sie diese Anfrage verstehen. Aber sie wird uns eine klarere Sicht darauf geben, was passiert. <\/p>\n
<\/p>\n
<\/p>\n
Dies ist eine rekursive Ansicht, die auch noch einen weiteren Abschnitt hat. Und sie gibt dann alles zusammen zur\u00fcck. Lassen Sie uns das verwenden. <\/p>\n
<\/p>\n
<\/p>\n
Was ist, wenn wir drei gleichzeitige Aktualisierungen durchf\u00fchren und sagen, dass die Zeile jetzt drei betr\u00e4gt. Und wir \u00e4ndern 3 in 4. <\/p>\n
<\/p>\n
<\/p>\n
Und hier sehen wir 4. Und die Transaktions-ID 702. <\/p>\n
<\/p>\n
<\/p>\n
Und dann werde ich 4 in 5 \u00e4ndern. 5 in 6, 6 in 7. Und ich stelle eine Reihe von Personen auf, die darauf warten, dass diese eine Transaktion abgeschlossen wird.<\/p>\n
<\/p>\n
<\/p>\n
Und alles wird klar. Welche ist die erste Reihe? Das ist 702. Das ist die Transaktions-ID, die urspr\u00fcnglich diesen Wert gesetzt hat. Und was steht in der Spalte Granted? Ich habe Markierungen f<\/code>. Das sind meine Updates, die (5, 6, 7) nicht genehmigt werden k\u00f6nnen, weil wir darauf warten, dass die Transaktions-ID 702 abgeschlossen wird. Da gibt es eine Sperre der Transaktions-ID. Und es ergibt 5 transaktionsspezifische Sperren.<\/p>\n<\/p>\n
Und wenn Sie sich 704 und 705 ansehen, steht dort noch nichts, weil sie noch nicht wissen, was passiert. Sie schreiben einfach, dass sie keine Ahnung haben, was los ist. Und sie werden einfach in den Schlaf gehen, weil sie darauf warten, dass jemand fertig ist und sie wecken, wenn die M\u00f6glichkeit besteht, die Reihe zu wechseln. <\/p>\n
<\/p>\n
<\/p>\n
So sieht das aus. Es ist klar, dass sie alle auf die 12. Zeile warten. <\/p>\n
<\/p>\n
<\/p>\n
Das ist, was wir hier gesehen haben. Hier ist 0\/12. <\/p>\n
<\/p>\n
<\/p>\n
Sobald die erste Transaktion genehmigt ist, k\u00f6nnen Sie hier sehen, wie die Hierarchie funktioniert. Jetzt wird alles klar. Sie werden alle bereinigt. Und sie befinden sich tats\u00e4chlich noch in der Warteschleife. <\/p>\n
<\/p>\n
<\/p>\n
So l\u00e4uft es ab. 702 wird committet. Jetzt erh\u00e4lt 703 die Zeilensperre, und dann wartet 704, bis 703 committet wurde. Auch 705 wartet darauf. Und wenn all dies abgeschlossen ist, bereinigen sie sich selbst. Ich m\u00f6chte darauf hinweisen, dass sich alle hintereinander anstellen. Es erinnert sehr an eine Situation im Verkehr, wenn alle auf das erste Auto warten. Das erste Auto h\u00e4lt an, und alle stellen sich in einer langen Reihe auf. Dann f\u00e4hrt es weiter, dann kann das n\u00e4chste Auto vorfahren, seine Sperre erhalten usw. <\/p>\n
<\/p>\n
<\/p>\n
Und falls Ihnen das nicht kompliziert genug erschien, sprechen wir jetzt \u00fcber Deadlocks. Ich wei\u00df nicht, wer von Ihnen schon einmal damit zu tun hatte. Das ist ein h\u00e4ufiges Problem in Datenbanksystemen. Ein Deadlock tritt dann auf, wenn eine Sitzung darauf wartet, dass eine andere Sitzung etwas ausf\u00fchrt. W\u00e4hrenddessen wartet die andere Sitzung darauf, dass die erste Sitzung etwas ausf\u00fchrt. <\/p>\n
<\/p>\n
Und wenn beispielsweise Ivan sagt: \u201eGib mir irgendetwas\u201c, und ich sage: \u201eNein, ich gebe es dir nur, wenn du mir etwas anderes gibst\u201c. Und er sagt: \u201eNein, ich gebe dir das nicht, wenn du mir nicht etwas gibst\u201c. Und dann stecken wir in einer Situation der toten Blockade fest. Ich bin mir sicher, dass Ivan das nicht tun w\u00fcrde, aber Sie verstehen den Sinn, dass zwei Personen etwas erhalten wollen und sie nicht bereit sind, es zu geben, bis die andere Person ihnen das gibt, was sie wollen. Und hier gibt es keine L\u00f6sung. <\/p>\n
<\/p>\n
Und im Grunde muss Ihre Datenbank das erkennen. Und dann muss eine der Sitzungen beendet oder geschlossen werden, denn sonst bleiben sie dort f\u00fcr immer. Und wir sehen das in Datenbanken, wir sehen das in Betriebssystemen. Und an allen Stellen, wo wir parallele Prozesse haben, kann so etwas passieren. <\/p>\n
<\/p>\n
<\/p>\n
Und wir werden jetzt zwei Deadlocks einrichten. Wir setzen 50 und 80. In der ersten Reihe werde ich ein Update von 50 auf 50 durchf\u00fchren. Ich erhalte die Transaktionsnummer 710. <\/p>\n
<\/p>\n
<\/p>\n
Und dann werde ich 80 auf 81 und 50 auf 51 \u00e4ndern. <\/p>\n
<\/p>\n
<\/p>\n
Und so wird es aussehen. Und deshalb hat 710 eine Blockierung der Reihe, w\u00e4hrend 711 auf eine Best\u00e4tigung wartet. Wir haben das gesehen, als wir aktualisiert haben. 710 ist der Besitzer unserer Reihe. Und 711 wartet darauf, dass 710 die Transaktion abschlie\u00dft.<\/p>\n
<\/p>\n
<\/p>\n
Und dort steht sogar, in welcher Zeile es zu Deadlocks kommt. Und hier wird es seltsam.<\/p>\n
<\/p>\n
<\/p>\n
Jetzt aktualisieren wir 80 auf 80. <\/p>\n
<\/p>\n
<\/p>\n
Und hier beginnen die Deadlocks. 710 wartet auf eine Antwort von 711, w\u00e4hrend 711 auf 710 wartet. Das wird nicht gut enden. Und es gibt keinen Ausweg. Sie werden auf eine Antwort des jeweils anderen warten. <\/p>\n
<\/p>\n
<\/p>\n
Und das wird einfach alles verz\u00f6gern. Und das wollen wir nicht. <\/p>\n
<\/p>\n
<\/p>\n
In Postgres gibt es M\u00f6glichkeiten, um zu erkennen, wann das passiert. Und wenn es geschieht, erhalten Sie einen solchen Fehler. Daraus wird klar, dass ein bestimmter Prozess auf einen SHARE LOCK von einem anderen Prozess wartet, der von Prozess 711 blockiert wird. Dieser Prozess wartete darauf, dass ein SHARE LOCK f\u00fcr eine bestimmte Transaktions-ID gew\u00e4hrt wird und wurde von einem anderen Prozess blockiert. Daher ist hier eine Deadlock-Situation gegeben.<\/p>\n
<\/p>\n
<\/p>\n
Gibt es auch dreiseitige Deadlocks? Ist das m\u00f6glich? Ja. <\/p>\n
<\/p>\n
<\/p>\n
Wir geben diese Zahlen in die Tabelle ein. Wir \u00e4ndern 40 auf 40, wir erstellen die Sperre. <\/p>\n
<\/p>\n
<\/p>\n
\u00c4ndern wir 60 auf 61, 80 auf 81. <\/p>\n
<\/p>\n
<\/p>\n
Und dann \u00e4ndern wir 80, und dann \u2013 bam! <\/p>\n
<\/p>\n
<\/p>\n
Und 714 wartet jetzt auf 715. 716 wartet auf 715. Mit dem l\u00e4sst sich schon nichts mehr machen.<\/p>\n
<\/p>\n
<\/p>\n
Hier sind es nicht mehr zwei Personen, hier sind es bereits drei. Ich will etwas von dir, dieser will etwas vom dritten, und der dritte will etwas von mir. Und wir befinden uns in einem dreiseitigen Erwartungszustand, weil wir alle darauf warten, dass die andere Person das beendet, was sie tun sollte. <\/p>\n
<\/p>\n
<\/p>\n
Und Postgres wei\u00df, bei welcher Zeile das passiert. Daher wird er Ihnen die folgende Nachricht anzeigen, die zeigt, dass Sie ein Problem haben, bei dem drei Eingaben sich gegenseitig blockieren. Und es gibt keine Einschr\u00e4nkungen. Das kann der Fall sein, wenn 20 Eintr\u00e4ge sich gegenseitig blockieren. <\/p>\n
<\/p>\n
<\/p>\n
Das n\u00e4chste Problem ist serializable. <\/p>\n
<\/p>\n
<\/p>\n
Wenn eine spezielle serializable Sperre.<\/p>\n
<\/p>\n
<\/p>\n
Und wir kommen zur\u00fcck zu 719. Es hat eine ganz normale Ausgabe. <\/p>\n
<\/p>\n
<\/p>\n
Und Sie k\u00f6nnen klicken, um eine Transaktion aus serializable zu erstellen.<\/p>\n
<\/p>\n
<\/p>\n
Und Sie verstehen, dass Sie jetzt eine andere Art von Sperre haben \u2013 das bedeutet serializable. <\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Und deshalb haben wir eine neue Art von Sperre, die SARieadLock genannt wird, die eine serielle Sperre ist und das Einf\u00fcgen von Seriennummern erm\u00f6glicht.<\/p>\n
<\/p>\n
<\/p>\n
Und au\u00dferdem k\u00f6nnen Sie einzigartige Indizes einf\u00fcgen. <\/p>\n
<\/p>\n
<\/p>\n
In dieser Tabelle haben wir einzigartige Indizes.<\/p>\n
<\/p>\n
<\/p>\n
Wenn ich hier also die Zahl 2 eingebe, habe ich 2. Aber ganz oben f\u00fcge ich noch eine 2 ein. Und Sie k\u00f6nnen sehen, dass 721 eine exklusive Sperre hat. Aber jetzt wartet 722, bis 721 seinen Vorgang abgeschlossen hat, denn es kann die 2 nicht einf\u00fcgen, solange es nicht wei\u00df, was mit 721 passiert. <\/p>\n
<\/p>\n
<\/p>\n
Und wenn wir eine Subtransaktion durchf\u00fchren.<\/p>\n
<\/p>\n
<\/p>\n
Hier haben wir 723.<\/p>\n
<\/p>\n
<\/p>\n
Wenn wir den Punkt speichern und dann aktualisieren, erhalten wir eine neue Transaktions-ID. Das ist ein weiteres Verhaltensmerkmal, das Sie kennen m\u00fcssen. Wenn wir das zur\u00fcckgeben, verschwindet die Transaktions-ID. 724 verschwindet. Aber jetzt haben wir 725. <\/p>\n
<\/p>\n
Was ich hier versuche, ist, Ihnen Beispiele f\u00fcr ungew\u00f6hnliche Sperren zu zeigen, die Sie finden k\u00f6nnen: sei es serialisierbare Sperren oder SAVEPOINT \u2013 das sind verschiedene Arten von Sperren, die in der Sperrtabelle erscheinen werden. <\/p>\n
<\/p>\n
<\/p>\n
Es handelt sich um die Erstellung expliziter Sperren, wo pg_advisory_lock verwendet wird. <\/p>\n
<\/p>\n
<\/p>\n
Sie sehen, dass der Sperrtyp hier als advisory aufgef\u00fchrt ist. Und hier steht in Rot 'advisory'. Und Sie k\u00f6nnen gleichzeitig mit pg_advisory_unlock so eine Sperre aufheben.<\/p>\n
<\/p>\n
<\/p>\n
Zum Abschluss m\u00f6chte ich Ihnen noch eine sehr interessante Sache zeigen. Ich werde eine weitere Ansicht erstellen. Aber ich werde die Tabelle pg_locks mit der Tabelle pg_stat_activity verbinden. Und warum m\u00f6chte ich das tun? Weil ich dadurch alle aktuellen Sitzungen sehen kann und welche Locks sie erwarten. Das ist ziemlich spannend, wenn wir die Locks-Tabelle und die Anfragen-Tabelle zusammenf\u00fchren. <\/p>\n
<\/p>\n
<\/p>\n
Und hier erstellen wir pg_stat_view. <\/p>\n
<\/p>\n
<\/p>\n
Wir aktualisieren die Zeile um eins. Hier sehen wir 724. Dann aktualisieren wir unsere Zeile auf drei. Und was sehen Sie hier jetzt? Das sind die Anfragen, d.h. Sie sehen die gesamte Liste der Anfragen, die in der linken Spalte aufgef\u00fchrt sind. Auf der rechten Seite sehen Sie die Locks und was sie erzeugen. Das k\u00f6nnte f\u00fcr Sie verst\u00e4ndlicher sein, sodass Sie nicht jedes Mal zu jeder Sitzung zur\u00fcckkehren m\u00fcssen, um zu sehen, ob Sie sich anschlie\u00dfen sollten oder nicht. Das erledigt sich von selbst. <\/p>\n
<\/p>\n
Eine weitere Funktion, die sehr n\u00fctzlich ist \u2013 das ist pg_blocking_pids<\/code>. Sie haben wahrscheinlich noch nie davon geh\u00f6rt. Was macht sie? Sie erm\u00f6glicht es uns zu sagen, dass f\u00fcr diese Sitzung 11740, welche spezifischen Prozess-IDs erwartet werden. Und Sie k\u00f6nnen sehen, dass 11740 724 erwartet. Und 724 steht ganz oben. 11306 ist Ihre Prozess-ID. Im Grunde geht diese Funktion durch Ihre Sperrtabelle. Ich wei\u00df, dass es ein bisschen kompliziert ist, aber Sie schaffen es, das zu verstehen. Im Prinzip durchl\u00e4uft diese Funktion diese Sperrtabelle und versucht herauszufinden, wo sich diese Prozess-ID befindet, unter Ber\u00fccksichtigung der Sperren, auf die sie wartet. Sie versucht auch zu berechnen, welche Prozess-ID der Prozess hat, der auf die Sperre wartet. Daher k\u00f6nnen Sie diese Funktion ausf\u00fchren. pg_blocking_pids<\/code>.<\/p>\n<\/p>\n
Und das kann sehr n\u00fctzlich sein. Wir haben das erst seit Version 9.6 hinzugef\u00fcgt, also ist diese Funktion erst 5 Jahre alt, aber sie ist sehr, sehr n\u00fctzlich. Das Gleiche gilt f\u00fcr die zweite Anfrage. Sie zeigt genau das, was wir sehen m\u00fcssen. <\/p>\n
<\/p>\n
<\/p>\n
Das ist, wor\u00fcber ich mit Ihnen sprechen wollte. Und wie ich es erwartet habe, haben wir unsere gesamte Zeit genutzt, da es so viele Folien gab. Die Folien sind zum Herunterladen verf\u00fcgbar. Ich m\u00f6chte mich bei Ihnen bedanken, dass Sie hier waren. Ich bin sicher, dass Ihnen der Rest der Konferenz gefallen wird, vielen Dank!<\/p>\n
<\/p>\n
Fragen:<\/p>\n
<\/p>\n
Wenn ich versuche, Zeilen zu aktualisieren, w\u00e4hrend eine zweite Sitzung versucht, die gesamte Tabelle zu l\u00f6schen. Soweit ich verstehe, sollte es so etwas wie einen Intent-Lock geben. Gibt es das in Postgres?<\/em><\/p>\n<\/p>\n
<\/p>\n
Lassen Sie uns ganz von vorne anfangen. Vielleicht erinnern Sie sich, dass wir, wenn Sie irgendetwas tun, zum Beispiel ein SELECT, einen AccessShareLock vergeben. Und das verhindert das L\u00f6schen der Tabelle. Wenn Sie also eine Zeile in der Tabelle aktualisieren oder l\u00f6schen m\u00f6chten, kann jemand die gesamte Tabelle nicht gleichzeitig l\u00f6schen, weil Sie diesen AccessShareLock \u00fcber die gesamte Tabelle und \u00fcber die Zeile halten. Und sobald Sie fertig sind, k\u00f6nnen sie sie l\u00f6schen. Aber solange Sie etwas dort \u00e4ndern, k\u00f6nnen sie das nicht tun.<\/p>\n
<\/p>\n
Lassen Sie es uns noch einmal betrachten. Lassen Sie uns zum Beispiel \u00fcber das L\u00f6schen sprechen. Und Sie sehen, dass auf der Zeile ein exklusiver Lock \u00fcber die gesamte Tabelle besteht. <\/p>\n
<\/p>\n
Wird das wie ein exklusives Lock aussehen, richtig?<\/em><\/p>\n<\/p>\n
Ja, das sieht danach aus. Ich verstehe, was Sie meinen. Sie sagen, dass ich, wenn ich ein SELECT ausf\u00fchre, ein ShareExclusive bekomme, und dann dieses in einen Row Exclusive umwandele. Wird das ein Problem sein? \u00dcberraschenderweise verursacht das jedoch kein Problem. Es scheint, als w\u00fcrde dies den Lock-Level erh\u00f6hen, aber tats\u00e4chlich habe ich einen Lock, der das L\u00f6schen verhindert. Und jetzt, wenn ich diesen Lock m\u00e4chtiger mache, verhindert er weiterhin das L\u00f6schen. Daher ist es nicht so, als w\u00fcrde ich nach oben gehen. Das hei\u00dft, er hat das auch auf der niedrigeren Ebene verhindert, sodass er, wenn ich das Level erh\u00f6he, immer noch das L\u00f6schen der Tabelle verhindert. <\/p>\n
<\/p>\n
Ich verstehe, was Sie meinen. Hier gibt es keinen Fall einer Lock-Level-Erh\u00f6hung, wo Sie versuchen, eine Lock zu befreien, um eine m\u00e4chtigere zu bekommen. Hier erh\u00f6ht es einfach \u00fcberall diese Verhinderung, daher gibt es keinen Konflikt. Aber das ist eine gute Frage. Vielen Dank, dass Sie sie gestellt haben!<\/p>\n
<\/p>\n
Was m\u00fcssen wir tun, um eine Deadlock-Situation zu vermeiden, wenn wir viele Sessions und eine gro\u00dfe Anzahl von Benutzern haben?<\/em><\/p>\n<\/p>\n
Postgres erkennt automatisch Situationen von Deadlocks und entfernt automatisch eine der betroffenen Sitzungen. Der einzige Weg, um Deadlocks zu vermeiden, besteht darin, die Sperren in der gleichen Reihenfolge zu setzen. Wenn Sie also Ihre Anwendung betrachten, ist oft der Grund f\u00fcr Deadlocks\u2026 Stellen wir uns vor, ich m\u00f6chte zwei verschiedene Dinge sperren. Eine Anwendung sperrt Tabelle 1, w\u00e4hrend eine andere Anwendung zuerst Tabelle 2 und dann Tabelle 1 sperrt. Der einfachste Weg, um Deadlocks zu vermeiden, besteht darin, sicherzustellen, dass die Sperren in allen Anwendungen in der gleichen Reihenfolge erfolgen. Dies beseitigt in der Regel 80 % der Probleme, weil unterschiedliche Personen diese Anwendungen schreiben. Wenn Sie sie in der gleichen Reihenfolge sperren, vermeiden Sie Deadlocks.<\/p>\n
<\/p>\n
Vielen Dank f\u00fcr Ihre Ausf\u00fchrungen! Sie sprachen \u00fcber vacuum full, und wenn ich richtig verstehe, dann ver\u00e4ndert vacuum full die Reihenfolge der Datens\u00e4tze in der einzelnen Speicherung, wodurch die aktuellen Datens\u00e4tze unver\u00e4ndert bleiben. Aber warum ben\u00f6tigt vacuum full einen exklusiven Sperrzugriff und warum gibt es Konflikte mit Schreiboperationen?<\/em><\/p>\n<\/p>\n
Das ist eine gute Frage. Der Grund daf\u00fcr ist, dass vacuum full die Tabelle belegt. Und wir erstellen im Wesentlichen eine neue Version der Tabelle. Die Tabelle wird neu sein. Das bedeutet, es wird eine vollkommen neue Version der Tabelle sein. Und das Problem ist, dass, wenn wir das tun, wir nicht m\u00f6chten, dass die Leute diese Tabelle lesen, da wir m\u00f6chten, dass sie die neue Tabelle sehen. Und daher h\u00e4ngt es mit der vorherigen Frage zusammen. Wenn wir gleichzeitig lesen k\u00f6nnten, k\u00f6nnten wir sie nicht verschieben und die Leute zur neuen Tabelle leiten. Wir m\u00fcssten warten, bis jeder mit dem Lesen dieser Tabelle fertig ist, und deshalb ist es im Wesentlichen eine Situation mit exklusiver Sperrung.
<\/p>\n
Ist es m\u00f6glich, einen Lock-Timeout in Postgres hinzuzuf\u00fcgen? In Oracle kann ich zum Beispiel \"select for update\" schreiben und 50 Sekunden auf ein Update warten. Das war gut f\u00fcr die Anwendung. Aber in Postgres muss ich entweder sofort darauf zugreifen und gar nicht warten oder auf ein bestimmtes Zeitfenster warten.<\/em> <\/p>\n<\/p>\n
Ja, Sie k\u00f6nnen einen Timeout f\u00fcr Ihre Sperren festlegen. Sie k\u00f6nnen auch den Befehl no way ausgeben, der \u2026 sein wird, wenn Sie die Sperre nicht sofort erhalten k\u00f6nnen. Also entweder Lock-Timeout oder etwas anderes, das Ihnen dies erm\u00f6glicht. Das geschieht nicht auf der syntaktischen Ebene. Es wird als Variable auf dem Server festgelegt. Manchmal kann dies nicht angewendet werden.<\/p>\n
<\/p>\n
K\u00f6nnten Sie den 75. Slide \u00f6ffnen?<\/em> <\/p>\n<\/p>\n
Ja.<\/p>\n
<\/p>\n
<\/p>\n
Und meine n\u00e4chste Frage lautet: Warum warten beide Aktualisierungsprozesse auf 703?<\/em><\/p>\n<\/p>\n
Das ist eine interessante Frage. Ich verstehe \u00fcbrigens nicht, warum Postgres das macht. Aber als 703 erstellt wurde, erwartete es 702. Und wenn 704 und 705 erscheinen, scheint es so, als w\u00fcssten sie nicht, worauf sie warten, denn es gibt noch nichts. So funktioniert Postgres: Wenn Sie keine Sperre erhalten k\u00f6nnen, sagt es: \"Warum sollten wir Sie \u00fcberhaupt bearbeiten?\", weil Sie ohnehin auf jemanden warten. Daher lassen wir es einfach im Leeren h\u00e4ngen, es wird das nicht einmal aktualisieren. Aber was ist hier passiert? Sobald 702 den Prozess abgeschlossen hat und 703 seine Sperre erh\u00e4lt, kehrt das System zur\u00fcck. Und es sagt, dass wir jetzt zwei Personen haben, die auf etwas warten. Lassen Sie uns beide zusammen aktualisieren. <\/p>\n
<\/p>\n
Ich wei\u00df nicht, warum Postgres das so macht. Aber es gibt ein Problem, das als f\u2026 bezeichnet wird. Mir scheint, das ist kein Begriff auf Russisch. Das ist, wenn alle auf einen Lock warten, selbst wenn es 20 Instanzen gibt, die auf den Lock warten. Und pl\u00f6tzlich wachen sie alle gleichzeitig auf. Und alle versuchen zu reagieren. Aber das System sorgt daf\u00fcr, dass alle auf 703 warten. Denn sie warten alle, und wir stellen sie sofort alle in eine Reihe. Und wenn ein neuer Anfrage aufkommt, die nach dieser entstanden ist, zum Beispiel 707, dann gibt es dort erneut eine Leere. <\/p>\n
<\/p>\n
Und ich denke, das geschieht, damit man sagen kann, dass zu diesem Zeitpunkt 702 auf 703 wartet, w\u00e4hrend all jene, die danach kommen, keinen Eintrag in diesem Feld haben. Aber sobald der erste Wartende abspringt und alle, die in diesem Moment bis zur Aktualisierung gewartet haben, den gleichen Marker erhalten. Und deshalb scheint es mir, dass dies so gestaltet ist, damit wir die Anfragen in der richtigen Reihenfolge verarbeiten k\u00f6nnen. <\/p>\n
<\/p>\n
Ich habe das immer als ein recht seltsames Ph\u00e4nomen betrachtet. Denn hier zum Beispiel listen wir sie \u00fcberhaupt nicht auf. Aber ich denke, jedes Mal, wenn wir ein neues Lock vergeben, schauen wir uns alle an, die in der Warteschleife sind. Dann stellen wir sie alle in einer Reihe auf. Und jeder Neue, der kommt, gelangt nur dann in die Warteschlange, wenn die n\u00e4chste Person fertig ist. Sehr gute Frage. Vielen Dank f\u00fcr Ihre Frage!<\/p>\n
<\/p>\n
Es erscheint mir viel logischer, wenn 705 auf 704 wartet.<\/em> <\/p>\n<\/p>\n
Das Problem ist folgendes: Technisch gesehen k\u00f6nnen Sie diesen oder jenen Prozess aufwecken. Und deshalb werden wir den einen oder den anderen aufwecken. Doch was passiert im System? Sie sehen, dass 703 seine eigene Transaktions-ID an der Spitze blockiert hat. So funktioniert Postgres. Und 703 blockiert seine eigene Transaktions-ID, also wird, wenn jemand wartet, er auf 703 warten. Im Grunde genommen wird 703 beendet. Und erst nach dessen Beendigung wird einer der Prozesse aufwachen. Und wir wissen nicht, welcher Prozess es sein wird. Dann verarbeiten wir alles schrittweise. Aber es ist unklar, welcher Prozess zuerst aufwacht, denn es k\u00f6nnte jeder dieser Prozesse sein. Im Grunde hatten wir einen Planer, der sagte, dass wir jetzt jeden dieser Prozesse aufwecken k\u00f6nnten. Wir w\u00e4hlen einfach einen zuf\u00e4llig aus. Daher m\u00fcssen beide markiert werden, weil wir jeden von ihnen aufwecken k\u00f6nnen. <\/p>\n
<\/p>\n
Das Problem ist, dass wir eine CP-Unendlichkeit haben. Daher ist es durchaus m\u00f6glich, dass wir einen sp\u00e4teren Prozess wecken k\u00f6nnen. Wenn wir also beispielsweise einen sp\u00e4teren Prozess wecken, erwarten wir den, der gerade eine Sperrung erhalten hat, weshalb wir nicht genau bestimmen, wer zuerst geweckt wird. Wir schaffen einfach eine solche Situation, und das System wird sie in zuf\u00e4lliger Reihenfolge wecken. <\/p>\n
<\/p>\n
Es gibt Artikel \u00fcber Locks von Yegor Rogov<\/a><\/noindex>. Schaut mal, die sind auch interessant und n\u00fctzlich. Das Thema ist nat\u00fcrlich extrem komplex. Vielen Dank, Bruce!<\/em><\/p>\nQuelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2020 \u0433\u043e\u0434\u0430 \u0411\u0440\u044e\u0441\u0430 \u041c\u043e\u043c\u0436\u0438\u0430\u043d\u0430 "Unlocking the Postgres Lock Manager". (\u041f\u0440\u0438\u043c\u0435\u0447\u0430\u043d\u0438\u0435: \u0412\u0441\u0435 SQL \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438\u0437 \u0441\u043b\u0430\u0439\u0434\u043e\u0432 \u0432\u044b \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043f\u043e \u044d\u0442\u043e\u0439 \u0441\u0441\u044b\u043b\u043a\u0435: http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql) \u041f\u0440\u0438\u0432\u0435\u0442! \u0417\u0430\u043c\u0435\u0447\u0430\u0442\u0435\u043b\u044c\u043d\u043e \u0441\u043d\u043e\u0432\u0430 \u0431\u044b\u0442\u044c \u0437\u0434\u0435\u0441\u044c \u0432 \u0420\u043e\u0441\u0441\u0438\u0438. \u042f \u043f\u0440\u043e\u0448\u0443 \u043f\u0440\u043e\u0449\u0435\u043d\u0438\u0435, \u0447\u0442\u043e \u044f \u043d\u0435 \u0441\u043c\u043e\u0433 \u043f\u0440\u0438\u0435\u0445\u0430\u0442\u044c \u0432 \u043f\u0440\u043e\u0448\u043b\u043e\u043c \u0433\u043e\u0434\u0443, \u043d\u043e \u0432 \u044d\u0442\u043e\u043c \u0433\u043e\u0434\u0443 \u0443 \u0418\u0432\u0430\u043d\u0430 \u0438 \u0443 \u043c\u0435\u043d\u044f \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u043f\u043b\u0430\u043d\u044b. \u042f, \u043d\u0430\u0434\u0435\u044e\u0441\u044c, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":87955,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-87954","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Entsperren](\"\/wp-content\/uploads\/2020\/07\/1f75fbb0cb41c306c33c823ef55f7238.png\")
<\/p>\n