http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex><\/p>\n<\/p>\n
Se her. Numrene p\u00e5 transaksjonen er uthevet i r\u00f8dt. Her vises funksjonen SELECT pg_back. Den returnerer min transaksjon og ID-en til denne transaksjonen. <\/p>\n
<\/p>\n
En annen ting, hvis du liker denne presentasjonen og \u00f8nsker \u00e5 starte den i databasen din, kan du f\u00f8lge lenken som er markert med rosa, og laste ned SQL for denne presentasjonen. Du kan enkelt kj\u00f8re den i PSQL-en din, og hele presentasjonen vil umiddelbart vises p\u00e5 skjermen din. Den vil ikke inneholde farger, men i det minste vil vi kunne se den.<\/p>\n
<\/p>\n
<\/p>\n
I dette tilfellet ser vi ID-en til transaksjonen. Dette er nummeret vi har gitt den. Det finnes ogs\u00e5 en annen type transaksjons-ID i Postgres, kalt virtuell transaksjons-ID.<\/p>\n
<\/p>\n
Og vi m\u00e5 forst\u00e5 dette. Det er veldig viktig, ellers kan vi ikke forst\u00e5 l\u00e5sing i Postgres.<\/p>\n
<\/p>\n
Virtuell transaksjons-ID er ID-en til en transaksjon som ikke inneholder permanente verdier. For eksempel, hvis jeg kj\u00f8rer en SELECT-kommando, kommer jeg sannsynligvis ikke til \u00e5 endre databasen, jeg vil ikke blokkere noe. Derfor, n\u00e5r vi kj\u00f8rer en enkel SELECT, gir vi ikke denne transaksjonen en permanent ID. Vi gir den bare en virtuell ID.<\/p>\n
<\/p>\n
Og dette \u00f8ker ytelsen til Postgres og forbedrer mulighetene for opprydding, derfor best\u00e5r den virtuelle transaksjons-ID-en av to tall. Det f\u00f8rste tallet f\u00f8r skr\u00e5streken er backend-ID-en. P\u00e5 h\u00f8yre side ser vi bare en teller.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 hvis jeg kj\u00f8rer en sp\u00f8rring, sier den at backend-ID-en er 2. <\/p>\n
<\/p>\n
<\/p>\n
Og hvis jeg kj\u00f8rer en serie slike transaksjoner, ser vi at telleren \u00f8ker hver gang jeg kj\u00f8rer en sp\u00f8rring. For eksempel n\u00e5r jeg kj\u00f8rer sp\u00f8rring 2\/10, 2\/11, 2\/12 osv. <\/p>\n
<\/p>\n
<\/p>\n
Legg merke til at det er to kolonner her. Til venstre ser vi den virtuelle transaksjons-ID-en \u2013 2\/12. P\u00e5 h\u00f8yre 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.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 snart jeg kj\u00f8rer kommandoen analyze (ANALYZE), gir den samme sp\u00f8rringen meg en permanent transaksjons-ID. Se hvordan dette har endret seg. F\u00f8r hadde jeg ikke denne ID-en, n\u00e5 har den dukket opp.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 her er en annen sp\u00f8rring, en annen transaksjon. Den virtuelle transaksjonsnummeret er 2\/13. Og hvis jeg ber om den permanente transaksjons-ID-en, vil jeg f\u00e5 den n\u00e5r jeg kj\u00f8rer sp\u00f8rringen. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 igjen. Vi har en virtuell transaksjons-ID og en permanent transaksjons-ID. Bare forst\u00e5 dette punktet for \u00e5 forst\u00e5 oppf\u00f8rselen til Postgres.<\/p>\n
<\/p>\n
<\/p>\n
Vi g\u00e5r videre til den tredje delen. Her vil vi bare se p\u00e5 de ulike typene l\u00e5ser i Postgres. Det er ikke s\u00e5 spennende. Den siste delen vil bli mye mer interessant. Men vi m\u00e5 se p\u00e5 det grunnleggende, ellers vil vi ikke forst\u00e5 hva som kommer videre. <\/p>\n
<\/p>\n
Vi skal g\u00e5 gjennom denne delen, vi ser p\u00e5 hver type l\u00e5s. Og jeg vil vise deg eksempler p\u00e5 hvordan de settes, hvordan de fungerer, og vise deg noen sp\u00f8rringer som kan brukes for \u00e5 se hvordan l\u00e5sing fungerer i Postgres.<\/p>\n
<\/p>\n
<\/p>\n
For \u00e5 lage en sp\u00f8rring og se hva som skjer i Postgres, m\u00e5 vi kj\u00f8re en sp\u00f8rring i systemvisningen. I dette tilfellet er pg_lock uthevet med r\u00f8dt. Pg_lock er en systemtabel som forteller oss hvilke l\u00e5ser som brukes i Postgres for \u00f8yeblikket.<\/p>\n
<\/p>\n
Men det er veldig vanskelig for meg \u00e5 vise deg pg_lock i seg selv, fordi det er ganske komplisert. Derfor har jeg laget en visning som viser pg_locks. Den gj\u00f8r ogs\u00e5 noe arbeid for meg, som gj\u00f8r at jeg bedre kan forst\u00e5. Det vil si at den ekskluderer mine l\u00e5ser, min egen \u00f8kt osv. Dette er bare standard SQL, og den lar meg vise deg bedre hva som skjer. <\/p>\n
<\/p>\n
<\/p>\n
En annen utfordring er at denne visningen er veldig bred, s\u00e5 jeg m\u00e5tte lage en andre \u2013 lockview2.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 vi har opprettet en tabell som heter Lockdemo. Og vi har opprettet \u00e9n rad der. Dette er v\u00e5r eksempeltabell. Og vi skal lage seksjoner bare for \u00e5 vise deg eksempler p\u00e5 l\u00e5sing. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5, \u00e9n rad, \u00e9n kolonne. Den f\u00f8rste typen l\u00e5s kalles ACCESS SHARE. Dette er den minst restriktive l\u00e5sen. Det betyr at den praktisk talt ikke konflikter med andre l\u00e5ser.<\/p>\n
<\/p>\n
Og dersom vi vil definere l\u00e5singen eksplisitt, kj\u00f8rer vi kommandoen \u00ablock table\u00bb. Dette vil tydelig l\u00e5se den, alts\u00e5 i ACCESS SHARE-modus kj\u00f8rer vi lock table. Og hvis jeg kj\u00f8rer PSQL i bakgrunnen, starter jeg p\u00e5 denne m\u00e5ten en annen sesjon fra min f\u00f8rste sesjon. Det vil si, hva gj\u00f8r jeg her? Jeg g\u00e5r til den andre sesjonen og sier: \u00abvis meg lockview for denne foresp\u00f8rselen\u00bb. Og her har jeg AccessShareLock i denne tabellen. Dette er akkurat det jeg ba om. Og den sier at l\u00e5sen har blitt tildelt. Veldig enkelt. <\/p>\n
<\/p>\n
<\/p>\n
Videre, hvis vi ser i den andre kolonnen, er det ingenting der. De er tomme. <\/p>\n
<\/p>\n
<\/p>\n
Og hvis jeg kj\u00f8rer kommandoen \u00abSELECT\u00bb, er dette en implisitt m\u00e5te \u00e5 be om AccessShareLock p\u00e5. S\u00e5 jeg slipper tabellen min og kj\u00f8rer foresp\u00f8rselen, og foresp\u00f8rselen returnerer flere rader. Og i en av radene ser vi AccessShareLock. Dermed for\u00e5rsaker SELECT AccessShareLock i tabellen. Og det konflikter praktisk talt ikke med noe, fordi det er en l\u00e5s av lavt niv\u00e5. <\/p>\n
<\/p>\n
<\/p>\n
Hva hvis jeg kj\u00f8rer SELECT og har tre forskjellige tabeller? Tidligere kj\u00f8rte jeg bare \u00e9n tabell, n\u00e5 kj\u00f8rer jeg tre: pg_class, pg_namespace og pg_attribute.<\/p>\n
<\/p>\n
<\/p>\n
Og n\u00e5, n\u00e5r jeg ser p\u00e5 foresp\u00f8rselen, ser jeg 9 AccessShareLocks i de tre tabellene. Hvorfor? Tre tabeller er uthevet med bl\u00e5tt: pg_attribute, pg_class, pg_namespace. Men du kan ogs\u00e5 se at alle indeksene som er definert gjennom disse tabellene, ogs\u00e5 har AccessShareLock.<\/p>\n
<\/p>\n
Og dette er en l\u00e5s som praktisk talt ikke konflikter med andre. Alt den gj\u00f8r, er \u00e5 hindre oss fra \u00e5 slippe tabellen s\u00e5 lenge vi velger den. Det gir mening. Det vil si, hvis vi velger en tabell, skulle den p\u00e5 det tidspunktet forsvinne, ville det v\u00e6rt galt, s\u00e5 AccessShare \u2013 er en lavniv\u00e5l\u00e5sing som sier \"ikke slett denne tabellen mens jeg jobber\".<\/strong>. I bunn og grunn er dette alt den gj\u00f8r. <\/p>\n<\/p>\n
<\/p>\n
ROW SHARE er en l\u00e5s som er litt annerledes. <\/p>\n
<\/p>\n
<\/p>\n
La oss ta et eksempel. SELECT ROW SHARE er en m\u00e5te \u00e5 l\u00e5se hver rad individuelt<\/strong>. Dermed kan ingen slette dem eller endre dem s\u00e5 lenge vi ser p\u00e5 dem. <\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
Her sier vi at l\u00e5sing brukes av oss.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 den eksklusive l\u00e5sen sier eksplisitt at den er eksklusiv. Og ogs\u00e5 hvis du sletter en rad i denne tabellen, vil det skje, som du kan se. <\/p>\n
<\/p>\n
<\/p>\n
SHARE EXCLUSIVE \u2013 dette er en lengre l\u00e5s.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Dette (ANALYZE) er analysekomenaden som vil bli brukt.<\/p>\n
<\/p>\n
<\/p>\n
SHARE LOCK \u2013 du kan eksplisitt l\u00e5se i delingsmodus.<\/p>\n
<\/p>\n
<\/p>\n
Du kan ogs\u00e5 opprette et unikt indeks. Og der kan du se SHARE LOCK, som er en del av dem. Og den l\u00e5ser tabellen og setter SHARE LOCK p\u00e5 den.<\/p>\n
<\/p>\n
Som standard betyr SHARE LOCK p\u00e5 tabellen at andre kan lese tabellen, men ingen kan modifisere den. Og det er nettopp det som skjer n\u00e5r du oppretter et unikt indeks.<\/strong><\/p>\n<\/p>\n
Hvis jeg oppretter en unik samtidig indeks, vil jeg ha en annen type l\u00e5sing, fordi, som du husker, bruk av samtidig indekser reduserer l\u00e5sekravene. Og hvis jeg bruker normal l\u00e5sing, normal indeks, vil jeg p\u00e5 den m\u00e5ten forhindre skriving til indeksen under opprettelsen. Hvis jeg bruker samtidig indeks, m\u00e5 jeg bruke en annen type l\u00e5sing. <\/p>\n
<\/p>\n
<\/p>\n
SHARE ROW EXCLUSIVE \u2013 den kan ogs\u00e5 settes eksplisitt.<\/p>\n
<\/p>\n
<\/p>\n
Eller vi kan lage en regel, dvs. ta et bestemt tilfelle der den vil bli brukt.<\/p>\n
<\/p>\n
<\/p>\n
EXCLUSIVE-l\u00e5sing betyr at ingen andre kan endre tabellen. <\/p>\n
<\/p>\n
<\/p>\n
Her ser vi forskjellige typer l\u00e5singer. <\/p>\n
<\/p>\n
<\/p>\n
ACCESS EXCLUSIVE, for eksempel, er en l\u00e5sekommando. For eksempel, hvis du gj\u00f8r CLUSTER table<\/code>, betyr det at ingen kan skrive dit. Og den l\u00e5ser ikke bare selve tabellen, men ogs\u00e5 indeksene.<\/p>\n<\/p>\n
<\/p>\n
Dette er den andre siden av ACCESS EXCLUSIVE l\u00e5sing, hvor vi ser spesifikt hva den blokkerer i tabellen. Den blokkerer individuelle rader i tabellen, noe som er ganske interessant.<\/p>\n
<\/p>\n
Dette er all den grunnleggende informasjonen jeg \u00f8nsket \u00e5 gi. Vi har snakket om l\u00e5ser, om transaksjons-ID-er, snakket om virtuelle transaksjons-ID-er, om permanente transaksjons-ID-er. <\/p>\n
<\/p>\n
<\/p>\n
Og n\u00e5 skal vi se p\u00e5 eksempler p\u00e5 l\u00e5ser. Dette er den mest interessante delen. Vi skal se p\u00e5 noen sv\u00e6rt interessante tilfeller. Og mitt m\u00e5l med denne presentasjonen er \u00e5 gi dere en bedre forst\u00e5else av hva Postgres faktisk gj\u00f8r n\u00e5r det pr\u00f8ver \u00e5 l\u00e5se forskjellige ting. Jeg f\u00f8ler at den er veldig flink til \u00e5 l\u00e5se enkeltkomponenter. <\/p>\n
<\/p>\n
La oss se p\u00e5 spesifikke eksempler.<\/p>\n
<\/p>\n
<\/p>\n
Vi begynner med tabeller og \u00e9n rad i tabellen. N\u00e5r jeg setter inn noe, vises det en ExclusiveLock, transaksjons-ID og ExclusiveLock for tabellen. <\/p>\n
<\/p>\n
<\/p>\n
Men hva skjer hvis jeg setter inn to rader til? Og n\u00e5 har vi tre rader i tabellen v\u00e5r. Jeg satte inn \u00e9n 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\u00e5setabellen. Og dette er i bunn og grunn Postgres sin grunnleggende oppf\u00f8rsel.<\/p>\n
<\/p>\n
Mange tenker at hvis du i databasen l\u00e5ser 100 rader, s\u00e5 vil du m\u00e5tte opprette 100 l\u00e5seoppf\u00f8ringer. Hvis jeg l\u00e5ser 1 000 rader p\u00e5 en gang, s\u00e5 trenger jeg 1 000 slike foresp\u00f8rseler. Og hvis jeg trenger \u00e5 blokkere en million eller en milliard. Men hvis vi gj\u00f8r det p\u00e5 denne m\u00e5ten, vil det ikke fungere s\u00e5 bra. Hvis du har brukt et system som oppretter l\u00e5seoppf\u00f8ringer for hver enkelt rad, ser du at dette er vanskelig. For du m\u00e5 umiddelbart bestemme deg for en l\u00e5setabell som kan v\u00e6re overbelastet, men Postgres gj\u00f8r det ikke slik. <\/p>\n
<\/p>\n
Og p\u00e5 dette lysbildet er det veldig viktig at det tydelig demonstreres at det er et annet system som fungerer innenfor MVCC, som l\u00e5ser enkeltlinjer. S\u00e5 n\u00e5r du l\u00e5ser milliarder av rader, oppretter ikke Postgres milliardene av separate l\u00e5sekommandoer. Og dette har en veldig positiv innvirkning p\u00e5 ytelsen. <\/p>\n
<\/p>\n
<\/p>\n
Hva med oppdateringen? Jeg oppdaterer n\u00e5 en rad, og du kan merke at den umiddelbart utf\u00f8rte to forskjellige operasjoner. Den har samtidig l\u00e5st tabellen, men den har ogs\u00e5 l\u00e5st indeksen. Og den m\u00e5tte l\u00e5se indeksen, fordi det er unike begrensninger p\u00e5 denne tabellen. Vi vil forsikre oss om at ingen endrer det, s\u00e5 vi l\u00e5ser det.<\/p>\n
<\/p>\n
<\/p>\n
Hva skjer hvis jeg vil oppdatere to rader? Vi ser at det oppf\u00f8rer seg p\u00e5 samme m\u00e5te. Vi gj\u00f8r dobbelt s\u00e5 mange oppdateringer, men fortsatt det samme antallet l\u00e5ste rader. <\/p>\n
<\/p>\n
Hvis du er interessert i hvordan Postgres gj\u00f8r dette, m\u00e5 du h\u00f8re p\u00e5 mine presentasjoner om MVCC for \u00e5 forst\u00e5 hvordan Postgres internt merker de radene som den endrer. Og Postgres har en m\u00e5te \u00e5 gj\u00f8re dette p\u00e5, men den gj\u00f8r det ikke p\u00e5 niv\u00e5et for tabell\u00e5s, den gj\u00f8r det p\u00e5 et lavere og mer effektivt niv\u00e5.<\/p>\n
<\/p>\n
<\/p>\n
Men hvis jeg vil slette noe? Hvis jeg sletter for eksempel en rad og jeg fortsatt har de to innledende l\u00e5sene, og selv om jeg \u00f8nsker \u00e5 slette dem alle, vil de fortsatt v\u00e6re til stede.<\/p>\n
<\/p>\n
<\/p>\n
Og, for eksempel, hvis jeg \u00f8nsker \u00e5 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\u00e5 et lavere niv\u00e5 inne i selve raden. Og under presentasjonen om MVCC snakket jeg om dette i detalj. Men det er veldig viktig, n\u00e5r du analyserer l\u00e5ser, \u00e5 s\u00f8rge for at du har en l\u00e5s p\u00e5 tabellniv\u00e5 og at du ikke ser opptaket av individuelle rader her. <\/p>\n
<\/p>\n
<\/p>\n
Hva med eksplisitt l\u00e5sing?<\/p>\n
<\/p>\n
<\/p>\n
Hvis jeg klikker 'oppdater', har jeg to l\u00e5ste rader. Og hvis jeg velger dem alle og klikker 'oppdater overalt', vil jeg fortsatt ha to l\u00e5sede oppf\u00f8ringer. <\/p>\n
<\/p>\n
<\/p>\n
Vi oppretter ikke separate oppf\u00f8ringer for hver enkelt rad. For ellers vil ytelsen synke, det kan bli for mye av det. Og vi kan havne i en vanskelig situasjon. <\/p>\n
<\/p>\n
<\/p>\n
Og det samme gjelder hvis vi gj\u00f8r delt, vi kan gj\u00f8re det for alt 30 ganger. <\/p>\n
<\/p>\n
<\/p>\n
Vi gjenoppretter tabellen v\u00e5r, sletter alt, og deretter setter vi inn en rad p\u00e5 nytt.<\/p>\n
<\/p>\n
<\/p>\n
En annen type oppf\u00f8rsel du ser i Postgres, er den veldig kjente og \u00f8nskelige oppf\u00f8rselen \u2013 at du kan utf\u00f8re oppdatering eller selektering. Og du kan gj\u00f8re 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. <\/p>\n
<\/p>\n
Jeg vil vise deg et eksempel p\u00e5 dette. Jeg skal n\u00e5 gj\u00f8re et valg. Deretter skal vi gj\u00f8re en INSERT. Og da kan du se \u2013 694. Du vil kunne se ID-en til transaksjonen som utf\u00f8rte denne innsettingen. Og slik fungerer det. <\/p>\n
<\/p>\n
<\/p>\n
Og hvis jeg n\u00e5 ser p\u00e5 min backend ID, s\u00e5 har den blitt \u2013 695. <\/p>\n
<\/p>\n
<\/p>\n
Og jeg kan se at 695 dukker opp i tabellen min. <\/p>\n
<\/p>\n
<\/p>\n
Og hvis jeg utf\u00f8rer en oppdatering her slik, f\u00e5r jeg en annen situasjon. I dette tilfellet er 695 en eksklusiv l\u00e5sing, og oppdatering har det samme atferd, men det oppst\u00e5r ikke konflikt mellom dem, noe som er ganske uvanlig. <\/p>\n
<\/p>\n
Og du kan merke deg at p\u00e5 toppen er det ShareLock, og nederst er det ExclusiveLock. Og begge transaksjoner ble oppn\u00e5dd.<\/p>\n
<\/p>\n
Og du m\u00e5 h\u00f8re mitt foredrag om MVCC for \u00e5 forst\u00e5 hvordan dette skjer. Men det er en illustrasjon p\u00e5 at du kan gj\u00f8re dette samtidig, dvs. b\u00e5de utf\u00f8re SELECT og UPDATE samtidig.<\/p>\n
<\/p>\n
<\/p>\n
La oss nullstille og gj\u00f8re en operasjon til. <\/p>\n
<\/p>\n
<\/p>\n
Hvis du pr\u00f8ver \u00e5 kj\u00f8re to oppdateringer samtidig p\u00e5 den samme raden, vil det bli l\u00e5st. Og husk at jeg sa at den lesende ikke blokkerer den skrivende, men den skrivende blokkerer leseren, men \u00e9n skribent blokkerer en annen skribent. Dvs. vi kan ikke ha to personer som oppdaterer den samme raden samtidig. Man m\u00e5 vente til den ene er ferdig. <\/p>\n
<\/p>\n
<\/p>\n
Og for \u00e5 illustrere dette vil jeg se p\u00e5 Lockdemo-tabellen. Og vi skal se p\u00e5 \u00e9n rad. Om transaksjon 698.<\/p>\n
<\/p>\n
Vi oppdaterte dette til 2. 699 er den f\u00f8rste oppdateringen. Og den har g\u00e5tt gjennom vellykket, eller s\u00e5 er den i en ventende transaksjon og venter p\u00e5 at vi skal bekrefte eller avbryte. <\/p>\n
<\/p>\n
<\/p>\n
Men se p\u00e5 noe annet \u2013 2\/51 \u2013 det er v\u00e5r f\u00f8rste transaksjon, v\u00e5r f\u00f8rste \u00f8kt. 3\/112 \u2013 det er den andre foresp\u00f8rselen som dukket opp \u00f8verst og som endret denne verdien til 3. Og hvis du ser n\u00f8ye, s\u00e5 har den \u00f8verste blokkert seg selv, som er 699. Men 3\/112 har ikke gitt noen blokkering. I kolonnen Lock_mode st\u00e5r det at den venter. Den venter p\u00e5 699. Og hvis du ser hvor 699 er, s\u00e5 er det h\u00f8yere oppe. Hva gjorde den f\u00f8rste \u00f8kten? Den opprettet en eksklusiv blokkering p\u00e5 sin egen transaksjons-ID. Det er slik Postgres gj\u00f8r det. Den blokkerer sin egen transaksjons-ID. Og hvis du vil vente til noen bekrefter eller kansellerer, m\u00e5 du vente til det er en ventende transaksjon. Derfor kan vi se den merkelige linjen. <\/p>\n
<\/p>\n
La oss se p\u00e5 det en gang til. Til venstre ser vi v\u00e5r behandlings-ID. I den andre kolonnen ser vi v\u00e5r 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\u00e5r det relation. Og derfor har du to typer blokkeringer i tabellen. Det er blokkering av relation. Og det er ogs\u00e5 blokkering av transactionid, hvor vi blokkerer oss selv, det er nettopp det som skjer i den f\u00f8rste raden eller nederst, hvor transactionid vi venter p\u00e5 at 699 skal fullf\u00f8re sin operasjon. <\/p>\n
<\/p>\n
Jeg ser hva som skjer her. Og det skjer to ting samtidig. Du ser p\u00e5 blokkeringen av transaksjons-ID i den f\u00f8rste raden, som blokkerer seg selv. Og den blokkerer seg selv for \u00e5 f\u00e5 folk til \u00e5 vente. <\/p>\n
<\/p>\n
Hvis du ser p\u00e5 den 6. linjen, er det samme post som den f\u00f8rste. Og derfor er transaksjon 699 blokkert. 700 blokkerer ogs\u00e5 seg selv. Og s\u00e5 vil du se i den nederste raden at vi venter p\u00e5 at 699 skal fullf\u00f8re sin operasjon.<\/p>\n
<\/p>\n
<\/p>\n
Og i lock_type, tuple ser du tallene. <\/p>\n
<\/p>\n
<\/p>\n
Du kan se at det er 0\/10. Og det er sidenummeret, og ogs\u00e5 offset for den spesifikke raden. <\/p>\n
<\/p>\n
<\/p>\n
Og du ser at det blir 0\/11 n\u00e5r vi oppdaterer. <\/p>\n
<\/p>\n
<\/p>\n
Men i virkeligheten er det 0\/10, fordi det er venting p\u00e5 denne operasjonen. Vi har mulighet til \u00e5 se at dette er raden jeg venter p\u00e5 \u00e5 bekrefte. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 snart vi bekreftet det og klikket p\u00e5 commit, og n\u00e5r oppdateringen er fullf\u00f8rt, er dette hva vi f\u00e5r igjen. Transaksjon 700 er den eneste l\u00e5sen, den venter ikke lenger p\u00e5 noen, fordi den er blitt kommittet. Den venter bare p\u00e5 at transaksjonen skal fullf\u00f8res. S\u00e5 snart 699 er ferdig, venter vi ikke lenger. Og n\u00e5 sier transaksjon 700 at alt er i orden, at alle l\u00e5sene den trenger, er tilgjengelige i alle tillatte tabeller. <\/p>\n
<\/p>\n
<\/p>\n
Og for \u00e5 gj\u00f8re det enda mer komplisert, oppretter vi en annen view som denne gangen gir oss hierarkiet. Jeg forventer ikke at du skal forst\u00e5 denne foresp\u00f8rselen. Men det vil gi oss et klarere bilde av hva som skjer. <\/p>\n
<\/p>\n
<\/p>\n
Dette er en rekursiv view, som ogs\u00e5 har en annen seksjon. Og den returnerer deretter alt sammen igjen. La oss bruke dette. <\/p>\n
<\/p>\n
<\/p>\n
Hva om vi gj\u00f8r tre samtidige oppdateringer og sier at raden n\u00e5 er lik tre. Og vi endrer 3 til 4. <\/p>\n
<\/p>\n
<\/p>\n
Og her ser vi 4. Og transaksjons-ID 702. <\/p>\n
<\/p>\n
<\/p>\n
Og deretter endrer jeg 4 til 5. Og 5 til 6, og 6 til 7. Og jeg lager en k\u00f8 av mennesker som venter p\u00e5 at denne ene transaksjonen skal fullf\u00f8res.<\/p>\n
<\/p>\n
<\/p>\n
Og alt blir forst\u00e5elig. Hvilken er den f\u00f8rste raden? Det er 702. Det er transaksjons-ID-en som opprinnelig satte denne verdien. Og hva st\u00e5r det i kolonnen Granted? Jeg har merker f<\/code>. Dette er mine oppdateringer, som (5, 6, 7) ikke kan godkjennes, fordi vi venter p\u00e5 at transaksjons-ID 702 skal bli ferdig. Der har vi en l\u00e5s p\u00e5 transaksjons-ID-en. Og det blir 5 transaksjonsl\u00e5ser ID.<\/p>\n<\/p>\n
Og hvis du ser p\u00e5 704, p\u00e5 705, s\u00e5 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\u00e5 i dvale, fordi de venter p\u00e5 at noen skal bli ferdig og vekke dem n\u00e5r muligheten til \u00e5 endre raden er der. <\/p>\n
<\/p>\n
<\/p>\n
Slik ser det ut. Det er klart at de alle venter p\u00e5 12. linje. <\/p>\n
<\/p>\n
<\/p>\n
Det er det vi s\u00e5 her. Her er 0\/12. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 snart den f\u00f8rste transaksjonen er godkjent, kan du her se hvordan hierarkiet fungerer. Og n\u00e5 blir alt klart. De blir alle rene. Og de er faktisk fortsatt i ventemodus. <\/p>\n
<\/p>\n
<\/p>\n
Dette er hva som skjer. 702 blir kommittet. N\u00e5 f\u00e5r 703 denne radl\u00e5sen, og s\u00e5 begynner 704 \u00e5 vente p\u00e5 at 703 skal bli kommittet. 705 venter ogs\u00e5 p\u00e5 dette. Og n\u00e5r alt dette er fullf\u00f8rt, s\u00e5 rydder de opp selv. Jeg vil gjerne p\u00e5peke at alle stiller seg i k\u00f8. Det er veldig likt en situasjon med trafikknedgang, der alle venter p\u00e5 den f\u00f8rste bilen. Den f\u00f8rste bilen stopper, og alle stiller seg i en lang rekke. S\u00e5 beveger den seg, s\u00e5 kan den neste bilen kj\u00f8re frem og f\u00e5 sin l\u00e5s, osv. <\/p>\n
<\/p>\n
<\/p>\n
Og hvis dette ikke virket komplisert nok, s\u00e5 skal vi n\u00e5 snakke om deadlocks. Jeg vet ikke hvem av dere som har v\u00e6rt borti dette. Det er et ganske vanlig problem i databaser. Men deadlocks er det tilfellet hvor \u00e9n sesjon venter p\u00e5 at en annen sesjon skal utf\u00f8re noe. Og samtidig venter den andre sesjonen p\u00e5 at den f\u00f8rste sesjonen skal utf\u00f8re noe. <\/p>\n
<\/p>\n
For eksempel, hvis Ivan sier: \u00abGi meg noe\u00bb, og jeg sier: \u00abNei, jeg gir deg dette bare hvis du gir meg noe annet\u00bb. Og han sier: \u00abNei, jeg gir deg ikke dette hvis du ikke gir meg noe\u00bb. Og vi havner i en deadlock-situasjon. Jeg er sikker p\u00e5 at Ivan ikke ville gjort slik, men dere forst\u00e5r meningen, at to personer vil ha noe og de er ikke villige til \u00e5 gi det fra seg f\u00f8r den andre personen gir dem det de \u00f8nsker. Og der finnes det ingen l\u00f8sning. <\/p>\n
<\/p>\n
I bunn og grunn m\u00e5 databasen din oppdage dette. Deretter m\u00e5 den fjerne eller lukke en av sesjonene, fordi hvis ikke s\u00e5 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. <\/p>\n
<\/p>\n
<\/p>\n
N\u00e5 skal vi sette opp to deadlocks. Vi setter 50 og 80. I den f\u00f8rste raden vil jeg utf\u00f8re en oppdatering fra 50 til 50. Jeg f\u00e5r transaksjonsnummer 710. <\/p>\n
<\/p>\n
<\/p>\n
Deretter skal jeg endre 80 til 81, og 50 til 51. <\/p>\n
<\/p>\n
<\/p>\n
Og slik vil det se ut. Derfor har 710 en radl\u00e5s, mens 711 venter p\u00e5 bekreftelse. Vi s\u00e5 dette n\u00e5r vi oppdaterte. 710 er eier av v\u00e5r rad. Og 711 venter p\u00e5 at 710 skal fullf\u00f8re transaksjonen.<\/p>\n
<\/p>\n
<\/p>\n
Det st\u00e5r til og med skrevet hvilken rad vi har deadlocks p\u00e5. Og her begynner det \u00e5 bli merkelig.<\/p>\n
<\/p>\n
<\/p>\n
N\u00e5 oppdaterer vi 80 til 80. <\/p>\n
<\/p>\n
<\/p>\n
Og her begynner deadlocks. 710 venter p\u00e5 svar fra 711, mens 711 venter p\u00e5 710. Og dette kommer ikke til \u00e5 ende godt. Det finnes ingen vei ut av dette. De vil vente p\u00e5 svar fra hverandre. <\/p>\n
<\/p>\n
<\/p>\n
Og dette vil bare begynne \u00e5 forsinke alt. Og det \u00f8nsker vi ikke. <\/p>\n
<\/p>\n
<\/p>\n
I Postgres finnes det m\u00e5ter \u00e5 oppdage n\u00e5r dette skjer. N\u00e5r det skjer, f\u00e5r du en feil som denne. Det er tydelig at en prosess venter p\u00e5 SHARE LOCK fra en annen prosess, alts\u00e5 som blokkeres av prosess 711. Og den prosessen ventet p\u00e5 \u00e5 f\u00e5 en SHARE LOCK p\u00e5 en spesifikk transaksjons-ID, som ble blokkert av en bestemt prosess. S\u00e5 her er det en deadlock.<\/p>\n
<\/p>\n
<\/p>\n
Er det mulig \u00e5 ha treveis deadlocks? Kan dette skje? Ja. <\/p>\n
<\/p>\n
<\/p>\n
Vi skriver disse tallene inn i tabellen. Vi endrer 40 til 40, vi l\u00e5ser. <\/p>\n
<\/p>\n
<\/p>\n
Endrer 60 til 61, 80 til 81. <\/p>\n
<\/p>\n
<\/p>\n
Deretter endrer vi 80, og s\u00e5 - boom! <\/p>\n
<\/p>\n
<\/p>\n
Og 714 venter n\u00e5 p\u00e5 715. 716 venter p\u00e5 715. Og det er ingenting \u00e5 gj\u00f8re med dette.<\/p>\n
<\/p>\n
<\/p>\n
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\u00e5 at den andre skal fullf\u00f8re det de m\u00e5 gj\u00f8re. <\/p>\n
<\/p>\n
<\/p>\n
Og Postgres vet hvilken rad dette skjer p\u00e5. Derfor vil det gi deg f\u00f8lgende 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. <\/p>\n
<\/p>\n
<\/p>\n
Neste problem er serializable. <\/p>\n
<\/p>\n
<\/p>\n
Hvis det er en spesifikk serializable blokkering.<\/p>\n
<\/p>\n
<\/p>\n
Og vi g\u00e5r tilbake til 719. Den har en helt normal utgang. <\/p>\n
<\/p>\n
<\/p>\n
Og du kan trykke for \u00e5 gj\u00f8re en transaksjon fra serializable.<\/p>\n
<\/p>\n
<\/p>\n
Og du forst\u00e5r at du n\u00e5 har en annen type blokkering SA \u2013 dette betyr serializable. <\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Derfor har vi en ny type blokkering, kalt SARieadLock, som er en seriesperring og lar deg angi serienumre.<\/p>\n
<\/p>\n
<\/p>\n
Og du kan ogs\u00e5 sette inn unike indekser. <\/p>\n
<\/p>\n
<\/p>\n
I denne tabellen har vi unike indekser.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 hvis jeg skriver nummer 2 her, s\u00e5 har jeg 2. Men helt p\u00e5 toppen setter jeg inn en annen 2. Og du kan se at 721 har en eksklusiv blokkering. Men n\u00e5 venter 722 p\u00e5 at 721 skal fullf\u00f8re sin operasjon, fordi den ikke kan sette inn 2 f\u00f8r den vet hva som skjer med 721. <\/p>\n
<\/p>\n
<\/p>\n
Og hvis vi lager en subtransaksjon.<\/p>\n
<\/p>\n
<\/p>\n
Her har vi 723.<\/p>\n
<\/p>\n
<\/p>\n
Og dersom vi beholder et punkt og deretter oppdaterer det, f\u00e5r vi en ny transaksjons-ID. Dette er en annen atferd du trenger \u00e5 vite om. Hvis vi returnerer dette, forsvinner transaksjons-ID-en. 724 forsvinner. Men n\u00e5 f\u00e5r vi 725. <\/p>\n
<\/p>\n
Og hva pr\u00f8ver jeg \u00e5 gj\u00f8re her? Jeg pr\u00f8ver \u00e5 vise deg eksempler p\u00e5 uvanlige l\u00e5ser som du kan finde: enten det er serializable-l\u00e5ser eller SAVEPOINT \u2013 dette er forskjellige typer l\u00e5ser som vil vises i l\u00e5stabelen. <\/p>\n
<\/p>\n
<\/p>\n
Dette er opprettelsen av eksplisitte l\u00e5ser som har pg_advisory_lock. <\/p>\n
<\/p>\n
<\/p>\n
Og du ser at l\u00e5setypen her er oppf\u00f8rt som advisory. Og det st\u00e5r skrevet med r\u00f8dt \u00abadvisory\u00bb. Og du kan samtidig l\u00e5se det med pg_advisory_unlock.<\/p>\n
<\/p>\n
<\/p>\n
Og for \u00e5 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\u00f8re dette? Fordi det lar meg se og observere alle n\u00e5v\u00e6rende \u00f8kter og se hvilke spesifikke l\u00e5ser de venter p\u00e5. Og det er ganske interessant n\u00e5r vi setter sammen l\u00e5setabellen og foresp\u00f8rselstabellen. <\/p>\n
<\/p>\n
<\/p>\n
Og her oppretter vi pg_stat_view. <\/p>\n
<\/p>\n
<\/p>\n
Og vi oppdaterer en rad med \u00e9n. Og her ser vi 724. Deretter oppdaterer vi raden v\u00e5r til tre. Og hva ser du her n\u00e5? Dette er foresp\u00f8rslene, det vil si at du ser hele listen over foresp\u00f8rslene listet i venstre kolonne. Og deretter kan du p\u00e5 h\u00f8yre side se l\u00e5ser og hva de skaper. Og dette kan v\u00e6re mer forst\u00e5elig for deg, slik at du ikke trenger \u00e5 g\u00e5 tilbake til hver \u00f8kt og sjekke \u2013 om det er n\u00f8dvendig \u00e5 bli med eller ikke. Det gj\u00f8r de for oss. <\/p>\n
<\/p>\n
En annen funksjon som er veldig nyttig \u2013 er pg_blocking_pids<\/code>. Du har kanskje aldri h\u00f8rt om den. Hva gj\u00f8r den? Den lar oss si at for denne sesjonen 11740, hvilke spesifikke prosess-IDs den venter p\u00e5. Og du kan se at 11740 venter p\u00e5 724. Og 724 er \u00f8verst. Og 11306 er din prosess-ID. I bunn og grunn g\u00e5r denne funksjonen gjennom l\u00e5netabellen din. Jeg vet at det er litt komplisert, men du klarer \u00e5 forst\u00e5 det. I bunn og grunn g\u00e5r denne funksjonen gjennom denne l\u00e5netabellen og pr\u00f8ver \u00e5 finne hvor denne prosess-IDen er, med tanke p\u00e5 de l\u00e5sene den venter p\u00e5. Og pr\u00f8ver ogs\u00e5 \u00e5 beregne hvilken prosess-ID den prosessen har som venter p\u00e5 l\u00e5ser. S\u00e5 du kan kj\u00f8re denne funksjonen pg_blocking_pids<\/code>.<\/p>\n<\/p>\n
Og dette kan v\u00e6re veldig nyttig. Vi la dette til f\u00f8rst med versjon 9.6, s\u00e5 denne funksjonen har bare eksistert i 5 \u00e5r, men den er veldig, veldig nyttig. Det samme gjelder den andre foresp\u00f8rselen. Den viser akkurat det vi trenger \u00e5 se. <\/p>\n
<\/p>\n
<\/p>\n
Dette er noe jeg \u00f8nsket \u00e5 diskutere med deg. Og som jeg forventet, brukte vi all v\u00e5r tid, fordi det var s\u00e5 mange lysbilder. Lysbildene er tilgjengelige for nedlasting. Jeg vil takke deg for at du var her. Jeg er sikker p\u00e5 at du vil like resten av konferansen, tusen takk!<\/p>\n
<\/p>\n
Sp\u00f8rsm\u00e5l:<\/p>\n
<\/p>\n
For eksempel, hvis jeg pr\u00f8ver \u00e5 oppdatere rader, mens den andre sesjonen pr\u00f8ver \u00e5 slette hele tabellen. S\u00e5 langt jeg forst\u00e5r, m\u00e5 det v\u00e6re noe som en intent lock. Finnes dette i Postgres?<\/em><\/p>\n<\/p>\n
<\/p>\n
La oss g\u00e5 tilbake til begynnelsen. Kanskje du husker at n\u00e5r du gj\u00f8r noe som for eksempel SELECT, gir vi AccessShareLock. Og dette forhindrer sletting av tabellen. S\u00e5 hvis du for eksempel \u00f8nsker \u00e5 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\u00e5 snart du er ferdig, kan de slette det. Men s\u00e5 lenge du endrer noe der, kan de ikke gj\u00f8re det.<\/p>\n
<\/p>\n
La oss pr\u00f8ve igjen. La oss g\u00e5 til eksemplet med sletting. Og du ser at det er en eksklusiv l\u00e5s over hele tabellen p\u00e5 raden. <\/p>\n
<\/p>\n
Det vil se ut som en eksklusiv l\u00e5s, ikke sant?<\/em><\/p>\n<\/p>\n
Ja, det ser ut som det. Jeg forst\u00e5r hva du snakker om. Du sier at hvis jeg utf\u00f8rer SELECT, s\u00e5 vil jeg ha ShareExclusive, og s\u00e5 konverterer jeg dette til Row Exclusive, blir det et problem? Men overraskende nok skaper det ikke et problem. Det er som \u00e5 \u00f8ke l\u00e5sen, men i bunn og grunn har jeg en l\u00e5s som forhindrer sletting. Og n\u00e5, n\u00e5r jeg gj\u00f8r denne l\u00e5sen sterkere, forhindrer den fortsatt sletting. S\u00e5 det er ikke slik at jeg hever det opp. Det vil si, den forhindret det selv n\u00e5r den var p\u00e5 et lavere niv\u00e5, s\u00e5 n\u00e5r jeg hever niv\u00e5et, forhindrer den fortsatt sletting av tabellen. <\/p>\n
<\/p>\n
Jeg forst\u00e5r hva du snakker om. Det er ikke et tilfelle av \u00f8kt l\u00e5sebredde, hvor du pr\u00f8ver \u00e5 slippe en l\u00e5s for \u00e5 innf\u00f8re en mer kraftfull. Her heves det bare allment beskyttelsen, s\u00e5 det skaper ikke noen konflikter. Men det er et godt sp\u00f8rsm\u00e5l. Takk for at du stilte det!<\/p>\n
<\/p>\n
Hva m\u00e5 vi gj\u00f8re for \u00e5 unng\u00e5 en deadlock-situasjon n\u00e5r vi har mange \u00f8kter og mange brukere?<\/em><\/p>\n<\/p>\n
Postgres oppdager automatisk situasjoner med deadlocks. Og vil automatisk fjerne en av \u00f8ktene. Den eneste m\u00e5ten \u00e5 unng\u00e5 deadlocks p\u00e5 er \u00e5 l\u00e5se folk i samme rekkef\u00f8lge. S\u00e5 n\u00e5r du ser p\u00e5 applikasjonen din, er \u00e5rsaken til deadlocks ofte... La oss si at jeg \u00f8nsker \u00e5 l\u00e5se to forskjellige ting. \u00c9n applikasjon l\u00e5ser tabell 1, mens en annen applikasjon l\u00e5ser 2, og deretter tabell 1. Den enkleste m\u00e5ten \u00e5 unng\u00e5 deadlocks p\u00e5 er \u00e5 se p\u00e5 applikasjonen din og s\u00f8rge for at l\u00e5sene skjer i den samme rekkef\u00f8lgen i alle applikasjoner. Og dette fjerner som regel 80 % av problemene, fordi mange forskjellige folk skriver disse applikasjonene. Og hvis du l\u00e5ser dem i samme rekkef\u00f8lge, vil du ikke st\u00e5 overfor en deadlock-situasjon.<\/p>\n
<\/p>\n
Takk for presentasjonen! Du snakket om vacuum full, og hvis jeg forst\u00e5r det riktig, s\u00e5 deformerer vacuum full rekkef\u00f8lgen av oppf\u00f8ringer i den enkelte lagringen, s\u00e5 de n\u00e5v\u00e6rende oppf\u00f8ringene forblir uendret. Men hvorfor tar vacuum full en eksklusiv l\u00e5s, og hvorfor er det konflikt med skriveoperasjoner?<\/em><\/p>\n<\/p>\n
Dette er et godt sp\u00f8rsm\u00e5l. \u00c5rsaken er at vacuum full tar tabellen. Og vi lager i hovedsak en ny versjon av tabellen. S\u00e5 tabellen blir ny. Det ender med at dette vil v\u00e6re en helt ny versjon av tabellen. Problemet er at n\u00e5r vi gj\u00f8r dette, \u00f8nsker vi ikke at folk skal lese den, fordi vi trenger dem til \u00e5 se den nye tabellen. Og derfor henger dette sammen med det forrige sp\u00f8rsm\u00e5let. Hvis vi kunne lese samtidig, ville vi ikke v\u00e6rt i stand til \u00e5 flytte den og lede folk til den nye tabellen. Vi m\u00e5tte ha ventet til alle var ferdige med \u00e5 lese denne tabellen, og derfor er dette i hovedsak en eksklusiv l\u00e5sesituasjon.
<\/p>\n
Er det mulig \u00e5 legge til locking timeout i Postgres? I Oracle kan jeg for eksempel skrive \u00abvelg for oppdatering\u00bb og vente 50 sekunder f\u00f8r oppdateringen. Dette var bra for applikasjonen. Men i Postgres m\u00e5 jeg enten gj\u00f8re det umiddelbart uten venting, eller vente til et visst tidspunkt.<\/em> <\/p>\n<\/p>\n
Ja, du kan velge timeout for l\u00e5sene dine. Du kan ogs\u00e5 gi kommandoen no way, som vil..., hvis du ikke kan f\u00e5 l\u00e5sen med en gang. S\u00e5 enten lock timeout eller noe annet som lar deg gj\u00f8re dette. Dette gj\u00f8res ikke p\u00e5 syntaktisk niv\u00e5. Dette gj\u00f8res som en variabel p\u00e5 serveren. Noen ganger kan dette ikke brukes.<\/p>\n
<\/p>\n
Kan du \u00e5pne 75. lysbildet?<\/em> <\/p>\n<\/p>\n
Ja.<\/p>\n
<\/p>\n
<\/p>\n
Og mitt sp\u00f8rsm\u00e5l er dette. Hvorfor venter begge oppdateringsprosessene p\u00e5 703?<\/em><\/p>\n<\/p>\n
Og dette er et utmerket sp\u00f8rsm\u00e5l. Jeg forst\u00e5r forresten ikke hvorfor Postgres gj\u00f8r dette. Men n\u00e5r 703 ble opprettet, forventet den 702. Og n\u00e5r 704 og 705 dukker opp, ser det ut som om de ikke vet hva de venter p\u00e5, fordi det ikke er noe der enn\u00e5. Og Postgres h\u00e5ndterer det slik: n\u00e5r du ikke kan f\u00e5 en l\u00e5s, sp\u00f8r den \u00abHva er poenget med \u00e5 behandle deg?\u00bb, fordi du allerede venter p\u00e5 noen. S\u00e5 vi lar det henge i luften, den oppdaterer det ikke i det hele tatt. Men hva skjedde her? S\u00e5 snart 702 fullf\u00f8rte prosessen og 703 fikk sin l\u00e5s, kom systemet tilbake. Og sa at n\u00e5 har vi to personer som venter. La oss oppdatere dem sammen. Og indikere at begge venter. <\/p>\n
<\/p>\n
Jeg vet ikke hvorfor Postgres gj\u00f8r slik. Men det er et problem som kalles f\u2026. Jeg mener, dette er ikke et begrep p\u00e5 russisk. Det er n\u00e5r alle venter p\u00e5 \u00e9n l\u00e5s, selv om det er 20 instanser som venter p\u00e5 l\u00e5sen. Og plutselig v\u00e5kner de alle opp samtidig. Og alle begynner \u00e5 pr\u00f8ve \u00e5 reagere. Men systemet s\u00f8rger for at alle venter p\u00e5 703. Fordi de alle venter, stiller vi dem umiddelbart i k\u00f8. Og hvis det dukker opp noen andre nye foresp\u00f8rsel, som ble dannet etter dette, for eksempel 707, s\u00e5 vil det igjen v\u00e6re tomt. <\/p>\n
<\/p>\n
Og jeg mener at dette gj\u00f8res for \u00e5 kunne si at p\u00e5 dette stadiet venter 702 p\u00e5 703, og alle som kommer etter dette, vil ikke ha noen post i dette feltet. Men s\u00e5 snart den f\u00f8rste som venter forlater, f\u00e5r alle som ventet i det \u00f8yeblikket f\u00f8r oppdateringen den samme mark\u00f8ren. Og derfor mener jeg det er gjort slik at vi kan h\u00e5ndtere dem i rekkef\u00f8lge, slik at de er riktig ordnet. <\/p>\n
<\/p>\n
Jeg har alltid sett p\u00e5 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\u00e5s, ser vi p\u00e5 alle som er i venteprosessen. S\u00e5 stiller vi dem i k\u00f8. Og s\u00e5 vil enhver ny som kommer, komme i k\u00f8 kun n\u00e5r den neste personen er ferdig med \u00e5 bli behandlet. Veldig godt sp\u00f8rsm\u00e5l. Tusen takk for sp\u00f8rsm\u00e5let!<\/p>\n
<\/p>\n
Jeg mener det er mye mer logisk n\u00e5r 705 venter p\u00e5 704.<\/em> <\/p>\n<\/p>\n
Men problemet her er som f\u00f8lger. 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\u00e5 toppen har blokkert sin egen transaksjons-ID. Slik fungerer Postgres. Og 703 blir blokkert av sin egen transaksjons-ID, s\u00e5 hvis noen \u00f8nsker \u00e5 vente, vil de vente p\u00e5 703. Og i realiteten fullf\u00f8rer 703. Og f\u00f8rst etter at den er fullf\u00f8rt, vil en av prosessene bli vekket. Og vi vet ikke hvilken av prosessene det vil v\u00e6re. Deretter behandler vi dem gradvis. Men det er ikke klart hvilken prosess som v\u00e5kner f\u00f8rst, fordi det kan v\u00e6re hvilken som helst av disse prosessene. I utgangspunktet hadde vi en planlegger som sa at vi n\u00e5 kan vekke hvilken som helst av disse prosessene. Vi velger bare \u00e9n tilfeldig. S\u00e5 begge m\u00e5 merkes, fordi vi kan vekke en av dem. <\/p>\n
<\/p>\n
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\u00e5 den som akkurat har f\u00e5tt blokkering, s\u00e5 vi kan ikke bestemme hvem som vil bli vekket f\u00f8rst. Vi skaper bare en slik situasjon, og systemet vil vekke dem i vilk\u00e5rlig rekkef\u00f8lge. <\/p>\n
<\/p>\n
Ja artikler om l\u00e5ser av Egor Rogov<\/a><\/noindex>. Ta en titt, de er ogs\u00e5 interessante og nyttige. Temaet er selvf\u00f8lgelig grusomt komplisert. Tusen takk, Bruce!<\/em><\/p>\nKilde: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2020 \u0433\u043e\u0434\u0430 \u0411\u0440\u044e\u0441\u0430 \u041c\u043e\u043c\u0436\u0438\u0430\u043d\u0430 "Unlocking the Postgres Lock Manager". (\u041f\u0440\u0438\u043c\u0435\u0447\u0430\u043d\u0438\u0435: \u0412\u0441\u0435 SQL \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438\u0437 \u0441\u043b\u0430\u0439\u0434\u043e\u0432 \u0432\u044b \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043f\u043e \u044d\u0442\u043e\u0439 \u0441\u0441\u044b\u043b\u043a\u0435: http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql) \u041f\u0440\u0438\u0432\u0435\u0442! \u0417\u0430\u043c\u0435\u0447\u0430\u0442\u0435\u043b\u044c\u043d\u043e \u0441\u043d\u043e\u0432\u0430 \u0431\u044b\u0442\u044c \u0437\u0434\u0435\u0441\u044c \u0432 \u0420\u043e\u0441\u0441\u0438\u0438. \u042f \u043f\u0440\u043e\u0448\u0443 \u043f\u0440\u043e\u0449\u0435\u043d\u0438\u0435, \u0447\u0442\u043e \u044f \u043d\u0435 \u0441\u043c\u043e\u0433 \u043f\u0440\u0438\u0435\u0445\u0430\u0442\u044c \u0432 \u043f\u0440\u043e\u0448\u043b\u043e\u043c \u0433\u043e\u0434\u0443, \u043d\u043e \u0432 \u044d\u0442\u043e\u043c \u0433\u043e\u0434\u0443 \u0443 \u0418\u0432\u0430\u043d\u0430 \u0438 \u0443 \u043c\u0435\u043d\u044f \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u043f\u043b\u0430\u043d\u044b. \u042f, \u043d\u0430\u0434\u0435\u044e\u0441\u044c, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":87955,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-87954","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Unlocking](\"\/wp-content\/uploads\/2020\/07\/1f75fbb0cb41c306c33c823ef55f7238.png\")
<\/p>\n