http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex><\/p>\n<\/p>\n
Regardons. Le num\u00e9ro de la transaction est en rouge. Ici, la fonction SELECT pg_back est montr\u00e9e. Elle renvoie ma transaction et l'ID de cette transaction. <\/p>\n
<\/p>\n
Une autre chose, si vous aimez cette pr\u00e9sentation et souhaitez l'ex\u00e9cuter dans votre base de donn\u00e9es, vous pouvez suivre ce lien en rose et t\u00e9l\u00e9charger le SQL pour cette pr\u00e9sentation. Et vous pouvez simplement l\u2019ex\u00e9cuter dans votre PSQL, et toute la pr\u00e9sentation appara\u00eetra sur votre \u00e9cran imm\u00e9diatement. Elle ne contiendra pas de couleurs, mais au moins nous pourrons la voir.<\/p>\n
<\/p>\n
<\/p>\n
Dans ce cas, nous voyons l'ID de la transaction. C'est le num\u00e9ro que nous lui avons attribu\u00e9. Il existe \u00e9galement un autre type d'ID de transaction dans Postgres, appel\u00e9 ID de transaction virtuel.<\/p>\n
<\/p>\n
Et nous devons comprendre cela. C'est tr\u00e8s important, sinon nous ne pourrons pas comprendre le blocage dans Postgres.<\/p>\n
<\/p>\n
L'ID de transaction virtuel est celui d'une transaction qui ne contient pas de valeurs permanentes. Par exemple, si j'ex\u00e9cute une commande SELECT, je ne vais probablement pas changer la base de donn\u00e9es, je ne vais rien bloquer. Ainsi, lorsque nous ex\u00e9cutons un simple SELECT, nous ne donnons pas \u00e0 cette transaction un ID permanent. Nous lui attribuons seulement un ID virtuel.<\/p>\n
<\/p>\n
Et cela am\u00e9liore les performances de Postgres, am\u00e9liore les capacit\u00e9s de nettoyage, donc l'ID de transaction virtuel est compos\u00e9 de deux nombres. Le premier nombre avant la barre oblique est l'ID du backend. \u00c0 droite, nous voyons simplement un compteur.<\/p>\n
<\/p>\n
<\/p>\n
Donc, si j'ex\u00e9cute une requ\u00eate, il indique que l'ID du backend est 2. <\/p>\n
<\/p>\n
<\/p>\n
Et si j'ex\u00e9cute une s\u00e9rie de telles transactions, nous voyons que le compteur augmente chaque fois que j'ex\u00e9cute une requ\u00eate. Par exemple, lorsque j'ex\u00e9cute les requ\u00eates 2\/10, 2\/11, 2\/12, etc. <\/p>\n
<\/p>\n
<\/p>\n
Notez qu'il y a deux colonnes ici. \u00c0 gauche, nous avons l'ID de transaction virtuel \u2013 2\/12. Et \u00e0 droite, nous avons l'ID de transaction permanent. Et ce champ est vide. Cette transaction ne modifie pas la base de donn\u00e9es. Donc, je ne lui attribue pas d'ID de transaction permanent.<\/p>\n
<\/p>\n
<\/p>\n
D\u00e8s que j'ex\u00e9cute la commande d'analyse (ANALYZE), la m\u00eame requ\u00eate me donne un ID de transaction permanent. Regardez comment cela a chang\u00e9. Auparavant, je n'avais pas cet ID, maintenant il est apparu.<\/p>\n
<\/p>\n
<\/p>\n
Donc, ici encore une fois une requ\u00eate, une autre transaction. Le num\u00e9ro de transaction virtuel est 2\/13. Et si je demande l'ID de transaction permanent, lorsque j'ex\u00e9cute la requ\u00eate, je l\u2019obtiendrai. <\/p>\n
<\/p>\n
<\/p>\n
Donc, encore une fois. Nous avons l'ID de transaction virtuel et l'ID de transaction permanent. Comprenez simplement ce point pour comprendre le comportement de Postgres.<\/p>\n
<\/p>\n
<\/p>\n
Nous passons \u00e0 la troisi\u00e8me section. Ici, nous allons simplement passer en revue les diff\u00e9rents types de verrouillages dans Postgres. Ce n'est pas tr\u00e8s int\u00e9ressant. La derni\u00e8re section sera beaucoup plus captivante. Mais nous devons aborder les bases, sinon nous ne comprendrons pas ce qui suit. <\/p>\n
<\/p>\n
Nous allons parcourir cette section, en observant chaque type de verrouillage. Je vais vous montrer des exemples de la fa\u00e7on dont ils sont d\u00e9finis, comment ils fonctionnent, et vous montrer quelques requ\u00eates que vous pouvez utiliser pour voir comment fonctionne le verrouillage dans Postgres.<\/p>\n
<\/p>\n
<\/p>\n
Pour cr\u00e9er une requ\u00eate et voir ce qui se passe dans Postgres, nous devons ex\u00e9cuter une requ\u00eate dans la vue syst\u00e8me. Dans ce cas, pg_lock est mis en \u00e9vidence en rouge. Pg_lock est une table syst\u00e8me qui nous indique quels verrouillages sont actuellement utilis\u00e9s dans Postgres.<\/p>\n
<\/p>\n
Cependant, il m'est tr\u00e8s difficile de vous montrer pg_lock en soi, car c'est assez complexe. C'est pourquoi j'ai cr\u00e9\u00e9 une vue qui montre pg_locks. Elle effectue \u00e9galement un certain travail pour moi, ce qui me permet de mieux comprendre. C'est-\u00e0-dire qu'elle exclut mes verrouillages, ma propre session, etc. C'est juste du SQL standard et cela me permet de mieux vous montrer ce qui se passe. <\/p>\n
<\/p>\n
<\/p>\n
Un autre probl\u00e8me est que cette vue est tr\u00e8s large, donc je dois cr\u00e9er une seconde \u2013 lockview2.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Ainsi, nous avons cr\u00e9\u00e9 une table appel\u00e9e Lockdemo. Et nous y avons cr\u00e9\u00e9 une ligne. C'est notre table d'exemple. Et nous allons cr\u00e9er des sections simplement pour vous montrer des exemples de verrouillages. <\/p>\n
<\/p>\n
<\/p>\n
Donc, une ligne, une colonne. Le premier type de verrouillage s'appelle ACCESS SHARE. C'est le verrouillage le moins restrictif. Cela signifie qu'il ne conflit pratiquement pas avec les autres verrouillages.<\/p>\n
<\/p>\n
Et si nous voulons explicitement d\u00e9finir le verrouillage, nous lan\u00e7ons la commande \u00ab lock table \u00bb. Cela bloquera explicitement, c'est-\u00e0-dire que nous ex\u00e9cutons lock table en mode ACCESS SHARE. Et si je lance PSQL en arri\u00e8re-plan, cela signifie que j'ouvre ainsi une deuxi\u00e8me session \u00e0 partir de ma premi\u00e8re session. Que vais-je faire ici ? Je passe \u00e0 l'autre session et je lui demande \u00ab montre-moi le lockview pour cette requ\u00eate \u00bb. Ici, j'ai AccessShareLock dans cette table. C'est exactement ce que j'ai demand\u00e9. Et il indique que le verrou a \u00e9t\u00e9 attribu\u00e9. C'est tr\u00e8s simple. <\/p>\n
<\/p>\n
<\/p>\n
Ensuite, si nous regardons la deuxi\u00e8me colonne, il n'y a rien. Elles sont vides. <\/p>\n
<\/p>\n
<\/p>\n
Et si j'ex\u00e9cute la commande \u00ab SELECT \u00bb, c'est une mani\u00e8re implicite (explicite) de demander AccessShareLock. Alors je lib\u00e8re ma table et j'ex\u00e9cute la requ\u00eate, et celle-ci retourne plusieurs lignes. Dans l'une des lignes, nous voyons AccessShareLock. Ainsi, SELECT appelle AccessShareLock dans la table. Et cela ne cr\u00e9e pratiquement aucun conflit, car il s'agit d'un verrouillage de bas niveau. <\/p>\n
<\/p>\n
<\/p>\n
Que se passe-t-il si je lance SELECT et que j'ai trois tables diff\u00e9rentes ? Auparavant, je n'ex\u00e9cutais qu'une seule table, maintenant j'en ex\u00e9cute trois : pg_class, pg_namespace et pg_attribute.<\/p>\n
<\/p>\n
<\/p>\n
Et maintenant, lorsque je regarde la requ\u00eate, je vois 9 AccessShareLocks dans les trois tables. Pourquoi ? En bleu, trois tables sont mises en \u00e9vidence : pg_attribute, pg_class, pg_namespace. Mais vous pouvez \u00e9galement voir que tous les index d\u00e9finis \u00e0 travers ces tables ont \u00e9galement AccessShareLock.<\/p>\n
<\/p>\n
Et c'est un verrou qui ne cr\u00e9e pratiquement pas de conflit avec d'autres. Tout ce qu'il fait, c'est de nous emp\u00eacher de r\u00e9initialiser la table pendant que nous la s\u00e9lectionnons. Cela a du sens. C'est-\u00e0-dire que si nous choisissons une table et qu'elle dispara\u00eet \u00e0 ce moment-l\u00e0, ce serait incorrect, donc AccessShare est un verrouillage de bas niveau qui nous indique \"ne supprimez pas cette table pendant que je travaille\".<\/strong>. En essence, c'est tout ce qu'il fait. <\/p>\n<\/p>\n
<\/p>\n
ROW SHARE est un verrou l\u00e9g\u00e8rement diff\u00e9rent. <\/p>\n
<\/p>\n
<\/p>\n
Prenons un exemple. SELECT ROW SHARE bloque chaque ligne individuellement.<\/strong>. Ainsi, personne ne peut les supprimer ou les modifier tant que nous les regardons. <\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
Ici, nous disons que le verrou est utilis\u00e9 par nous.<\/p>\n
<\/p>\n
<\/p>\n
Donc, le verrou exclusif indique explicitement qu'il est exclusif. Et aussi, si vous supprimez une ligne dans cette table, c'est ce qui se passera, comme vous pouvez le voir. <\/p>\n
<\/p>\n
<\/p>\n
SHARE EXCLUSIVE \u2013 c'est un verrouillage plus long.<\/strong><\/p>\n<\/p>\n
<\/p>\n
C'est la commande (ANALYZE) de l'analyseur qui sera utilis\u00e9e.<\/p>\n
<\/p>\n
<\/p>\n
SHARE LOCK \u2013 vous pouvez explicitement verrouiller en mode share.<\/p>\n
<\/p>\n
<\/p>\n
Vous pouvez \u00e9galement cr\u00e9er un index unique. Et l\u00e0, vous pouvez voir le SHARE LOCK, qui en fait partie. Et il bloque la table et lui impose un verrou SHARE LOCK.<\/p>\n
<\/p>\n
Par d\u00e9faut, le SHARE LOCK sur la table signifie que d'autres personnes peuvent lire la table, mais personne ne peut la modifier. Et c'est ce qui se passe lorsque vous cr\u00e9ez un index unique.<\/strong><\/p>\n<\/p>\n
Si je cr\u00e9e un index unique en mode concurrently, j'aurai un autre type de verrouillage, car, comme vous le savez, l'utilisation des index en mode concurrently r\u00e9duit l'exigence de verrouillage. Et si j'utilise un verrou normal, un index normal, je pr\u00e9viendrai ainsi l'\u00e9criture dans l'index de la table pendant sa cr\u00e9ation. Si j'utilise un index en mode concurrently, je dois utiliser un autre type de verrou. <\/p>\n
<\/p>\n
<\/p>\n
SHARE ROW EXCLUSIVE \u2013 encore une fois, cela peut \u00eatre d\u00e9clar\u00e9 explicitement.<\/p>\n
<\/p>\n
<\/p>\n
Ou nous pouvons cr\u00e9er une r\u00e8gle, c'est-\u00e0-dire prendre un cas particulier dans lequel elle sera utilis\u00e9e.<\/p>\n
<\/p>\n
<\/p>\n
Le verrou EXCLUSIVE signifie que personne d'autre ne pourra modifier la table. <\/p>\n
<\/p>\n
<\/p>\n
Ici, nous voyons diff\u00e9rents types de verrouillages. <\/p>\n
<\/p>\n
<\/p>\n
ACCESS EXCLUSIVE, par exemple, est une commande de verrouillage. Par exemple, si vous faites CLUSTER table<\/code>, cela signifie que personne ne pourra y \u00e9crire. Et cela bloque non seulement la table elle-m\u00eame, mais aussi les index.<\/p>\n<\/p>\n
<\/p>\n
C'est la deuxi\u00e8me page du verrou ACCESS EXCLUSIVE, o\u00f9 nous voyons pr\u00e9cis\u00e9ment ce qu'il bloque dans la table. Il bloque des lignes individuelles de la table, ce qui est assez int\u00e9ressant.<\/p>\n
<\/p>\n
Voici toutes les informations de base que je voulais fournir. Nous avons parl\u00e9 des verrous, des ID de transactions, des ID de transactions virtuelles, et des ID de transactions permanents. <\/p>\n
<\/p>\n
<\/p>\n
Nous allons maintenant passer aux exemples de verrous. C'est la partie la plus int\u00e9ressante. Nous allons examiner des cas tr\u00e8s captivants. Mon objectif dans cette pr\u00e9sentation est de vous donner une meilleure compr\u00e9hension de ce que Postgres fait r\u00e9ellement lorsqu'il tente de verrouiller certaines choses. Je pense qu'il est tr\u00e8s efficace pour verrouiller des parties sp\u00e9cifiques. <\/p>\n
<\/p>\n
Examinons certains exemples.<\/p>\n
<\/p>\n
<\/p>\n
Commen\u00e7ons par les tables et une ligne dans la table. Lorsque j'ins\u00e8re quelque chose, j'obtiens un ExclusiveLock, l'ID de la transaction et un ExclusiveLock sur la table. <\/p>\n
<\/p>\n
<\/p>\n
Que se passe-t-il si j'ins\u00e8re encore deux lignes ? Nous avons maintenant trois lignes dans notre table. J'ai ins\u00e9r\u00e9 une ligne et obtenu ceci en sortie. Et si j'ins\u00e8re encore deux lignes, quelle est l'anomalie ici ? Il y a une \u00e9tranget\u00e9, car j'ai ajout\u00e9 trois lignes \u00e0 cette table, mais j'ai toujours deux lignes dans la table de verrouillage. Et c'est, en substance, le comportement fondamental de Postgres.<\/p>\n
<\/p>\n
Beaucoup pensent que si dans une base de donn\u00e9es, vous verrouillez 100 lignes, il vous faudra cr\u00e9er 100 entr\u00e9es de verrouillage. Si je verrouille imm\u00e9diatement 1 000 lignes, alors il me faudra 1 000 telles requ\u00eates. Et si je dois en verrouiller un million ou un milliard. Mais si nous agissons ainsi, cela ne fonctionnera pas tr\u00e8s bien. Si vous avez utilis\u00e9 un syst\u00e8me qui cr\u00e9e des entr\u00e9es de verrouillage pour chaque ligne individuelle, vous voyez que c'est compliqu\u00e9. Car il vous faut d\u00e9terminer imm\u00e9diatement la table de verrouillage, qui peut \u00eatre satur\u00e9e, mais Postgres ne fait pas cela. <\/p>\n
<\/p>\n
Et sur cette diapositive, il est tr\u00e8s important de noter qu'il est clairement d\u00e9montr\u00e9 qu'il existe un autre syst\u00e8me qui fonctionne \u00e0 l'int\u00e9rieur du MVCC, qui verrouille des lignes individuelles. Ainsi, lorsque vous verrouillez des milliards de lignes, Postgres ne cr\u00e9e pas un milliard de commandes distinctes de verrouillage. Et cela am\u00e9liore consid\u00e9rablement les performances. <\/p>\n
<\/p>\n
<\/p>\n
Qu'en est-il de la mise \u00e0 jour ? Je mets actuellement \u00e0 jour une ligne, et vous pouvez constater qu'elle ex\u00e9cute imm\u00e9diatement deux op\u00e9rations diff\u00e9rentes. Elle a bloqu\u00e9 la table tout en bloquant \u00e9galement l'index. Elle devait bloquer l'index en raison des contraintes uniques sur cette table. Nous voulons nous assurer que personne ne le modifie, donc nous le bloquons.<\/p>\n
<\/p>\n
<\/p>\n
Que se passe-t-il si je veux mettre \u00e0 jour deux lignes ? Nous voyons qu'elle se comporte de la m\u00eame mani\u00e8re. Nous effectuons deux fois plus de mises \u00e0 jour, mais le m\u00eame nombre de verrous de lignes. <\/p>\n
<\/p>\n
Si vous \u00eates curieux de savoir comment Postgres s'y prend, vous devez \u00e9couter mes pr\u00e9sentations sur le MVCC pour comprendre comment Postgres marque en interne les lignes qu'il modifie. Et Postgres a un moyen de le faire, mais il ne le fait pas au niveau de verrouillage des tables, il le fait \u00e0 un niveau plus bas et plus efficace.<\/p>\n
<\/p>\n
<\/p>\n
Et si je veux supprimer quelque chose ? Si je supprime par exemple une ligne et que j'ai toujours mes deux entr\u00e9es de verrou, m\u00eame si je voulais les supprimer toutes, elles seraient toujours pr\u00e9sentes.<\/p>\n
<\/p>\n
<\/p>\n
Et par exemple, si je veux ins\u00e9rer 1 000 lignes, puis soit supprimer, soit ajouter 1 000 lignes, alors les lignes individuelles que j'ajoute ou modifie ne sont pas enregistr\u00e9es ici. Elles sont enregistr\u00e9es \u00e0 un niveau plus bas \u00e0 l'int\u00e9rieur de la ligne elle-m\u00eame. Et lors de ma pr\u00e9sentation sur le MVCC, j'en ai parl\u00e9 en d\u00e9tail. Mais il est tr\u00e8s important, lorsque vous analysez les verrouillages, de vous assurer que vous avez un verrou au niveau de la table et que vous ne voyez pas ici comment se passent les \u00e9critures des lignes individuelles. <\/p>\n
<\/p>\n
<\/p>\n
Qu'en est-il du verrouillage explicite ?<\/p>\n
<\/p>\n
<\/p>\n
Si je clique sur \u00ab mettre \u00e0 jour \u00bb, j'ai deux lignes verrouill\u00e9es. Et si je les s\u00e9lectionne toutes et clique sur \u00ab mettre \u00e0 jour partout \u00bb, j'ai toujours deux enregistrements de verrou. <\/p>\n
<\/p>\n
<\/p>\n
Nous ne cr\u00e9ons pas d'enregistrements s\u00e9par\u00e9s pour chaque ligne individuelle. Parce que cela nuirait aux performances, cela pourrait en avoir trop. Et nous pourrions nous retrouver dans une situation difficile. <\/p>\n
<\/p>\n
<\/p>\n
Et il en va de m\u00eame si nous faisons un partage, nous pouvons le faire 30 fois. <\/p>\n
<\/p>\n
<\/p>\n
Nous r\u00e9tablissons notre table, nous supprimons tout, puis nous ins\u00e9rons \u00e0 nouveau une ligne.<\/p>\n
<\/p>\n
<\/p>\n
Un autre comportement que vous pouvez observer dans Postgres est ce comportement bien connu et souhaitable : vous pouvez effectuer un update ou un select. Et vous pouvez le faire simultan\u00e9ment. Le select ne bloque pas l'update et inversement. Nous disons que le lecteur ne bloque pas l'\u00e9crivain, et l'\u00e9crivain ne bloque pas le lecteur. <\/p>\n
<\/p>\n
Je vais vous montrer un exemple. Je vais faire un select maintenant. Ensuite, nous ferons un INSERT. Et vous pourrez voir \u2013 694. Vous pourrez voir l'ID de la transaction qui a effectu\u00e9 cette insertion. Et c'est ainsi que cela fonctionne. <\/p>\n
<\/p>\n
<\/p>\n
Et si je regarde maintenant l'ID de mon backend, il est devenu \u2013 695. <\/p>\n
<\/p>\n
<\/p>\n
Et je peux voir que 695 appara\u00eet dans ma table. <\/p>\n
<\/p>\n
<\/p>\n
Et si je fais une mise \u00e0 jour ici comme \u00e7a, j'obtiens un autre cas. Dans ce cas, 695 \u2013 c'est un verrou exclusif, et l'update a un comportement similaire, mais il n'y a pas de conflit entre eux, ce qui est assez inhabituel. <\/p>\n
<\/p>\n
Et vous pouvez remarquer qu'en haut \u2013 c'est un ShareLock, et en bas \u2013 c'est un ExclusiveLock. Et les deux transactions ont \u00e9t\u00e9 faites.<\/p>\n
<\/p>\n
Et il faut \u00e9couter ma pr\u00e9sentation sur MVCC pour comprendre comment cela se passe. Mais c'est une illustration de ce que vous pouvez faire simultan\u00e9ment, c'est-\u00e0-dire faire SELECT et UPDATE en m\u00eame temps.<\/p>\n
<\/p>\n
<\/p>\n
R\u00e9initialisons et faisons \u00e0 nouveau une op\u00e9ration. <\/p>\n
<\/p>\n
<\/p>\n
Si vous essayez d'ex\u00e9cuter deux updates simultan\u00e9ment sur la m\u00eame ligne, cela sera bloqu\u00e9. Et rappelez-vous, je vous ai dit que le lecteur ne bloque pas l'\u00e9crivain, et l'\u00e9crivain bloque le lecteur, mais un \u00e9crivain bloque un autre \u00e9crivain. C'est-\u00e0-dire que nous ne pouvons pas faire en sorte que deux personnes mettent \u00e0 jour la m\u00eame ligne en m\u00eame temps. Il faut attendre qu'un d'eux termine. <\/p>\n
<\/p>\n
<\/p>\n
Et pour illustrer cela, je vais regarder la table Lockdemo. Et nous allons examiner une ligne. Pour la transaction 698.<\/p>\n
<\/p>\n
Nous l'avons mise \u00e0 jour \u00e0 2. 699 \u2013 c'est la premi\u00e8re mise \u00e0 jour. Et elle a r\u00e9ussi ou elle est en attente dans la transaction et attend que nous confirmions ou annulions. <\/p>\n
<\/p>\n
<\/p>\n
Mais regardez autre chose \u2013 2\/51 \u2013 c'est notre premi\u00e8re transaction, notre premi\u00e8re session. 3\/112 \u2013 c'est la deuxi\u00e8me requ\u00eate qui est apparue en haut et qui a remplac\u00e9 cette valeur par 3. Et si vous remarquez, le sup\u00e9rieur s'est bloqu\u00e9 lui-m\u00eame, qui est 699. Mais 3\/112 n'a pas fourni de blocage. Dans la colonne Lock_mode, il est \u00e9crit qu'il attend. Il attend 699. Et si vous regardez o\u00f9 est 699, il est au-dessus. Et qu'est-ce que la premi\u00e8re session a fait ? Elle a cr\u00e9\u00e9 un verrou exclusif sur son propre ID de transaction. C'est comme \u00e7a que Postgres fonctionne. Il bloque son propre ID de transaction. Et si vous voulez attendre que quelqu'un confirme ou annule, vous devez attendre qu'il y ait une transaction en attente. C'est pourquoi nous pouvons voir cette ligne \u00e9trange. <\/p>\n
<\/p>\n
Regardons encore une fois. \u00c0 gauche, nous voyons notre ID de traitement. Dans la deuxi\u00e8me colonne, nous voyons notre ID virtuel de transaction, et dans la troisi\u00e8me, nous voyons lock_type. Que signifie cela ? En gros, cela dit qu'il bloque l'ID de transaction. Mais remarquez que dans toutes les lignes en bas, il est \u00e9crit relation. Et donc, vous avez deux types de verrouillage dans la table. Il y a le verrouillage de relation. Et il y a aussi le verrouillage transactionid, o\u00f9 vous vous bloquez vous-m\u00eame, c'est exactement ce qui se passe dans la premi\u00e8re ligne ou en bas, o\u00f9 transactionid, o\u00f9 nous attendons que 699 termine son op\u00e9ration. <\/p>\n
<\/p>\n
Je regarde ce qu'il se passe ici. Et deux choses se produisent simultan\u00e9ment. Vous regardez le verrouillage par ID de transaction dans la premi\u00e8re ligne, qui se bloque elle-m\u00eame. Et elle se bloque elle-m\u00eame pour forcer les gens \u00e0 attendre. <\/p>\n
<\/p>\n
Si vous regardez la 6e ligne, c'est le m\u00eame enregistrement que le premier. Et donc la transaction 699 est bloqu\u00e9e. 700 se bloque aussi lui-m\u00eame. Et ensuite, dans la ligne inf\u00e9rieure, vous verrez que nous attendons que 699 termine son op\u00e9ration.<\/p>\n
<\/p>\n
<\/p>\n
Et dans lock_type, tuple vous voyez des num\u00e9ros. <\/p>\n
<\/p>\n
<\/p>\n
Vous pouvez voir que c'est 0\/10. Et c'est le num\u00e9ro de page, et aussi l'offset de cette ligne sp\u00e9cifique. <\/p>\n
<\/p>\n
<\/p>\n
Et vous voyez que cela devient 0\/11 lorsque nous mettons \u00e0 jour. <\/p>\n
<\/p>\n
<\/p>\n
Mais en r\u00e9alit\u00e9 \u2013 c'est 0\/10, car cette op\u00e9ration est en attente. Nous avons la possibilit\u00e9 de voir que c'est cette ligne que j'attends pour confirmer. <\/p>\n
<\/p>\n
<\/p>\n
Une fois que nous l'avons valid\u00e9 et cliqu\u00e9 sur commit, et lorsque la mise \u00e0 jour est termin\u00e9e, voici ce que nous obtenons \u00e0 nouveau. La transaction 700 est le seul verrouillage, elle n'attend plus personne, car elle a \u00e9t\u00e9 valid\u00e9e. Elle attend simplement que la transaction se termine. D\u00e8s que 699 se termine, nous n'attendons plus rien. Et maintenant, la transaction 700 indique que tout va bien, que tous les verrous n\u00e9cessaires sont pr\u00e9sents dans toutes les tables autoris\u00e9es. <\/p>\n
<\/p>\n
<\/p>\n
Et pour compliquer encore les choses, nous cr\u00e9ons une autre vue, qui cette fois nous fournira une hi\u00e9rarchie. Je ne m'attends pas \u00e0 ce que vous compreniez cette requ\u00eate. Mais cela nous donnera une vision plus claire de ce qui se passe. <\/p>\n
<\/p>\n
<\/p>\n
C'est une vue r\u00e9cursive, qui a \u00e9galement une autre section. Et elle renvoie ensuite tout ensemble. Utilisons cela. <\/p>\n
<\/p>\n
<\/p>\n
Que se passerait-il si nous faisions trois mises \u00e0 jour simultan\u00e9es et disions que la rang\u00e9e est maintenant \u00e9gale \u00e0 trois. Et nous changeons 3 en 4. <\/p>\n
<\/p>\n
<\/p>\n
Et voici nous voyons 4. Et l'ID de transaction 702. <\/p>\n
<\/p>\n
<\/p>\n
Et ensuite je change 4 en 5. Et 5 en 6, et 6 en 7. Et je fais la file de personnes qui attendent que cette seule transaction se termine.<\/p>\n
<\/p>\n
<\/p>\n
Et tout devient clair. Quelle est la premi\u00e8re rang\u00e9e ? C'est 702. C'est l'ID de transaction qui a initialement d\u00e9fini cette valeur. Et qu'est-ce que j'ai dans la colonne Accord\u00e9 ? J'ai des marques f<\/code>. Ce sont mes mises \u00e0 jour, qui (5, 6, 7) ne peuvent pas \u00eatre valid\u00e9es, car nous attendons que l'ID de transaction 702 se termine. Nous avons un verrou sur l'ID de transaction. Ce sont donc 5 verrous d'ID transactionnels.<\/p>\n<\/p>\n
Et si vous regardez 704, 705, il n'y a rien not\u00e9 l\u00e0-bas, car ils ne savent pas encore ce qui se passe. Ils \u00e9crivent simplement qu'ils n'ont aucune id\u00e9e de ce qui se passe. Et ils vont simplement s'endormir, car ils attendent que quelqu'un termine et les r\u00e9veille quand il y a une opportunit\u00e9 de changer la rang\u00e9e. <\/p>\n
<\/p>\n
<\/p>\n
Voici \u00e0 quoi cela ressemble. Il est clair qu'ils attendent tous la ligne 12. <\/p>\n
<\/p>\n
<\/p>\n
C'est ce que nous avons vu ici. Voici 0\/12. <\/p>\n
<\/p>\n
<\/p>\n
Donc, une fois que la premi\u00e8re transaction est approuv\u00e9e, vous pouvez voir ici comment la hi\u00e9rarchie fonctionne. Et maintenant, tout devient clair. Ils sont tous lib\u00e9r\u00e9s. Et ils sont en fait toujours en attente. <\/p>\n
<\/p>\n
<\/p>\n
Voici ce qui se passe. 702 s'engage. Et maintenant 703 re\u00e7oit ce verrou de ligne, puis 704 commence \u00e0 attendre que 703 s'engage. Et 705 attend \u00e9galement cela. Et quand tout cela est termin\u00e9, ils se nettoient eux-m\u00eames. Je voudrais souligner que tout le monde fait la queue. Cela ressemble beaucoup \u00e0 une situation de bouchon, o\u00f9 tout le monde attend la premi\u00e8re voiture. La premi\u00e8re voiture s'arr\u00eate et tout le monde fait une longue file. Ensuite, elle avance, puis la voiture suivante peut passer devant et obtenir son verrou, etc. <\/p>\n
<\/p>\n
<\/p>\n
Et si cela ne vous semble pas assez compliqu\u00e9, parlons maintenant des deadlocks. Je ne sais pas qui parmi vous en a d\u00e9j\u00e0 rencontr\u00e9. C'est un probl\u00e8me assez courant dans les syst\u00e8mes de bases de donn\u00e9es. Mais les deadlocks sont le cas o\u00f9 une session attend qu'une autre session ex\u00e9cute quelque chose. Pendant ce temps, l'autre session attend que la premi\u00e8re session ex\u00e9cute quelque chose. <\/p>\n
<\/p>\n
Et, par exemple, si Ivan dit : \u00ab Donne-moi quelque chose \u00bb, et que je dis : \u00ab Non, je te le donnerai seulement si tu me donnes autre chose \u00bb. Et il dit : \u00ab Non, je ne te donnerai pas cela si tu ne me donnes pas \u00bb. Et nous nous retrouvons dans une situation de deadlock. Je suis s\u00fbr qu'Ivan ne ferait pas cela, mais vous comprenez le sens : deux personnes veulent obtenir quelque chose et elles ne sont pas pr\u00eates \u00e0 le donner tant que l'autre personne ne leur a pas donn\u00e9 ce qu'elles veulent. Et il n'y a pas de solution. <\/p>\n
<\/p>\n
Et en gros, votre base de donn\u00e9es doit le d\u00e9tecter. Et ensuite, il est n\u00e9cessaire de terminer ou de fermer l'une des sessions, sinon elles resteront l\u00e0 pour toujours. Et nous le voyons dans les bases de donn\u00e9es, nous le voyons dans les syst\u00e8mes d'exploitation. Et dans tous les endroits o\u00f9 nous avons des processus parall\u00e8les, cela peut se produire. <\/p>\n
<\/p>\n
<\/p>\n
Et nous allons maintenant \u00e9tablir deux deadlocks. Nous allons \u00e9tablir 50 et 80. Dans la premi\u00e8re rang\u00e9e, je vais effectuer une mise \u00e0 jour de 50 \u00e0 50. J'obtenirai le num\u00e9ro de transaction 710. <\/p>\n
<\/p>\n
<\/p>\n
Et ensuite je vais changer 80 \u00e0 81, et 50 \u00e0 51. <\/p>\n
<\/p>\n
<\/p>\n
Et voici \u00e0 quoi cela va ressembler. Et donc 710 a un verrou de ligne, tandis que 711 attend une confirmation. Nous avons vu cela lors de la mise \u00e0 jour. 710 est le propri\u00e9taire de notre ligne. Et 711 attend que 710 termine la transaction.<\/p>\n
<\/p>\n
<\/p>\n
Et il y a m\u00eame une indication sur la ligne exacte o\u00f9 nous avons des deadlocks. Et c'est l\u00e0 que cela commence \u00e0 devenir \u00e9trange.<\/p>\n
<\/p>\n
<\/p>\n
Maintenant, nous mettons \u00e0 jour 80 \u00e0 80. <\/p>\n
<\/p>\n
<\/p>\n
Et voil\u00e0, c'est l\u00e0 que commencent les deadlocks. 710 attend une r\u00e9ponse de 711, tandis que 711 attend 710. Et cela ne va pas bien se terminer. Il n'y a pas d'issue. Ils vont attendre une r\u00e9ponse l'un de l'autre. <\/p>\n
<\/p>\n
<\/p>\n
Et cela va simplement commencer \u00e0 tout retarder. Et nous ne voulons pas \u00e7a. <\/p>\n
<\/p>\n
<\/p>\n
Et dans Postgres, il existe des moyens de d\u00e9tecter quand cela se produit. Et quand cela se produit, vous obtenez l'erreur suivante. Cela montre clairement qu'un certain processus attend un SHARE LOCK d'un autre processus, c'est-\u00e0-dire qui est bloqu\u00e9 par le processus 711. Et ce processus attendait qu'un SHARE LOCK soit accord\u00e9 pour un certain ID de transaction et a \u00e9t\u00e9 bloqu\u00e9 par un certain processus. Donc ici, nous avons une situation de deadlock.<\/p>\n
<\/p>\n
<\/p>\n
Y a-t-il des deadlocks \u00e0 trois voies ? Est-ce possible ? Oui. <\/p>\n
<\/p>\n
<\/p>\n
Nous saisissons ces nombres dans le tableau. Nous changeons 40 en 40, nous faisons une verrouillage. <\/p>\n
<\/p>\n
<\/p>\n
Nous changeons 60 en 61, 80 en 81. <\/p>\n
<\/p>\n
<\/p>\n
Et ensuite nous changeons 80, et ensuite \u2013 boum ! <\/p>\n
<\/p>\n
<\/p>\n
Et 714 attend maintenant 715. 716 attend 715. Et il n'y a plus rien \u00e0 faire avec \u00e7a.<\/p>\n
<\/p>\n
<\/p>\n
Il n'y a pas deux personnes ici, mais trois. Je veux quelque chose de toi, celui-ci veut quelque chose de la troisi\u00e8me personne, et la troisi\u00e8me personne veut quelque chose de moi. Et nous nous retrouvons dans une attente \u00e0 trois, car nous attendons tous que l'autre personne termine ce qu'elle doit faire. <\/p>\n
<\/p>\n
<\/p>\n
Et Postgres sait sur quelle ligne cela se produit. C'est pourquoi il vous donnera le message suivant, qui montre que vous avez un probl\u00e8me o\u00f9 trois entr\u00e9es se bloquent mutuellement. Et ici, il n'y a pas de limites. Cela peut se produire si 20 enregistrements se bloquent mutuellement. <\/p>\n
<\/p>\n
<\/p>\n
Le probl\u00e8me suivant est le serializable. <\/p>\n
<\/p>\n
<\/p>\n
S'il s'agit d'un verrou sp\u00e9cial de type serializable.<\/p>\n
<\/p>\n
<\/p>\n
Nous revenons \u00e0 719. Sa sortie est tout \u00e0 fait normale. <\/p>\n
<\/p>\n
<\/p>\n
Et vous pouvez appuyer pour effectuer une transaction de type serializable.<\/p>\n
<\/p>\n
<\/p>\n
Et vous comprenez que vous avez maintenant un autre type de verrou SA \u2013 cela signifie serializable. <\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Et donc nous avons un nouveau type de verrou appel\u00e9 SARieadLock, qui est un verrou s\u00e9rie et permet d'introduire des s\u00e9ries.<\/p>\n
<\/p>\n
<\/p>\n
Et vous pouvez \u00e9galement ins\u00e9rer des index uniques. <\/p>\n
<\/p>\n
<\/p>\n
Dans ce tableau, nous avons des index uniques.<\/p>\n
<\/p>\n
<\/p>\n
Donc, si je saisis le num\u00e9ro 2 ici, j'ai donc 2. Mais tout en haut, j'ins\u00e8re un autre 2. Et vous pouvez voir que le 721 a un verrou exclusif. Mais maintenant, 722 attend que 721 termine son op\u00e9ration, car il ne peut pas ins\u00e9rer 2 tant qu'il ne sait pas ce qui va se passer avec 721. <\/p>\n
<\/p>\n
<\/p>\n
Et si nous faisons une subtransaction.<\/p>\n
<\/p>\n
<\/p>\n
Voici notre 723.<\/p>\n
<\/p>\n
<\/p>\n
Et si nous conservons un point et que nous le mettons \u00e0 jour, nous obtenons un nouvel ID de transaction. C'est un autre comportement que vous devez conna\u00eetre. Si nous le retournons, l'ID de transaction dispara\u00eet. 724 dispara\u00eet. Mais maintenant, nous avons 725. <\/p>\n
<\/p>\n
Et que suis-je en train d'essayer de faire ici ? J'essaie de vous montrer des exemples de verrouillages inhabituels que vous pourriez rencontrer : que ce soit des verrouillages s\u00e9rialisables ou des SAVEPOINTS \u2013 ce sont diff\u00e9rents types de verrouillages qui appara\u00eetront dans la table des verrouillages. <\/p>\n
<\/p>\n
<\/p>\n
C'est la cr\u00e9ation de verrouillages explicites qui comportent pg_advisory_lock. <\/p>\n
<\/p>\n
<\/p>\n
Et vous voyez que le type de verrouillage est list\u00e9 ici comme \u00e9tant advisory. Et ici, il est \u00e9crit en rouge \u00ab advisory \u00bb. Et vous pouvez simultan\u00e9ment le bloquer avec pg_advisory_unlock.<\/p>\n
<\/p>\n
<\/p>\n
Pour conclure, je voudrais vous montrer une autre chose incroyable. Je vais cr\u00e9er un autre type. Mais je vais lier la table pg_locks \u00e0 la table pg_stat_activity. Et pourquoi veux-je faire cela ? Parce que cela me permettra de voir toutes les sessions en cours et d'observer quels types de verrouillages elles attendent. C'est assez int\u00e9ressant de rassembler la table des verrouillages et la table des requ\u00eates. <\/p>\n
<\/p>\n
<\/p>\n
Et ici, nous cr\u00e9ons pg_stat_view. <\/p>\n
<\/p>\n
<\/p>\n
Et nous mettons \u00e0 jour la ligne \u00e0 un. Et ici, nous voyons 724. Puis nous mettons notre ligne \u00e0 trois. Et que voyez-vous ici maintenant ? Ce sont des requ\u00eates, c'est-\u00e0-dire que vous voyez toute la liste des requ\u00eates \u00e9num\u00e9r\u00e9es dans la colonne de gauche. Ensuite, \u00e0 droite, vous pouvez voir les verrouillages et ce qu'ils cr\u00e9ent. C'est peut-\u00eatre plus clair pour vous afin que vous n'ayez pas \u00e0 revenir \u00e0 chaque session pour voir s'il faut y participer ou non. Cela se fait pour nous. <\/p>\n
<\/p>\n
Une autre fonctionnalit\u00e9 qui est tr\u00e8s utile est pg_blocking_pids<\/code>Vous n'en avez probablement jamais entendu parler. Que fait-elle ? Elle nous permet de dire que pour cette session 11740, quels ID de processus elle attend pr\u00e9cis\u00e9ment. Et vous pouvez voir que 11740 attend 724. Et 724 est en haut de la liste. Quant \u00e0 11306, c'est votre ID de processus. En gros, cette fonction parcourt votre tableau de verrouillage. Je sais que c'est un peu complexe, mais vous parvenez \u00e0 le comprendre. En substance, cette fonction parcourt ce tableau de verrouillage et essaie de trouver o\u00f9 se trouve cet ID de processus, en tenant compte des verrouillages qu'il attend. Elle essaie \u00e9galement de calculer quel ID de processus est associ\u00e9 \u00e0 celui qui attend les verrouillages. Vous pouvez donc ex\u00e9cuter cette fonction. pg_blocking_pids<\/code>.<\/p>\n<\/p>\n
Et c'est tr\u00e8s utile. Nous l'avons ajout\u00e9e seulement depuis la version 9.6, donc cette fonction n'a que 5 ans, mais elle est extr\u00eamement utile. Il en va de m\u00eame pour la deuxi\u00e8me requ\u00eate. Elle montre exactement ce que nous devons voir. <\/p>\n
<\/p>\n
<\/p>\n
C'est le sujet dont je voulais discuter avec vous. Comme je m'y attendais, nous avons utilis\u00e9 tout notre temps, car il y avait une si grande quantit\u00e9 de diapositives. Les diapositives sont disponibles en t\u00e9l\u00e9chargement. Je voudrais vous remercier d'\u00eatre ici. Je suis s\u00fbr que vous appr\u00e9cierez le reste de la conf\u00e9rence, merci beaucoup !<\/p>\n
<\/p>\n
Questions :<\/p>\n
<\/p>\n
Par exemple, si j'essaie de mettre \u00e0 jour des lignes alors qu'une autre session tente de supprimer toute la table. D'apr\u00e8s ce que je comprends, il devrait y avoir quelque chose comme un 'intent lock'. Existe-t-il cela dans Postgres ?<\/em><\/p>\n<\/p>\n
<\/p>\n
Revenons au tout d\u00e9but. Peut-\u00eatre vous rappelez-vous que quand vous faites quoi que ce soit, par exemple, un SELECT, nous \u00e9mettons un AccessShareLock. Et cela emp\u00eache la suppression de la table. Donc, si vous souhaitez mettre \u00e0 jour une ligne dans la table ou en supprimer une, quelqu'un ne peut pas supprimer toute la table en m\u00eame temps, car vous maintenez cet AccessShareLock sur toute la table et sur la ligne. Une fois que vous avez termin\u00e9, ils peuvent la supprimer. Mais tant que vous modifiez quelque chose, ils ne le peuvent pas.<\/p>\n
<\/p>\n
Faisons-le encore une fois. Passons \u00e0 un exemple de suppression. Et vous voyez qu'il y a un verrou exclusif sur toute la table sur cette ligne. <\/p>\n
<\/p>\n
Cela ressemblera \u00e0 un verrou exclusif, n'est-ce pas ?<\/em><\/p>\n<\/p>\n
Oui, cela ressemble \u00e0 cela. Je comprends de quoi vous parlez. Vous dites que si j'ex\u00e9cute un SELECT, je vais avoir un ShareExclusive, et ensuite je le transforme en \u00e9tat Row Exclusive, est-ce que cela pose probl\u00e8me ? Mais \u00e9trangement, cela ne cr\u00e9e pas de probl\u00e8me. Cela ressemble \u00e0 une \u00e9l\u00e9vation du niveau de verrouillage, mais en substance, j'ai un verrou qui emp\u00eache la suppression. Et maintenant, quand je rends ce verrou plus puissant, il emp\u00eache toujours la suppression. Donc, ce n'est pas comme si je montais en niveau. C'est-\u00e0-dire qu'il l'emp\u00eachait m\u00eame quand il \u00e9tait \u00e0 un niveau inf\u00e9rieur, donc lorsque j'\u00e9l\u00e8ve son niveau, il emp\u00eache toujours la suppression de la table. <\/p>\n
<\/p>\n
Je comprends de quoi vous parlez. Il n'y a pas de cas d'augmentation du niveau de verrouillage o\u00f9 vous essayez de renoncer \u00e0 un verrou pour en introduire un plus puissant. Ici, cela augmente simplement globalement cette pr\u00e9vention, donc cela ne provoque aucun conflit. Mais c'est une bonne question. Merci beaucoup de l'avoir pos\u00e9e !<\/p>\n
<\/p>\n
Que devons-nous faire pour \u00e9viter une situation de deadlock lorsque nous avons de nombreuses sessions et un grand nombre d'utilisateurs ?<\/em><\/p>\n<\/p>\n
Postgres d\u00e9tecte automatiquement les situations de deadlock. Et il supprimera automatiquement l'une des sessions. Le seul moyen d'\u00e9viter la situation de deadlocks est de verrouiller les gens dans le m\u00eame ordre. Donc, lorsque vous regardez votre application, la plupart du temps, la cause des deadlocks... Imaginons que je veuille verrouiller deux choses diff\u00e9rentes. Une application verrouille la table 1, et une autre application verrouille la 2, puis la table 1. Et la fa\u00e7on la plus simple d'\u00e9viter les deadlocks est de voir votre application et d'essayer de vous assurer que le verrouillage se fait dans le m\u00eame ordre dans toutes les applications. Et cela \u00e9limine g\u00e9n\u00e9ralement 80 % des probl\u00e8mes, car diverses personnes \u00e9crivent ces applications. Et si vous les verrouillez dans le m\u00eame ordre, vous ne rencontrerez pas de situation de deadlock.<\/p>\n
<\/p>\n
Merci beaucoup pour votre pr\u00e9sentation ! Vous parliez de vacuum full, et si je comprends bien, vacuum full d\u00e9forme l'ordre des enregistrements dans le stockage s\u00e9par\u00e9, donc il maintient les enregistrements actuels inchang\u00e9s. Et pourquoi vacuum full n\u00e9cessite-t-il un acc\u00e8s exclusif au verrou et pourquoi cela entre-t-il en conflit avec les op\u00e9rations d'\u00e9criture ?<\/em><\/p>\n<\/p>\n
C'est une bonne question. La raison en est que le vacuum full prend la table. Nous cr\u00e9ons essentiellement une nouvelle version de la table. Ce sera donc une toute nouvelle version de la table. Et le probl\u00e8me est que, lorsque nous faisons cela, nous ne voulons pas que les gens lisent l'ancienne version, car nous avons besoin qu'ils voient la nouvelle table. C'est donc li\u00e9 \u00e0 votre question pr\u00e9c\u00e9dente. Si nous pouvions lire simultan\u00e9ment, nous ne pourrions pas d\u00e9placer et diriger les gens vers la nouvelle table. Nous devrions attendre que chacun ait fini de lire cette table, ce qui en gros cr\u00e9e une situation de verrouillage exclusif.
<\/p>\n
Est-il possible d'ajouter un d\u00e9lai d'attente de verrouillage dans Postgres ? Dans Oracle, je peux par exemple \u00e9crire \u00ab s\u00e9lectionner pour mise \u00e0 jour \u00bb et attendre 50 secondes avant la mise \u00e0 jour. Cela \u00e9tait bon pour l'application. Mais dans Postgres, je dois soit le faire imm\u00e9diatement et ne pas attendre du tout, soit attendre jusqu'\u00e0 un certain moment.<\/em> <\/p>\n<\/p>\n
Oui, vous pouvez choisir un d\u00e9lai d'attente pour vos verrouillages. Vous pouvez \u00e9galement \u00e9mettre la commande no way, qui sera \u2026, si vous ne pouvez pas obtenir le verrou imm\u00e9diatement. Donc soit un d\u00e9lai d'attente de verrouillage, soit autre chose qui permettra cela. Cela ne se fait pas au niveau syntaxique. Cela se fait comme une variable sur le serveur. Parfois, cela ne peut pas \u00eatre utilis\u00e9.<\/p>\n
<\/p>\n
Pouvez-vous ouvrir le diapositive 75 ?<\/em> <\/p>\n<\/p>\n
Oui.<\/p>\n
<\/p>\n
<\/p>\n
Et ma question est la suivante. Pourquoi les deux processus de mise \u00e0 jour attendent-ils 703 ?<\/em><\/p>\n<\/p>\n
C'est une question tr\u00e8s pertinente. Je ne comprends d'ailleurs pas pourquoi Postgres fait cela. Mais lorsque 703 a \u00e9t\u00e9 cr\u00e9\u00e9, il s'attendait \u00e0 702. Et quand 704 et 705 apparaissent, il semble qu'ils ne sachent pas ce qu'ils attendent, parce qu'il n'y a rien pour l'instant. Et Postgres agit ainsi : quand vous ne pouvez pas obtenir un verrou, il se dit \u00ab Pourquoi vous traiter ? \u00bb, car vous attendez d\u00e9j\u00e0 quelqu'un. Donc, laissons-le en suspens, il ne met \u00e0 jour rien du tout. Mais que se passe-t-il ici ? Une fois que 702 a termin\u00e9 le processus et que 703 a obtenu son verrou, le syst\u00e8me revient en arri\u00e8re. Et il dit que maintenant nous avons deux personnes en attente. Et ensuite, mettons-les \u00e0 jour ensemble. Et indiquons que les deux attendent. <\/p>\n
<\/p>\n
Je ne sais pas pourquoi Postgres fait cela. Mais il y a un probl\u00e8me appel\u00e9 f\u2026. Il me semble que ce n'est pas un terme en fran\u00e7ais. C'est quand tout le monde attend un verrou, m\u00eame si 20 instances attendent le m\u00eame verrou. Et tout \u00e0 coup, ils se r\u00e9veillent tous en m\u00eame temps. Tous commencent \u00e0 essayer de r\u00e9agir. Mais le syst\u00e8me fait que tout le monde attend 703. Parce qu'ils attendent tous, et nous les mettons imm\u00e9diatement en file. Et si une nouvelle demande appara\u00eet, par exemple, 707, il y aura \u00e0 nouveau un vide. <\/p>\n
<\/p>\n
Et je pense que c'est fait pour pouvoir dire qu'\u00e0 ce stade 702 attend 703, alors que tous ceux qui viennent apr\u00e8s n'ont aucune note dans ce champ. Mais d\u00e8s que le premier en attente part, tous ceux qui attendaient \u00e0 ce moment-l\u00e0 avant la mise \u00e0 jour re\u00e7oivent le m\u00eame marqueur. Et donc, il me semble que c'est fait pour que nous puissions traiter dans l'ordre, afin qu'ils soient correctement class\u00e9s. <\/p>\n
<\/p>\n
Je l'ai toujours vu comme un ph\u00e9nom\u00e8ne assez \u00e9trange. Parce qu'ici, par exemple, nous ne les \u00e9num\u00e9rons pas du tout. Mais il me semble que chaque fois que nous donnons un nouveau verrou, nous regardons toutes les personnes en attente. Ensuite, nous les mettons tous en file. Et ensuite, toute nouvelle arriv\u00e9e ne sera mise en file que lorsque la personne suivante aura termin\u00e9 le traitement. Tr\u00e8s bonne question. Merci beaucoup pour votre question !<\/p>\n
<\/p>\n
Il me semble beaucoup plus logique que 705 attende 704.<\/em> <\/p>\n<\/p>\n
Mais le probl\u00e8me est le suivant.Techniquement, vous pouvez r\u00e9veiller l'un ou l'autre. Et donc nous allons r\u00e9veiller l'un ou l'autre. Mais que se passe-t-il dans le fonctionnement du syst\u00e8me ? Vous voyez que 703, tout en haut, a verrouill\u00e9 son propre ID de transaction. C'est comme \u00e7a que Postgres fonctionne. Et 703 est bloqu\u00e9 par son propre ID de transaction, donc, si quelqu'un veut attendre, il attendra 703. Et en gros, 703 se termine. Et ce n'est qu'apr\u00e8s son ach\u00e8vement qu'un des processus se r\u00e9veille. Et nous ne savons pas quel processus se r\u00e9veillera. Ensuite, nous traitons progressivement tout. Mais il n'est pas clair quel processus se r\u00e9veille en premier, car cela peut \u00eatre n'importe lequel de ces processus. En gros, nous avions un planificateur qui disait que nous pouvions maintenant r\u00e9veiller n'importe lequel de ces processus. Nous choisissons simplement l'un d'eux au hasard. C'est pourquoi les deux doivent \u00eatre marqu\u00e9s, car nous pouvons r\u00e9veiller l'un ou l'autre. <\/p>\n
<\/p>\n
Et le probl\u00e8me est que nous avons CP-infini. Et donc, il est tout \u00e0 fait probable que nous puissions r\u00e9veiller le plus tardif. Et si, par exemple, nous r\u00e9veilleons le plus tardif, nous attendrons celui qui vient juste de recevoir le verrou, donc nous ne savons pas qui sera r\u00e9veill\u00e9 en premier. Nous cr\u00e9ons simplement une telle situation, et le syst\u00e8me les r\u00e9veillera dans un ordre al\u00e9atoire. <\/p>\n
<\/p>\n
Oui articles sur les verrous d'Yegor Rogov<\/a><\/noindex>. Regardez, ils sont aussi int\u00e9ressants et utiles. Le sujet est, bien s\u00fbr, extr\u00eamement complexe. Merci beaucoup, Bruce !<\/em><\/p>\nSource : 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
![\"D\u00e9verrouillage](\"\/wp-content\/uploads\/2020\/07\/1f75fbb0cb41c306c33c823ef55f7238.png\")
<\/p>\n