http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex><\/p>\n<\/p>\n
Wir sehen. 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 dem rosa hervorgehobenen Link folgen 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 wird keine Farben enthalten, aber zumindest werden wir sie sehen k\u00f6nnen.<\/p>\n
<\/p>\n
<\/p>\n
In diesem Fall sehen wir die ID der Transaktion. Das ist die Nummer, die wir ihr zugewiesen haben. Es gibt auch noch einen anderen Typ von 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 die ID einer Transaktion, die keine dauerhaften Werte enth\u00e4lt. Wenn ich beispielsweise den SELECT-Befehl ausf\u00fchre, werde ich wahrscheinlich nicht die Datenbank \u00e4ndern und nichts sperren. Daher vergeben wir beim Ausf\u00fchren eines einfachen SELECTs dieser Transaktion keine dauerhafte ID. Wir geben ihr nur eine virtuelle ID.<\/p>\n
<\/p>\n
Das verbessert die Leistung von Postgres und erh\u00f6ht die M\u00f6glichkeiten zur Bereinigung. Daher besteht die virtuelle Transaktions-ID aus zwei Zahlen. Die erste Zahl vor dem Slash ist die ID des Backends. Rechts sehen wir einfach einen Z\u00e4hler.<\/p>\n
<\/p>\n
<\/p>\n
Wenn ich also eine Abfrage ausf\u00fchre, zeigt sie an, dass die Backend-ID 2 ist. <\/p>\n
<\/p>\n
<\/p>\n
Wenn ich eine Reihe solcher Transaktionen ausf\u00fchre, 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. ausf\u00fchre. <\/p>\n
<\/p>\n
<\/p>\n
Bitte beachten Sie, dass hier zwei Spalten vorhanden sind. Links sehen wir die virtuelle Transaktions-ID \u2013 2\/12. Rechts haben wir die dauerhafte Transaktions-ID. Und dieses Feld ist leer. Diese Transaktion modifiziert die Datenbank nicht. Deshalb weise ich ihr keine dauerhafte Transaktions-ID zu.<\/p>\n
<\/p>\n
<\/p>\n
Sobald ich den Befehl analysieren (ANALYZE) ausf\u00fchre, gibt mir die gleiche Abfrage eine dauerhafte Transaktions-ID. Sehen Sie, wie sich das ge\u00e4ndert hat. Fr\u00fcher hatte ich diese ID nicht, jetzt ist sie erschienen.<\/p>\n
<\/p>\n
<\/p>\n
Hier ist also eine weitere Abfrage, eine weitere Transaktion. Die virtuelle Transaktionsnummer ist 2\/13. Und wenn ich nach der dauerhaften Transaktions-ID frage, werde ich sie erhalten, sobald ich die Abfrage ausgef\u00fchrt habe. <\/p>\n
<\/p>\n
<\/p>\n
Also, noch einmal. Wir haben die virtuelle Transaktions-ID und die 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 gehen wir einfach die verschiedenen Arten von Sperren in Postgres durch. Es ist nicht besonders spannend. Der letzte Abschnitt wird viel interessanter sein. Aber wir m\u00fcssen die grundlegenden Dinge betrachten, denn sonst verstehen wir nicht, was als N\u00e4chstes kommt. <\/p>\n
<\/p>\n
Wir werden diesen Abschnitt durchgehen, wir werden uns jeden Sperrtyp ansehen. Und ich werde Ihnen Beispiele zeigen, wie sie eingerichtet werden, wie sie funktionieren, und Ihnen einige Abfragen zeigen, die Sie verwenden k\u00f6nnen, um zu sehen, wie die Sperren in Postgres funktionieren.<\/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 haben wir pg_lock in rot markiert. Pg_lock ist eine Systemtabelle, die uns sagt, welche Sperren derzeit in Postgres verwendet werden.<\/p>\n
<\/p>\n
Es ist jedoch sehr schwierig f\u00fcr mich, Ihnen pg_lock alleine zu zeigen, da es ziemlich komplex ist. Daher habe ich eine Ansicht erstellt, die pg_locks zeigt. Und sie f\u00fchrt auch einige Arbeiten f\u00fcr mich aus, die es mir erm\u00f6glichen, besser zu verstehen. Das hei\u00dft, sie schlie\u00dft meine Sperren, meine eigene Sitzung usw. aus. Das ist einfach standardm\u00e4\u00dfiges SQL und es erm\u00f6glicht mir, Ihnen besser zu zeigen, was passiert. <\/p>\n
<\/p>\n
<\/p>\n
Ein weiteres Problem ist, dass diese Ansicht sehr umfassend ist, daher muss ich eine zweite erstellen \u2013 lockview2.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Also haben wir eine Tabelle erstellt, die Lockdemo hei\u00dft. Und wir haben dort eine Zeile erstellt. Das ist unsere Beispieltabelle. 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 wird ACCESS SHARE genannt. Das ist die am wenigsten einschr\u00e4nkende Sperre. Das bedeutet, dass sie praktisch nicht mit anderen Sperren in Konflikt steht.<\/p>\n
<\/p>\n
Und wenn wir die Sperrung explizit festlegen wollen, f\u00fchren wir den Befehl \u201elock table\u201c aus. Und das wird eindeutig gesperrt, d. h. im ACCESS SHARE-Modus f\u00fchren wir lock table aus. Und wenn ich PSQL im Hintergrund ausf\u00fchre, starte ich auf diese Weise eine zweite Sitzung aus meiner ersten Sitzung. Was mache ich hier? Ich gehe zu einer anderen Sitzung und sage ihr: \u201eZeig mir die lockview f\u00fcr diese Anfrage\u201c. Und hier habe ich AccessShareLock in dieser Tabelle. Das ist genau das, was ich angefordert habe. Und er sagt, dass die Sperrung zugewiesen wurde. Ganz einfach. <\/p>\n
<\/p>\n
<\/p>\n
Wenn wir uns die zweite Spalte ansehen, sehen wir nichts. Sie sind leer. <\/p>\n
<\/p>\n
<\/p>\n
Und wenn ich den Befehl \u201eSELECT\u201c ausf\u00fchre, ist das eine implizite (explizite) M\u00f6glichkeit, um AccessShareLock anzufordern. Daher gebe ich meine Tabelle frei und f\u00fchre die Abfrage aus, und die Abfrage gibt mehrere Zeilen zur\u00fcck. Und in einer der Zeilen sehen wir AccessShareLock. Somit ruft SELECT AccessShareLock in der Tabelle auf. Und es gibt praktisch keinen Konflikt, weil es sich um eine Low-Level-Sperre handelt. <\/p>\n
<\/p>\n
<\/p>\n
Was passiert, wenn ich SELECT mit drei verschiedenen Tabellen ausf\u00fchre? Zuvor 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 Abfrage betrachte, sehe ich 9 AccessShareLocks in drei Tabellen. Warum? Drei Tabellen sind blau hervorgehoben: pg_attribute, pg_class, pg_namespace. Aber Sie k\u00f6nnen auch sehen, dass alle Indizes, die \u00fcber diese Tabellen definiert sind, ebenfalls AccessShareLock haben.<\/p>\n
<\/p>\n
Und das ist eine Sperre, die praktisch keinen Konflikt mit anderen hat. Alles, was sie tut, ist einfach, dass sie uns nicht erlaubt, die Tabelle zur\u00fcckzusetzen, w\u00e4hrend wir sie ausw\u00e4hlen. Das macht Sinn. D. h. wenn wir eine Tabelle ausw\u00e4hlen, verschwindet sie in diesem Moment, das ist falsch, deshalb. AccessShare ist eine Low-Level-Sperre, die uns sagt: \"L\u00f6schen Sie diese Tabelle nicht, solange ich arbeite\".<\/strong>. Im Grunde ist das alles, was sie tut. <\/p>\n<\/p>\n
<\/p>\n
ROW SHARE \u2013 das ist eine Sperre, die etwas anders ist. <\/p>\n
<\/p>\n
<\/p>\n
Lassen Sie uns ein Beispiel nehmen. SELECT ROW SHARE ist eine Art von Sperre f\u00fcr jede 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 sagt explizit, dass sie exklusiv ist. Und wenn Sie eine Zeile in dieser Tabelle l\u00f6schen, wird es so geschehen, 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, der verwendet wird.<\/p>\n
<\/p>\n
<\/p>\n
Mit SHARE LOCK k\u00f6nnen Sie explizit im Freigabemodus blockieren.<\/p>\n
<\/p>\n
<\/p>\n
Sie k\u00f6nnen auch einen einzigartigen Index erstellen. Und dort sehen Sie SHARE LOCK, das Teil davon ist. Und es blockiert die Tabelle und setzt eine SHARE LOCK darauf.<\/p>\n
<\/p>\n
Standardm\u00e4\u00dfig bedeutet SHARE LOCK auf der Tabelle, dass andere Personen die Tabelle lesen k\u00f6nnen, aber niemand sie modifizieren kann. Und genau das passiert, wenn Sie einen einzigartigen Index erstellen.<\/strong><\/p>\n<\/p>\n
Wenn ich einen einzigartigen Index concurrently erstelle, werde ich einen anderen Sperrtyp haben, denn wie Sie sich erinnern, verringert die Verwendung von concurrently Indizes die Anforderungen an die Sperrung. Und wenn ich eine normale Sperre, einen normalen Index verwende, verhindere ich so das Schreiben in den Index der Tabelle w\u00e4hrend seiner Erstellung. Wenn ich einen concurrently Index verwende, muss ich einen anderen Sperrtyp verwenden. <\/p>\n
<\/p>\n
<\/p>\n
SHARE ROW EXCLUSIVE kann auch explizit angegeben werden.<\/p>\n
<\/p>\n
<\/p>\n
Oder wir k\u00f6nnen eine Regel erstellen, d. h. einen bestimmten Fall definieren, 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 ist beispielsweise ein Sperrbefehl. Zum Beispiel, wenn Sie die Tabelle CLUSTER<\/code>, bedeutet das, dass niemand dort schreiben kann. Und es blockiert nicht nur die Tabelle selbst, sondern auch die Indizes.<\/p>\n<\/p>\n
<\/p>\n
Das ist die zweite Seite der ACCESS EXCLUSIVE-Sperre, auf der wir konkret sehen, was sie in der Tabelle blockiert. Sie blockiert einzelne Zeilen der Tabelle, was ziemlich interessant ist.<\/p>\n
<\/p>\n
Dies sind alle grundlegenden Informationen, die ich Ihnen 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
Und jetzt werden wir uns einige Beispiele f\u00fcr Sperren ansehen. Dies ist der spannendste Teil. Wir werden sehr interessante F\u00e4lle betrachten. Mein Ziel in dieser Pr\u00e4sentation ist es, Ihnen ein besseres Verst\u00e4ndnis davon zu geben, was Postgres tats\u00e4chlich macht, wenn es versucht, verschiedene 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 mit einer Zeile in einer Tabelle. Wenn ich etwas einf\u00fcge, wird mir ein ExclusiveLock angezeigt, die Transaktions-ID und das ExclusiveLock auf der Tabelle. <\/p>\n
<\/p>\n
<\/p>\n
Was passiert, wenn ich zwei weitere Zeilen einf\u00fcge? Jetzt haben wir drei Zeilen in unserer Tabelle. Ich habe eine Zeile eingef\u00fcgt und das hier als Ausgabe erhalten. Und wenn ich noch zwei Zeilen einf\u00fcge, was ist hier ungew\u00f6hnlich? Es gibt etwas Seltsames, denn ich habe drei Zeilen zu dieser Tabelle hinzugef\u00fcgt, aber ich habe immer noch zwei Zeilen in der Sperrtabelle. Und das ist im Wesentlichen das grundlegende Verhalten von Postgres.<\/p>\n
<\/p>\n
Viele denken, dass wenn Sie in einer Datenbank 100 Zeilen sperren, Sie 100 Sperreintr\u00e4ge 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 das so machen, wird es nicht sehr gut funktionieren. Wenn Sie ein System verwendet haben, das Sperreintr\u00e4ge f\u00fcr jede einzelne Zeile erstellt, sehen Sie, dass das kompliziert ist. Denn Sie m\u00fcssen sofort die Sperrtabelle definieren, die \u00fcberlaufen kann, aber so funktioniert Postgres nicht. <\/p>\n
<\/p>\n
Und auf dieser Folie ist es sehr wichtig, dass hier eindeutig gezeigt wird, dass es noch ein anderes System gibt, das innerhalb von MVCC arbeitet und einzelne Zeilen sperrt. Daher erstellt Postgres, wenn Sie Milliarden von Zeilen sperren, nicht eine Milliarde separater Sperrkommandos. Und das wirkt sich sehr positiv auf die Leistung aus. <\/p>\n
<\/p>\n
<\/p>\n
Wie sieht es mit dem Update aus? Ich aktualisiere gerade eine Zeile, und Sie werden vielleicht bemerken, dass er sofort zwei verschiedene Operationen durchgef\u00fchrt hat. Er hat die Tabelle gleichzeitig gesperrt, aber auch den Index gesperrt. Und er musste den Index sperren, weil es eindeutige Einschr\u00e4nkungen in dieser Tabelle gibt. und wir wollen sicherstellen, dass ihn niemand \u00e4ndert, deshalb sperren wir ihn.<\/p>\n
<\/p>\n
<\/p>\n
Was passiert, wenn ich zwei Zeilen aktualisieren m\u00f6chte? Und wir sehen, dass es sich gleich verh\u00e4lt. Wir f\u00fchren doppelt so viele Aktualisierungen durch, aber die gleiche Anzahl von Sperrzeilen. <\/p>\n
<\/p>\n
Wenn Sie sich fragen, wie Postgres das macht, m\u00fcssen Sie sich meine Vortr\u00e4ge \u00fcber MVCC anh\u00f6ren, um zu erfahren, wie Postgres intern diese Zeilen markiert, die er \u00e4ndert. Und Postgres hat eine Methode, mit der er das macht, aber er macht es nicht auf Tabellen-Sperr-Ebene, sondern auf einer niedrigeren und effizienteren Ebene.<\/p>\n
<\/p>\n
<\/p>\n
Und wenn ich etwas l\u00f6schen m\u00f6chte? Wenn ich zum Beispiel eine Zeile l\u00f6sche und ich immer noch meine zwei anf\u00e4nglichen Sperren habe, und selbst wenn ich sie alle l\u00f6schen m\u00f6chte, bleiben sie trotzdem vorhanden.<\/p>\n
<\/p>\n
<\/p>\n
Und wenn ich zum Beispiel 1.000 Zeilen einf\u00fcgen m\u00f6chte und dann entweder l\u00f6schen oder 1.000 Zeilen hinzuf\u00fcgen m\u00f6chte, werden die einzelnen Zeilen, die ich hinzuf\u00fcge oder \u00e4ndere, hier nicht gespeichert. Sie werden auf einer niedrigeren Ebene innerhalb der Zeile selbst gespeichert. Und w\u00e4hrend des Vortrags \u00fcber MVCC habe ich das detailliert besprochen. Aber es ist sehr wichtig, wenn Sie Sperren analysieren, sicherzustellen, dass Sie eine Sperre auf Tabellenebene haben und dass Sie hier nicht sehen, wie einzelne Zeilen aufgezeichnet werden. <\/p>\n
<\/p>\n
<\/p>\n
Und wie sieht es mit einer expliziten Sperre aus?<\/p>\n
<\/p>\n
<\/p>\n
Wenn ich auf 'Aktualisieren' klicke, habe ich zwei gesperrte Zeilen. Und wenn ich sie alle ausw\u00e4hle und auf '\u00dcberall aktualisieren' klicke, habe ich immer noch zwei Sperreintr\u00e4ge. <\/p>\n
<\/p>\n
<\/p>\n
Wir erstellen keine separaten Eintr\u00e4ge f\u00fcr jede einzelne Zeile. Denn das w\u00fcrde die Leistung beeintr\u00e4chtigen, da es vielleicht zu viel davon gibt. Und wir k\u00f6nnten in einer unangenehmen Situation landen. <\/p>\n
<\/p>\n
<\/p>\n
Und dasselbe gilt, wenn wir shared machen, k\u00f6nnen wir das auf alle 30 Mal tun. <\/p>\n
<\/p>\n
<\/p>\n
Wir stellen unsere Tabelle wieder her, l\u00f6schen alles und f\u00fcgen dann erneut eine Zeile ein.<\/p>\n
<\/p>\n
<\/p>\n
Eine weitere Verhaltensweise, die Sie in Postgres sehen, ist das sehr gut bekannte und gew\u00fcnschte Verhalten \u2013 Sie k\u00f6nnen ein Update oder ein Select durchf\u00fchren. Und Sie k\u00f6nnen dies gleichzeitig tun. Und das Select blockiert nicht das Update und umgekehrt. Wir sagen dem Lesenden, dass er den Schreibenden nicht blockiert, und der Schreibende blockiert nicht den Lesenden. <\/p>\n
<\/p>\n
Ich werde Ihnen ein Beispiel daf\u00fcr zeigen. Ich werde jetzt eine Auswahl treffen. Dann werden wir ein INSERT durchf\u00fchren. Und Sie werden dann die ID der Transaktion, die dieses Insert durchgef\u00fchrt hat, sehen k\u00f6nnen \u2013 694. 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, dann erhalte ich einen anderen Fall. In diesem Fall ist 695 eine exklusive Sperre, und das Update hat dasselbe Verhalten, aber zwischen ihnen entsteht kein Konflikt, was ziemlich ungew\u00f6hnlich ist. <\/p>\n
<\/p>\n
Und Sie k\u00f6nnen bemerken, dass oben \u2013 das ist eine ShareLock, und unten \u2013 das ist eine ExclusiveLock. Und beide Transaktionen wurden erstellt.<\/p>\n
<\/p>\n
Und Sie sollten mein Referat \u00fcber MVCC anh\u00f6ren, um zu verstehen, wie das funktioniert. Aber das ist eine Veranschaulichung des, was Sie gleichzeitig tun k\u00f6nnen, d.h. SELECT und UPDATE gleichzeitig durchf\u00fchren.<\/p>\n
<\/p>\n
<\/p>\n
Lassen Sie 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 blockiert. Und denken Sie daran, ich sagte, dass der Lesende den Schreibenden nicht blockiert, der Schreibende aber den Lesenden blockiert, und ein Schreibender blockiert einen anderen Schreibenden. Das hei\u00dft, wir k\u00f6nnen nicht zulassen, dass zwei Personen gleichzeitig dieselbe Zeile aktualisieren. Einer muss warten, bis der andere fertig ist. <\/p>\n
<\/p>\n
<\/p>\n
Und um das zu veranschaulichen, werde ich mir die Lockdemo-Tabelle ansehen. Und wir werden uns eine Zeile anschauen. Bei der Transaktion 698.<\/p>\n
<\/p>\n
Wir haben sie auf 2 aktualisiert. 699 \u2013 das ist das erste Update. Und es war erfolgreich oder es befindet sich in einer wartenden Transaktion und wartet darauf, dass wir best\u00e4tigen oder abbrechen. <\/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 die diesen Wert auf 3 ge\u00e4ndert hat. Und wenn Sie bemerken, hat sich der obere selbst blockiert, der 699 ist. Aber 3\/112 hat keine Sperre bereitgestellt. In der Spalte Lock_mode steht, dass er wartet. Er wartet auf 699. Und wenn Sie schauen, wo 699 ist, ist es dar\u00fcber. Und was hat die erste Sitzung gemacht? Sie hat eine exklusive Sperre auf ihrer eigenen Transaktions-ID gesetzt. So macht es Postgres. Es blockiert die eigene Transaktions-ID. Und wenn Sie warten m\u00f6chten, bis jemand best\u00e4tigt oder abbricht, m\u00fcssen Sie warten, bis es eine wartende Transaktion gibt. Deshalb k\u00f6nnen wir diese seltsame Zeile sehen. <\/p>\n
<\/p>\n
Lassen Sie uns noch einmal hinschauen. Links sehen wir unsere Prozess-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 sagt sie, dass sie die Transaktions-ID blockiert. Aber beachten Sie, dass in allen Zeilen unten 'relation' steht. Und deshalb haben Sie zwei Arten von Sperren in der Tabelle. Es gibt die Sperre 'relation'. Und es gibt auch die Sperre 'transactionid', wo Sie selbst blockieren. Das ist genau das, was in der ersten Zeile oder ganz unten passiert, wo transactionid steht, wo wir warten, dass 699 seine Operation abschlie\u00dft. <\/p>\n
<\/p>\n
Ich schaue mir an, was hier passiert. Und hier passieren gleichzeitig zwei Dinge. Sie schauen sich die Sperre nach der Transaktions-ID in der ersten Zeile an, die sich selbst blockiert. Und sie blockiert sich selbst, um die Leute warten zu lassen. <\/p>\n
<\/p>\n
Wenn Sie sich die 6. Zeile anschauen, ist das dieselbe Aufzeichnung wie die erste. Und deshalb wird die Transaktion 699 blockiert. 700 blockiert sich ebenfalls selbst. Und dann sehen Sie in der unteren Zeile, dass wir warten, bis 699 seine Operation abschlie\u00dft.<\/p>\n
<\/p>\n
<\/p>\n
Und im lock_type sehen Sie tuple-Nummern. <\/p>\n
<\/p>\n
<\/p>\n
Sie k\u00f6nnen sehen, dass es 0\/10 ist. Und das ist die Seitennummer sowie der Offset dieser speziellen 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 tats\u00e4chlich ist es 0\/10, weil auf die Durchf\u00fchrung dieser Operation gewartet wird. Wir haben die M\u00f6glichkeit zu sehen, dass dies die Zeile ist, auf die ich warte, um sie zu best\u00e4tigen. <\/p>\n
<\/p>\n
<\/p>\n
Sobald wir es best\u00e4tigt und auf Commit geklickt haben und das Update abgeschlossen ist, ist das, was wir wieder erhalten. Transaktion 700 ist die einzige Sperre, sie wartet auf niemanden mehr, da sie bereits kommittiert wurde. Sie wartet nur 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 allen erlaubten 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 Abfrage verstehen. Aber es gibt uns eine klarere Sicht darauf, was vor sich geht. <\/p>\n
<\/p>\n
<\/p>\n
Dies ist eine rekursive Ansicht, die auch einen weiteren Abschnitt hat. Und dann gibt es alles zusammen zur\u00fcck. Lassen Sie uns das verwenden. <\/p>\n
<\/p>\n
<\/p>\n
Was w\u00e4re, wenn wir drei gleichzeitige Updates durchf\u00fchren und sagen, dass die Reihe 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 \u00e4ndere ich 4 in 5. Und 5 in 6, und 6 in 7. Und ich stelle eine Warteschlange 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 diesen Wert urspr\u00fcnglich festgelegt 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. Dort haben wir die Sperre der Transaktions-ID. Und es gibt 5 Transaktionssperren-IDs.<\/p>\n<\/p>\n
Und wenn Sie sich 704 und 705 ansehen, steht dort noch nichts geschrieben, weil sie noch nicht wissen, was passiert. Sie schreiben einfach, dass sie keine Ahnung haben, was passiert. Und sie werden einfach schlafen gehen, weil sie warten, dass jemand fertig ist und sie weckt, wenn es die Gelegenheit gibt, die Reihe zu \u00e4ndern. <\/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 das, 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. Und jetzt wird alles klar. Sie werden alle klar. Und sie sind tats\u00e4chlich immer noch im Warten. <\/p>\n
<\/p>\n
<\/p>\n
Das ist, was passiert. 702 wird festgeschrieben. Und jetzt erh\u00e4lt 703 diese Zeilen-Sperre, w\u00e4hrend 704 darauf wartet, dass 703 festgeschrieben wird. Auch 705 wartet darauf. Und wenn das alles abgeschlossen ist, reinigen sie sich selbst. Ich m\u00f6chte darauf hinweisen, dass sich alle in einer Warteschlange anstellen. Das \u00e4hnelt sehr der Situation mit einem Stau, wenn alle auf das erste Auto warten. Das erste Auto hat angehalten, und alle stellen sich in eine lange Reihe. Dann f\u00e4hrt es weiter, dann kann das n\u00e4chste Auto vorfahren und seine Sperre erhalten usw. <\/p>\n
<\/p>\n
<\/p>\n
Und wenn Ihnen das nicht kompliziert genug erschien, sprechen wir jetzt \u00fcber Deadlocks. Ich wei\u00df nicht, wer von Ihnen schon einmal mit ihnen zu tun hatte. Es ist ein recht verbreitetes Problem in Datenbanksystemen. Aber Deadlocks sind der Fall, 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
Zum Beispiel, wenn Ivan sagt: \u201eGib mir etwas\u201c, und ich sage: \u201eNein, ich gebe dir das nur, wenn du mir etwas anderes gibst\u201c. Und er sagt: \u201eNein, ich gebe es dir nicht, wenn du mir nichts gibst\u201c. Dann befinden wir uns in einer Deadlock-Situation. Ich bin mir sicher, dass Ivan das nicht tun w\u00fcrde, aber Sie verstehen den Sinn: Wir haben zwei Personen, die etwas erhalten m\u00f6chten, und sie sind nicht bereit, es zu geben, solange die andere Person ihnen nicht gibt, was sie wollen. Und es gibt keine L\u00f6sung. <\/p>\n
<\/p>\n
Im Wesentlichen muss Ihre Datenbank dies erkennen. Und dann m\u00fcssen Sie eine der Sitzungen schlie\u00dfen oder abbrechen, denn sonst bleiben sie dort f\u00fcr immer. Und wir sehen das in Datenbanken, wir sehen das in Betriebssystemen. Und an allen Orten, an denen wir parallele Prozesse haben, kann so etwas vorkommen. <\/p>\n
<\/p>\n
<\/p>\n
Wir setzen jetzt zwei Deadlocks. Wir setzen 50 und 80. In der ersten Zeile werde ich ein Update von 50 auf 50 durchf\u00fchren. Ich erhalte die Transaktionsnummer 710. <\/p>\n
<\/p>\n
<\/p>\n
Dann werde ich 80 auf 81 und 50 auf 51 \u00e4ndern. <\/p>\n
<\/p>\n
<\/p>\n
So wird es aussehen. Daher hat 710 eine Zeilen-Sperre, w\u00e4hrend 711 auf eine Best\u00e4tigung wartet. Wir haben das gesehen, als wir aktualisierten. 710 ist der Eigent\u00fcmer unserer Zeile. Und 711 wartet darauf, dass 710 die Transaktion abschlie\u00dft.<\/p>\n
<\/p>\n
<\/p>\n
Es steht sogar dabei, an welcher Zeile unser Deadlock auftritt. Und dort f\u00e4ngt es an, merkw\u00fcrdig zu werden.<\/p>\n
<\/p>\n
<\/p>\n
Jetzt aktualisieren wir 80 auf 80. <\/p>\n
<\/p>\n
<\/p>\n
Und hier beginnt das Deadlock. 710 wartet auf eine R\u00fcckmeldung von 711, w\u00e4hrend 711 auf 710 wartet. Das wird nicht gut enden. Und es gibt keinen Ausweg. Sie werden aufeinander 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 zu erkennen, wann das passiert. Und wenn das passiert, erhalten Sie diese Fehlermeldung. Daraus wird klar, dass ein Prozess auf einen SHARE LOCK von einem anderen Prozess wartet, das hei\u00dft, der von Prozess 711 blockiert wird. Und dieser Prozess wartete darauf, einen SHARE LOCK f\u00fcr eine bestimmte Transaktions-ID zu erhalten und wurde von einem anderen Prozess blockiert. Daher handelt es sich hier um eine Deadlock-Situation.<\/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 setzen eine Sperre. <\/p>\n
<\/p>\n
<\/p>\n
Wir \u00e4ndern 60 auf 61, 80 auf 81. <\/p>\n
<\/p>\n
<\/p>\n
Und dann \u00e4ndern wir 80 und dann \u2013 boom! <\/p>\n
<\/p>\n
<\/p>\n
Und 714 wartet jetzt auf 715. 716 wartet auf 715. Und damit kann man nichts mehr machen.<\/p>\n
<\/p>\n
<\/p>\n
Hier sind nicht nur zwei Personen, hier sind schon drei Personen. Ich will etwas von dir, dieser will etwas von der dritten Person, und die dritte Person will etwas von mir. Und wir kommen in eine dreiseitige Warteschlange, weil wir alle darauf warten, dass die andere Person das, was sie tun soll, abschlie\u00dft. <\/p>\n
<\/p>\n
<\/p>\n
Und Postgres wei\u00df, in welcher Zeile das passiert. Deshalb wird er Ihnen die n\u00e4chste Meldung geben, die zeigt, dass Sie ein Problem haben, bei dem drei Prozesse sich gegenseitig blockieren. Und hier gibt es keine Einschr\u00e4nkungen. Das kann in einem Szenario passieren, in dem 20 Datens\u00e4tze 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 auftritt.<\/p>\n
<\/p>\n
<\/p>\n
Und wir kehren zu 719 zur\u00fcck. Es gibt eine ganz normale Ausgabe. <\/p>\n
<\/p>\n
<\/p>\n
Und Sie k\u00f6nnen klicken, um die Transaktion aus serializable durchzuf\u00fchren.<\/p>\n
<\/p>\n
<\/p>\n
Und Sie erkennen, dass Sie jetzt eine andere Art von Sperre haben \u2013 das ist SA, was serializable bedeutet. <\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Und deshalb haben wir eine neue Art von Sperre, die SARieadLock hei\u00dft, die eine serielle Sperre ist und das Einf\u00fcgen von Seriennummern erm\u00f6glicht.<\/p>\n
<\/p>\n
<\/p>\n
Und Sie k\u00f6nnen auch eindeutige Indizes einf\u00fcgen. <\/p>\n
<\/p>\n
<\/p>\n
In dieser Tabelle haben wir eindeutige Indizes.<\/p>\n
<\/p>\n
<\/p>\n
Wenn ich also die Zahl 2 hier eingebe, dann habe ich 2. Aber ganz oben f\u00fcge ich noch einmal 2 hinzu. Und Sie k\u00f6nnen sehen, dass 721 eine exklusive Sperre hat. Aber jetzt wartet 722 darauf, dass 721 seine Operation abschlie\u00dft, weil es die 2 nicht einf\u00fcgen kann, bis es wei\u00df, was mit 721 geschieht. <\/p>\n
<\/p>\n
<\/p>\n
Und wenn wir eine Subtransaktion machen.<\/p>\n
<\/p>\n
<\/p>\n
Hier haben wir 723.<\/p>\n
<\/p>\n
<\/p>\n
Wenn wir den Punkt beibehalten und ihn dann aktualisieren, erhalten wir eine neue Transaktions-ID. Das ist ein weiteres Verhaltensmerkmal, das Sie wissen sollten. Wenn wir dies zur\u00fcckgeben, geht die Transaktions-ID weg. 724 verschwindet. Aber jetzt erscheint 725. <\/p>\n
<\/p>\n
Und was versuche ich hier zu tun? Ich versuche, Ihnen Beispiele f\u00fcr ungew\u00f6hnliche Sperren zu zeigen, die Sie finden k\u00f6nnen: ob es sich um serialisierbare Sperren oder SAVEPOINT handelt \u2013 das sind verschiedene Arten von Sperren, die in der Sperrtabelle erscheinen werden. <\/p>\n
<\/p>\n
<\/p>\n
Es handelt sich um das Erstellen expliziter (statischer) Sperren, bei denen pg_advisory_lock verwendet wird. <\/p>\n
<\/p>\n
<\/p>\n
Und Sie sehen, dass der Sperrtyp hier als advisory aufgef\u00fchrt ist. Und hier steht in Rot \u201eadvisory\u201c. Und Sie k\u00f6nnen gleichzeitig mit pg_advisory_unlock so sperren.<\/p>\n
<\/p>\n
<\/p>\n
Und zum Abschluss m\u00f6chte ich Ihnen noch eine geniale Sache zeigen. Ich werde eine weitere Art erstellen. Aber ich werde die Tabelle pg_locks mit der Tabelle pg_stat_activity verbinden. Und warum m\u00f6chte ich das tun? Weil ich mir damit alle aktuellen Sitzungen ansehen und sehen kann, auf welche Sperren sie warten. Das ist ziemlich interessant, wenn wir die Sperrtabelle und die Abfragetabelle zusammenbringen. <\/p>\n
<\/p>\n
<\/p>\n
Und hier erstellen wir pg_stat_view. <\/p>\n
<\/p>\n
<\/p>\n
Und wir aktualisieren eine Zeile um eins. Und hier sehen wir 724. Dann aktualisieren wir unsere Zeile auf drei. Was sehen Sie hier jetzt? Das sind die Abfragen, d.h. Sie sehen die gesamte Liste der Abfragen, die in der linken Spalte aufgef\u00fchrt sind. Und dann sehen Sie auf der rechten Seite die Sperren und was sie erzeugen. Das kann 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 m\u00fcssen oder nicht. Das \u00fcbernehmen f\u00fcr uns. <\/p>\n
<\/p>\n
Eine weitere Funktion, die sehr n\u00fctzlich ist \u2013 das ist pg_blocking_pids<\/code>. Sie haben wahrscheinlich noch nie von ihr geh\u00f6rt. Was macht sie? Sie erlaubt uns zu sagen, dass f\u00fcr diese Sitzung 11740, welche spezifischen Prozess-IDs sie erwartet. Und Sie k\u00f6nnen sehen, dass 11740 724 erwartet. Und 724 steht ganz oben. Und 11306 ist Ihre Prozess-ID. Grunds\u00e4tzlich durchl\u00e4uft diese Funktion Ihre Sperrtabelle. Und ich wei\u00df, dass das ein bisschen kompliziert ist, aber Sie verstehen es. Im Grunde genommen durchl\u00e4uft diese Funktion diese Sperrtabelle und versucht zu finden, wo sich diese Prozess-ID befindet, und ber\u00fccksichtigt dabei die Sperren, auf die sie wartet. Sie versucht auch herauszufinden, welche Prozess-ID der Prozess hat, der auf die Sperren wartet. Daher k\u00f6nnen Sie diese Funktion ausf\u00fchren. pg_blocking_pids<\/code>.<\/p>\n<\/p>\n
Und das kann sehr hilfreich sein. Wir haben es erst mit der Version 9.6 hinzugef\u00fcgt, sodass diese Funktion erst 5 Jahre alt ist, aber sie ist sehr und 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 es, wor\u00fcber ich mit Ihnen sprechen wollte. Und wie ich erwartet habe, haben wir unsere ganze Zeit genutzt, weil es eine so gro\u00dfe Anzahl an Folien gab. Und die Folien sind zum Download verf\u00fcgbar. Ich m\u00f6chte Ihnen danken, dass Sie hier waren. Ich bin mir sicher, dass Ihnen der Rest der Konferenz gefallen wird, vielen Dank!<\/p>\n
<\/p>\n
Fragen:<\/p>\n
<\/p>\n
Zum Beispiel, wenn ich versuche, Zeilen zu aktualisieren, w\u00e4hrend eine zweite Sitzung versucht, die gesamte Tabelle zu l\u00f6schen. So wie ich es verstehe, sollte es da etwas wie einen Intent Lock geben. Gibt es das in Postgres?<\/em><\/p>\n<\/p>\n
<\/p>\n
Gehen wir zur\u00fcck zum Anfang. Vielleicht erinnern Sie sich, dass wir, wenn Sie irgendetwas tun, zum Beispiel wenn Sie einen SELECT durchf\u00fchren, ein AccessShareLock vergeben. Und das verhindert das L\u00f6schen der Tabelle. Wenn Sie also zum Beispiel eine Reihe in der Tabelle aktualisieren oder eine Reihe l\u00f6schen m\u00f6chten, kann jemand nicht gleichzeitig die gesamte Tabelle l\u00f6schen, da Sie dieses AccessShareLock \u00fcber der gesamten Tabelle und \u00fcber der Reihe halten. Und sobald Sie fertig sind, k\u00f6nnen sie sie l\u00f6schen. Aber solange Sie direkt etwas dort ver\u00e4ndern, k\u00f6nnen sie das nicht tun.<\/p>\n
<\/p>\n
Lassen Sie es uns noch einmal durchgehen. Lassen Sie uns zum Beispiel auf das L\u00f6schen eingehen. Und Sie sehen, dass \u00fcber der Reihe ein exklusives Lock \u00fcber der gesamten Tabelle liegt. <\/p>\n
<\/p>\n
Das w\u00fcrde wie ein lock exclusive aussehen, richtig?<\/em><\/p>\n<\/p>\n
Ja, das sieht so aus. Ich verstehe, wor\u00fcber Sie sprechen. Sie sagen, dass ich, wenn ich ein SELECT ausf\u00fchre, ShareExclusive habe und es dann in den Zustand Row Exclusive \u00fcbergehe, ob das ein Problem wird? Aber \u00fcberraschenderweise verursacht das kein Problem. Es ist wie eine Erh\u00f6hung des Sperrgrades, aber im Wesentlichen habe ich einen Lock, der das L\u00f6schen verhindert. Und jetzt, wenn ich diesen Lock st\u00e4rker mache, verhindert er immer noch das L\u00f6schen. Daher ist es nicht so, dass ich nach oben gehe. Das hei\u00dft, es hat das auch auf einem niedrigeren Niveau verhindert, darum, wenn ich es erh\u00f6he, verhindert es immer noch das L\u00f6schen der Tabelle. <\/p>\n
<\/p>\n
Ich verstehe, wor\u00fcber Sie sprechen. Hier gibt es keinen Fall einer Erh\u00f6hung des Sperrgrades, wo Sie versuchen, eine Sperre aufzugeben, um eine st\u00e4rkere einzuf\u00fchren. Hier wird einfach \u00fcberall diese Verhinderung erh\u00f6ht, sodass es keinen Konflikt gibt. Aber das ist eine gute Frage. Vielen Dank, dass Sie sie gestellt haben!<\/p>\n
<\/p>\n
Was m\u00fcssen wir tun, um eine Situation mit Deadlocks zu vermeiden, wenn wir viele Sitzungen und eine gro\u00dfe Anzahl von Benutzern haben?<\/em><\/p>\n<\/p>\n
Postgres erkennt automatisch Deadlock-Situationen. Und wird automatisch eine der Sitzungen beenden. Der einzige Weg, um Deadlocks zu vermeiden, besteht darin, die Sperren in der gleichen Reihenfolge anzuwenden. Daher, wenn Sie sich Ihre Anwendung anschauen, ist es oft die Ursache f\u00fcr Deadlocks ... Stellen wir uns vor, ich m\u00f6chte zwei verschiedene Dinge sperren. Eine Anwendung sperrt Tabelle 1, und eine andere Anwendung sperrt 2, und dann Tabelle 1. Der einfachste Weg, Deadlocks zu vermeiden, besteht darin, Ihre Anwendung zu betrachten und sicherzustellen, dass die Sperrung in derselben Reihenfolge in allen Anwendungen erfolgt. Und das eliminiert in der Regel 80 % der Probleme, weil die unterschiedlichsten Menschen diese Anwendungen entwickeln. Und wenn Sie sie in derselben Reihenfolge sperren, kommen Sie nicht in die Deadlock-Situation.<\/p>\n
<\/p>\n
Vielen Dank f\u00fcr Ihren Vortrag! Sie haben \u00fcber Vacuum Full gesprochen und, wenn ich richtig verstehe, ver\u00e4ndert Vacuum Full die Reihenfolge der Datens\u00e4tze in der einzelnen Speicherung, sodass die aktuellen Datens\u00e4tze unver\u00e4ndert bleiben. Aber warum erfordert Vacuum Full einen exklusiven Sperrzugriff und warum gibt es Konflikte mit Schreibvorg\u00e4ngen?<\/em><\/p>\n<\/p>\n
Das ist eine gute Frage. Der Grund daf\u00fcr ist, dass vacuum full die Tabelle \u00fcbernimmt. Wir erstellen im Grunde genommen eine neue Version der Tabelle. Die Tabelle wird also neu sein. Das bedeutet, dass es sich um eine v\u00f6llig neue Version der Tabelle handeln wird. Und das Problem ist, dass wir nicht wollen, dass die Leute das lesen, w\u00e4hrend wir das tun, denn wir m\u00fcssen sicherstellen, dass sie die neue Tabelle sehen. Deshalb h\u00e4ngt das mit der vorherigen Frage zusammen. Wenn wir gleichzeitig lesen k\u00f6nnten, k\u00f6nnten wir es nicht verschieben und die Leute auf die neue Tabelle umleiten. Wir m\u00fcssten abwarten, bis alle mit dem Lesen dieser Tabelle fertig sind, und deshalb ist es im Wesentlichen eine exklusive Sperrsituation.
<\/p>\n
Ist es m\u00f6glich, einen Sperrzeitlimit in Postgres hinzuzuf\u00fcgen? In Oracle kann ich zum Beispiel 'select for update' schreiben und 50 Sekunden auf das Update warten. Das war gut f\u00fcr die Anwendung. Aber in Postgres muss ich das entweder sofort tun und \u00fcberhaupt nicht warten, oder bis zu einem bestimmten Zeitpunkt warten.<\/em> <\/p>\n<\/p>\n
Ja, Sie k\u00f6nnen einen Timeout f\u00fcr Ihre Sperren w\u00e4hlen. Sie k\u00f6nnen auch den Befehl 'no way' ausgeben, der \u2026, wenn Sie die Sperre nicht sofort erhalten k\u00f6nnen. Also entweder lock timeout oder etwas anderes, das Ihnen das erm\u00f6glicht. Das wird nicht auf syntaktischer Ebene gemacht. Es wird als Variable auf dem Server eingestellt. Manchmal kann man das nicht verwenden.<\/p>\n
<\/p>\n
K\u00f6nnten Sie die Folie 75 \u00f6ffnen?<\/em> <\/p>\n<\/p>\n
Ja.<\/p>\n
<\/p>\n
<\/p>\n
Und meine Frage lautet: Warum warten beide Update-Prozesse auf 703?<\/em><\/p>\n<\/p>\n
Und das ist eine gro\u00dfartige Frage. Ich verstehe \u00fcbrigens nicht, warum Postgres das macht. Als 703 erstellt wurde, erwartete es 702. Und als 704 und 705 erscheinen, scheint es, dass sie nicht wissen, auf was sie warten, denn es gibt noch nichts. Und Postgres macht es so: Wenn Sie keine Sperre erhalten k\u00f6nnen, schreibt es: \u201eWas hat einen Sinn beim Verarbeiten von euch?\u201c weil ihr sowieso auf jemanden wartet. Daher lassen wir es einfach in der Luft h\u00e4ngen, es aktualisiert das \u00fcberhaupt nicht. 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 warten. Und dann lass uns sie gemeinsam aktualisieren. Und wir geben an, dass beide warten. <\/p>\n
<\/p>\n
Ich wei\u00df nicht, warum Postgres das macht. Aber es gibt ein Problem, das f\u2026 genannt wird. Mir scheint, dass dies kein Begriff auf Russisch ist. Es ist, wenn alle auf eine Sperre warten, selbst wenn 20 Instanzen warten, die auf eine Sperre warten. Und pl\u00f6tzlich wachen sie alle gleichzeitig auf. Und alle beginnen zu versuchen, zu reagieren. Aber das System sorgt daf\u00fcr, dass alle 703 erwarten. Weil sie alle warten, und wir stellen sie sofort alle in eine Schlange. Und wenn eine neue Anfrage erscheint, die danach erstellt wurde, zum Beispiel 707, dann wird es dort wieder Leere geben. <\/p>\n
<\/p>\n
Und ich denke, das wird gemacht, damit man sagen kann, dass 702 in dieser Phase auf 703 wartet, und alle, die danach kommen, haben keinen Eintrag in diesem Feld. Aber sobald der erste Wartende geht und alle, die zu diesem Zeitpunkt bis zur Aktualisierung gewartet haben, den gleichen Marker erhalten. Und deshalb glaube ich, dass dies gemacht wurde, damit wir der Reihe nach verarbeiten k\u00f6nnen, damit sie richtig geordnet sind. <\/p>\n
<\/p>\n
Ich habe es immer als ein ziemlich seltsames Ph\u00e4nomen betrachtet. Denn hier zum Beispiel listen wir sie \u00fcberhaupt nicht auf. Aber ich denke, jedes Mal, wenn wir eine neue Sperre vergeben, schauen wir auf all jene, die im Wartemodus sind. Dann stellen wir alle in eine Schlange. Und jeder neue, der kommt, kommt nur in die Schlange, wenn die n\u00e4chste Person mit der Verarbeitung fertig ist. Eine sehr gute Frage. Vielen Dank f\u00fcr die 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 entweder diesen oder jenen wecken. Deshalb wecken wir den einen oder den anderen. Aber was passiert im Betriebssystem? Sie sehen, wie 703 ganz oben seine eigene Transaktions-ID blockiert hat. So funktioniert Postgres. Und 703 wird durch seine eigene Transaktions-ID blockiert, deshalb, wenn jemand warten m\u00f6chte, wird er auf 703 warten. Im Wesentlichen beendet 703 die Operation. Und erst nach seinem Abschluss wird einer der Prozesse geweckt. Und wir wissen nicht, welcher Prozess das sein wird. Dann verarbeiten wir schrittweise alles. Aber es ist unklar, welcher Prozess zuerst geweckt wird, denn es kann einer dieser Prozesse sein. Im Wesentlichen hatten wir einen Scheduler, der sagte, dass wir jetzt jeden dieser Prozesse wecken k\u00f6nnen. Wir w\u00e4hlen einfach einen zuf\u00e4llig aus. Daher m\u00fcssen beide markiert werden, da wir jeden von ihnen wecken k\u00f6nnen. <\/p>\n
<\/p>\n
Und das Problem ist, dass wir CP-Unendlichkeit haben. Daher k\u00f6nnten wir durchaus einen sp\u00e4teren Prozess wecken. Wenn wir beispielsweise einen sp\u00e4teren Prozess wecken, erwarten wir denjenigen, der gerade die Sperre erhalten hat, daher bestimmen wir nicht, welcher Prozess zuerst geweckt wird. Wir schaffen einfach eine solche Situation, und das System wird sie in zuf\u00e4lliger Reihenfolge wecken. <\/p>\n
<\/p>\n
Ja Artikel \u00fcber Locks von Jegor Rogow<\/a><\/noindex>. Schauen Sie, sie sind auch interessant und n\u00fctzlich. Das Thema ist nat\u00fcrlich \u00e4u\u00dferst 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
![\"Entsperrung](\"\/wp-content\/uploads\/2020\/07\/1f75fbb0cb41c306c33c823ef55f7238.png\")
<\/p>\n