http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex><\/p>\n<\/p>\n
Lad os se. Nummeret p\u00e5 transaktionen er fremh\u00e6vet med r\u00f8dt. Her vises funktionen SELECT pg_back. Den returnerer min transaktion og ID'en p\u00e5 denne transaktion. <\/p>\n
<\/p>\n
En anden ting, hvis du kan lide denne pr\u00e6sentation, og du vil have den i din database, kan du f\u00f8lge dette link, der er fremh\u00e6vet i pink, og downloade SQL til denne pr\u00e6sentation. Du kan bare k\u00f8re det i dit PSQL, og hele pr\u00e6sentationen vises p\u00e5 din sk\u00e6rm \u00f8jeblikkeligt. Den vil ikke indeholde farver, men i det mindste vil vi kunne se den.<\/p>\n
<\/p>\n
<\/p>\n
I dette tilf\u00e6lde ser vi transaktions-ID'et. Det er det nummer, vi har tildelt det. Og der er en anden type transaktions-ID i Postgres, som kaldes virtuel transaktions-ID.<\/p>\n
<\/p>\n
Og vi skal forst\u00e5 dette. Det er meget vigtigt, ellers kan vi ikke forst\u00e5 l\u00e5sningen i Postgres.<\/p>\n
<\/p>\n
Virtuel transaktions-ID er et transaktions-ID, der ikke indeholder permanente v\u00e6rdier. For eksempel, hvis jeg k\u00f8rer en SELECT-kommando, s\u00e5 \u00e6ndrer jeg sandsynligvis ikke databasen, jeg vil ikke l\u00e5se noget. Derfor, n\u00e5r vi k\u00f8rer en simpel SELECT, tildeler vi ikke denne transaktion et permanent ID. Vi giver den kun et virtuelt ID.<\/p>\n
<\/p>\n
Og det forbedrer ydeevnen i Postgres, forbedrer mulighederne for oprydning, s\u00e5 det virtuelle transaktions-ID best\u00e5r af to tal. Det f\u00f8rste tal f\u00f8r skr\u00e5stregen er backend-id'et. Og til h\u00f8jre ser vi bare en t\u00e6ller.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 hvis jeg k\u00f8rer en foresp\u00f8rgsel, siger den, at backend-id'et er 2. <\/p>\n
<\/p>\n
<\/p>\n
Og hvis jeg k\u00f8rer en serie af s\u00e5danne transaktioner, ser vi, at t\u00e6lleren hver gang \u00f8ges, n\u00e5r jeg k\u00f8rer foresp\u00f8rgslen. For eksempel n\u00e5r jeg k\u00f8rer foresp\u00f8rgslerne 2\/10, 2\/11, 2\/12 osv. <\/p>\n
<\/p>\n
<\/p>\n
V\u00e6r opm\u00e6rksom p\u00e5, at der her er to kolonner. Til venstre ser vi det virtuelle transaktions-ID \u2013 2\/12. Og til h\u00f8jre har vi det permanente transaktions-ID. Og dette felt er tomt. Denne transaktion \u00e6ndrer ikke databasen. Derfor tildeler jeg ikke et permanent transaktions-ID til den.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 snart jeg k\u00f8rer analys\u00e9r-kommandoen (ANALYZE), giver den samme foresp\u00f8rgsel mig et permanent transaktions-ID. Se hvordan det har \u00e6ndret sig. Jeg havde ikke dette ID f\u00f8r, nu er det til stede.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 her er endnu en foresp\u00f8rgsel, endnu en transaktion. Det virtuelle transaktionsnummer er 2\/13. Og hvis jeg beder om det permanente transaktions-ID, s\u00e5 vil jeg f\u00e5 det, n\u00e5r jeg k\u00f8rer foresp\u00f8rgslen. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 endnu en gang. Vi har det virtuelle transaktions-ID og det permanente transaktions-ID. Bare forst\u00e5 dette punkt for at forst\u00e5 Postgres' adf\u00e6rd.<\/p>\n
<\/p>\n
<\/p>\n
Vi g\u00e5r videre til det tredje afsnit. Her vil vi kort gennemg\u00e5 de forskellige typer af l\u00e5sninger i Postgres. Det er ikke meget interessant. Det sidste afsnit bliver langt mere interessant. Men vi skal tage de grundl\u00e6ggende ting i betragtning, for ellers vil vi ikke forst\u00e5, hvad der kommer n\u00e6ste gang. <\/p>\n
<\/p>\n
Vi vil d\u00e6kke dette afsnit, vi vil se p\u00e5 hver type l\u00e5sning. Og jeg vil vise jer eksempler p\u00e5, hvordan de etableres, hvordan de fungerer, og vise jer nogle foresp\u00f8rgsler, som kan bruges til at se, hvordan l\u00e5sning fungerer i Postgres.<\/p>\n
<\/p>\n
<\/p>\n
For at oprette en foresp\u00f8rgsel og se, hvad der sker i Postgres, skal vi k\u00f8re en foresp\u00f8rgsel p\u00e5 systemvisningen. I dette tilf\u00e6lde er pg_lock markeret med r\u00f8dt. Pg_lock er en systemtabel, der fort\u00e6ller os, hvilke l\u00e5sninger der i \u00f8jeblikket er aktive i Postgres.<\/p>\n
<\/p>\n
Det er dog meget sv\u00e6rt for mig at vise jer pg_lock i sig selv, fordi det er ret komplekst. Derfor har jeg oprettet en visning, der viser pg_locks. Og det udf\u00f8rer ogs\u00e5 noget arbejde for mig, som g\u00f8r det lettere for mig at forst\u00e5. Det vil sige, at det udelukker mine egne l\u00e5sninger, min egen session osv. Dette er blot standard SQL, og det giver mig bedre mulighed for at vise jer, hvad der foreg\u00e5r. <\/p>\n
<\/p>\n
<\/p>\n
En anden udfordring er, at denne visning er meget bred, s\u00e5 jeg m\u00e5 oprette en anden \u2013 lockview2.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 vi har oprettet en tabel kaldet Lockdemo. Og vi har oprettet \u00e9n r\u00e6kke der. Det er vores eksempel tabel. Og vi vil oprette afsnit for blot at vise jer eksempler p\u00e5 l\u00e5sninger. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 en r\u00e6kke, en kolonne. Den f\u00f8rste type l\u00e5sning kaldes ACCESS SHARE. Dette er den mindst begr\u00e6nsende l\u00e5sning. Det betyder, at den n\u00e6sten ikke konflikter med andre l\u00e5sninger.<\/p>\n
<\/p>\n
Og hvis vi vil eksplicit definere l\u00e5sningen, k\u00f8rer vi kommandoen \u00ablock table\u00bb. Den vil tydeligt l\u00e5se, dvs. i ACCESS SHARE-tilstand k\u00f8rer vi lock table. Hvis jeg k\u00f8rer PSQL i baggrunden, starter jeg dermed en anden session fra min f\u00f8rste session. Hvad g\u00f8r jeg her? Jeg skifter til den anden session og siger til den \u00abvis mig lockview for denne foresp\u00f8rgsel\u00bb. Her har jeg AccessShareLock i denne tabel. Det er lige pr\u00e6cis, hvad jeg bad om. Og den siger, at l\u00e5sen er tildelt. Meget enkelt. <\/p>\n
<\/p>\n
<\/p>\n
Derefter, hvis vi ser p\u00e5 den anden kolonne, er der intet. De er tomme. <\/p>\n
<\/p>\n
<\/p>\n
Og hvis jeg k\u00f8rer kommandoen \u00abSELECT\u00bb, er det en implicit (explicit) m\u00e5de at anmode om AccessShareLock. S\u00e5 jeg l\u00e5ser min tabel og k\u00f8rer foresp\u00f8rgslen, og foresp\u00f8rgslen returnerer flere r\u00e6kker. Og i en af r\u00e6kkerne ser vi AccessShareLock. S\u00e5ledes udl\u00f8ser SELECT AccessShareLock i tabellen. Og den konflikter stort set med ingenting, fordi det er en lav-niveau l\u00e5s. <\/p>\n
<\/p>\n
<\/p>\n
Hvad hvis jeg k\u00f8rer SELECT, og jeg har tre forskellige tabeller? Tidligere k\u00f8rte jeg kun en tabel, nu k\u00f8rer jeg tre: pg_class, pg_namespace og pg_attribute.<\/p>\n
<\/p>\n
<\/p>\n
Og nu, n\u00e5r jeg ser p\u00e5 foresp\u00f8rgslen, ser jeg 9 AccessShareLocks i de tre tabeller. Hvorfor? Tre tabeller er fremh\u00e6vet med bl\u00e5: pg_attribute, pg_class, pg_namespace. Men du kan ogs\u00e5 se, at alle indekser, der er defineret gennem disse tabeller, ogs\u00e5 har AccessShareLock.<\/p>\n
<\/p>\n
Og det er en l\u00e5s, der stort set ikke konflikter med andre. Alt, hvad den g\u00f8r, er at forhindre os i at nulstille tabellen, mens vi v\u00e6lger den. Det giver mening. Dvs. hvis vi v\u00e6lger en tabel, s\u00e5 forsvinder den p\u00e5 det tidspunkt, hvilket ville v\u00e6re forkert, derfor AccessShare er en lavt niveau l\u00e5s, der siger \"fjern ikke denne tabel, mens jeg arbejder\".<\/strong>. I bund og grund er det alt, hvad den g\u00f8r. <\/p>\n<\/p>\n
<\/p>\n
ROW SHARE er en lidt anderledes l\u00e5s. <\/p>\n
<\/p>\n
<\/p>\n
Lad os tage et eksempel. SELECT ROW SHARE er en m\u00e5de at l\u00e5se hver r\u00e6kke enkeltvis p\u00e5.<\/strong>. S\u00e5ledes kan ingen slette eller \u00e6ndre dem, mens vi ser p\u00e5 dem. <\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
Her siger vi, at l\u00e5sningen bruges af os.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 den eksklusive l\u00e5s siger eksplicit, at den er eksklusiv. Og hvis du sletter en r\u00e6kke i denne tabel, s\u00e5 vil det ogs\u00e5 ske, som du kan se. <\/p>\n
<\/p>\n
<\/p>\n
SHARE EXCLUSIVE \u2013 det er en l\u00e6ngere l\u00e5s.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Dette (ANALYZE) er en analysekommando, der vil blive brugt.<\/p>\n
<\/p>\n
<\/p>\n
SHARE LOCK \u2013 du kan eksplicit l\u00e5se i delingsmode.<\/p>\n
<\/p>\n
<\/p>\n
Du kan ogs\u00e5 oprette en unik indeks. Og der kan du se SHARE LOCK, som er en del af dem. Og den l\u00e5ser tabellen og s\u00e6tter en SHARE LOCK p\u00e5 den.<\/p>\n
<\/p>\n
Som standard betyder SHARE LOCK p\u00e5 tabellen, at andre kan l\u00e6se tabellen, men ingen kan \u00e6ndre den. Og det er pr\u00e6cis, hvad der sker, n\u00e5r du opretter en unik indeks.<\/strong><\/p>\n<\/p>\n
Hvis jeg opretter en unik concurrently indeks, s\u00e5 vil jeg have en anden type l\u00e5s, fordi, som du husker, reducerer brugen af concurrently indekser l\u00e5sekravene. Og hvis jeg bruger normal l\u00e5s, normal indeks, s\u00e5 forhindrer jeg dermed skrivning til indeks-tabellen under dens oprettelse. Hvis jeg bruger concurrently indeks, s\u00e5 skal jeg bruge en anden type l\u00e5s. <\/p>\n
<\/p>\n
<\/p>\n
SHARE ROW EXCLUSIVE \u2013 den kan igen angives eksplicit.<\/p>\n
<\/p>\n
<\/p>\n
Eller vi kan oprette en regel, dvs. tage en bestemt situation, hvor den vil blive brugt.<\/p>\n
<\/p>\n
<\/p>\n
EXCLUSIVE-l\u00e5s betyder, at ingen andre kan \u00e6ndre tabellen. <\/p>\n
<\/p>\n
<\/p>\n
Her ser vi forskellige typer l\u00e5se. <\/p>\n
<\/p>\n
<\/p>\n
ACCESS EXCLUSIVE, for eksempel, er en l\u00e5sekommando. For eksempel, hvis du laver CLUSTER table<\/code>, s\u00e5 betyder det, at ingen vil kunne skrive til det. Og den l\u00e5ser ikke kun selve tabellen, men ogs\u00e5 indeksene.<\/p>\n<\/p>\n
<\/p>\n
Dette er den anden side af ACCESS EXCLUSIVE-l\u00e5s, hvor vi pr\u00e6cist ser, hvad den l\u00e5ser i tabellen. Den l\u00e5ser individuelle r\u00e6kker i tabellen, hvilket er ret interessant.<\/p>\n
<\/p>\n
Dette er alle de grundl\u00e6ggende oplysninger, jeg \u00f8nskede at give. Vi har talt om blokeringer, om transaktions-ID'er, vi talte om virtuelle transaktions-ID'er, om permanente transaktions-ID'er. <\/p>\n
<\/p>\n
<\/p>\n
Og nu vil vi gennemg\u00e5 eksempler p\u00e5 blokeringer. Dette er den mest interessante del. Vi vil se p\u00e5 meget interessante tilf\u00e6lde. Og mit m\u00e5l med denne pr\u00e6sentation er at give dig en bedre forst\u00e5else af, hvad Postgres faktisk g\u00f8r, n\u00e5r det fors\u00f8ger at blokere visse ting. Jeg synes, det klarer at blokere individuelle dele meget godt. <\/p>\n
<\/p>\n
Lad os se p\u00e5 nogle konkrete eksempler.<\/p>\n
<\/p>\n
<\/p>\n
Vi starter med tabeller og en enkelt r\u00e6kke i tabellen. N\u00e5r jeg inds\u00e6tter noget, f\u00e5r jeg vist ExclusiveLock, transaktions-ID'et og ExclusiveLock p\u00e5 tabellen. <\/p>\n
<\/p>\n
<\/p>\n
Hvad sker der, hvis jeg inds\u00e6tter to r\u00e6kker mere? Og nu har vi tre r\u00e6kker i vores tabel. Jeg indsatte \u00e9n r\u00e6kke og fik dette som output. Og hvis jeg inds\u00e6tter to r\u00e6kker mere, hvad er der s\u00e5 m\u00e6rkeligt ved dette? Der er en underlighed, fordi jeg har tilf\u00f8jet tre r\u00e6kker til denne tabel, men jeg har stadig to r\u00e6kker i blokeringstabellen. Og det er i bund og grund det grundl\u00e6ggende adf\u00e6rdsm\u00f8nster i Postgres.<\/p>\n
<\/p>\n
Mange tror, at hvis du i databasen blokerer 100 r\u00e6kker, s\u00e5 skal du lave 100 blokeringer. Hvis jeg blokerer 1.000 r\u00e6kker p\u00e5 \u00e9n gang, s\u00e5 er jeg n\u00f8dt til at lave 1.000 s\u00e5danne foresp\u00f8rgsler. Og hvis jeg har brug for at blokere en million eller milliard. Men hvis vi g\u00f8r det, vil det ikke fungere s\u00e6rlig godt. Hvis du har brugt et system, der opretter blokeringer for hver enkelt r\u00e6kke, kan du se, at det er kompliceret. Fordi du skal definere blokeringstabellen p\u00e5 \u00e9n gang, som kan l\u00f8be over, men Postgres g\u00f8r ikke s\u00e5dan. <\/p>\n
<\/p>\n
Og p\u00e5 denne slide er det meget vigtigt, at det her tydeligt viser, at der er et andet system, der arbejder indenfor MVCC, som blokerer individuelle r\u00e6kker. Derfor, n\u00e5r du blokerer milliarder af r\u00e6kker, skaber Postgres ikke en milliard separate blokeringer. Og det p\u00e5virker ydeevnen meget positivt. <\/p>\n
<\/p>\n
<\/p>\n
Hvordan er det med opdatering? Jeg opdaterer lige nu en r\u00e6kke, og du kan m\u00e5ske bem\u00e6rke, at den straks udf\u00f8rte to forskellige operationer. Den har samtidig l\u00e5st tabellen, men den har ogs\u00e5 l\u00e5st indekset. Og den skulle l\u00e5se indekset, fordi der er unikke begr\u00e6nsninger p\u00e5 denne tabel. Vi vil sikre os, at ingen \u00e6ndrer det, derfor l\u00e5ser vi det.<\/p>\n
<\/p>\n
<\/p>\n
Hvad hvis jeg vil opdatere to r\u00e6kker? Og vi ser, at den opf\u00f8rer sig det samme. Vi udf\u00f8rer dobbelt s\u00e5 mange opdateringer, men det samme antal l\u00e5ser\u00e6kker. <\/p>\n
<\/p>\n
Hvis du er interesseret i, hvordan Postgres g\u00f8r det, skal du lytte til mine pr\u00e6sentationer om MVCC for at l\u00e6re, hvordan Postgres internt markerer de r\u00e6kker, den \u00e6ndrer. Og Postgres har en m\u00e5de, hvorp\u00e5 den g\u00f8r det, men den g\u00f8r det ikke p\u00e5 tabelniveau, men p\u00e5 et lavere og mere effektivt niveau.<\/p>\n
<\/p>\n
<\/p>\n
Og hvis jeg vil slette noget? Hvis jeg sletter for eksempel \u00e9n r\u00e6kke, og jeg stadig har mine to l\u00e5seindgange, s\u00e5 selvom jeg \u00f8nsker at slette dem alle, er de stadig der.<\/p>\n
<\/p>\n
<\/p>\n
For eksempel, hvis jeg vil inds\u00e6tte 1.000 r\u00e6kker, og derefter slette eller tilf\u00f8je 1.000 r\u00e6kker, s\u00e5 registreres de individuelle r\u00e6kker, jeg tilf\u00f8jer eller \u00e6ndrer, ikke her. De registreres p\u00e5 et lavere niveau inden i selve r\u00e6kken. Og under pr\u00e6sentationen om MVCC talte jeg om dette i detaljer. Men det er meget vigtigt, n\u00e5r du analyserer l\u00e5se, at sikre, at du har en l\u00e5s p\u00e5 tabelniveau, og at du ikke ser, hvordan individuelle r\u00e6kker registreres her. <\/p>\n
<\/p>\n
<\/p>\n
Hvad med eksplicit l\u00e5sning?<\/p>\n
<\/p>\n
<\/p>\n
Hvis jeg trykker p\u00e5 'opdater', har jeg to l\u00e5ste r\u00e6kker. Og hvis jeg markerer dem alle og trykker p\u00e5 'opdater alle', har jeg stadig to l\u00e5seposter tilbage. <\/p>\n
<\/p>\n
<\/p>\n
Vi opretter ikke separate poster for hver enkelt r\u00e6kke. For ellers falder ydeevnen, der kan blive for meget af det. Og vi kan havne i en uheldig situation. <\/p>\n
<\/p>\n
<\/p>\n
Og det samme, hvis vi g\u00f8r det shared, kan vi g\u00f8re det p\u00e5 alle 30 gange. <\/p>\n
<\/p>\n
<\/p>\n
Vi gendanner vores tabel, sletter alt, og s\u00e5 inds\u00e6tter vi \u00e9n r\u00e6kke igen.<\/p>\n
<\/p>\n
<\/p>\n
En anden opf\u00f8rsel, som du ser i Postgres, er en meget velkendt og \u00f8nsket adf\u00e6rd \u2013 det vil sige, at du kan udf\u00f8re update eller select. Og du kan g\u00f8re det samtidigt. Og select blokerer ikke update, og det samme g\u00e6lder omvendt. Vi siger, at l\u00e6seren ikke blokerer for den, der skriver, og den, der skriver, blokerer ikke l\u00e6seren. <\/p>\n
<\/p>\n
Jeg vil vise dig et eksempel p\u00e5 dette. Jeg vil nu lave et valg. Vi vil senere lave et INSERT. Og du vil derefter kunne se \u2013 694. Du vil kunne se ID for den transaktion, der udf\u00f8rte denne inds\u00e6ttelse. Og det er s\u00e5dan, det fungerer. <\/p>\n
<\/p>\n
<\/p>\n
Og hvis jeg nu kigger p\u00e5 mit backend ID, s\u00e5 er det blevet \u2013 695. <\/p>\n
<\/p>\n
<\/p>\n
Og jeg kan se, at 695 vises i min tabel. <\/p>\n
<\/p>\n
<\/p>\n
Og hvis jeg udf\u00f8rer en opdatering her p\u00e5 denne m\u00e5de, s\u00e5 f\u00e5r jeg et andet tilf\u00e6lde. I dette tilf\u00e6lde er 695 en eksklusiv l\u00e5s, og opdateringen har samme adf\u00e6rd, men der opst\u00e5r ikke konflikt mellem dem, hvilket er ret us\u00e6dvanligt. <\/p>\n
<\/p>\n
Og du kan bem\u00e6rke, at \u00f8verst \u2013 det er ShareLock, og nederst \u2013 det er ExclusiveLock. Og begge transaktioner blev gennemf\u00f8rt.<\/p>\n
<\/p>\n
Og du b\u00f8r lytte til mit foredrag om MVCC for at forst\u00e5, hvordan det sker. Men dette er en illustration af, at du kan g\u00f8re dette samtidigt, dvs. b\u00e5de udf\u00f8re SELECT og UPDATE.<\/p>\n
<\/p>\n
<\/p>\n
Lad os nulstille og lave en operation \u00e9n gang til. <\/p>\n
<\/p>\n
<\/p>\n
Hvis du pr\u00f8ver at k\u00f8re to updates p\u00e5 samme r\u00e6kke samtidigt, s\u00e5 vil det blive l\u00e5st. Og husk, jeg sagde, at l\u00e6seren ikke blokerer for skribenten, men skribenten blokerer for l\u00e6seren, men \u00e9n skribent blokerer en anden skribent. Det vil sige, at vi ikke kan have to personer, der samtidig opdaterer den samme r\u00e6kke. Vi skal vente, indtil en af \u200b\u200bdem er f\u00e6rdig. <\/p>\n
<\/p>\n
<\/p>\n
Og for at illustrere dette vil jeg kigge p\u00e5 Lockdemo-tabellen. Og vi vil se p\u00e5 \u00e9n r\u00e6kke. P\u00e5 transaktion 698.<\/p>\n
<\/p>\n
Vi opdaterede det til 2. 699 \u2013 det f\u00f8rste opdatering. Og det blev gennemf\u00f8rt med succes, eller det er i en ventende transaktion og venter p\u00e5, at vi bekr\u00e6fter eller annullerer. <\/p>\n
<\/p>\n
<\/p>\n
Men se p\u00e5 noget andet \u2013 2\/51 \u2013 det er vores f\u00f8rste transaktion, vores f\u00f8rste session. 3\/112 \u2013 det er den anden foresp\u00f8rgsel, der dukkede op ovenfor og som \u00e6ndrede denne v\u00e6rdi til 3. Og hvis du bem\u00e6rker, s\u00e5 blokerede den \u00f8verste sig selv, som er 699. Men 3\/112 gav ikke nogen blokering. I kolonnen Lock_mode st\u00e5r der, at den venter. Den venter p\u00e5 699. Og hvis du ser, hvor 699 er, er det ovenover. Og hvad gjorde den f\u00f8rste session? Den oprettede en eksklusiv blokering p\u00e5 sin egen transaktions-ID. Det er s\u00e5dan, Postgres g\u00f8r det. Den blokerer sin egen transaktions-ID. Og hvis du vil vente p\u00e5, at nogen bekr\u00e6fter eller annullerer, skal du vente, indtil der er en ventende transaktion. Og derfor kan vi se den m\u00e6rkelige linje. <\/p>\n
<\/p>\n
Lad os se p\u00e5 det igen. Til venstre ser vi vores behandlings-ID. I den anden kolonne ser vi vores virtuelle transaktions-ID, og i den tredje ser vi lock_type. Hvad betyder det? I bund og grund siger den, at den blokerer transaktions-ID'et. Men bem\u00e6rk, at der i alle r\u00e6kkerne nedenunder st\u00e5r relation. Og derfor har du to slags blokering i tabellen. Der er relation blokering. Og der er ogs\u00e5 transactionid blokering, hvor du blokerer dig selv, det er netop hvad der sker i den f\u00f8rste r\u00e6kke eller i bunden, hvor transationid er, hvor vi venter p\u00e5, at 699 afslutter sin operation. <\/p>\n
<\/p>\n
Jeg ser, hvad der sker her. Og der sker to ting p\u00e5 \u00e9n gang. Du ser p\u00e5 blokeringen af transaktions-ID'et i den f\u00f8rste r\u00e6kke, som blokerer sig selv. Og den blokerer sig selv for at f\u00e5 folk til at vente. <\/p>\n
<\/p>\n
Hvis du ser p\u00e5 den 6. r\u00e6kke, s\u00e5 er det samme optegnelse som den f\u00f8rste. Og derfor blokeres transaktion 699. 700 blokerer ogs\u00e5 sig selv. Og s\u00e5 vil du i den nederste r\u00e6kke se, at vi venter p\u00e5, at 699 afslutter sin operation.<\/p>\n
<\/p>\n
<\/p>\n
Og i lock_type, tuple kan du se numrene. <\/p>\n
<\/p>\n
<\/p>\n
Du kan se, at det er 0\/10. Og det er sidenummeret, og ogs\u00e5 offset for denne specifikke r\u00e6kke. <\/p>\n
<\/p>\n
<\/p>\n
Og du ser, at det bliver 0\/11, n\u00e5r vi opdaterer. <\/p>\n
<\/p>\n
<\/p>\n
Men i virkeligheden \u2013 det er 0\/10, fordi denne operation venter. Vi har mulighed for at se, at det er den r\u00e6kke, som jeg venter p\u00e5 at bekr\u00e6fte. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 snart vi bekr\u00e6fter det og klikker p\u00e5 commit, og n\u00e5r opdateringen er f\u00e6rdig, er dette, hvad vi f\u00e5r tilbage. Transaktion 700 er den eneste l\u00e5s, den venter ikke p\u00e5 nogen, fordi den er blevet bekr\u00e6ftet. Den venter blot p\u00e5, at transaktionen afsluttes. S\u00e5 snart 699 er f\u00e6rdig, venter vi ikke l\u00e6ngere. Og nu siger transaktion 700, at alt er i orden, at alle de n\u00f8dvendige l\u00e5se er tilg\u00e6ngelige i alle tilladte tabeller. <\/p>\n
<\/p>\n
<\/p>\n
Og for at g\u00f8re det hele endnu mere kompliceret, opretter vi endnu en view, der denne gang vil give os hierarkiet. Jeg forventer ikke, at du forst\u00e5r denne foresp\u00f8rgsel. Men det vil give os et klarere billede af, hvad der foreg\u00e5r. <\/p>\n
<\/p>\n
<\/p>\n
Dette er et rekursivt view, som ogs\u00e5 har endnu en sektion. Og det samler s\u00e5 alt sammen igen. Lad os bruge det. <\/p>\n
<\/p>\n
<\/p>\n
Hvad hvis vi laver tre samtidige opdateringer og siger, at r\u00e6kken nu er lig med tre. Og vi \u00e6ndrer 3 til 4. <\/p>\n
<\/p>\n
<\/p>\n
Og her ser vi 4. Og transaktions-ID 702. <\/p>\n
<\/p>\n
<\/p>\n
Og s\u00e5 \u00e6ndrer jeg 4 til 5. Og 5 til 6, og 6 til 7. Og jeg stiller en r\u00e6kke mennesker i k\u00f8, der venter p\u00e5, at denne ene transaktion bliver afsluttet.<\/p>\n
<\/p>\n
<\/p>\n
Og alt bliver klart. Hvad er den f\u00f8rste r\u00e6kke? Det er 702. Det er transaktions-ID'et, der oprindeligt satte denne v\u00e6rdi. Og hvad st\u00e5r der i kolonnen Granted? Jeg har bem\u00e6rkninger f<\/code>. Det er mine opdateringer, der (5, 6, 7) ikke kan godkendes, fordi vi venter p\u00e5, at transaktions-ID 702 afslutter. Der har vi en l\u00e5s p\u00e5 transaktions-ID. Og der resulterer i 5 transaktionsl\u00e5s-ID'er.<\/p>\n<\/p>\n
Og hvis du ser p\u00e5 704, p\u00e5 705, s\u00e5 er der stadig ikke skrevet noget, fordi de stadig ikke ved, hvad der foreg\u00e5r. De skriver bare, at de ikke aner, hvad der sker. Og de vil bare g\u00e5 i dvale, fordi de venter p\u00e5, at nogen afslutter og v\u00e6kker dem, n\u00e5r det bliver muligt at \u00e6ndre r\u00e6kken. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5dan ser det ud. Det er klart, at de alle venter p\u00e5 r\u00e6kke 12. <\/p>\n
<\/p>\n
<\/p>\n
Det er hvad vi s\u00e5 her. Her er 0\/12. <\/p>\n
<\/p>\n
<\/p>\n
Og s\u00e5 snart den f\u00f8rste transaktion er godkendt, kan du her se, hvordan hierarkiet fungerer. Og nu bliver alt klart. De alle bliver rene. Og de er faktisk stadig i venteposition. <\/p>\n
<\/p>\n
<\/p>\n
Dette er, hvad der sker. 702 begynder at committe. Og nu f\u00e5r 703 denne r\u00e6kke-l\u00e5s, og s\u00e5 begynder 704 at vente p\u00e5, at 703 committer. 705 venter ogs\u00e5 p\u00e5 dette. Og n\u00e5r det hele afsluttes, rydder de selv op. Jeg vil gerne p\u00e5pege, at alle stiller sig i k\u00f8. Det ligner meget en trafikprop, hvor alle venter p\u00e5 den f\u00f8rste bil. Den f\u00f8rste bil stopper, og alle stiller sig i en lang r\u00e6kke. S\u00e5 bev\u00e6ger den sig, hvorefter den n\u00e6ste bil kan k\u00f8re frem og f\u00e5 sin l\u00e5s osv. <\/p>\n
<\/p>\n
<\/p>\n
Og hvis du syntes, det var ikke kompliceret nok, s\u00e5 skal vi nu tale om deadlocks. Jeg ved ikke, hvem af jer der har oplevet dette. Det er et ret almindeligt problem i databasesystemer. Men deadlocks opst\u00e5r, n\u00e5r en session venter p\u00e5, at en anden session udf\u00f8rer noget. I mellemtiden venter den anden session p\u00e5, at den f\u00f8rste session udf\u00f8rer noget. <\/p>\n
<\/p>\n
For eksempel, hvis Ivan siger: \u201cGiv mig noget\u201d, og jeg siger: \u201cNej, jeg giver dig kun dette, hvis du giver mig noget andet\u201d. Og han siger: \u201cNej, jeg giver dig ikke dette, medmindre du giver mig\u201d. S\u00e5 ender vi i en d\u00f8d l\u00e5sesituation. Jeg er sikker p\u00e5, at Ivan ikke ville g\u00f8re det, men du forst\u00e5r pointen, at vi har to personer, der \u00f8nsker at f\u00e5 noget, og de er ikke villige til at give det, f\u00f8r den anden person giver dem, hvad de \u00f8nsker. Og der er ingen l\u00f8sning. <\/p>\n
<\/p>\n
I det v\u00e6sentlige skal din database opdage dette. Og s\u00e5 skal den lukke eller afslutte en af sessionerne, fordi ellers bliver de h\u00e6ngende der for evigt. Dette ser vi i databaser, vi ser det i operativsystemer. Og alle steder, hvor vi har parallelle processer, kan dette ske. <\/p>\n
<\/p>\n
<\/p>\n
Og nu vil vi s\u00e6tte to deadlocks. Vi vil s\u00e6tte 50 og 80. I f\u00f8rste r\u00e6kke vil jeg udf\u00f8re en opdatering fra 50 til 50. Jeg f\u00e5r transaktionsnummeret 710. <\/p>\n
<\/p>\n
<\/p>\n
Og s\u00e5 vil jeg \u00e6ndre 80 til 81, og 50 til 51. <\/p>\n
<\/p>\n
<\/p>\n
Og s\u00e5dan vil det se ud. Derfor har 710 en r\u00e6kke-l\u00e5s, og 711 venter p\u00e5 bekr\u00e6ftelse. Vi s\u00e5 det, da vi opdaterede. 710 er ejer af vores r\u00e6kke. Og 711 venter p\u00e5, at 710 afslutter transaktionen.<\/p>\n
<\/p>\n
<\/p>\n
Og der st\u00e5r endda angivet pr\u00e6cist p\u00e5 hvilken r\u00e6kke, vi oplever deadlocks. Og det er her, det begynder at blive m\u00e6rkeligt.<\/p>\n
<\/p>\n
<\/p>\n
Nu opdaterer vi 80 til 80. <\/p>\n
<\/p>\n
<\/p>\n
Og her begynder deadlocks. 710 venter p\u00e5 respons fra 711, mens 711 venter p\u00e5 710. Og dette vil ikke ende godt. Der er ingen vej ud. De vil vente p\u00e5 hinanden. <\/p>\n
<\/p>\n
<\/p>\n
Og det vil bare begynde at forsinke det hele. Det \u00f8nsker vi ikke. <\/p>\n
<\/p>\n
<\/p>\n
Og i Postgres er der m\u00e5der at opdage, n\u00e5r dette sker. N\u00e5r det sker, f\u00e5r du en fejl som denne. Det bliver klart, at en proces venter p\u00e5 en SHARE LOCK fra en anden proces, der blokkeres af proces 711. Den proces \u00f8nskede en SHARE LOCK p\u00e5 en given transaktions-ID og blev blokkeret af en anden proces. S\u00e5 her er der tale om en deadlock.<\/p>\n
<\/p>\n
<\/p>\n
Kan der v\u00e6re en trevej deadlock? Er det muligt? Ja. <\/p>\n
<\/p>\n
<\/p>\n
Vi indtaster disse tal i tabellen. Vi \u00e6ndrer 40 til 40, vi laver en blokering. <\/p>\n
<\/p>\n
<\/p>\n
\u00c6ndrer 60 til 61, 80 til 81. <\/p>\n
<\/p>\n
<\/p>\n
Og s\u00e5 \u00e6ndrer vi 80, og s\u00e5 \u2013 bam! <\/p>\n
<\/p>\n
<\/p>\n
Og 714 venter nu p\u00e5 715. 716 venter p\u00e5 715. Og der er ikke noget at g\u00f8re ved det.<\/p>\n
<\/p>\n
<\/p>\n
Her er der ikke blot to personer, men tre. Jeg \u00f8nsker noget fra dig, denne \u00f8nsker noget fra den tredje person, og den tredje person \u00f8nsker noget fra mig. Og vi ender i en trevejsventesituation, fordi vi alle venter p\u00e5, at den anden skal f\u00e6rdigg\u00f8re, hvad de skal g\u00f8re. <\/p>\n
<\/p>\n
<\/p>\n
Og Postgres ved, hvilken r\u00e6kke dette sker i. Derfor giver den dig den f\u00f8lgende besked, der viser, at du har et problem, hvor tre input blokerer hinanden. Og der er ingen begr\u00e6nsninger. Dette kan v\u00e6re i tilf\u00e6lde, hvor 20 optegnelser blokerer hinanden. <\/p>\n
<\/p>\n
<\/p>\n
Det n\u00e6ste problem er serializable. <\/p>\n
<\/p>\n
<\/p>\n
Hvis der er en s\u00e6rlig serializable blokering.<\/p>\n
<\/p>\n
<\/p>\n
Og vi vender tilbage til 719. Den har en helt normal udgave. <\/p>\n
<\/p>\n
<\/p>\n
Og du kan klikke for at g\u00f8re transaktionen serializable.<\/p>\n
<\/p>\n
<\/p>\n
Og du forst\u00e5r, at du nu har en anden form for blokering SA \u2013 det betyder serializable. <\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Derfor har vi en ny form for blokering, der kaldes SARieadLock, som er en serieblokering og tillader indt\u00e6gt af serier.<\/p>\n
<\/p>\n
<\/p>\n
Og du kan ogs\u00e5 inds\u00e6tte unikke indekser. <\/p>\n
<\/p>\n
<\/p>\n
I denne tabel har vi unikke indekser.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 hvis jeg indtaster tallet 2 her, har jeg 2. Men helt \u00f8verst inds\u00e6tter jeg endnu et 2. Og du kan se, at 721 har en eksklusiv l\u00e5s. Men nu venter 722 p\u00e5, at 721 skal f\u00e6rdigg\u00f8re sin operation, fordi den ikke kan inds\u00e6tte 2, f\u00f8r den ved, hvad der sker med 721. <\/p>\n
<\/p>\n
<\/p>\n
Og hvis vi laver en subtransaction.<\/p>\n
<\/p>\n
<\/p>\n
Her har vi 723.<\/p>\n
<\/p>\n
<\/p>\n
Og hvis vi gemmer punktet og derefter opdaterer det, f\u00e5r vi et nyt transaktions-ID. Dette er endnu en adf\u00e6rd, du skal kende til. Hvis vi returnerer dette, forsvinder transaktions-ID'et. 724 forsvinder. Men nu har vi 725. <\/p>\n
<\/p>\n
Og hvad pr\u00f8ver jeg at g\u00f8re her? Jeg pr\u00f8ver at vise dig eksempler p\u00e5 us\u00e6dvanlige l\u00e5se, som du kan finde: uanset om det er serializable l\u00e5se eller SAVEPOINT \u2013 disse er forskellige typer l\u00e5se, der vil blive vist i l\u00e5setabellen. <\/p>\n
<\/p>\n
<\/p>\n
Dette er oprettelsen af eksplicitte (\u00e5bne) l\u00e5se, hvor pg_advisory_lock. <\/p>\n
<\/p>\n
<\/p>\n
Og du kan se, at l\u00e5setypen her er angivet som advisory. Og det st\u00e5r med r\u00f8dt 'advisory'. Og du kan samtidig l\u00e5se med pg_advisory_unlock.<\/p>\n
<\/p>\n
<\/p>\n
Og for at afslutte vil jeg gerne vise dig endnu en fantastisk ting. Jeg vil lave en anden type. Men jeg vil forbinde tabellen pg_locks med tabellen pg_stat_activity. Og hvorfor vil jeg g\u00f8re dette? Fordi det vil give mig mulighed for at se og overv\u00e5ge alle nuv\u00e6rende sessioner og se, hvilke specifikke l\u00e5se de venter p\u00e5. Og det er ret interessant, n\u00e5r vi samler l\u00e5setabellen og foresp\u00f8rgsels-tabellen. <\/p>\n
<\/p>\n
<\/p>\n
Og her opretter vi pg_stat_view. <\/p>\n
<\/p>\n
<\/p>\n
Og vi opdaterer r\u00e6kken med \u00e9n. Og her ser vi 724. Og derefter opdaterer vi vores r\u00e6kke til tre. Og hvad ser du her nu? Dette er foresp\u00f8rgsler, alts\u00e5 ser du hele listen over foresp\u00f8rgsler, der er angivet i den venstre kolonne. Og derefter kan du se l\u00e5sene og hvad de skaber p\u00e5 h\u00f8jre side. Og dette kan v\u00e6re mere forst\u00e5eligt for dig, s\u00e5 du ikke beh\u00f8ver at vende tilbage til hver session hver gang for at se, om du skal tilslutte dig eller ej. Dette g\u00f8r de for os. <\/p>\n
<\/p>\n
En anden funktion, der er meget nyttig \u2013 er pg_blocking_pids<\/code>Du har nok aldrig h\u00f8rt om det. Hvad g\u00f8r det? Det tillader os at sige, at for denne session 11740, hvilke specifikke proces-ID'er den forventer. Og du kan se, at 11740 forventer 724. Og 724 er \u00f8verst. Mens 11306 er dit proces-ID. I bund og grund g\u00e5r denne funktion igennem din l\u00e5ntabel. Jeg ved, det er lidt sv\u00e6rt, men du f\u00e5r det til at forst\u00e5. I bund og grund g\u00e5r denne funktion gennem denne l\u00e5ntabel og fors\u00f8ger at finde, hvor dette proces-ID er, baseret p\u00e5 de l\u00e5sninger, den venter p\u00e5. Og det fors\u00f8ger ogs\u00e5 at beregne, hvilket specifikt proces-ID der tilh\u00f8rer den proces, der venter p\u00e5 l\u00e5sninger. Derfor kan du k\u00f8re denne funktion. pg_blocking_pids<\/code>.<\/p>\n<\/p>\n
Og det kan v\u00e6re meget nyttigt. Vi tilf\u00f8jede det f\u00f8rst med version 9.6, s\u00e5 denne funktion er kun fem \u00e5r gammel, men den er meget, meget nyttig. Det samme g\u00e6lder for den anden foresp\u00f8rgsel. Den viser pr\u00e6cist det, vi har brug for at se. <\/p>\n
<\/p>\n
<\/p>\n
Det er, hvad jeg ville tale med dig om. Og som jeg forventede, brugte vi al vores tid, fordi der var s\u00e5 mange dias. Diasene kan downloades. Jeg vil gerne takke dig for at du var her. Jeg er sikker p\u00e5, at du vil nyde resten af konferencen, tusind tak!<\/p>\n
<\/p>\n
Sp\u00f8rgsm\u00e5l:<\/p>\n
<\/p>\n
For eksempel, hvis jeg pr\u00f8ver at opdatere r\u00e6kkerne, mens den anden session pr\u00f8ver at slette hele tabellen. S\u00e5 vidt jeg forst\u00e5r, burde der v\u00e6re noget som en intent lock. Findes der noget s\u00e5dan i Postgres?<\/em><\/p>\n<\/p>\n
<\/p>\n
Lad os g\u00e5 tilbage til begyndelsen. M\u00e5ske husker du, at n\u00e5r du laver hvad som helst, for eksempel n\u00e5r du laver en SELECT, s\u00e5 giver vi en AccessShareLock. Og det forhindrer sletning af tabellen. Derfor, hvis du for eksempel vil opdatere en r\u00e6kke i tabellen eller slette en r\u00e6kke, s\u00e5 kan nogen ikke slette hele tabellen samtidig, fordi du holder denne AccessShareLock over hele tabellen og over r\u00e6kken. Og s\u00e5 snart du er f\u00e6rdig, kan de slette det. Men mens du direkte \u00e6ndrer noget der, kan de ikke g\u00f8re det.<\/p>\n
<\/p>\n
Lad os g\u00f8re det igen. Lad os g\u00e5 til eksemplet med sletning. Og du ser, hvordan der er en eksklusiv lock over hele tabellen p\u00e5 r\u00e6kken. <\/p>\n
<\/p>\n
Det vil se ud som en eksklusiv l\u00e5s, ikke?<\/em><\/p>\n<\/p>\n
Ja, det lyder som det. Jeg forst\u00e5r, hvad du siger. Du siger, at hvis jeg udf\u00f8rer SELECT, s\u00e5 f\u00e5r jeg ShareExclusive, og hvis jeg derefter \u00e6ndrer det til Row Exclusive, bliver det et problem? Men overraskende nok skaber det ikke et problem. Det ligner en stigende l\u00e5sningsgrad, men i bund og grund har jeg en l\u00e5s, der forhindrer sletning. Og nu, n\u00e5r jeg g\u00f8r denne l\u00e5s st\u00e6rkere, forhindrer den stadig sletning. S\u00e5 det er ikke s\u00e5dan, at jeg h\u00e6ver det. Det vil sige, den forhindrede det, selv da den var p\u00e5 et lavere niveau, s\u00e5 n\u00e5r jeg h\u00e6ver den, forhindrer den stadig sletning af tabellen. <\/p>\n
<\/p>\n
Jeg forst\u00e5r, hvad du siger. Der er ikke et tilf\u00e6lde af stigende l\u00e5sningsgrad, hvor du pr\u00f8ver at afgive \u00e9n l\u00e5s for at indf\u00f8re en mere kraftfuld. Her \u00f8ger det bare generelt forhindringen, s\u00e5 det for\u00e5rsager ingen konflikt. Men det er et godt sp\u00f8rgsm\u00e5l. Tak fordi du stillede det!<\/p>\n
<\/p>\n
Hvad skal vi g\u00f8re for at undg\u00e5 deadlock-situationer, n\u00e5r vi har mange sessioner og et stort antal brugere?<\/em><\/p>\n<\/p>\n
Postgres registrerer automatisk deadlock-situationer. Og vil automatisk fjerne en af sessionerne. Den eneste m\u00e5de at undg\u00e5 deadlock-situationen p\u00e5 er at l\u00e5se folk i den samme r\u00e6kkef\u00f8lge. S\u00e5 n\u00e5r du ser p\u00e5 din applikation, er \u00e5rsagen til deadlocks ofte... Lad os forestille os, at jeg vil l\u00e5se to forskellige ting. \u00c9n applikation l\u00e5ser tabel 1, mens en anden applikation l\u00e5ser tabel 2 og derefter tabel 1. Den nemmeste m\u00e5de at undg\u00e5 deadlocks p\u00e5 er at se p\u00e5 din applikation og s\u00f8rge for, at l\u00e5sningen sker i den samme r\u00e6kkef\u00f8lge i alle applikationer. Og det fjerner som regel 80 % af problemerne, fordi meget forskellige mennesker skriver disse applikationer. Og hvis du l\u00e5ser dem i den samme r\u00e6kkef\u00f8lge, s\u00e5 st\u00e5r du ikke over for en deadlock-situation.<\/p>\n
<\/p>\n
Mange tak for dit indl\u00e6g! Du talte om vacuum full, og hvis jeg forst\u00e5r det korrekt, omformer vacuum full r\u00e6kkef\u00f8lgen af poster i det enkelte opbevaringsomr\u00e5de, s\u00e5 de nuv\u00e6rende poster forbliver u\u00e6ndrede. Men hvorfor tager vacuum full en eksklusiv l\u00e5s, og hvorfor kommer det i konflikt med skriveoperationer?<\/em><\/p>\n<\/p>\n
Det er et godt sp\u00f8rgsm\u00e5l. \u00c5rsagen er, at vacuum full tager tabellen. Og vi skaber i princippet en ny version af tabellen. Tabellen vil v\u00e6re ny. Det resulterer i, at det bliver en helt ny version af tabellen. Og problemet er, at n\u00e5r vi g\u00f8r det, vil vi ikke have, at folk l\u00e6ser det, fordi vi har brug for, at de ser den nye tabel. Og derfor h\u00e6nger det sammen med det tidligere sp\u00f8rgsm\u00e5l. Hvis vi kunne l\u00e6se samtidig, ville vi ikke kunne flytte det og dirigere folk til den nye tabel. Vi ville v\u00e6re n\u00f8dt til at vente, indtil alle f\u00e6rdiggjorde med at l\u00e6se denne tabel, og derfor, i princippet, er det en eksklusiv l\u00e5sesituation.
<\/p>\n
Er det muligt at tilf\u00f8je locking timeout i Postgres? I Oracle kan jeg for eksempel skrive 'v\u00e6lg til opdatering' og vente 50 sekunder f\u00f8r opdateringen. Det var godt for applikationen. Men i Postgres skal jeg enten g\u00f8re det med det samme og slet ikke vente, eller vente i en vis tid.<\/em> <\/p>\n<\/p>\n
Ja, du kan v\u00e6lge timeout for dine l\u00e5s. Du kan ogs\u00e5 give kommandoen no way, som vil v\u00e6re ..., hvis du ikke kan f\u00e5 l\u00e5sen med det samme. S\u00e5 enten lock timeout eller noget andet, der giver dig mulighed for at g\u00f8re det. Det g\u00f8res ikke p\u00e5 syntaksniveau. Det g\u00f8res som en variabel p\u00e5 serveren. Nogle gange kan det ikke bruges.<\/p>\n
<\/p>\n
Kan du \u00e5bne 75. slide?<\/em> <\/p>\n<\/p>\n
Ja.<\/p>\n
<\/p>\n
<\/p>\n
Og mit sp\u00f8rgsm\u00e5l er f\u00f8lgende. Hvorfor venter begge opdateringsprocesser p\u00e5 703?<\/em><\/p>\n<\/p>\n
Og det er et fantastisk sp\u00f8rgsm\u00e5l. Jeg forst\u00e5r ikke, hvorfor Postgres g\u00f8r det. Men da 703 blev oprettet, forventede den 702. Og n\u00e5r 704 og 705 dukker op, ser det ud til, at de ikke ved, hvad de venter p\u00e5, fordi der ikke er noget der endnu. Og Postgres g\u00f8r det s\u00e5dan: n\u00e5r du ikke kan f\u00e5 en l\u00e5s, s\u00e5 siger den \"Hvad er meningen med at behandle dig?\", fordi du allerede venter p\u00e5 nogen. S\u00e5 lad os bare lade det h\u00e6nge i luften, det opdaterer slet ikke. Men hvad skete der her? S\u00e5 snart 702 afsluttede processen, og 703 fik sin l\u00e5s, gik systemet tilbage. Og sagde, at nu har vi to personer, der venter. S\u00e5 lad os opdatere dem sammen. Og indikere, at begge venter. <\/p>\n
<\/p>\n
Jeg ved ikke, hvorfor Postgres g\u00f8r det. Men der er et problem, der kaldes f\u2026. Jeg tror, det ikke er et term p\u00e5 russisk. Det er, n\u00e5r alle venter p\u00e5 en l\u00e5s, selvom der er 20 instanser, der venter p\u00e5 l\u00e5sen. Og pludselig v\u00e5gner de alle op samtidigt. Og alle begynder at fors\u00f8ge at reagere. Men systemet g\u00f8r det s\u00e5dan, at alle venter p\u00e5 703. Fordi de alle venter, s\u00e5 stiller vi dem straks i k\u00f8. Og hvis der dukker en anden ny anmodning op, som blev dannet efter dette, for eksempel 707, s\u00e5 vil der igen v\u00e6re tomhed. <\/p>\n
<\/p>\n
Og jeg tror, det g\u00f8res, s\u00e5 vi kan sige, at p\u00e5 dette tidspunkt venter 702 p\u00e5 703, og alle dem, der kommer efter dette, vil ikke have nogen registrering i dette felt. Men s\u00e5 snart den f\u00f8rste ventende forlader, f\u00e5r alle dem, der ventede p\u00e5 det tidspunkt op til opdateringen, den samme mark\u00f8r. Og derfor tror jeg, det er gjort, s\u00e5 vi kan behandle i r\u00e6kkef\u00f8lge, s\u00e5 de bliver korrekt ordnet. <\/p>\n
<\/p>\n
Jeg har altid set p\u00e5 dette som et ret m\u00e6rkeligt f\u00e6nomen. Fordi her n\u00e6vner vi for eksempel slet ikke dem. Men jeg f\u00f8ler, hver gang vi giver en ny lock, ser vi p\u00e5 alle dem, der er i ventemodus. S\u00e5 stiller vi dem alle i k\u00f8. Og derefter kommer enhver ny, som ankommer, kun i k\u00f8, n\u00e5r den n\u00e6ste person er f\u00e6rdig med at blive behandlet. Meget godt sp\u00f8rgsm\u00e5l. Tak fordi du stillede sp\u00f8rgsm\u00e5let!<\/p>\n
<\/p>\n
Jeg synes, det er meget mere logisk, n\u00e5r 705 venter p\u00e5 704.<\/em> <\/p>\n<\/p>\n
Men problemet er f\u00f8lgende. Teknisk set kan du v\u00e6kke enten den ene eller den anden. Og derfor v\u00e6kker vi den ene eller den anden. Men hvad sker der i systemets arbejde? Du kan se, at 703 \u00f8verst har l\u00e5st sin egen transaktions-ID. Det er, hvordan Postgres fungerer. Og 703 l\u00e5ses af sin egen transaktions-ID, s\u00e5 hvis nogen vil vente, s\u00e5 venter de p\u00e5 703. Og i det v\u00e6sentlige afslutter 703. Og f\u00f8rst efter at den er afsluttet, bliver en af processerne v\u00e6kket. Og vi ved ikke, hvilken proces det bliver. Derefter behandler vi langsomt alle. Men det er uklart, hvilken proces der v\u00e6kkes f\u00f8rst, fordi det kan v\u00e6re en hvilken som helst af disse processer. I bund og grund havde vi en scheduler, der sagde, at vi nu kan v\u00e6kke en hvilken som helst af disse processer. Vi v\u00e6lger bare en tilf\u00e6ldigt. Derfor skal begge markeres, fordi vi kan v\u00e6kke en hvilken som helst af dem. <\/p>\n
<\/p>\n
Og problemet er, at vi har CP-uendelighed. Og derfor kan vi meget vel v\u00e6kke den senere. Og hvis vi for eksempel v\u00e6kker den senere, s\u00e5 vil vi vente p\u00e5 den, der netop har f\u00e5et l\u00e5sen, s\u00e5 vi kan ikke bestemme, hvem der pr\u00e6cist bliver v\u00e6kket f\u00f8rst. Vi skaber simpelthen en s\u00e5dan situation, og systemet vil v\u00e6kke dem i vilk\u00e5rlig r\u00e6kkef\u00f8lge. <\/p>\n
<\/p>\n
Der er artikler om locks af Yegor Rogov<\/a><\/noindex>. Se, de er ogs\u00e5 interessante og nyttige. Emnet er selvf\u00f8lgelig skr\u00e6mmende komplekst. Mange tak, 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