Unlocking the Postgres Lock Manager. Bruce Momjian

Tolkning av Bruce Momjian sin rapport fra 2020 "Unlocking the Postgres Lock Manager".

(Merk: Alle SQL-forespørslene fra lysbildene kan du få tilgang til via denne lenken: http://momjian.us/main/writings/pgsql/locking.sql)

Hei! Det er flott å være her igjen i Russland. Jeg beklager at jeg ikke kunne komme i fjor, men i år har Ivan og jeg store planer. Jeg håper å være her mye oftere. Jeg elsker å reise til Russland. Jeg skal besøke Tyumen og Tver. Jeg er veldig glad for at jeg får muligheten til å besøke disse byene.

Jeg heter Bruce Momjian. Jeg jobber i EnterpriseDB og har jobbet med Postgres i mer enn 23 år. Jeg bor i Philadelphia, USA. Jeg reiser omtrent 90 dager i året og deltar på omtrent 40 konferanser. Min nettside, som inneholder lysbilder som jeg nå skal vise dere. Etter konferansen kan dere laste dem ned fra min personlige side. Der finner dere også rundt 30 presentasjoner, videoinnhold og et stort antall blogginnlegg, mer enn 500. Dette er en ganske innholdsrik ressurs, og hvis dere er interessert i dette materialet, ønsker jeg dere velkommen til å ta nytte av det.

Jeg har tidligere vært lærer, professor før jeg begynte å jobbe med Postgres. Jeg er veldig glad for nå å få fortelle dere det jeg skal fortelle. Dette er en av de mest interessante presentasjonene mine, og den inneholder 110 lysbilder. Vi starter med enkle emner, og mot slutten av presentasjonen vil det bli stadig mer komplisert.

Dette er en ganske ubehagelig samtale. Låsning er ikke det mest populære emnet. Vi ønsker at det skal forsvinne. Det er som å dra til tannlegen.

1. Låsing er et problem for mange mennesker som jobber med databaser og hvor flere prosesser kjører samtidig. De trenger låsing. Jeg vil gi dere grunnleggende kunnskap om låsing i dag.
2. Transaksjonsidentifikatorer. Dette er en ganske kjedelig del av presentasjonen, men de må forstås.
3. Videre skal vi snakke om typer låsing. Dette er en ganske mekanisk del.
4. Og deretter vil vi gå gjennom noen eksempler på låsing. Dette vil bli ganske vanskelig å forstå.

La oss snakke om låsinger.

Terminologien er temmelig kompleks hos oss. Hvor mange av dere vet hvor dette utdraget kommer fra? To personer. Det er fra et spill som heter «Kolosalt eventyr i hulen». Det var et tekstbasert dataspill på 80-tallet, tror jeg. Man måtte gå inn i en hule, i en labyrint, og teksten endret seg, men innholdet var omtrent det samme hver gang. Slik husker jeg dette spillet.

Og her ser vi navnene på blokkeringene som kommer fra Oracle. Vi bruker dem.

Her ser vi termer som forvirrer meg. For eksempel, SHARE UPDATE EXCLUSIVE. Deretter SHARE RAW EXCLUSIVE. Ærlig talt, disse navnene er ikke veldig klare. Vi skal prøve å se nærmere på dem. Noen inneholder ordet «share», som betyr – å skille seg. Noen inneholder ordet «exclusive» — eksklusiv. I noen finnes begge disse ordene. Jeg vil gjerne begynne med hvordan disse blokkeringene fungerer.

Og det er også veldig viktig ordet «access» — tilgang. Og ordet «row» — rad. Det vil si distribusjon av tilgang, distribusjon av rader.

Et annet problem som må forstås i Postgres, jeg kan dessverre ikke fortelle om det i mitt innlegg, er MVCC. Jeg har en egen presentasjon om dette emnet på nettstedet mitt. Og hvis du tror at denne presentasjonen er komplisert, så er MVCC nok min mest kompliserte. Og hvis du er interessert, kan du se den på nettstedet. Du kan se videoen.

Et annet punkt vi må forstå – er transaksjonsidentifikatorene. Mange transaksjoner kan ikke fungere uten unike identifikatorer. Her har vi en forklaring på hva en transaksjon er. I Postgres finnes det to systemer for nummerering av transaksjoner. Jeg vet, dette er ikke en veldig pen løsning.

Vær også oppmerksom på at lysbildene vil være relativt vanskelige å forstå, så det som er uthevet i rødt, det må vi legge særlig merke til.

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

Se her. Numrene på transaksjonen er uthevet i rødt. Her vises funksjonen SELECT pg_back. Den returnerer min transaksjon og ID-en til denne transaksjonen.

En annen ting, hvis du liker denne presentasjonen og ønsker å starte den i databasen din, kan du følge lenken som er markert med rosa, og laste ned SQL for denne presentasjonen. Du kan enkelt kjøre den i PSQL-en din, og hele presentasjonen vil umiddelbart vises på skjermen din. Den vil ikke inneholde farger, men i det minste vil vi kunne se den.

I dette tilfellet ser vi ID-en til transaksjonen. Dette er nummeret vi har gitt den. Det finnes også en annen type transaksjons-ID i Postgres, kalt virtuell transaksjons-ID.

Og vi må forstå dette. Det er veldig viktig, ellers kan vi ikke forstå låsing i Postgres.

Virtuell transaksjons-ID er ID-en til en transaksjon som ikke inneholder permanente verdier. For eksempel, hvis jeg kjører en SELECT-kommando, kommer jeg sannsynligvis ikke til å endre databasen, jeg vil ikke blokkere noe. Derfor, når vi kjører en enkel SELECT, gir vi ikke denne transaksjonen en permanent ID. Vi gir den bare en virtuell ID.

Og dette øker ytelsen til Postgres og forbedrer mulighetene for opprydding, derfor består den virtuelle transaksjons-ID-en av to tall. Det første tallet før skråstreken er backend-ID-en. På høyre side ser vi bare en teller.

Så hvis jeg kjører en spørring, sier den at backend-ID-en er 2.

Og hvis jeg kjører en serie slike transaksjoner, ser vi at telleren øker hver gang jeg kjører en spørring. For eksempel når jeg kjører spørring 2/10, 2/11, 2/12 osv.

Legg merke til at det er to kolonner her. Til venstre ser vi den virtuelle transaksjons-ID-en – 2/12. På høyre side har vi den permanente transaksjons-ID-en. Og dette feltet er tomt. Denne transaksjonen modifiserer ikke databasen. Derfor tildeler jeg den ikke en permanent transaksjons-ID.

Så snart jeg kjører kommandoen analyze (ANALYZE), gir den samme spørringen meg en permanent transaksjons-ID. Se hvordan dette har endret seg. Før hadde jeg ikke denne ID-en, nå har den dukket opp.

Så her er en annen spørring, en annen transaksjon. Den virtuelle transaksjonsnummeret er 2/13. Og hvis jeg ber om den permanente transaksjons-ID-en, vil jeg få den når jeg kjører spørringen.

Så igjen. Vi har en virtuell transaksjons-ID og en permanent transaksjons-ID. Bare forstå dette punktet for å forstå oppførselen til Postgres.

Vi går videre til den tredje delen. Her vil vi bare se på de ulike typene låser i Postgres. Det er ikke så spennende. Den siste delen vil bli mye mer interessant. Men vi må se på det grunnleggende, ellers vil vi ikke forstå hva som kommer videre.

Vi skal gå gjennom denne delen, vi ser på hver type lås. Og jeg vil vise deg eksempler på hvordan de settes, hvordan de fungerer, og vise deg noen spørringer som kan brukes for å se hvordan låsing fungerer i Postgres.

For å lage en spørring og se hva som skjer i Postgres, må vi kjøre en spørring i systemvisningen. I dette tilfellet er pg_lock uthevet med rødt. Pg_lock er en systemtabel som forteller oss hvilke låser som brukes i Postgres for øyeblikket.

Men det er veldig vanskelig for meg å vise deg pg_lock i seg selv, fordi det er ganske komplisert. Derfor har jeg laget en visning som viser pg_locks. Den gjør også noe arbeid for meg, som gjør at jeg bedre kan forstå. Det vil si at den ekskluderer mine låser, min egen økt osv. Dette er bare standard SQL, og den lar meg vise deg bedre hva som skjer.

En annen utfordring er at denne visningen er veldig bred, så jeg måtte lage en andre – lockview2.

Den viser meg flere kolonner fra tabellen, og en annen som viser meg de gjenværende kolonnene. Dette er ganske komplisert, så jeg har prøvd å presentere dette så enkelt som mulig.

Så vi har opprettet en tabell som heter Lockdemo. Og vi har opprettet én rad der. Dette er vår eksempeltabell. Og vi skal lage seksjoner bare for å vise deg eksempler på låsing.

Så, én rad, én kolonne. Den første typen lås kalles ACCESS SHARE. Dette er den minst restriktive låsen. Det betyr at den praktisk talt ikke konflikter med andre låser.

Og dersom vi vil definere låsingen eksplisitt, kjører vi kommandoen «lock table». Dette vil tydelig låse den, altså i ACCESS SHARE-modus kjører vi lock table. Og hvis jeg kjører PSQL i bakgrunnen, starter jeg på denne måten en annen sesjon fra min første sesjon. Det vil si, hva gjør jeg her? Jeg går til den andre sesjonen og sier: «vis meg lockview for denne forespørselen». Og her har jeg AccessShareLock i denne tabellen. Dette er akkurat det jeg ba om. Og den sier at låsen har blitt tildelt. Veldig enkelt.

Videre, hvis vi ser i den andre kolonnen, er det ingenting der. De er tomme.

Og hvis jeg kjører kommandoen «SELECT», er dette en implisitt måte å be om AccessShareLock på. Så jeg slipper tabellen min og kjører forespørselen, og forespørselen returnerer flere rader. Og i en av radene ser vi AccessShareLock. Dermed forårsaker SELECT AccessShareLock i tabellen. Og det konflikter praktisk talt ikke med noe, fordi det er en lås av lavt nivå.

Hva hvis jeg kjører SELECT og har tre forskjellige tabeller? Tidligere kjørte jeg bare én tabell, nå kjører jeg tre: pg_class, pg_namespace og pg_attribute.

Og nå, når jeg ser på forespørselen, ser jeg 9 AccessShareLocks i de tre tabellene. Hvorfor? Tre tabeller er uthevet med blått: pg_attribute, pg_class, pg_namespace. Men du kan også se at alle indeksene som er definert gjennom disse tabellene, også har AccessShareLock.

Og dette er en lås som praktisk talt ikke konflikter med andre. Alt den gjør, er å hindre oss fra å slippe tabellen så lenge vi velger den. Det gir mening. Det vil si, hvis vi velger en tabell, skulle den på det tidspunktet forsvinne, ville det vært galt, så AccessShare er en lås av lavt nivå som sier «ikke slett denne tabellen så lenge jeg jobber». I bunn og grunn er dette alt den gjør.

ROW SHARE er en lås som er litt annerledes.

La oss ta et eksempel. SELECT ROW SHARE er en måte å låse hver rad individuelt. Dermed kan ingen slette dem eller endre dem så lenge vi ser på dem.

Så, hva er SHARE LOCK? Vi ser at transaksjons-ID 681 er for SELECT. Og det er interessant. Hva har skjedd her? For første gang ser vi et nummer i "Lock"-feltet. Vi tar transaksjons-ID, og den sier at den låser det i eksklusiv modus. Alt den gjør, er å si at jeg har en rad som teknisk sett er låst et sted i tabellen. Men den sier ikke hvor spesifikt. Litt senere ser vi nærmere på dette.

Her sier vi at låsing brukes av oss.

Så den eksklusive låsen sier eksplisitt at den er eksklusiv. Og også hvis du sletter en rad i denne tabellen, vil det skje, som du kan se.

SHARE EXCLUSIVE – dette er en lengre lås.

Dette (ANALYZE) er analysekomenaden som vil bli brukt.

SHARE LOCK – du kan eksplisitt låse i delingsmodus.

Du kan også opprette et unikt indeks. Og der kan du se SHARE LOCK, som er en del av dem. Og den låser tabellen og setter SHARE LOCK på den.

Som standard betyr SHARE LOCK på tabellen at andre kan lese tabellen, men ingen kan modifisere den. Og det er nettopp det som skjer når du oppretter et unikt indeks.

Hvis jeg oppretter en unik samtidig indeks, vil jeg ha en annen type låsing, fordi, som du husker, bruk av samtidig indekser reduserer låsekravene. Og hvis jeg bruker normal låsing, normal indeks, vil jeg på den måten forhindre skriving til indeksen under opprettelsen. Hvis jeg bruker samtidig indeks, må jeg bruke en annen type låsing.

SHARE ROW EXCLUSIVE – den kan også settes eksplisitt.

Eller vi kan lage en regel, dvs. ta et bestemt tilfelle der den vil bli brukt.

EXCLUSIVE-låsing betyr at ingen andre kan endre tabellen.

Her ser vi forskjellige typer låsinger.

ACCESS EXCLUSIVE, for eksempel, er en låsekommando. For eksempel, hvis du gjør CLUSTER table, betyr det at ingen kan skrive dit. Og den låser ikke bare selve tabellen, men også indeksene.

Dette er den andre siden av ACCESS EXCLUSIVE låsing, hvor vi ser spesifikt hva den blokkerer i tabellen. Den blokkerer individuelle rader i tabellen, noe som er ganske interessant.

Dette er all den grunnleggende informasjonen jeg ønsket å gi. Vi har snakket om låser, om transaksjons-ID-er, snakket om virtuelle transaksjons-ID-er, om permanente transaksjons-ID-er.

Og nå skal vi se på eksempler på låser. Dette er den mest interessante delen. Vi skal se på noen svært interessante tilfeller. Og mitt mål med denne presentasjonen er å gi dere en bedre forståelse av hva Postgres faktisk gjør når det prøver å låse forskjellige ting. Jeg føler at den er veldig flink til å låse enkeltkomponenter.

La oss se på spesifikke eksempler.

Vi begynner med tabeller og én rad i tabellen. Når jeg setter inn noe, vises det en ExclusiveLock, transaksjons-ID og ExclusiveLock for tabellen.

Men hva skjer hvis jeg setter inn to rader til? Og nå har vi tre rader i tabellen vår. Jeg satte inn én rad og fikk dette som resultat. Og hvis jeg setter inn to rader til, hva er merkelig med dette? Det er noe merkelig her, for jeg la til tre rader i denne tabellen, men jeg har fortsatt to rader i låsetabellen. Og dette er i bunn og grunn Postgres sin grunnleggende oppførsel.

Mange tenker at hvis du i databasen låser 100 rader, så vil du måtte opprette 100 låseoppføringer. Hvis jeg låser 1 000 rader på en gang, så trenger jeg 1 000 slike forespørseler. Og hvis jeg trenger å blokkere en million eller en milliard. Men hvis vi gjør det på denne måten, vil det ikke fungere så bra. Hvis du har brukt et system som oppretter låseoppføringer for hver enkelt rad, ser du at dette er vanskelig. For du må umiddelbart bestemme deg for en låsetabell som kan være overbelastet, men Postgres gjør det ikke slik.

Og på dette lysbildet er det veldig viktig at det tydelig demonstreres at det er et annet system som fungerer innenfor MVCC, som låser enkeltlinjer. Så når du låser milliarder av rader, oppretter ikke Postgres milliardene av separate låsekommandoer. Og dette har en veldig positiv innvirkning på ytelsen.

Hva med oppdateringen? Jeg oppdaterer nå en rad, og du kan merke at den umiddelbart utførte to forskjellige operasjoner. Den har samtidig låst tabellen, men den har også låst indeksen. Og den måtte låse indeksen, fordi det er unike begrensninger på denne tabellen. Vi vil forsikre oss om at ingen endrer det, så vi låser det.

Hva skjer hvis jeg vil oppdatere to rader? Vi ser at det oppfører seg på samme måte. Vi gjør dobbelt så mange oppdateringer, men fortsatt det samme antallet låste rader.

Hvis du er interessert i hvordan Postgres gjør dette, må du høre på mine presentasjoner om MVCC for å forstå hvordan Postgres internt merker de radene som den endrer. Og Postgres har en måte å gjøre dette på, men den gjør det ikke på nivået for tabellås, den gjør det på et lavere og mer effektivt nivå.

Men hvis jeg vil slette noe? Hvis jeg sletter for eksempel en rad og jeg fortsatt har de to innledende låsene, og selv om jeg ønsker å slette dem alle, vil de fortsatt være til stede.

Og, for eksempel, hvis jeg ønsker å sette inn 1 000 rader, og deretter slette eller legge til 1 000 rader, vil de individuelle radene jeg legger til eller endrer, ikke bli registrert her. De blir registrert på et lavere nivå inne i selve raden. Og under presentasjonen om MVCC snakket jeg om dette i detalj. Men det er veldig viktig, når du analyserer låser, å sørge for at du har en lås på tabellnivå og at du ikke ser opptaket av individuelle rader her.

Hva med eksplisitt låsing?

Hvis jeg klikker 'oppdater', har jeg to låste rader. Og hvis jeg velger dem alle og klikker 'oppdater overalt', vil jeg fortsatt ha to låsede oppføringer.

Vi oppretter ikke separate oppføringer for hver enkelt rad. For ellers vil ytelsen synke, det kan bli for mye av det. Og vi kan havne i en vanskelig situasjon.

Og det samme gjelder hvis vi gjør delt, vi kan gjøre det for alt 30 ganger.

Vi gjenoppretter tabellen vår, sletter alt, og deretter setter vi inn en rad på nytt.

En annen type oppførsel du ser i Postgres, er den veldig kjente og ønskelige oppførselen – at du kan utføre oppdatering eller selektering. Og du kan gjøre dette samtidig. Seleksjonen blokkerer ikke oppdateringen, og det samme gjelder motsatt vei. Vi sier at den som leser ikke blokkerer den som skriver, og den som skriver blokkerer ikke leseren.

Jeg vil vise deg et eksempel på dette. Jeg skal nå gjøre et valg. Deretter skal vi gjøre en INSERT. Og da kan du se – 694. Du vil kunne se ID-en til transaksjonen som utførte denne innsettingen. Og slik fungerer det.

Og hvis jeg nå ser på min backend ID, så har den blitt – 695.

Og jeg kan se at 695 dukker opp i tabellen min.

Og hvis jeg utfører en oppdatering her slik, får jeg en annen situasjon. I dette tilfellet er 695 en eksklusiv låsing, og oppdatering har det samme atferd, men det oppstår ikke konflikt mellom dem, noe som er ganske uvanlig.

Og du kan merke deg at på toppen er det ShareLock, og nederst er det ExclusiveLock. Og begge transaksjoner ble oppnådd.

Og du må høre mitt foredrag om MVCC for å forstå hvordan dette skjer. Men det er en illustrasjon på at du kan gjøre dette samtidig, dvs. både utføre SELECT og UPDATE samtidig.

La oss nullstille og gjøre en operasjon til.

Hvis du prøver å kjøre to oppdateringer samtidig på den samme raden, vil det bli låst. Og husk at jeg sa at den lesende ikke blokkerer den skrivende, men den skrivende blokkerer leseren, men én skribent blokkerer en annen skribent. Dvs. vi kan ikke ha to personer som oppdaterer den samme raden samtidig. Man må vente til den ene er ferdig.

Og for å illustrere dette vil jeg se på Lockdemo-tabellen. Og vi skal se på én rad. Om transaksjon 698.

Vi oppdaterte dette til 2. 699 er den første oppdateringen. Og den har gått gjennom vellykket, eller så er den i en ventende transaksjon og venter på at vi skal bekrefte eller avbryte.

Men se på noe annet – 2/51 – det er vår første transaksjon, vår første økt. 3/112 – det er den andre forespørselen som dukket opp øverst og som endret denne verdien til 3. Og hvis du ser nøye, så har den øverste blokkert seg selv, som er 699. Men 3/112 har ikke gitt noen blokkering. I kolonnen Lock_mode står det at den venter. Den venter på 699. Og hvis du ser hvor 699 er, så er det høyere oppe. Hva gjorde den første økten? Den opprettet en eksklusiv blokkering på sin egen transaksjons-ID. Det er slik Postgres gjør det. Den blokkerer sin egen transaksjons-ID. Og hvis du vil vente til noen bekrefter eller kansellerer, må du vente til det er en ventende transaksjon. Derfor kan vi se den merkelige linjen.

La oss se på det en gang til. Til venstre ser vi vår behandlings-ID. I den andre kolonnen ser vi vår virtuelle transaksjons-ID, og i den tredje ser vi lock_type. Hva betyr dette? I bunn og grunn sier det at den blokkerer transaksjons-ID. Men merk at i alle radene nederst står det relation. Og derfor har du to typer blokkeringer i tabellen. Det er blokkering av relation. Og det er også blokkering av transactionid, hvor vi blokkerer oss selv, det er nettopp det som skjer i den første raden eller nederst, hvor transactionid vi venter på at 699 skal fullføre sin operasjon.

Jeg ser hva som skjer her. Og det skjer to ting samtidig. Du ser på blokkeringen av transaksjons-ID i den første raden, som blokkerer seg selv. Og den blokkerer seg selv for å få folk til å vente.

Hvis du ser på den 6. linjen, er det samme post som den første. Og derfor er transaksjon 699 blokkert. 700 blokkerer også seg selv. Og så vil du se i den nederste raden at vi venter på at 699 skal fullføre sin operasjon.

Og i lock_type, tuple ser du tallene.

Du kan se at det er 0/10. Og det er sidenummeret, og også offset for den spesifikke raden.

Og du ser at det blir 0/11 når vi oppdaterer.

Men i virkeligheten er det 0/10, fordi det er venting på denne operasjonen. Vi har mulighet til å se at dette er raden jeg venter på å bekrefte.

Så snart vi bekreftet det og klikket på commit, og når oppdateringen er fullført, er dette hva vi får igjen. Transaksjon 700 er den eneste låsen, den venter ikke lenger på noen, fordi den er blitt kommittet. Den venter bare på at transaksjonen skal fullføres. Så snart 699 er ferdig, venter vi ikke lenger. Og nå sier transaksjon 700 at alt er i orden, at alle låsene den trenger, er tilgjengelige i alle tillatte tabeller.

Og for å gjøre det enda mer komplisert, oppretter vi en annen view som denne gangen gir oss hierarkiet. Jeg forventer ikke at du skal forstå denne forespørselen. Men det vil gi oss et klarere bilde av hva som skjer.

Dette er en rekursiv view, som også har en annen seksjon. Og den returnerer deretter alt sammen igjen. La oss bruke dette.

Hva om vi gjør tre samtidige oppdateringer og sier at raden nå er lik tre. Og vi endrer 3 til 4.

Og her ser vi 4. Og transaksjons-ID 702.

Og deretter endrer jeg 4 til 5. Og 5 til 6, og 6 til 7. Og jeg lager en kø av mennesker som venter på at denne ene transaksjonen skal fullføres.

Og alt blir forståelig. Hvilken er den første raden? Det er 702. Det er transaksjons-ID-en som opprinnelig satte denne verdien. Og hva står det i kolonnen Granted? Jeg har merker f. Dette er mine oppdateringer, som (5, 6, 7) ikke kan godkjennes, fordi vi venter på at transaksjons-ID 702 skal bli ferdig. Der har vi en lås på transaksjons-ID-en. Og det blir 5 transaksjonslåser ID.

Og hvis du ser på 704, på 705, så er det fortsatt ingenting skrevet, fordi de fortsatt ikke vet hva som skjer. De skriver bare at de ikke har anelse om hva som skjer. Og de vil bare gå i dvale, fordi de venter på at noen skal bli ferdig og vekke dem når muligheten til å endre raden er der.

Slik ser det ut. Det er klart at de alle venter på 12. linje.

Det er det vi så her. Her er 0/12.

Så snart den første transaksjonen er godkjent, kan du her se hvordan hierarkiet fungerer. Og nå blir alt klart. De blir alle rene. Og de er faktisk fortsatt i ventemodus.

Dette er hva som skjer. 702 blir kommittet. Nå får 703 denne radlåsen, og så begynner 704 å vente på at 703 skal bli kommittet. 705 venter også på dette. Og når alt dette er fullført, så rydder de opp selv. Jeg vil gjerne påpeke at alle stiller seg i kø. Det er veldig likt en situasjon med trafikknedgang, der alle venter på den første bilen. Den første bilen stopper, og alle stiller seg i en lang rekke. Så beveger den seg, så kan den neste bilen kjøre frem og få sin lås, osv.

Og hvis dette ikke virket komplisert nok, så skal vi nå snakke om deadlocks. Jeg vet ikke hvem av dere som har vært borti dette. Det er et ganske vanlig problem i databaser. Men deadlocks er det tilfellet hvor én sesjon venter på at en annen sesjon skal utføre noe. Og samtidig venter den andre sesjonen på at den første sesjonen skal utføre noe.

For eksempel, hvis Ivan sier: «Gi meg noe», og jeg sier: «Nei, jeg gir deg dette bare hvis du gir meg noe annet». Og han sier: «Nei, jeg gir deg ikke dette hvis du ikke gir meg noe». Og vi havner i en deadlock-situasjon. Jeg er sikker på at Ivan ikke ville gjort slik, men dere forstår meningen, at to personer vil ha noe og de er ikke villige til å gi det fra seg før den andre personen gir dem det de ønsker. Og der finnes det ingen løsning.

I bunn og grunn må databasen din oppdage dette. Deretter må den fjerne eller lukke en av sesjonene, fordi hvis ikke så vil de forbli der for alltid. Vi ser dette i databaser, vi ser det i operativsystemer. Om hvor som helst vi har parallelle prosesser, kan dette skje.

Nå skal vi sette opp to deadlocks. Vi setter 50 og 80. I den første raden vil jeg utføre en oppdatering fra 50 til 50. Jeg får transaksjonsnummer 710.

Deretter skal jeg endre 80 til 81, og 50 til 51.

Og slik vil det se ut. Derfor har 710 en radlås, mens 711 venter på bekreftelse. Vi så dette når vi oppdaterte. 710 er eier av vår rad. Og 711 venter på at 710 skal fullføre transaksjonen.

Det står til og med skrevet hvilken rad vi har deadlocks på. Og her begynner det å bli merkelig.

Nå oppdaterer vi 80 til 80.

Og her begynner deadlocks. 710 venter på svar fra 711, mens 711 venter på 710. Og dette kommer ikke til å ende godt. Det finnes ingen vei ut av dette. De vil vente på svar fra hverandre.

Og dette vil bare begynne å forsinke alt. Og det ønsker vi ikke.

I Postgres finnes det måter å oppdage når dette skjer. Når det skjer, får du en feil som denne. Det er tydelig at en prosess venter på SHARE LOCK fra en annen prosess, altså som blokkeres av prosess 711. Og den prosessen ventet på å få en SHARE LOCK på en spesifikk transaksjons-ID, som ble blokkert av en bestemt prosess. Så her er det en deadlock.

Er det mulig å ha treveis deadlocks? Kan dette skje? Ja.

Vi skriver disse tallene inn i tabellen. Vi endrer 40 til 40, vi låser.

Endrer 60 til 61, 80 til 81.

Deretter endrer vi 80, og så - boom!

Og 714 venter nå på 715. 716 venter på 715. Og det er ingenting å gjøre med dette.

Her er det ikke bare to personer, her er det tre personer. Jeg vil ha noe fra deg, den andre vil ha noe fra den tredje personen, og den tredje personen vil ha noe fra meg. Vi befinner oss i en trepartsventing, fordi vi alle venter på at den andre skal fullføre det de må gjøre.

Og Postgres vet hvilken rad dette skjer på. Derfor vil det gi deg følgende melding, som viser at du har et problem, hvor tre prosesser blokkerer hverandre. Og her er det ingen begrensninger. Dette kan skje i en situasjon hvor 20 poster blokkerer hverandre.

Neste problem er serializable.

Hvis det er en spesifikk serializable blokkering.

Og vi går tilbake til 719. Den har en helt normal utgang.

Og du kan trykke for å gjøre en transaksjon fra serializable.

Og du forstår at du nå har en annen type blokkering SA – dette betyr serializable.

Derfor har vi en ny type blokkering, kalt SARieadLock, som er en seriesperring og lar deg angi serienumre.

Og du kan også sette inn unike indekser.

I denne tabellen har vi unike indekser.

Så hvis jeg skriver nummer 2 her, så har jeg 2. Men helt på toppen setter jeg inn en annen 2. Og du kan se at 721 har en eksklusiv blokkering. Men nå venter 722 på at 721 skal fullføre sin operasjon, fordi den ikke kan sette inn 2 før den vet hva som skjer med 721.

Og hvis vi lager en subtransaksjon.

Her har vi 723.

Og dersom vi beholder et punkt og deretter oppdaterer det, får vi en ny transaksjons-ID. Dette er en annen atferd du trenger å vite om. Hvis vi returnerer dette, forsvinner transaksjons-ID-en. 724 forsvinner. Men nå får vi 725.

Og hva prøver jeg å gjøre her? Jeg prøver å vise deg eksempler på uvanlige låser som du kan finde: enten det er serializable-låser eller SAVEPOINT – dette er forskjellige typer låser som vil vises i låstabelen.

Dette er opprettelsen av eksplisitte låser som har pg_advisory_lock.

Og du ser at låsetypen her er oppført som advisory. Og det står skrevet med rødt «advisory». Og du kan samtidig låse det med pg_advisory_unlock.

Og for å avslutte vil jeg vise deg enda en fantastisk ting. Jeg vil lage en annen type. Men jeg vil koble tabellen pg_locks med tabellen pg_stat_activity. Og hvorfor vil jeg gjøre dette? Fordi det lar meg se og observere alle nåværende økter og se hvilke spesifikke låser de venter på. Og det er ganske interessant når vi setter sammen låsetabellen og forespørselstabellen.

Og her oppretter vi pg_stat_view.

Og vi oppdaterer en rad med én. Og her ser vi 724. Deretter oppdaterer vi raden vår til tre. Og hva ser du her nå? Dette er forespørslene, det vil si at du ser hele listen over forespørslene listet i venstre kolonne. Og deretter kan du på høyre side se låser og hva de skaper. Og dette kan være mer forståelig for deg, slik at du ikke trenger å gå tilbake til hver økt og sjekke – om det er nødvendig å bli med eller ikke. Det gjør de for oss.

En annen funksjon som er veldig nyttig – er pg_blocking_pids. Du har kanskje aldri hørt om den. Hva gjør den? Den lar oss si at for denne sesjonen 11740, hvilke spesifikke prosess-IDs den venter på. Og du kan se at 11740 venter på 724. Og 724 er øverst. Og 11306 er din prosess-ID. I bunn og grunn går denne funksjonen gjennom lånetabellen din. Jeg vet at det er litt komplisert, men du klarer å forstå det. I bunn og grunn går denne funksjonen gjennom denne lånetabellen og prøver å finne hvor denne prosess-IDen er, med tanke på de låsene den venter på. Og prøver også å beregne hvilken prosess-ID den prosessen har som venter på låser. Så du kan kjøre denne funksjonen pg_blocking_pids.

Og dette kan være veldig nyttig. Vi la dette til først med versjon 9.6, så denne funksjonen har bare eksistert i 5 år, men den er veldig, veldig nyttig. Det samme gjelder den andre forespørselen. Den viser akkurat det vi trenger å se.

Dette er noe jeg ønsket å diskutere med deg. Og som jeg forventet, brukte vi all vår tid, fordi det var så mange lysbilder. Lysbildene er tilgjengelige for nedlasting. Jeg vil takke deg for at du var her. Jeg er sikker på at du vil like resten av konferansen, tusen takk!

Spørsmål:

For eksempel, hvis jeg prøver å oppdatere rader, mens den andre sesjonen prøver å slette hele tabellen. Så langt jeg forstår, må det være noe som en intent lock. Finnes dette i Postgres?

La oss gå tilbake til begynnelsen. Kanskje du husker at når du gjør noe som for eksempel SELECT, gir vi AccessShareLock. Og dette forhindrer sletting av tabellen. Så hvis du for eksempel ønsker å oppdatere en rad i tabellen eller slette en rad, kan ikke noen slette hele tabellen samtidig med det, fordi du holder denne AccessShareLock over hele tabellen og over raden. Og så snart du er ferdig, kan de slette det. Men så lenge du endrer noe der, kan de ikke gjøre det.

La oss prøve igjen. La oss gå til eksemplet med sletting. Og du ser at det er en eksklusiv lås over hele tabellen på raden.

Det vil se ut som en eksklusiv lås, ikke sant?

Ja, det ser ut som det. Jeg forstår hva du snakker om. Du sier at hvis jeg utfører SELECT, så vil jeg ha ShareExclusive, og så konverterer jeg dette til Row Exclusive, blir det et problem? Men overraskende nok skaper det ikke et problem. Det er som å øke låsen, men i bunn og grunn har jeg en lås som forhindrer sletting. Og nå, når jeg gjør denne låsen sterkere, forhindrer den fortsatt sletting. Så det er ikke slik at jeg hever det opp. Det vil si, den forhindret det selv når den var på et lavere nivå, så når jeg hever nivået, forhindrer den fortsatt sletting av tabellen.

Jeg forstår hva du snakker om. Det er ikke et tilfelle av økt låsebredde, hvor du prøver å slippe en lås for å innføre en mer kraftfull. Her heves det bare allment beskyttelsen, så det skaper ikke noen konflikter. Men det er et godt spørsmål. Takk for at du stilte det!

Hva må vi gjøre for å unngå en deadlock-situasjon når vi har mange økter og mange brukere?

Postgres oppdager automatisk situasjoner med deadlocks. Og vil automatisk fjerne en av øktene. Den eneste måten å unngå deadlocks på er å låse folk i samme rekkefølge. Så når du ser på applikasjonen din, er årsaken til deadlocks ofte... La oss si at jeg ønsker å låse to forskjellige ting. Én applikasjon låser tabell 1, mens en annen applikasjon låser 2, og deretter tabell 1. Den enkleste måten å unngå deadlocks på er å se på applikasjonen din og sørge for at låsene skjer i den samme rekkefølgen i alle applikasjoner. Og dette fjerner som regel 80 % av problemene, fordi mange forskjellige folk skriver disse applikasjonene. Og hvis du låser dem i samme rekkefølge, vil du ikke stå overfor en deadlock-situasjon.

Takk for presentasjonen! Du snakket om vacuum full, og hvis jeg forstår det riktig, så deformerer vacuum full rekkefølgen av oppføringer i den enkelte lagringen, så de nåværende oppføringene forblir uendret. Men hvorfor tar vacuum full en eksklusiv lås, og hvorfor er det konflikt med skriveoperasjoner?

Dette er et godt spørsmål. Årsaken er at vacuum full tar tabellen. Og vi lager i hovedsak en ny versjon av tabellen. Så tabellen blir ny. Det ender med at dette vil være en helt ny versjon av tabellen. Problemet er at når vi gjør dette, ønsker vi ikke at folk skal lese den, fordi vi trenger dem til å se den nye tabellen. Og derfor henger dette sammen med det forrige spørsmålet. Hvis vi kunne lese samtidig, ville vi ikke vært i stand til å flytte den og lede folk til den nye tabellen. Vi måtte ha ventet til alle var ferdige med å lese denne tabellen, og derfor er dette i hovedsak en eksklusiv låsesituasjon.
Vi sier bare at vi låser fra begynnelsen av, fordi vi vet at vi på slutten vil trenge en eksklusiv lås for å flytte alle til den nye kopien. Så potensielt kan vi tillate dette. Og vi gjør dette med samtidige indeksering. Men det er mye mer komplisert. Og det relaterer seg sterkt til ditt forrige spørsmål om eksklusiv lås.

Er det mulig å legge til locking timeout i Postgres? I Oracle kan jeg for eksempel skrive «velg for oppdatering» og vente 50 sekunder før oppdateringen. Dette var bra for applikasjonen. Men i Postgres må jeg enten gjøre det umiddelbart uten venting, eller vente til et visst tidspunkt.

Ja, du kan velge timeout for låsene dine. Du kan også gi kommandoen no way, som vil..., hvis du ikke kan få låsen med en gang. Så enten lock timeout eller noe annet som lar deg gjøre dette. Dette gjøres ikke på syntaktisk nivå. Dette gjøres som en variabel på serveren. Noen ganger kan dette ikke brukes.

Kan du åpne 75. lysbildet?

Ja.

Og mitt spørsmål er dette. Hvorfor venter begge oppdateringsprosessene på 703?

Og dette er et utmerket spørsmål. Jeg forstår forresten ikke hvorfor Postgres gjør dette. Men når 703 ble opprettet, forventet den 702. Og når 704 og 705 dukker opp, ser det ut som om de ikke vet hva de venter på, fordi det ikke er noe der ennå. Og Postgres håndterer det slik: når du ikke kan få en lås, spør den «Hva er poenget med å behandle deg?», fordi du allerede venter på noen. Så vi lar det henge i luften, den oppdaterer det ikke i det hele tatt. Men hva skjedde her? Så snart 702 fullførte prosessen og 703 fikk sin lås, kom systemet tilbake. Og sa at nå har vi to personer som venter. La oss oppdatere dem sammen. Og indikere at begge venter.

Jeg vet ikke hvorfor Postgres gjør slik. Men det er et problem som kalles f…. Jeg mener, dette er ikke et begrep på russisk. Det er når alle venter på én lås, selv om det er 20 instanser som venter på låsen. Og plutselig våkner de alle opp samtidig. Og alle begynner å prøve å reagere. Men systemet sørger for at alle venter på 703. Fordi de alle venter, stiller vi dem umiddelbart i kø. Og hvis det dukker opp noen andre nye forespørsel, som ble dannet etter dette, for eksempel 707, så vil det igjen være tomt.

Og jeg mener at dette gjøres for å kunne si at på dette stadiet venter 702 på 703, og alle som kommer etter dette, vil ikke ha noen post i dette feltet. Men så snart den første som venter forlater, får alle som ventet i det øyeblikket før oppdateringen den samme markøren. Og derfor mener jeg det er gjort slik at vi kan håndtere dem i rekkefølge, slik at de er riktig ordnet.

Jeg har alltid sett på dette som et ganske merkelig fenomen. Fordi her, for eksempel, ikke oppregnes dem i det hele tatt. Men jeg mener at hver gang vi gir en ny lås, ser vi på alle som er i venteprosessen. Så stiller vi dem i kø. Og så vil enhver ny som kommer, komme i kø kun når den neste personen er ferdig med å bli behandlet. Veldig godt spørsmål. Tusen takk for spørsmålet!

Jeg mener det er mye mer logisk når 705 venter på 704.

Men problemet her er som følger. Teknisk kan du vekke enten den ene eller den andre. Og derfor vil vi vekke den ene eller den andre. Men hva skjer i driften av systemet? Du ser hvordan 703 på toppen har blokkert sin egen transaksjons-ID. Slik fungerer Postgres. Og 703 blir blokkert av sin egen transaksjons-ID, så hvis noen ønsker å vente, vil de vente på 703. Og i realiteten fullfører 703. Og først etter at den er fullført, vil en av prosessene bli vekket. Og vi vet ikke hvilken av prosessene det vil være. Deretter behandler vi dem gradvis. Men det er ikke klart hvilken prosess som våkner først, fordi det kan være hvilken som helst av disse prosessene. I utgangspunktet hadde vi en planlegger som sa at vi nå kan vekke hvilken som helst av disse prosessene. Vi velger bare én tilfeldig. Så begge må merkes, fordi vi kan vekke en av dem.

Og problemet er at vi har CP-uendelighet. Og derfor er det ganske sannsynlig at vi kan vekke den senere. Og hvis vi for eksempel vekker den senere, vil vi vente på den som akkurat har fått blokkering, så vi kan ikke bestemme hvem som vil bli vekket først. Vi skaper bare en slik situasjon, og systemet vil vekke dem i vilkårlig rekkefølge.

Ja artikler om låser av Egor Rogov. Ta en titt, de er også interessante og nyttige. Temaet er selvfølgelig grusomt komplisert. Tusen takk, Bruce!

Kilde: habr.com