Låser upp Postgres Lock Manager. Bruce Momjian

Transkription av Bruce Momjians föredrag 2020 "Låsa upp Postgres Lock Manager".

(Obs: Alla SQL-frågor från bilderna kan erhållas från denna länk: http://momjian.us/main/writings/pgsql/locking.sql)

Hallå! Det är fantastiskt att vara här i Ryssland igen. Jag är ledsen att jag inte kunde komma förra året, men i år har Ivan och jag stora planer. Jag hoppas kunna vara här mycket oftare. Jag älskar att komma till Ryssland. Jag kommer att besöka Tyumen, Tver. Jag är väldigt glad att jag kommer att kunna besöka dessa städer.

Jag heter Bruce Momjian. Jag arbetar på EnterpriseDB och har arbetat med Postgres i över 23 år. Jag bor i Philadelphia, USA. Jag reser ungefär 90 dagar om året. Och jag deltar i ett 40-tal konferenser. Min Hemsida, som innehåller bilderna som jag nu ska visa dig. Därför kan du efter konferensen ladda ner dem från min personliga hemsida. Den innehåller också ett 30-tal presentationer. Det finns också videor och ett stort antal blogginlägg, mer än 500. Detta är en ganska informativ resurs. Och om du är intresserad av detta material, då inbjuder jag dig att använda det.

Jag brukade vara lärare, professor innan jag började arbeta med Postgres. Och jag är väldigt glad att jag nu ska kunna berätta vad jag ska berätta för dig. Det här är en av mina mest intressanta presentationer. Och den här presentationen innehåller 110 bilder. Vi kommer att börja prata med enkla saker, och mot slutet kommer rapporten att bli mer och mer komplex och bli ganska komplex.

Det här är ett ganska obehagligt samtal. Blockering är inte det mest populära ämnet. Vi vill att det här ska försvinna någonstans. Det är som att gå till tandläkaren.

1. Låsning är ett problem för många människor som arbetar i databaser och har flera processer igång samtidigt. De behöver blockering. Det vill säga, idag ska jag ge dig grundläggande kunskaper om blockering.
2. Transaktions-ID:n. Detta är en ganska tråkig del av presentationen, men de måste förstås.
3. Därefter kommer vi att prata om typer av blockering. Detta är en ganska mekanisk del.
4. Och nedan kommer vi att ge några exempel på blockering. Och det kommer att vara ganska svårt att förstå.

Låt oss prata om blockering.

Vår terminologi är ganska komplex. Hur många av er vet var detta avsnitt kommer ifrån? Två personer. Det här är från ett spel som heter Colossal Cave Adventure. Det var ett textbaserat datorspel på 80-talet tror jag. Där fick man gå in i en grotta, in i en labyrint, och texten ändrades, men innehållet var ungefär detsamma varje gång. Det är så jag minns det här spelet.

Och här ser vi namnet på låsen som kom till oss från Oracle. Vi använder dem.

Här ser vi termer som förvirrar mig. Till exempel, DELA UPPDATERING ECXLUSIVE. Nästa DELA RAW ECXLUSIVE. För att vara ärlig är dessa namn inte särskilt tydliga. Vi kommer att försöka överväga dem mer i detalj. Vissa innehåller ordet "dela", vilket betyder att separera. Vissa innehåller ordet "exklusiv". Vissa innehåller båda dessa ord. Jag skulle vilja börja med hur dessa lås fungerar.

Och ordet "tillgång" är också mycket viktigt. Och orden "rad" är en sträng. Det vill säga åtkomstfördelning, radfördelning.

En annan fråga som måste förstås i Postgres, som jag tyvärr inte kommer att kunna ta upp i mitt föredrag, är MVCC. Jag har en separat presentation om detta ämne på min hemsida. Och om du tycker att den här presentationen är svår så är MVCC förmodligen min svåraste. Och om du är intresserad kan du se den på hemsidan. Du kan titta på videon.

En annan sak vi behöver förstå är transaktions-ID:n. Många transaktioner kan inte fungera utan unika identifierare. Och här har vi en förklaring av vad en transaktion är. Postgres har två transaktionsnummersystem. Jag vet att detta inte är en särskilt snygg lösning.

Tänk också på att bilderna kommer att vara ganska svåra att förstå, så det som är markerat i rött är det du behöver vara uppmärksam på.

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

Låt oss se. Transaktionsnumret är markerat i rött. Funktionen SELECT pg_back visas här. Det returnerar min transaktion och transaktions-ID.

En sak till, om du gillar den här presentationen och vill köra den på din databas, så kan du gå till den här länken i rosa och ladda ner SQL för denna presentation. Och du kan helt enkelt köra den i din PSQL och hela presentationen kommer direkt på din skärm. Den kommer inte att innehålla blommor, men vi kan åtminstone se den.

I det här fallet ser vi transaktions-ID. Det här är numret vi tilldelade henne. Och det finns en annan typ av transaktions-ID i Postgres, som kallas virtuellt transaktions-ID

Och vi måste förstå detta. Detta är väldigt viktigt, annars kommer vi inte att kunna förstå låsning i Postgres.

Ett virtuellt transaktions-ID är ett transaktions-ID som inte innehåller beständiga värden. Till exempel, om jag kör ett SELECT-kommando, så kommer jag troligen inte att ändra databasen, jag kommer inte att låsa någonting. Så när vi kör en enkel SELECT ger vi inte transaktionen ett beständigt ID. Vi ger henne bara ett virtuellt ID där.

Och detta förbättrar Postgres prestanda, förbättrar rensningsmöjligheterna, så det virtuella transaktions-ID:t består av två siffror. Det första numret före snedstrecket är backend-ID:t. Och till höger ser vi bara en räknare.

Därför, om jag kör en begäran, står det att backend-ID är 2.

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

Tänk på att det finns två kolumner här. Till vänster ser vi det virtuella transaktions-ID – 2/12. Och till höger har vi ett permanent transaktions-ID. Och det här fältet är tomt. Och denna transaktion ändrar inte databasen. Så jag ger det inte ett permanent transaktions-ID.

Så snart jag kör analyskommandot ((ANALYSE)), ger samma fråga mig ett permanent transaktions-ID. Se hur detta har förändrats för oss. Jag hade inte detta ID förut, men nu har jag det.

Så här är en annan begäran, en annan transaktion. Det virtuella transaktionsnumret är 2/13. Och om jag ber om ett beständigt transaktions-ID kommer jag att få det när jag kör frågan.

Alltså en gång till. Vi har ett virtuellt transaktions-ID och ett beständigt transaktions-ID. Förstå bara denna punkt för att förstå Postgres beteende.

Vi går vidare till det tredje avsnittet. Här kommer vi helt enkelt att gå igenom de olika typerna av lås i Postgres. Det är inte särskilt intressant. Det sista avsnittet kommer att bli mycket mer intressant. Men vi måste överväga de grundläggande sakerna, för annars förstår vi inte vad som kommer att hända härnäst.

Vi går igenom det här avsnittet, vi kommer att titta på varje typ av lås. Och jag ska visa dig exempel på hur de är installerade, hur de fungerar, jag ska visa dig några frågor som du kan använda för att se hur låsning fungerar i Postgres.

För att skapa en fråga och se vad som händer i Postgres måste vi skicka frågan i systemvyn. I det här fallet är pg_lock markerat i rött. Pg_lock är en systemtabell som talar om 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 dig pg_lock i sig eftersom det är ganska komplext. Så jag skapade en vy som visar pg_locks. Och det gör också en del arbete för mig som gör att jag kan förstå bättre. Det vill säga, det utesluter mina lås, min egen session etc. Det är bara standard SQL och det låter dig bättre visa dig vad som händer.

Ett annat problem är att den här vyn är väldigt bred, så jag måste skapa en andra - lockview2.

Och det visar mig fler kolumner från tabellen. Och en till som visar mig resten av kolumnerna. Det här är ganska komplicerat, så jag försökte presentera det så enkelt som möjligt.

Så vi skapade en tabell som heter Lockdemo. Och vi skapade en rad där. Detta är vår exempeltabell. Och vi kommer att skapa avsnitt bara för att visa dig exempel på lås.

Alltså en rad, en kolumn. Den första typen av lås kallas ACCESS SHARE. Detta är den minst restriktiva blockeringen. Detta innebär att det praktiskt taget inte kommer i konflikt med andra lås.

Och om vi uttryckligen vill definiera ett lås, kör vi kommandot "låstabell". Och det kommer uppenbarligen att blockera, det vill säga i ACCESS SHARE-läge startar vi låstabellen. Och om jag kör PSQL i bakgrunden, så startar jag den andra sessionen från min första session på detta sätt. Det vill säga, vad ska jag göra här? Jag går till en annan session och säger till den "visa mig låsvyn för denna begäran." Och här har jag AccessShareLock i den här tabellen. Detta är precis vad jag begärde. Och han säger att blocket är tilldelat. Väldigt enkelt.

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

Och om jag kör kommandot "SELECT" så är detta det implicita (explicita) sättet att begära AccessShareLock. Så jag släpper min tabell och kör frågan och frågan returnerar flera rader. Och i en av raderna ser vi AccessShareLock. Således anropar SELECT AccessShareLock på bordet. Och det kommer inte i konflikt med praktiskt taget någonting eftersom det är ett lågnivålås.

Vad händer om jag kör en 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å frågan ser jag 9 AccessShareLocks i tre tabeller. Varför? Tre tabeller är markerade i 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 här är ett lås som praktiskt taget inte kommer i konflikt med andra. Och allt det gör är att helt enkelt hindra oss från att nollställa tabellen medan vi väljer den. Det är vettigt. Det vill säga, om vi väljer en tabell försvinner den i det ögonblicket, då är detta fel, så AccessShare är ett lågnivålås som säger till oss "släpp inte det här bordet medan jag jobbar". I grund och botten är det allt hon gör.

RADDELNING - Det här låset är lite annorlunda.

Låt oss ta ett exempel. SELECT ROW SHARE metod för att låsa varje rad individuellt. På så sätt kan ingen radera dem eller ändra dem medan vi tittar på dem.

Så vad gör SHARE LOCK? Vi ser att transaktions-ID är 681 för SELECT. Och det här är intressant. Vad hände här? Första gången vi ser numret är i fältet "Lås". Vi tar transaktions-ID:t och det står att det blockerar det i exklusivt läge. Allt det gör är att det står att jag har en rad som tekniskt sett är låst någonstans i tabellen. Men han säger inte exakt var. Vi ska titta på detta mer i detalj lite senare.

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

Så ett exklusivt lås säger uttryckligen att det är exklusivt. Och även om du tar bort en rad i den här tabellen, så är detta vad som kommer att hända, som du kan se.

SHARE EXCLUSIVE är ett längre lås.

Detta är (ANALYSE) analysatorkommandot som kommer att användas.

DELA LÅS – du kan explicit låsa i delningsläge.

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

Som standard betyder DELA LÅS på ett bord att andra personer kan läsa tabellen, men ingen kan ändra den. Och det är precis vad som händer när du skapar ett unikt index.

Om jag skapar ett unikt samtidigt index kommer jag att ha en annan typ av låsning eftersom, som ni minns, att använda samtidigt index minskar låsningskravet. Och om jag använder ett normalt lås, ett normalt index, så kommer jag därmed att förhindra att skriva till tabellindexet medan det skapas. Om jag använder ett index samtidigt måste jag använda en annan typ av låsning.

DELA RAD EXKLUSIVT – återigen kan den ställas in explicit (exkl. explicit).

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

EXKLUSIV låsning gör att ingen annan kan byta bord.

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

ACCESS EXCLUSIVE är till exempel ett blockeringskommando. Till exempel om du gör det CLUSTER table, då kommer detta att innebära att ingen kommer att kunna skriva där. Och det låser inte bara själva tabellen, utan även indexen.

Detta är den andra sidan av ACCESS EXCLUSIVE-blockeringen, där vi ser exakt vad den blockerar i tabellen. Den låser enskilda bordsrader, vilket är ganska intressant.

Det var all grundläggande information jag ville ge. Vi pratade om lås, om transaktions-ID, vi pratade om virtuella transaktions-ID, om permanenta transaktions-ID.

Och nu ska vi gå igenom några blockerande exempel. Detta är den mest intressanta delen. Vi kommer att titta på mycket intressanta fall. Och mitt mål i den här presentationen är att ge dig en bättre förståelse för vad Postgres faktiskt gör när den försöker blockera vissa saker. Jag tror att han är väldigt bra på att blockera delar.

Låt oss titta på några specifika exempel.

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

Vad händer om jag infogar två rader till? Och nu har vårt bord tre rader. Och jag satte in en rad och fick detta som en utgång. Och om jag sätter in två rader till, vad är det för konstigt med det? Det är en konstig sak här eftersom jag har lagt till tre rader till den här tabellen, men jag har fortfarande två rader i låstabellen. Och detta är i grunden det grundläggande beteendet hos Postgres.

Många tror att om du låser 100 rader i en databas, måste du skapa 100 låsposter. Om jag blockerar 1 000 rader på en gång kommer jag att behöva 1 000 sådana frågor. Och om jag behöver en miljon eller en miljard för att blockera. Men om vi gör det här kommer det inte att fungera särskilt bra. Om du har använt ett system som skapar blockeringsposter för varje enskild rad, då kan du se att detta är komplicerat. För du måste omedelbart definiera en låstabell som kan svämma över, men det gör inte Postgres.

Och det som verkligen är viktigt med den här bilden är att den tydligt visar att det finns ett annat system som körs inuti MVCC som låser enskilda rader. Så när du låser miljarder rader skapar Postgres inte en miljard separata låskommandon. Och detta har en mycket god effekt på produktiviteten.

Vad sägs om en uppdatering? Jag uppdaterar raden nu och du kan se att den har utfört två olika operationer samtidigt. Det låste bordet samtidigt, men det låste också indexet. Och han behövde låsa indexet eftersom det finns unika begränsningar på den här tabellen. Och vi vill se till att ingen ändrar det, så vi blockerar det.

Vad händer om jag vill uppdatera två rader? Och vi ser att han beter sig på samma sätt. Vi gör dubbelt så många uppdateringar, men exakt lika många låslinjer.

Om du undrar hur Postgres gör detta, måste du lyssna på mina föredrag om MVCC för att lära dig hur Postgres internt markerar dessa rader att det förändras. Och Postgres har ett sätt att göra detta på, men det gör det inte på bordslåsningsnivån, det gör det på en lägre och mer effektiv nivå.

Vad händer om jag vill radera något? Om jag tar bort till exempel en rad och jag har kvar mina två blockerande ingångar, och även om jag vill ta bort alla så finns de kvar.

Och, till exempel, jag vill infoga 1 000 rader, och sedan antingen ta bort eller lägga till 1 000 rader, sedan de enskilda raderna som jag lägger till eller ändrar, de registreras inte här. De är skrivna på en lägre nivå inom själva serien. Och under MVCC-talet talade jag om detta i detalj. Men det är väldigt viktigt när du analyserar lås att se till att du låser på tabellnivå och att du inte ser hur enskilda rader registreras här.

Vad sägs om explicit blockering?

Om jag klickar på uppdatera har jag två rader låsta. Och om jag väljer dem alla och klickar på "uppdatera överallt", så har jag fortfarande två blockeringsposter.

Vi skapar inte separata poster för varje enskild rad. För då sjunker produktiviteten, det kan bli för mycket av det. Och vi kan hamna i en obehaglig situation.

Och samma sak, om vi delat kan vi göra allt 30 gånger.

Vi återställer vår tabell, tar bort allt och sätter sedan in en rad igen.

Ett annat beteende som du ser i Postgres som är mycket välkänt och önskat beteende är att du kan göra en uppdatering eller ett urval. Och du kan göra detta samtidigt. Och select blockerar inte uppdatering och samma sak i motsatt riktning. Vi säger åt läsaren att inte blockera författaren, och författaren blockerade inte läsaren.

Jag ska visa dig ett exempel på detta. Jag kommer att göra ett val nu. Vi kommer sedan att göra INSERT. Och då kan du se - 694. Du kan se ID:t för transaktionen som utförde denna infogning. Och det är så det fungerar.

Och om jag tittar på mitt backend-ID nu är det nu 695.

Och jag kan se 695 dyka upp i min tabell.

Och om jag uppdaterar här så här så får jag ett annat fall. I det här fallet är 695 ett exklusivt lås, och uppdateringen har samma beteende, men det finns ingen konflikt mellan dem, vilket är ganska ovanligt.

Och du kan se att det längst upp är ShareLock, och längst ner är det ExclusiveLock. Och båda transaktionerna fungerade.

Och du måste lyssna på mitt föredrag på MVCC för att förstå hur detta händer. Men det här är en illustration av att du kan göra det samtidigt, dvs göra en SELECT och en UPDATE samtidigt.

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

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

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

Vi har uppdaterat detta till 2. 699 är den första uppdateringen. Och den lyckades eller så är den i en väntande transaktion och väntar på att vi ska bekräfta eller avbryta.

Men titta på något annat - 2/51 är vår första transaktion, vår första session. 3/112 är den andra begäran som kom från toppen som ändrade det värdet till 3. Och om du märker så låste den översta sig själv, vilket är 699. Men 3/112 beviljade inte låset. Kolumnen Lock_mode säger vad den väntar på. Den förväntar sig 699. Och om man tittar på var 699 är så är den högre. Och vad gjorde den första sessionen? Hon skapade ett exklusivt lås på sitt eget transaktions-ID. Så här gör Postgres. Den blockerar sitt eget transaktions-ID. Och om du vill vänta på att någon ska bekräfta eller avbryta, måste du vänta medan det finns en väntande transaktion. Och det är därför vi kan se en konstig linje.

Låt oss titta igen. Till vänster ser vi vårt bearbetnings-ID. I den andra kolumnen ser vi vårt virtuella transaktions-ID och i den tredje ser vi lock_type. Vad betyder det här? Det som står är i huvudsak att det blockerar transaktions-ID:t. Men lägg märke till att alla rader längst ner säger relation. Och så har du två typer av lås på bordet. Det finns ett relationslås. Och så finns det transaktions-id-blockeringen, där du blockerar på egen hand, vilket är exakt vad som händer på första raden eller längst ner, där transaktions-id är, där vi väntar på att 699 ska avsluta sin operation.

Jag får se vad som händer här. Och här händer två saker samtidigt. Du tittar på ett transaktions-ID-lås i den första raden som låser sig själv. Och hon blockerar sig själv för att få folk att vänta.

Om du tittar på den 6:e raden är det samma post som den första. Och därför är transaktion 699 blockerad. 700 är också självlåsande. Och sedan på den nedre raden ser du att vi väntar på att 699 ska avsluta sin operation.

Och i lock_type, tuple ser du siffror.

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

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

Men i verkligheten är det 0/10, eftersom det finns en väntan på denna operation. Vi har möjlighet att se att det här är serien som jag väntar på att få bekräftat.

När vi har bekräftat det och tryckt på commit, och när uppdateringen är klar, är detta vad vi får igen. Transaktion 700 är det enda låset, det väntar inte på någon annan eftersom det har begåtts. Den väntar helt enkelt på att transaktionen ska slutföras. När 699 tar slut väntar vi inte på något längre. Och nu säger transaktion 700 att allt är bra, att den har alla lås den behöver på alla tillåtna bord.

Och för att göra det hela ännu mer komplicerat skapar vi en annan vy, som denna gång kommer att ge oss en hierarki. Jag förväntar mig inte att du förstår denna begäran. Men detta kommer att ge oss en tydligare bild av vad som händer.

Detta är en rekursiv syn som också har ett annat avsnitt. Och sedan för den samman allt igen. Låt oss använda det här.

Tänk om vi gör tre samtidiga uppdateringar och säger att raden nu är tre. Och vi ändrar 3 till 4.

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

Och sedan ändrar jag 4 till 5. Och 5 till 6 och 6 till 7. Och jag kommer att ställa upp ett antal personer som kommer att vänta på att den här transaktionen ska avslutas.

Och allt blir klart. Vad är den första raden? Detta är 702. Detta är transaktions-ID som ursprungligen satte detta värde. Vad står det i min Granted-kolumn? Jag har märken f. Det här är mina uppdateringar som (5, 6, 7) inte kan godkännas eftersom vi väntar på att transaktions-ID 702 ska avslutas. Där har vi blockering av transaktions-ID. Och detta resulterar i 5 transaktions-ID-lås.

Och om du tittar på 704, på 705, har ingenting skrivits där ännu, eftersom de inte vet vad som händer ännu. De skriver helt enkelt att de inte har en aning om vad som händer. Och de kommer bara att lägga sig för att de väntar på att någon ska sluta och bli väckt när det finns möjlighet att byta rad.

Så här ser det ut. Det är tydligt att de alla väntar på den 12:e raden.

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

Så när den första transaktionen är godkänd kan du här se hur hierarkin fungerar. Och nu blir allt klart. De blir alla rena. Och de väntar faktiskt fortfarande.

Här är vad som händer. 702 begår. Och nu får 703 det här radlåset, och sedan börjar 704 vänta på att 703 ska begås. Och 705:an väntar på detta också. Och när allt detta är klart städar de upp sig. Och jag vill poängtera att alla ställer upp. Och det här är väldigt likt en situation i en bilkö när alla väntar på den första bilen. Den första bilen stannar och alla ställer sig i en lång rad. Sedan rör den på sig, då kan nästa bil köra fram och få sitt block osv.

Och om detta inte verkade komplicerat nog för dig, så ska vi nu prata med dig om dödlägen. Jag vet inte vem av er som har stött på dem. Detta är ett ganska vanligt problem i databassystem. Men dödlägen är när en session väntar på att en annan session ska göra något. Och i detta ögonblick väntar en annan session på den första sessionen för att göra något.

Och, till exempel, om Ivan säger: "Ge mig något," och jag säger: "Nej, jag kommer bara att ge det till dig om du ger mig något annat." Och han säger, "Nej, jag kommer inte att ge det till dig om du inte ger det till mig." Och vi hamnar i en dödläge. Jag är säker på att Ivan inte kommer att göra detta, men du förstår innebörden av att vi har två personer som vill få något och de är inte redo att ge bort det förrän den andra personen ger dem vad de vill ha. Och det finns ingen lösning.

Och i huvudsak måste din databas upptäcka detta. Och sedan måste du ta bort eller stänga en av sessionerna, för annars kommer de att förbli där för alltid. Och vi ser det i databaser, vi ser det i operativsystem. Och på alla ställen där vi har parallella processer kan detta hända.

Och nu ska vi installera två dödlägen. Vi sätter 50 och 80. På första raden uppdaterar jag från 50 till 50. Jag får transaktionsnummer 710.

Och sedan ändrar jag 80 till 81 och 50 till 51.

Och så här kommer det att se ut. Så 710 har en rad blockerad och 711 väntar på bekräftelse. Vi såg detta när vi uppdaterade. 710 är ägare till vår serie. Och 711 väntar på att 710 ska slutföra transaktionen.

Och det står till och med på vilken rad låsningarna uppstår. Och det är här det börjar bli konstigt.

Nu uppdaterar vi 80 till 80.

Och det är här låsningarna börjar. 710 väntar på svar från 711 och 711 väntar på 710. Och detta kommer inte att sluta bra. Och det finns ingen väg ur detta. Och de kommer att förvänta sig ett svar från varandra.

Och det kommer bara att börja försena allt. Och det vill vi inte.

Och Postgres har sätt att märka när detta händer. Och när detta händer får du det här felet. Och av detta är det tydligt att en sådan och en sådan process väntar på ett DELÅS från en annan process, d.v.s. som är blockerad av 711-processen. Och den processen väntade på att ett DELÅS skulle ges på ett sådant och ett transaktions-ID och blockerades av en sådan och en sådan process. Därför råder här ett dödläge.

Finns det trevägs låsningar? Är det möjligt? Ja.

Vi matar in dessa siffror i en tabell. Vi ändrar 40 till 40, vi blockerar.

Vi ändrar 60 till 61, 80 till 81.

Och så byter vi 80 och sedan bom!

Och 714 väntar nu på 715. 716:an väntar på 715:an. Och inget kan göras åt det.

Det är inte längre två personer här, det finns redan tre personer här. Jag vill ha något av dig, den här vill ha något av en tredje person och den tredje personen vill ha något av mig. Och vi hamnar i en trevägsvänta eftersom vi alla väntar på att den andra personen ska slutföra vad de behöver göra.

Och Postgres vet på vilken rad detta händer. Och så kommer det att ge dig följande meddelande, som visar att du har ett problem där tre ingångar blockerar varandra. Och det finns inga begränsningar här. Detta kan vara fallet när 20 poster blockerar varandra.

Nästa problem kan serialiseras.

Om speciellt serialiserbart lås.

Och vi återgår till 719. Dess uteffekt är ganska normal.

Och du kan klicka för att göra transaktionen från serialiserbar.

Och du inser att du nu har en annan typ av SA-lås - det betyder serialiserbart.

Och så har vi en ny typ av lås som heter SARieadLock, som är ett seriellt lås och låter dig ange serier.

Och du kan också infoga unika index.

I den här tabellen har vi unika index.

Så om jag sätter in siffran 2 här, så har jag en 2:a. Men längst upp lägger jag in ytterligare 2. Och du kan se att 721 har ett exklusivt lås. Men nu väntar 722 på att 721 ska slutföra 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 deltransaktioner.

Här har vi 723.

Och om vi sparar punkten och sedan uppdaterar den får vi ett nytt transaktions-ID. Detta är ett annat beteendemönster du måste vara medveten om. Om vi ​​returnerar detta, försvinner transaktions-ID:t. 724 går. Men nu har vi 725.

Så vad försöker jag göra här? Jag försöker visa dig exempel på ovanliga lås som du kan hitta: oavsett om det är serialiserbara lås eller SAVEPOINT, det är olika typer av lås som kommer att dyka upp i låstabellen.

Detta är skapandet av explicita (explicita) lås, som har pg_advisory_lock.

Och du ser att blockeringstypen är listad som rådgivande. Och här står det "rådgivande" i rött. Och du kan samtidigt blockera så här med pg_advisory_unlock.

Och avslutningsvis skulle jag vilja visa er ytterligare en häpnadsväckande sak. Jag skapar en annan vy. Men jag kommer att förena tabellen pg_locks med tabellen pg_stat_activity. Och varför vill jag göra det här? Eftersom detta gör att jag kan titta och se alla aktuella sessioner och se exakt vilken typ av lås de väntar på. Och detta är ganska intressant när vi sätter ihop låstabellen och frågetabellen.

Och här skapar vi pg_stat_view.

Och vi uppdaterar raden i taget. Och här ser vi 724. Och så uppdaterar vi vår rad till tre. Och vad ser du här nu? Dessa är förfrågningar, det vill säga du ser hela listan med förfrågningar som finns listade i den vänstra kolumnen. Och sedan på höger sida kan du se blockeringarna och vad de skapar. Och det kan vara tydligare för dig så att du inte behöver gå tillbaka till varje pass varje gång och se om du behöver vara med eller inte. De gör det åt oss.

En annan funktion som är mycket användbar är pg_blocking_pids. Du har förmodligen aldrig hört talas om henne. Vad gör hon? Det låter oss berätta att för denna session 11740 vilka specifika process-ID:n den väntar på. Och du kan se att 11740 väntar på 724. Och 724 är allra högst upp. Och 11306 är ditt process-ID. I huvudsak går denna funktion genom ditt låsbord. Och jag vet att det är lite komplicerat, men man lyckas förstå det. Den här funktionen går i huvudsak igenom den här låstabellen och försöker hitta var detta process-ID ges de lås som den väntar på. Och den försöker också ta reda på vilket process-ID processen som väntar på låset har. Så du kan köra den här funktionen pg_blocking_pids.

Och detta kan vara mycket användbart. Vi har bara lagt till detta i version 9.6, så den här funktionen är bara 5 år gammal, men den är väldigt, väldigt användbar. Och detsamma gäller den andra begäran. Det visar precis vad vi behöver se.

Det här är vad jag ville prata med dig om. Och som jag förväntade mig använde vi all vår tid eftersom det var så många rutschkanor. Och bilderna finns att ladda ner. Jag skulle vilja tacka dig för att du är här. Jag är säker på att du kommer att njuta av resten av konferensen, tack så mycket!

Frågor:

Till exempel, om jag försöker uppdatera rader och den andra sessionen försöker ta bort hela tabellen. Vad jag förstår borde det finnas något som liknar ett avsiktslås. Finns det något sådant i Postgres?

Låt oss gå tillbaka till början. Du kanske kommer ihåg att när du gör något, till exempel när du gör ett SELECT, utfärdar vi ett AccessShareLock. Och detta förhindrar att bordet tappas. Så om du till exempel vill uppdatera en rad i en tabell eller ta bort en rad, så kan någon inte ta bort hela tabellen samtidigt eftersom du håller detta AccessShareLock över hela tabellen och över raden. Och när du är klar kan de ta bort den. Men medan du direkt ändrar något där, kommer de inte att kunna göra det.

Vi gör det igen. Låt oss gå vidare till raderingsexemplet. Och du ser hur det finns ett exklusivt lås på raden ovanför hela bordet.

Detta kommer att se ut som låsexklusivt, eller hur?

Ja, det ser ut som det. Jag förstår vad du pratar om. Du säger att om jag gör en SELECT så har jag en ShareExclusive och sedan gör jag den Row Exclusive, blir det ett problem? Men förvånansvärt nog utgör detta inga problem. Detta ser ut som att öka låsgraden, men i huvudsak har jag ett lås som förhindrar radering. Och nu, när jag gör det här låset kraftfullare, förhindrar det fortfarande radering. Så det är inte så att jag går upp. Det vill säga, det hindrade det från att hända när det var på en lägre nivå också, så när jag höjer dess nivå förhindrar det fortfarande att tabellen raderas.

Jag förstår vad du pratar om. Det finns inget låseskaleringsfall här, där du försöker ge upp ett lås för att införa ett starkare. Här ökar det bara detta förebyggande över hela linjen, så det skapar ingen konflikt. Men det är en bra fråga. Tack så mycket för att du frågar detta!

Vad behöver vi göra för att undvika en dödläge när vi har många sessioner, ett stort antal användare?

Postgres märker automatiskt dödlägessituationer. Och det kommer automatiskt att ta bort en av sessionerna. Det enda sättet att undvika död blockering är att blockera personer i samma ordning. Så när du tittar på din ansökan, ofta orsaken till dödlägen... Låt oss föreställa oss att jag vill blockera två olika saker. En applikation låser tabell 1 och en annan applikation låser 2 och sedan tabell 1. Och det enklaste sättet att undvika dödläge är att titta på din applikation och försöka se till att låsningen sker i samma ordning i alla applikationer. Och detta eliminerar vanligtvis 80% av problemen, eftersom alla typer av människor skriver dessa ansökningar. Och om du blockerar dem i samma ordning, stöter du inte på en dödlägessituation.

Tack så mycket för din prestation! Du pratade om vakuum fullt och, om jag förstår det rätt, så förvränger vakuum fullt ordningen på poster i separat lagring, så de behåller de nuvarande posterna oförändrade. Varför tar vakuum full exklusiv låsåtkomst och varför kommer det i konflikt med skrivoperationer?

Det är en bra fråga. Anledningen är att vakuum fullt tar bordet. Och vi skapar i princip en ny version av tabellen. Och bordet blir nytt. Det visar sig att detta kommer att vara en helt ny version av tabellen. Och problemet är att när vi gör det här vill vi inte att folk ska läsa det eftersom vi behöver dem för att se den nya tabellen. Och så ansluter detta till föregående fråga. Om vi ​​kunde läsa samtidigt skulle vi inte kunna flytta det och dirigera folk till ett nytt bord. Vi skulle behöva vänta tills alla läst klart den här tabellen, så det är i princip en låsexklusiv situation.
Vi säger bara att vi låser från början eftersom vi vet att vi i slutet kommer att behöva ett exklusivt lås för att kunna flytta alla till det nya exemplaret. Så vi kan potentiellt lösa detta. Och vi gör det på detta sätt med samtidig indexering. Men det här är mycket svårare att göra. Och detta hänger mycket ihop med din tidigare fråga om lås exklusivt.

Är det möjligt att lägga till låsningstidsgräns till Postgres? I Oracle kan jag till exempel skriva "välj att uppdatera" och vänta 50 sekunder innan jag uppdaterar. Det var bra för applikationen. Men i Postgres måste jag antingen göra det direkt och inte vänta alls, eller vänta till ett tag.

Ja, du kan välja en timeout på dina lås, på dina lås. Du kan också utfärda ett no way-kommando, vilket kommer... om du inte omedelbart kan få låset. Därför antingen en låsningstid eller något annat som gör att du kan göra detta. Detta görs inte på den syntaktiska nivån. Detta görs som en variabel på servern. Ibland kan detta inte användas.

Kan du öppna bild 75?

Ja.

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

Och det här är en jättebra fråga. Jag förstår förresten inte varför Postgres gör det här. Men när 703 skapades väntade den 702. Och när 704 och 705 dyker upp verkar det som om de inte vet vad de förväntar sig eftersom det inte finns något där än. Och Postgres gör det så här: när du inte kan få ett lås, skriver den "Vad är poängen med att behandla dig?", eftersom du redan väntar på någon. Så vi låter det bara hänga i luften, det kommer inte att uppdatera det alls. Men vad hände här? Så snart 702 slutförde processen och 703 fick sitt lås, återvände systemet tillbaka. Och hon sa att nu har vi två personer som väntar. Och låt oss sedan uppdatera dem tillsammans. Och låt oss indikera att båda väntar.

Jag vet inte varför Postgres gör det här. Men det finns ett problem som heter f…. Det verkar för mig att detta inte är en term på ryska. Det är då alla väntar på ett slott, även om det är 20 myndigheter som väntar på slottet. Och plötsligt vaknar de alla samtidigt. Och alla börjar försöka reagera. Men systemet gör att alla väntar på 703. För de väntar alla, och vi kommer omedelbart att rada upp alla. Och om någon annan ny förfrågan dyker upp som genererades efter detta, till exempel 707, kommer det att bli tomhet igen.

Och det verkar för mig att detta är gjort så att vi kan säga att i det här skedet väntar 702 på 703, och alla de som kommer efter det kommer inte att ha någon post i detta fält. Men så fort den första servitören går får alla som väntade i det ögonblicket innan uppdateringen samma token. Och så tror jag att det här är gjort för att vi ska kunna bearbeta i ordning så att de blir ordentligt beställda.

Jag såg alltid på det här som ett ganska konstigt fenomen. För här, till exempel, listar vi dem inte alls. Men det verkar för mig att varje gång vi ger ett nytt lås så tittar vi på alla de som är i färd med att vänta. Sedan radar vi upp dem alla. Och då kommer en ny som kommer in först i kön när nästa person har bearbetats färdigt. Mycket bra fråga. Tack så mycket för din fråga!

Det verkar för mig som att det är mycket mer logiskt när 705 förväntar sig 704.

Men problemet här är följande. Tekniskt sett kan du väcka det ena eller det andra. Och så kommer vi att vakna upp det ena eller det andra. Men vad händer i systemet? Du kan se hur 703 högst upp har blockerat sitt eget transaktions-ID. Så här fungerar Postgres. Och 703 är blockerad av sitt eget transaktions-ID, så om någon vill vänta kommer de att vänta på 703. Och i huvudsak slutförs 703. Och först efter dess slutförs vaknar en av processerna. Och vi vet inte exakt vad denna process kommer att vara. Sedan bearbetar vi allt gradvis. Men det är inte klart vilken process som väcks först, eftersom det kan vara någon av dessa processer. I huvudsak hade vi en schemaläggare som sa att vi nu kan väcka någon av dessa processer. Vi väljer bara en slumpmässigt. Så båda måste 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 ganska troligt att vi kan väcka den senare. Och om vi till exempel väcker den senare kommer vi att vänta på den som precis fått blocket, så vi bestämmer inte vem som ska väckas först. Vi skapar helt enkelt en sådan situation, och systemet kommer att väcka dem i en slumpmässig ordning.

Det finns artiklar om lås av Egor Rogov. Titta, de är också intressanta och användbara. Ämnet är naturligtvis fruktansvärt komplext. Tack så mycket, Bruce!

Källa: will.com