Unlocking the Postgres Lock Manager. Bruce Momjian

Avkodning av Bruce Momjian årsrapport 2020 "Unlocking the Postgres Lock Manager".

(Observera: Du kan få alla SQL-frågor från bilderna via denna länk: http://momjian.us/main/writings/pgsql/locking.sql)

Hej! Det är underbart att vara här i Ryssland igen. Jag ber om ursäkt för att jag inte kunde komma förra året, men i år har Ivan och jag stora planer. Jag hoppas att jag kommer att vara här mycket oftare. Jag älskar att besöka Ryssland. Jag kommer att besöka Tyumen och Tver. Jag är mycket glad att jag får möjlighet att besöka dessa städer.

Jag heter Bruce Momjian. Jag arbetar på EnterpriseDB och har jobbat med Postgres i över 23 år. Jag bor i Philadelphia, USA. Jag reser ungefär 90 dagar om året och deltar i cirka 40 konferenser. Min webbplats, som innehåller de bilder jag kommer att visa er nu. Så efter konferensen kan ni ladda ner dem från min privata webbplats. Där finns också omkring 30 presentationer. Dessutom finns det videor och ett stort antal bloggposter, över 500. Det är en ganska innehållsrik resurs. Och om ni är intresserade av detta material inbjuder jag er att använda det.

Tidigare var jag lärare, professor innan jag började arbeta med Postgres. Och jag är mycket glad att jag nu får berätta för er vad jag planerar att berätta. Det här är en av mina mest intressanta presentationer. Och denna presentation innehåller 110 bilder. Vi kommer att börja med enkla saker, och mot slutet kommer redovisningen att bli alltmer komplex och ganska svår.

Det här är en ganska obehaglig diskussion. Blockering är inte det mest populära ämnet. Vi vill att det ska försvinna. Det är som att gå till tandläkaren.

1. Blockering är ett problem för många som arbetar med databaser och har flera processer som körs samtidigt. De behöver blockering. Det vill säga, idag kommer jag att ge er grundläggande kunskaper om blockering.
2. Transaktions-ID:n. Det här är en ganska tråkig del av presentationen, men den måste förstås.
3. Därefter kommer vi att prata om blockeringstyper. Det här är en ganska mekanisk del.
4. Och därefter kommer vi att ge några exempel på blockeringar. Och det kommer att vara ganska svårt att ta till sig.

Låt oss prata om blockeringar.

Terminologin är ganska komplex hos oss. Hur många av er vet var denna passage kommer ifrån? Två personer. Det är från spelet som heter "Kolosalt äventyr i grottan". Det var ett textbaserat datorspel på 80-talet, tror jag. Man behövde gå in i en grotta, i en labyrint och texten ändrades, men innehållet var ungefär detsamma varje gång. Så här minns jag spelet.

Och här ser vi namnen på låsningar som kommit till oss från Oracle. Vi använder dem.

Här ser vi termer som förvirrar mig. Till exempel, SHARE UPDATE EXCLUSIVE. Sedan SHARE RAW EXCLUSIVE. Ärligt talat är dessa namn inte särskilt tydliga. Vi kommer att försöka titta närmare på dem. Vissa innehåller ordet "share", vilket betyder – att separera. Vissa innehåller ordet "exclusive" – exklusiv. I vissa finns båda dessa ord. Jag skulle vilja börja med hur dessa låsningar fungerar.

Och också är ordet "access" mycket viktigt. Och ordet "row" – rad. Det vill säga fördelning av åtkomst, fördelning av rader.

Ett annat problem som måste förstås i Postgres, jag kan tyvärr inte berätta om det i min presentation, är MVCC. Jag har en separat presentation om detta ämne på min webbplats. Och om du tror att denna presentation är svår, så är MVCC – troligen min mest komplexa. Och om du är intresserad kan du titta på den på webbplatsen. Du kan se videon.

En annan punkt som vi måste förstå – är transaktionsidentifierare. Många transaktioner kan inte fungera utan unika identifierare. Och här har vi en förklaring av vad en transaktion är. I Postgres finns det två system för numrering av transaktioner. Jag vet, det är ingen vacker lösning.

Tänk också på att bilderna kommer att vara ganska svåra att förstå, så det som är framhävt i röd färg, det är just det som du bör uppmärksamma.

http://momjian.us/main/writings/pgsql/locking.sql

Vi ser. Nummeret för transaktionen är framhävt i röd färg. Här visas funktionen SELECT pg_back. Den returnerar min transaktion och ID för denna transaktion.

En annan sak, om du gillar den här presentationen och vill köra den i din databas, kan du följa den rosa markerade länken och ladda ner SQL för den här presentationen. Och du kan enkelt köra den i din PSQL så kommer hela presentationen att dyka upp på din skärm omedelbart. Den kommer inte att innehålla färger, men i alla fall kan vi se den.

I det här fallet ser vi transaktions-ID:t. Det är numret som vi tilldelade den. Det finns också en annan typ av transaktions-ID i Postgres som kallas virtuellt transaktions-ID.

Och vi måste förstå detta. Det är mycket viktigt, annars kan vi inte förstå låsning i Postgres.

Virtuellt transaktions-ID är ett transaktions-ID som inte innehåller permanenta värden. Till exempel, om jag kör ett SELECT-kommando, kommer jag troligen inte att ändra databasen, jag kommer inte att blockera något. Därför, när vi kör ett enkelt SELECT, tilldelar vi inte denna transaktion ett permanent ID. Vi ger den bara ett virtuellt ID.

Och detta ökar prestationen i Postgres, förbättrar möjligheterna för rensning, så virtuellt transaktions-ID består av två nummer. Det första numret före snedstrecket är backend-ID:t. Och till höger ser vi bara en räknare.

Så när jag kör en fråga, säger det att backend-ID:t är 2.

Och om jag kör en serie sådana transaktioner ser vi att räknaren ökar varje gång jag kör en fråga. Till exempel när jag kör fråga 2/10, 2/11, 2/12 och så vidare.

Observera att det finns två kolumner här. Till vänster ser vi det virtuella transaktions-ID:t - 2/12. Och till höger har vi det permanenta transaktions-ID:t. Och detta fält är tomt. Denna transaktion modifierar inte databasen. Därför tilldelar jag den inte ett permanent transaktions-ID.

Så snart jag kör kommandot analysera (ANALYZE), ger samma fråga mig ett permanent transaktions-ID. Se hur detta har förändrats. Tidigare hade jag inte detta ID, nu har jag det.

Och här är ännu en fråga, ytterligare en transaktion. Det virtuella transaktionsnumret - 2/13. Och om jag begär det permanenta transaktions-ID:t, får jag det när jag kör frågan.

Så, ännu en gång. Vi har det virtuella transaktions-ID:t och det permanenta transaktions-ID:t. Förstå detta för att förstå Postgres beteende.

Vi går vidare till den tredje delen. Här kommer vi att gå igenom de olika typerna av lås i Postgres. Det är inte så intressant. Den sista delen kommer att vara mycket mer spännande. Men vi måste täcka de grundläggande sakerna, annars kommer vi inte att förstå vad som kommer härnäst.

Vi kommer att gå igenom denna del, vi kommer att titta på varje typ av lås. Och jag kommer att visa er exempel på hur de sätts, hur de fungerar, och ge er några frågor som ni kan använda för att se hur lås fungerar i Postgres.

För att skapa en fråga och se vad som händer i Postgres, behöver vi utföra en fråga i systemvyn. I det här fallet har vi markerat pg_lock med röd färg. Pg_lock är en systemtabell som berättar för oss vilka lås som för närvarande används i Postgres.

Det är dock väldigt svårt för mig att visa er pg_lock som det är, eftersom det är ganska komplicerat. Därför har jag skapat en vy som visar pg_locks. Den utför också lite arbete för mig som hjälper mig att förstå bättre. Det vill säga att den exkluderar mina lås, min egen session och så vidare. Det är bara standard SQL och det gör att jag bättre kan visa er vad som händer.

En annan utmaning är att denna vy är väldigt bred, så jag behöver skapa en andra vy – lockview2.

Den visar mig fler kolumner från tabellen. Och en annan som visar mig de övriga kolumnerna. Det är ganska komplicerat, så jag har försökt att presentera det så enkelt som möjligt.

Så vi har skapat en tabell som heter Lockdemo. Där har vi skapat en rad. Det är vår provtabell. Och vi kommer att skapa avsnitt för att bara visa er exempel på lås.

Så en rad, en kolumn. Den första typen av lås kallas ACCESS SHARE. Det är den minst begränsande låset. Det betyder att den praktiskt taget inte konfliktar med andra lås.

Och om vi vill explicit definiera låsningen kör vi kommandot «lock table». Och det kommer tydligt att låsa, det vill säga i ACCESS SHARE-läge kör vi lock table. Och om jag kör PSQL i bakgrunden, så startar jag på det sättet en andra session från min första session. Vad gör jag här? Jag går till en annan session och säger till den «visa mig lockview för denna förfrågan». Och här har jag AccessShareLock i denna tabell. Det är precis vad jag begärde. Och den säger att låsningen har tilldelats. Mycket enkelt.

Vidare, om vi tittar på den andra kolumnen, så finns det inget där. De är tomma.

Och om jag kör kommandot «SELECT», så är det ett implicerat (explicit) sätt att begära AccessShareLock. Så jag släpper min tabell och kör förfrågan, och förfrågan returnerar flera rader. Och i en av raderna ser vi AccessShareLock. Således anropar SELECT AccessShareLock i tabellen. Och den konflikerar praktiskt taget inte med något, eftersom det är en låsning av låg nivå.

Vad händer om jag kör SELECT och har tre olika tabeller? Tidigare körde jag bara en tabell, nu kör jag tre: pg_class, pg_namespace och pg_attribute.

Och nu när jag tittar på förfrågan, ser jag 9 AccessShareLocks i tre tabeller. Varför? Tre tabeller markeras med blått: pg_attribute, pg_class, pg_namespace. Men du kan också se att alla index som definieras genom dessa tabeller också har AccessShareLock.

Och det är en låsning som praktiskt taget inte konflikterar med andra. Och allt den gör är att helt enkelt förhindra oss från att återställa tabellen så länge vi väljer den. Det har mening. Det vill säga, om vi väljer en tabell och den försvinner just då, så är det fel, så AccessShare är en låsning av låg nivå som säger oss "ta inte bort denna tabell medan jag arbetar". I själva verket är det allt den gör.

ROW SHARE – det är en låsning som är lite annorlunda.

Låt oss ta ett exempel. SELECT ROW SHARE är ett sätt att låsa varje rad för sig. Således kan ingen ta bort dem eller ändra dem medan vi ser på dem.

Så vad gör SHARE LOCK? Vi ser att transaktions-ID 681 används för SELECT. Och det är intressant. Vad har hänt här? För första gången ser vi ett nummer i 'Lock'-fältet. Vi tar transaktions-ID och det säger att det låser den i exklusivt läge. Allt det gör är att det säger att jag har en rad som tekniskt är låst någonstans i tabellen. Men den säger inte var specifikt. Lite senare ska vi titta närmare på detta.

Här säger vi att låsning används av oss.

Så, exklusiv låsning säger explicit att den är exklusiv. Och också, om du tar bort en rad i denna tabell, så kommer det att hända, som du kan se.

SHARE EXCLUSIVE – det är en längre låsning.

Detta (ANALYZE) är en analyskommando som kommer att användas.

SHARE LOCK – du kan explicit låsa i delat läge.

Du kan också skapa en unik index. Och där kan du se SHARE LOCK, som är en del av dem. och det låser tabellen och sätter ett SHARE LOCK på den.

Som standard betyder SHARE LOCK på tabellen att andra kan läsa tabellen, men ingen kan modifiera den. Och det är vad som händer när du skapar en unik index.

Om jag skapar en unik concurrent index, så kommer jag att ha en annan typ av låsning, eftersom, som du kommer ihåg, att använda concurrent index minskar låskravet. Och om jag använder normal låsning, normal index, så hindrar jag på så sätt skrivandet i indexet under skapandet. Om jag använder concurrent index, så måste jag använda en annan typ av låsning.

SHARE ROW EXCLUSIVE – än en gång kan den anges explicit.

Eller så kan vi skapa en regel, dvs. ta ett visst fall där den kommer att användas.

EXCLUSIVE låsning betyder att ingen annan kan ändra tabellen.

Här ser vi olika typer av låsningar.

ACCESS EXCLUSIVE, till exempel, är en låsningskommando. Till exempel, om du gör CLUSTER table, så kommer det att betyda att ingen kan skriva dit. Och den låser inte bara själva tabellen, utan också indexen.

Detta är den andra sidan av ACCESS EXCLUSIVE-låsning, där vi ser specifikt vad den låser i tabellen. Den låser individuella rader i tabellen, vilket är ganska intressant.

Det här är all grundläggande information som jag ville ge. Vi har pratat om lås, transaktions-ID, virtuella transaktions-ID och permanenta transaktions-ID.

Och nu ska vi gå igenom exempel på lås. Detta är den mest intressanta delen. Vi kommer att titta på väldigt intressanta fall. Min uppgift i den här presentationen är att ge er en bättre förståelse för vad Postgres faktiskt gör när det försöker låsa olika saker. Jag tycker att det är mycket bra på att låsa specifika delar.

Låt oss titta på vissa exempel.

Vi börjar med tabeller och en rad i tabellen. När jag sätter in något visas ExclusiveLock, transaktions-ID och ExclusiveLock på tabellen.

Vad händer om jag sätter in ytterligare två rader? Och nu har vi tre rader i vår tabell. Jag satte in en rad och fick detta som utdata. Och om jag sätter in ytterligare två rader, vad är konstigt här? Här finns det en konstighet, för jag har lagt till tre rader till denna tabell, men jag har fortfarande två rader i låstabellen. Och det är i grunden Postgres grundläggande beteende.

Många tror att om du blockerar 100 rader i databasen, så kommer du behöva skapa 100 låspostningar. Om jag blockerar 1 000 rader på en gång, så behöver jag 1 000 sådana förfrågningar. Och om jag behöver blockera en miljon eller en miljard. Men om vi gör så, kommer det inte fungera särskilt bra. Om du har använt ett system som skapar låsposter för varje enskild rad så ser du att det är komplicerat. För du måste definiera låstabellen med en gång, och den kan bli överfull. Men Postgres gör inte så.

Och på det här bilden är det mycket viktigt att det tydligt visas att det finns ytterligare ett system som arbetar inom MVCC, som låser enskilda rader. Så när du blockerar miljarder rader, skapar Postgres inte en miljard separata låsningar. Och det påverkar prestandan mycket positivt.

Hur är det med uppdateringen? Jag uppdaterar just nu en rad, och du kanske märker att den omedelbart utförde två olika operationer. Den blockerade tabellen, men den blockerade också indexet. Det var nödvändigt att blockera indexet eftersom det finns unika begränsningar på denna tabell. Vi vill säkerställa att ingen ändrar det, så vi blockerar det.

Vad händer om jag vill uppdatera två rader? Och vi ser att den beter sig likadant. Vi genomför dubbelt så många uppdateringar, men exakt samma antal radblockeringar.

Om du undrar hur Postgres gör detta, behöver du lyssna på mina presentationer om MVCC för att förstå hur Postgres internt märker dessa rader som den ändrar. Och Postgres har ett sätt att göra detta på, men det görs inte på tabellblockeringsnivå; det görs på en lägre och mer effektiv nivå.

Men vad händer om jag vill ta bort något? Om jag tar bort till exempel en rad och jag fortfarande har mina två lås kvar, även om jag skulle vilja ta bort dem allihop, kommer de fortfarande att finnas där.

Och till exempel, om jag vill infoga 1 000 rader och sedan antingen ta bort eller lägga till 1 000 rader, så skrivs de individuella raderna som jag lägger till eller ändrar inte här. De skrivs till en lägre nivå inne i själva raden. Under presentationen om MVCC pratade jag om detta i detalj. Men det är mycket viktigt, när du analyserar blockeringar, att säkerställa att du har blockering på tabellnivå och att du här inte ser hur individuella rader skrivs.

Vad sägs om explicit blockering?

Om jag trycker på 'uppdatera', så har jag två låsta rader. Och om jag väljer alla och trycker på 'uppdatera överallt', så har jag fortfarande två blockinspelningar.

Vi skapar inte separata poster för varje enskild rad. För annars sjunker prestandan, och det kan bli för mycket. Vi kan hamna i en obehaglig situation.

Och samma sak gäller om vi gör på delad nivå, vi kan göra det 30 gånger.

Vi återställer vår tabell, raderar allt, och sedan lägger vi igen till en rad.

En annan typ av beteende som du ser i Postgres är det mycket välkända och önskvärda beteendet – det är att du kan utföra en update eller select. Och du kan göra detta samtidigt. Och select blockerar inte update och vice versa. Vi säger till läsaren att inte blockera den som skriver, och den som skriver blockerar inte läsaren.

Jag ska visa dig ett exempel på detta. Jag kommer nu att göra ett val. Sedan kommer vi att göra en INSERT. Och du kommer att kunna se – 694. Du kommer att se ID för transaktionen som gjorde denna insättning. Och så här fungerar det.

Och om jag nu tittar på min backend-ID, så har den blivit – 695.

Och jag kan se att 695 visas i min tabell.

Och om jag gör en uppdatering här så här, får jag ett annat fall. I detta fall är 695 en exklusiv låsning, och uppdateringen har samma beteende, men mellan dem uppstår ingen konflikt, vilket är ganska ovanligt.

Och du kan märka att överst är det ShareLock, och längst ner är det ExclusiveLock. Och båda transaktionerna blev framgångsrika.

Du bör lyssna på mitt föredrag om MVCC för att förstå hur detta sker. Men detta är en illustration av att du kan göra detta samtidigt, dvs. göra SELECT och UPDATE på en gång.

Låt oss återställa och göra en operation igen.

Om du försöker köra två update samtidigt på samma rad, kommer det att blockeras. Och kom ihåg att jag sa att en läsare inte blockerar en skrivare, och en skrivare blockerar inte en läsare, men en skrivare blockerar en annan skrivare. Det vill säga, vi kan inte låta två personer samtidigt uppdatera samma rad. De måste vänta tills en av dem är klar.

Och för att illustrera detta kommer jag att titta på Lockdemo-tabellen. Och vi ska titta på en rad. På transaktion 698.

Vi uppdaterade detta till 2. 699 – det första uppdateringen. Och det har gått igenom framgångsrikt eller så är det i en väntande transaktion och väntar på att vi ska bekräfta eller avbryta.

Men titta på det här – 2/51 – det är vår första transaktion, vår första session. 3/112 – det är den andra förfrågan som dök upp ovanifrån och som ändrade detta värde till 3. Och om du lägger märke till, så blockerade den övre sig själv, vilken var 699. Men 3/112 gav ingen blockering. I kolumnen Lock_mode står det att den väntar. Den väntar på 699. Och om du kollar var 699 är, så är den högre upp. Och vad gjorde den första sessionen? Den skapade en exklusiv blockering på sitt eget transaktions-ID. Det är så Postgres gör. Den blockerar sitt eget transaktions-ID. Och om du vill vänta på att någon ska bekräfta eller avbryta, så måste du vänta på att det finns en väntande transaktion. Och därför kan vi se en konstig rad.

Låt oss titta igen. Till vänster ser vi vårt processerings-ID. I den andra kolumnen ser vi vårt virtuella transaktions-ID, och i den tredje ser vi lock_type. Vad betyder det? I princip säger den att den blockerar transaktions-ID. Men lägg märke till att det i alla rader längst ner står relation. Och därför har du två typer av blockeringar i tabellen. Det finns en relationblockering. Och det finns också en transactionid-blockering, där vi blockerar själva, vilket exakt är det som händer i den första raden eller längst ner, där transactionid, där vi väntar på att 699 ska avsluta sin operation.

Jag ser vad som händer här. Och här sker två saker samtidigt. Du tittar på blockeringen av transaktions-ID i den första raden, som blockerar sig själv. Och den blockerar sig själv för att få folk att vänta.

Om du tittar på den sjätte raden, så är det samma post som den första. Och därför blockeras transaktionen 699. 700 blockerar också sig själv. Och sedan i den nedersta raden kommer du se att vi väntar på att 699 ska avsluta sin operation.

Och i lock_type, tuple ser du siffrorna.

Du kan se att det är 0/10. Och det är sidnumret, och även offset för denna specifika rad.

Och du ser att det blir 0/11 när vi uppdaterar.

Men egentligen är det 0/10, eftersom denna operation väntar. Vi har möjlighet att se att det är den rad som jag väntar på att bekräfta.

Så snart vi bekräftade det och tryckte på commit, och när uppdateringen var klar, är det här vad vi får igen. Transaktion 700 är den enda låsningen, den väntar inte längre på någon annan eftersom den har blivit commitad. Den väntar bara på att transaktionen ska avslutas. Så snart 699 är klar väntar vi inte längre på något. Och nu säger transaktion 700 att allt är okej, att den har alla lås som den behöver i alla tillåtna tabeller.

Och för att komplicera allt detta ytterligare skapar vi en till vy, som den här gången kommer att ge oss en hierarki. Jag förväntar mig inte att ni förstår denna fråga. Men det kommer att ge oss en tydligare bild av vad som händer.

Det är en rekursiv vy, som också har ett annat avsnitt. Och det returnerar sedan allt ihop. Låt oss använda det.

Vad händer om vi gör tre samtidiga uppdateringar och säger att raden just nu är tre. Och vi förändrar 3 till 4.

Och här ser vi 4. Och transaktions-ID 702.

Och sedan byter jag 4 till 5. Och 5 till 6, och 6 till 7. Och jag köar en rad personer som kommer att vänta på att denna enskilda transaktion ska avslutas.

Och allt blir tydligt. Vilken är den första raden? Det är 702. Det är transaktions-ID som ursprungligen satte detta värde. Och vad har jag skrivit i kolumnen Granted? Jag har markeringar f. Det är mina uppdateringar, som (5, 6, 7), som inte kan godkännas eftersom vi väntar på att transaktions-ID 702 ska avslutas. Där har vi en låsning av transaktions-ID. Och det ger 5 transaktionslåsning ID.

Och om ni tittar på 704, på 705, så står det fortfarande ingenting där, eftersom de fortfarande inte vet vad som händer. De skriver bara att de inte har en aning om vad som händer. Och de kommer helt enkelt att somna, eftersom de väntar på att någon ska avsluta och väcka dem när det blir möjligt att ändra raden.

Så här ser det ut. Det är tydligt att de alla väntar på rad 12.

Detta är vad vi såg här. Här är 0/12.

Så snart den första transaktionen är godkänd, kan ni här se hur hierarkin fungerar. Och nu blir allt klart. De alla blir rena. Och de är faktiskt fortfarande i vänteläge.

Det här är vad som händer. 702 gör en commit. Och nu får 703 denna radlåsningsstatus, och sedan börjar 704 vänta på att 703 ska göra en commit. Och 705 väntar också på detta. När allt detta avslutas städar de upp efter sig själva. Jag vill påpeka att alla ställer sig i kö. Det liknar verkligen en trafikstockning, där alla väntar på att den första bilen ska passera. Den första bilen stannar, och alla ställer sig i en lång rad. Sedan rör den sig, sedan kan nästa bil köra fram och få sin låsning och så vidare.

Och om du tyckte att det här var tillräckligt komplicerat, så ska vi nu prata om deadlocks. Jag vet inte vem av er som har stött på dem. Det här är ett ganska vanligt problem i databassystem. Men deadlocks är det fall då en session väntar på att något ska utföras av en annan session. Samtidigt väntar den andra sessionen på att den första sessionen ska utföra något.

Till exempel, om Ivan säger: "Ge mig något", och jag säger: "Nej, jag ger dig det bara om du ger mig något annat". Och han säger: "Nej, jag ger dig inte det om du inte ger mig". Och vi hamnar i en deadlock-situation. Jag är säker på att Ivan inte skulle göra så, men du förstår poängen, vi har två personer som vill ha något och de är inte villiga att ge det förrän den andra personen ger dem det de vill ha. Här finns det ingen lösning.

I grund och botten behöver din databas upptäcka detta. Och du måste sedan avsluta eller stänga en av sessionerna, för annars kommer de att stanna där för alltid. Vi ser detta i databaser, vi ser det i operativsystem. Och överallt där vi har parallella processer kan detta hända.

Nu kommer vi att sätta upp två deadlocks. Vi sätter 50 och 80. I den första raden kommer jag att göra en uppdatering från 50 till 50. Jag får transaktionsnummer 710.

Sedan kommer jag att ändra 80 till 81, och 50 till 51.

Och så här kommer det att se ut. Därför har 710 en radlåsning, medan 711 väntar på bekräftelse. Vi såg detta när vi uppdaterade. 710 är ägaren av vår rad. Och 711 väntar på att 710 ska avsluta transaktionen.

Och det står till och med på vilken specifik rad vi har en deadlock. Och här börjar det bli konstigt.

Nu uppdaterar vi 80 till 80.

Och här är där deadlocks börjar. 710 väntar på svar från 711, medan 711 väntar på 710. Och det kommer att sluta illa. Det finns ingen utväg här. Och de kommer att vänta på varandras svar.

Och det här kommer bara att börja försena allt. Och vi vill inte ha det.

Och i Postgres finns det sätt att märka när detta händer. Och när det händer får du ett sådant felmeddelande. Och det blir tydligt att en viss process väntar på SHARE LOCK från en annan process, det vill säga en som blockeras av process 711. Och den processen väntade på att få SHARE LOCK på en viss transaktions-ID och blev blockerad av en viss process. Så situationen är en deadlock.

Men finns det trevägs-deadlocks? Är det möjligt? Ja.

Vi matar in dessa siffror i tabellen. Vi ändrar 40 till 40, vi skapar en låsning.

Vi ändrar 60 till 61, 80 till 81.

Och sedan ändrar vi 80, och sedan – boom!

Och 714 väntar nu på 715. 716 väntar på 715. Och med det går det inte att göra något.

Här är det inte längre två personer, här är det redan tre personer. Jag vill ha något från dig, den här vill ha något från den tredje personen, och den tredje personen vill ha något från mig. Och vi hamnar i en trevägsväntan, eftersom vi alla väntar på att den andra personen ska avsluta vad de måste göra.

Och Postgres vet på vilken rad detta händer. Och därför ger det dig följande meddelande, som visar att du har ett problem där tre ingångar blockerar varandra. Och det finns inga begränsningar. Det kan vara i ett fall där 20 poster blockerar varandra.

Nästa problem är serializable.

Om det är en speciell serializable-låsning.

Och vi går tillbaka till 719. Den har en fullt normal utdata.

Och du kan klicka för att göra en transaktion från serializable.

Och du förstår att du nu har en annan typ av låsning SA – det betyder serializable.

Och därför har vi en ny typ av låsning som kallas SARieadLock, som är en seriell låsning och tillåter inmatning av serienummer.

Och du kan också infoga unika index.

I denna tabell har vi unika index.

Så om jag matar in siffran 2 här, så får jag 2. Men högst upp matar jag in ännu en 2. Och du kan se att 721 har en exklusiv låsning. Men nu väntar 722 på att 721 ska avsluta sin operation, eftersom den inte kan infoga 2 förrän den vet vad som kommer att hända med 721.

Och om vi gör en subtransaction.

Här har vi 723.

Och om vi sparar punkten och sedan uppdaterar den, får vi en ny transaktions-ID. Detta är ytterligare ett beteende som du behöver känna till. Om vi återför detta, avlägsnas transaktions-ID:n. 724 försvinner. Men nu får vi 725.

Och vad försöker jag göra här? Jag försöker visa dig exempel på ovanliga lås som du kan stöta på: oavsett om det handlar om serializable-lås eller SAVEPOINT – det är olika typer av lås som kommer att dyka upp i lås tabellen.

Detta handlar om att skapa explicita (eller explicita) lås, som har pg_advisory_lock.

Och du ser att låstypen här anges som advisory. Och här står det skrivet i rött "advisory". Och du kan samtidigt låsa så här med pg_advisory_unlock.

Och för att avsluta vill jag visa dig en annan spännande sak. Jag kommer att skapa en annan typ. Men jag kommer att sammanfoga tabellen pg_locks med tabellen pg_stat_activity. Och varför vill jag göra detta? För att detta gör att jag kan se och få en översikt av alla aktuella sessioner och se vilka specifika lås de väntar på. Och detta är ganska intressant när vi sätter samman låstabellen och frågetabellen.

Och här skapar vi pg_stat_view.

Och vi uppdaterar raden med ett. Och här ser vi 724. Sedan uppdaterar vi vår rad till tre. Och vad ser du här nu? Det är förfrågningar, dvs. du ser hela listan över förfrågningar som listas i vänster kolumn. Och sedan kan du se låsen och vad de skapar på högra sidan. Och detta kan vara mer begripligt för dig, så du inte behöver gå tillbaka till varje session varje gång och kolla – om du behöver gå med i den eller inte. Det görs för oss.

En annan funktion som är mycket användbar är pg_blocking_pidsDu har kanske aldrig hört talas om det. Vad gör det? Det låter oss säga att för den här sessionen 11740, vilka specifika process-ID:n den förväntar sig. Och du kan se att 11740 förväntar sig 724. Och 724 är högst upp. Och 11306 är ditt process-ID. I princip går den här funktionen igenom din låsningstabell. Och jag vet att det är lite komplicerat, men du verkar förstå det. I princip går den här funktionen igenom den här låsningstabellen och försöker hitta var detta proces-ID finns, med hänsyn till de låsningar den väntar på. Den försöker också räkna ut vilket specifikt proces-ID som den process har som väntar på låsningar. Så du kan köra den här funktionen. pg_blocking_pids.

Och det kan vara väldigt användbart. Vi lade till detta först i version 9.6, så den här funktionen är bara 5 år gammal, men den är mycket och verkligen användbar. Detsamma gäller den andra frågan. Den visar exakt det vi behöver se.

Det är det jag ville prata med er om. Och som jag förväntade mig använde vi all vår tid, eftersom det var så många bilder. Och bilderna finns tillgängliga för nedladdning. Jag vill tacka er för att ni kom hit. Jag är säker på att ni kommer att uppskatta resten av konferensen, stort tack!

Frågor:

Till exempel, om jag försöker uppdatera rader, medan en annan session försöker ta bort hela tabellen. Såvitt jag förstår skulle det behöva finnas något som heter intent lock. Finns det något sådant i Postgres?

Vi går tillbaka till början. Kanske minns du att när du gör vad som helst, till exempel när du gör en SELECT, så ger vi AccessShareLock. Och detta förhindrar att tabellen tas bort. Så om du till exempel vill uppdatera en rad i tabellen eller ta bort en rad, så kan ingen ta bort hela tabellen samtidigt, eftersom du håller det här AccessShareLock över hela tabellen och över raden. Och när du är klar kan de ta bort den. Men så länge du gör något där, kan de inte göra det.

Låt oss gå igenom det en gång till. Låt oss ta exemplet med borttagning. Och du ser hur det finns en exklusiv lås över hela tabellen på raden.

Det skulle se ut som en exklusiv lås, eller hur?

Ja, det verkar så. Jag förstår vad du menar. Du säger att om jag utför SELECT kommer jag att ha ShareExclusive, och om jag sedan ändrar detta till Row Exclusive, blir det ett problem? Men överraskande nog skapar detta inget problem. Det verkar som om jag ökar låsningsgraden, men i grunden har jag en lås som förhindrar borttagning. Och just nu, när jag gör denna lås starkare, förhindrar den fortfarande borttagning. Så det handlar inte om att jag höjer mig. Det vill säga, den förhindrade detta även när den var på en lägre nivå, så när jag höjer dess nivå förhindrar den fortfarande borttagning av tabellen.

Jag förstår vad du menar. Här finns inget fall av ökning av låsningsgraden där du försöker frigöra en lås för att införa en starkare. Här ökar det bara generellt denna förhindran, så det orsakar ingen konflikt. Men det är en bra fråga. Tack så mycket för att du ställde den!

Vad behöver vi göra för att undvika situationen med deadlock när vi har många sessioner och ett stort antal användare?

Postgres upptäcker automatiskt situationer med deadlock. Och det kommer automatiskt att ta bort en av sessionerna. Det enda sättet att undvika dödlåsningssituationer är att låsa personer i samma ordning. Så när du tittar på din applikation är anledningen till deadlocks ofta... Låt oss säga att jag vill låsa två olika saker. En applikation låser tabell 1, och en annan applikation låser 2, och sedan tabell 1. Det enklaste sättet att undvika deadlocks är att titta på din applikation och försöka se till att låsningen sker i samma ordning i alla applikationer. Och det brukar ta bort 80 % av problemen, eftersom olika människor skriver dessa applikationer. Och om du låser dem i samma ordning, så stöter du inte på dödlåsningssituationen.

Tack så mycket för din presentation! Du talade om vacuum full och om jag förstår rätt, så deformerar vacuum full ordningen på poster i en särskild lagring, så nuvarande poster förblir oförändrade. Men varför tar vacuum full exklusiv låsning och varför står det i konflikt med skrivoperationer?

Det är en bra fråga. Anledningen är att vacuum full tar tabellen. Och vi skapar i själva verket en ny version av tabellen. Tabellen kommer att bli ny. Det innebär att det blir en helt ny version av tabellen. Problemet är att när vi gör detta, vill vi inte att folk ska läsa den, för vi behöver att de ser den nya tabellen. Därför kopplar det samman med den tidigare frågan. Om vi kunde läsa samtidigt, skulle vi inte kunna flytta den och rikta folk till den nya tabellen. Vi skulle behöva vänta tills alla hade slutat läsa denna tabell, och därför handlar det i grunden om en exklusiv låsning.
Vi säger helt enkelt att vi låser från början, eftersom vi vet att vi i slutet kommer att behöva en exklusiv låsning för att flytta alla till den nya kopian. Så potentiellt kan vi lösa det. Och vi gör det med samtidig indexering. Men det är mycket svårare att göra. Och det berör starkt din tidigare fråga om exklusiv låsning.

Är det möjligt att lägga till locking timeout i Postgres? I Oracle kan jag till exempel skriva "välj för uppdatering" och vänta 50 sekunder innan uppdateringen. Det fungerade bra för applikationen. Men i Postgres måste jag antingen göra det omedelbart och inte vänta alls, eller vänta till en viss tid.

Ja, du kan välja timeout för dina lås. Du kan också ge kommandot no way, som kommer att … om du inte kan få lås omedelbart. Så antingen lock timeout eller något annat som tillåter dig att göra det. Det görs inte på syntaktisk nivå. Det görs som en variabel på servern. Ibland går det inte att använda.

Kan du öppna 75-sidan?

Ja.

Och min fråga är följande. Varför väntar båda uppdateringsprocesserna på 703?

Och det är en utmärkt fråga. Jag förstår inte, förresten, varför Postgres gör så här. Men när 703 skapades, förväntade den sig 702. Och när 704 och 705 dyker upp verkar det som att de inte vet vad de väntar på, eftersom det fortfarande inte finns något där. Och Postgres gör så här: när du inte kan få en lås, så skriver den "Vad är meningen med att behandla er?" eftersom du redan väntar på någon. Så vi låter bara låsningen hänga i luften, den uppdaterar inte detta över huvud taget. Men vad hände här? Så snart 702 fullföljde processen och 703 fick sin lås, så återgick systemet. Och sade att nu har vi två personer som väntar. Och sedan uppdaterar vi dem tillsammans. Och vi anger att båda väntar.

Jag vet inte varför Postgres gör så här. Men det finns ett problem som kallas f…. Jag tror att det inte är en term på svenska. Det är när alla väntar på en lås, även om det finns 20 instanser som väntar på låset. Och plötsligt vaknar de alla samtidigt. Och alla börjar försöka reagera. Men systemet gör så att alla väntar på 703. Eftersom de alla väntar, och vi placerar dem omedelbart i kö. Och om någon annan ny förfrågan dyker upp som skapades efter detta, till exempel 707, så kommer det att bli tomt igen.

Och jag tror att detta görs för att man ska kunna säga att vid denna tidpunkt väntar 702 på 703, och alla som kommer efter detta kommer inte ha någon post i detta fält. Men så snart den första som väntar lämnar, och alla som väntade vid den tidpunkten innan uppdateringen får samma märke. Och därför tror jag att det här görs för att vi ska kunna bearbeta dem i ordning, så att de är korrekt sorterade.

Jag har alltid sett detta som ett ganska konstigt fenomen. Eftersom vi här till exempel inte listar dem överhuvudtaget. Men jag tror att varje gång vi ger en ny lås, så ser vi på alla som är i väntande process. Då ställer vi dem alla i kö. Och sedan kommer vilken ny som helst som dyker upp, in i kön först när nästa person har avslutat behandlingen. Mycket bra fråga. Tack så mycket för frågan!

Jag tycker att det är mycket mer logiskt när 705 väntar på 704.

Men problemet här är det följande. Tekniskt sett kan ni väcka antingen den ena eller den andra. Och därför kommer vi att väcka den ena eller den andra. Men vad händer i systemets arbete? Ni ser hur 703 i toppen blockerade sitt eget transaktions-ID. Så fungerar Postgres. Och 703 blockeras av sitt eget transaktions-ID, så om någon vill vänta, kommer de att vänta på 703. Och i grund och botten avslutar 703. Och först efter att den har avslutats väcks någon av processerna. Och vi vet inte vilken process som kommer att väckas först. Sedan hanterar vi allt gradvis. Men det är oklart vilken process som väcks först, eftersom det kan vara någon av dessa processer. I grund och botten hade vi en schemaläggare som sa att vi nu kan väcka vilken av dessa processer som helst. Vi väljer helt enkelt en slumpmässigt. Därför måste båda noteras, eftersom vi kan väcka någon av dem.

Och problemet är att vi har CP-oändlighet. Och därför är det helt möjligt att vi kan väcka den senare. Och om vi till exempel väcker den senare, kommer vi att vänta på den som just fick en blockering, så vi kan inte avgöra vem som kommer att väckas först. Vi skapar helt enkelt en sådan situation, och systemet kommer att väcka dem i godtycklig ordning.

Det finns artiklar om lås av Yegor Rogov. Titta, de är också intressanta och användbara. Temat är självklart fruktansvärt komplext. Tack så mycket, Bruce!

Källa: habr.com