http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex><\/p>\n<\/p>\n
Vi ser. Nummeret f\u00f6r transaktionen \u00e4r framh\u00e4vt i r\u00f6d f\u00e4rg. H\u00e4r visas funktionen SELECT pg_back. Den returnerar min transaktion och ID f\u00f6r denna transaktion. <\/p>\n
<\/p>\n
En annan sak, om du gillar den h\u00e4r presentationen och vill k\u00f6ra den i din databas, kan du f\u00f6lja den rosa markerade l\u00e4nken och ladda ner SQL f\u00f6r den h\u00e4r presentationen. Och du kan enkelt k\u00f6ra den i din PSQL s\u00e5 kommer hela presentationen att dyka upp p\u00e5 din sk\u00e4rm omedelbart. Den kommer inte att inneh\u00e5lla f\u00e4rger, men i alla fall kan vi se den.<\/p>\n
<\/p>\n
<\/p>\n
I det h\u00e4r fallet ser vi transaktions-ID:t. Det \u00e4r numret som vi tilldelade den. Det finns ocks\u00e5 en annan typ av transaktions-ID i Postgres som kallas virtuellt transaktions-ID.<\/p>\n
<\/p>\n
Och vi m\u00e5ste f\u00f6rst\u00e5 detta. Det \u00e4r mycket viktigt, annars kan vi inte f\u00f6rst\u00e5 l\u00e5sning i Postgres.<\/p>\n
<\/p>\n
Virtuellt transaktions-ID \u00e4r ett transaktions-ID som inte inneh\u00e5ller permanenta v\u00e4rden. Till exempel, om jag k\u00f6r ett SELECT-kommando, kommer jag troligen inte att \u00e4ndra databasen, jag kommer inte att blockera n\u00e5got. D\u00e4rf\u00f6r, n\u00e4r vi k\u00f6r ett enkelt SELECT, tilldelar vi inte denna transaktion ett permanent ID. Vi ger den bara ett virtuellt ID.<\/p>\n
<\/p>\n
Och detta \u00f6kar prestationen i Postgres, f\u00f6rb\u00e4ttrar m\u00f6jligheterna f\u00f6r rensning, s\u00e5 virtuellt transaktions-ID best\u00e5r av tv\u00e5 nummer. Det f\u00f6rsta numret f\u00f6re snedstrecket \u00e4r backend-ID:t. Och till h\u00f6ger ser vi bara en r\u00e4knare.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 n\u00e4r jag k\u00f6r en fr\u00e5ga, s\u00e4ger det att backend-ID:t \u00e4r 2. <\/p>\n
<\/p>\n
<\/p>\n
Och om jag k\u00f6r en serie s\u00e5dana transaktioner ser vi att r\u00e4knaren \u00f6kar varje g\u00e5ng jag k\u00f6r en fr\u00e5ga. Till exempel n\u00e4r jag k\u00f6r fr\u00e5ga 2\/10, 2\/11, 2\/12 och s\u00e5 vidare. <\/p>\n
<\/p>\n
<\/p>\n
Observera att det finns tv\u00e5 kolumner h\u00e4r. Till v\u00e4nster ser vi det virtuella transaktions-ID:t - 2\/12. Och till h\u00f6ger har vi det permanenta transaktions-ID:t. Och detta f\u00e4lt \u00e4r tomt. Denna transaktion modifierar inte databasen. D\u00e4rf\u00f6r tilldelar jag den inte ett permanent transaktions-ID.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 snart jag k\u00f6r kommandot analysera (ANALYZE), ger samma fr\u00e5ga mig ett permanent transaktions-ID. Se hur detta har f\u00f6r\u00e4ndrats. Tidigare hade jag inte detta ID, nu har jag det.<\/p>\n
<\/p>\n
<\/p>\n
Och h\u00e4r \u00e4r \u00e4nnu en fr\u00e5ga, ytterligare en transaktion. Det virtuella transaktionsnumret - 2\/13. Och om jag beg\u00e4r det permanenta transaktions-ID:t, f\u00e5r jag det n\u00e4r jag k\u00f6r fr\u00e5gan. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5, \u00e4nnu en g\u00e5ng. Vi har det virtuella transaktions-ID:t och det permanenta transaktions-ID:t. F\u00f6rst\u00e5 detta f\u00f6r att f\u00f6rst\u00e5 Postgres beteende.<\/p>\n
<\/p>\n
<\/p>\n
Vi g\u00e5r vidare till den tredje delen. H\u00e4r kommer vi att g\u00e5 igenom de olika typerna av l\u00e5s i Postgres. Det \u00e4r inte s\u00e5 intressant. Den sista delen kommer att vara mycket mer sp\u00e4nnande. Men vi m\u00e5ste t\u00e4cka de grundl\u00e4ggande sakerna, annars kommer vi inte att f\u00f6rst\u00e5 vad som kommer h\u00e4rn\u00e4st. <\/p>\n
<\/p>\n
Vi kommer att g\u00e5 igenom denna del, vi kommer att titta p\u00e5 varje typ av l\u00e5s. Och jag kommer att visa er exempel p\u00e5 hur de s\u00e4tts, hur de fungerar, och ge er n\u00e5gra fr\u00e5gor som ni kan anv\u00e4nda f\u00f6r att se hur l\u00e5s fungerar i Postgres.<\/p>\n
<\/p>\n
<\/p>\n
F\u00f6r att skapa en fr\u00e5ga och se vad som h\u00e4nder i Postgres, beh\u00f6ver vi utf\u00f6ra en fr\u00e5ga i systemvyn. I det h\u00e4r fallet har vi markerat pg_lock med r\u00f6d f\u00e4rg. Pg_lock \u00e4r en systemtabell som ber\u00e4ttar f\u00f6r oss vilka l\u00e5s som f\u00f6r n\u00e4rvarande anv\u00e4nds i Postgres.<\/p>\n
<\/p>\n
Det \u00e4r dock v\u00e4ldigt sv\u00e5rt f\u00f6r mig att visa er pg_lock som det \u00e4r, eftersom det \u00e4r ganska komplicerat. D\u00e4rf\u00f6r har jag skapat en vy som visar pg_locks. Den utf\u00f6r ocks\u00e5 lite arbete f\u00f6r mig som hj\u00e4lper mig att f\u00f6rst\u00e5 b\u00e4ttre. Det vill s\u00e4ga att den exkluderar mina l\u00e5s, min egen session och s\u00e5 vidare. Det \u00e4r bara standard SQL och det g\u00f6r att jag b\u00e4ttre kan visa er vad som h\u00e4nder. <\/p>\n
<\/p>\n
<\/p>\n
En annan utmaning \u00e4r att denna vy \u00e4r v\u00e4ldigt bred, s\u00e5 jag beh\u00f6ver skapa en andra vy \u2013 lockview2.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 vi har skapat en tabell som heter Lockdemo. D\u00e4r har vi skapat en rad. Det \u00e4r v\u00e5r provtabell. Och vi kommer att skapa avsnitt f\u00f6r att bara visa er exempel p\u00e5 l\u00e5s. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 en rad, en kolumn. Den f\u00f6rsta typen av l\u00e5s kallas ACCESS SHARE. Det \u00e4r den minst begr\u00e4nsande l\u00e5set. Det betyder att den praktiskt taget inte konfliktar med andra l\u00e5s.<\/p>\n
<\/p>\n
Och om vi vill explicit definiera l\u00e5sningen k\u00f6r vi kommandot \u00ablock table\u00bb. Och det kommer tydligt att l\u00e5sa, det vill s\u00e4ga i ACCESS SHARE-l\u00e4ge k\u00f6r vi lock table. Och om jag k\u00f6r PSQL i bakgrunden, s\u00e5 startar jag p\u00e5 det s\u00e4ttet en andra session fr\u00e5n min f\u00f6rsta session. Vad g\u00f6r jag h\u00e4r? Jag g\u00e5r till en annan session och s\u00e4ger till den \u00abvisa mig lockview f\u00f6r denna f\u00f6rfr\u00e5gan\u00bb. Och h\u00e4r har jag AccessShareLock i denna tabell. Det \u00e4r precis vad jag beg\u00e4rde. Och den s\u00e4ger att l\u00e5sningen har tilldelats. Mycket enkelt. <\/p>\n
<\/p>\n
<\/p>\n
Vidare, om vi tittar p\u00e5 den andra kolumnen, s\u00e5 finns det inget d\u00e4r. De \u00e4r tomma. <\/p>\n
<\/p>\n
<\/p>\n
Och om jag k\u00f6r kommandot \u00abSELECT\u00bb, s\u00e5 \u00e4r det ett implicerat (explicit) s\u00e4tt att beg\u00e4ra AccessShareLock. S\u00e5 jag sl\u00e4pper min tabell och k\u00f6r f\u00f6rfr\u00e5gan, och f\u00f6rfr\u00e5gan returnerar flera rader. Och i en av raderna ser vi AccessShareLock. S\u00e5ledes anropar SELECT AccessShareLock i tabellen. Och den konflikerar praktiskt taget inte med n\u00e5got, eftersom det \u00e4r en l\u00e5sning av l\u00e5g niv\u00e5. <\/p>\n
<\/p>\n
<\/p>\n
Vad h\u00e4nder om jag k\u00f6r SELECT och har tre olika tabeller? Tidigare k\u00f6rde jag bara en tabell, nu k\u00f6r jag tre: pg_class, pg_namespace och pg_attribute.<\/p>\n
<\/p>\n
<\/p>\n
Och nu n\u00e4r jag tittar p\u00e5 f\u00f6rfr\u00e5gan, ser jag 9 AccessShareLocks i tre tabeller. Varf\u00f6r? Tre tabeller markeras med bl\u00e5tt: pg_attribute, pg_class, pg_namespace. Men du kan ocks\u00e5 se att alla index som definieras genom dessa tabeller ocks\u00e5 har AccessShareLock.<\/p>\n
<\/p>\n
Och det \u00e4r en l\u00e5sning som praktiskt taget inte konflikterar med andra. Och allt den g\u00f6r \u00e4r att helt enkelt f\u00f6rhindra oss fr\u00e5n att \u00e5terst\u00e4lla tabellen s\u00e5 l\u00e4nge vi v\u00e4ljer den. Det har mening. Det vill s\u00e4ga, om vi v\u00e4ljer en tabell och den f\u00f6rsvinner just d\u00e5, s\u00e5 \u00e4r det fel, s\u00e5 AccessShare \u2013 \u044d\u0442\u043e \u0431\u043b\u043e\u043a\u0438\u0440\u043e\u0432\u043a\u0430 \u043d\u0438\u0437\u043a\u043e\u0433\u043e \u0443\u0440\u043e\u0432\u043d\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c "\u043d\u0435 \u0443\u0434\u0430\u043b\u044f\u0439\u0442\u0435 \u044d\u0442\u0443 \u0442\u0430\u0431\u043b\u0438\u0446\u0443, \u043f\u043e\u043a\u0430 \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u044e"<\/strong>. I sj\u00e4lva verket \u00e4r det allt den g\u00f6r. <\/p>\n<\/p>\n
<\/p>\n
ROW SHARE \u2013 det \u00e4r en l\u00e5sning som \u00e4r lite annorlunda. <\/p>\n
<\/p>\n
<\/p>\n
L\u00e5t oss ta ett exempel. SELECT ROW SHARE \u00e4r ett s\u00e4tt att l\u00e5sa varje rad f\u00f6r sig<\/strong>. S\u00e5ledes kan ingen ta bort dem eller \u00e4ndra dem medan vi ser p\u00e5 dem. <\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
H\u00e4r s\u00e4ger vi att l\u00e5sning anv\u00e4nds av oss.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5, exklusiv l\u00e5sning s\u00e4ger explicit att den \u00e4r exklusiv. Och ocks\u00e5, om du tar bort en rad i denna tabell, s\u00e5 kommer det att h\u00e4nda, som du kan se. <\/p>\n
<\/p>\n
<\/p>\n
SHARE EXCLUSIVE \u2013 det \u00e4r en l\u00e4ngre l\u00e5sning.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Detta (ANALYZE) \u00e4r en analyskommando som kommer att anv\u00e4ndas.<\/p>\n
<\/p>\n
<\/p>\n
SHARE LOCK \u2013 du kan explicit l\u00e5sa i delat l\u00e4ge.<\/p>\n
<\/p>\n
<\/p>\n
Du kan ocks\u00e5 skapa en unik index. Och d\u00e4r kan du se SHARE LOCK, som \u00e4r en del av dem. och det l\u00e5ser tabellen och s\u00e4tter ett SHARE LOCK p\u00e5 den.<\/p>\n
<\/p>\n
Som standard betyder SHARE LOCK p\u00e5 tabellen att andra kan l\u00e4sa tabellen, men ingen kan modifiera den. Och det \u00e4r vad som h\u00e4nder n\u00e4r du skapar en unik index.<\/strong><\/p>\n<\/p>\n
Om jag skapar en unik concurrent index, s\u00e5 kommer jag att ha en annan typ av l\u00e5sning, eftersom, som du kommer ih\u00e5g, att anv\u00e4nda concurrent index minskar l\u00e5skravet. Och om jag anv\u00e4nder normal l\u00e5sning, normal index, s\u00e5 hindrar jag p\u00e5 s\u00e5 s\u00e4tt skrivandet i indexet under skapandet. Om jag anv\u00e4nder concurrent index, s\u00e5 m\u00e5ste jag anv\u00e4nda en annan typ av l\u00e5sning. <\/p>\n
<\/p>\n
<\/p>\n
SHARE ROW EXCLUSIVE \u2013 \u00e4n en g\u00e5ng kan den anges explicit.<\/p>\n
<\/p>\n
<\/p>\n
Eller s\u00e5 kan vi skapa en regel, dvs. ta ett visst fall d\u00e4r den kommer att anv\u00e4ndas.<\/p>\n
<\/p>\n
<\/p>\n
EXCLUSIVE l\u00e5sning betyder att ingen annan kan \u00e4ndra tabellen. <\/p>\n
<\/p>\n
<\/p>\n
H\u00e4r ser vi olika typer av l\u00e5sningar. <\/p>\n
<\/p>\n
<\/p>\n
ACCESS EXCLUSIVE, till exempel, \u00e4r en l\u00e5sningskommando. Till exempel, om du g\u00f6r CLUSTER table<\/code>, s\u00e5 kommer det att betyda att ingen kan skriva dit. Och den l\u00e5ser inte bara sj\u00e4lva tabellen, utan ocks\u00e5 indexen.<\/p>\n<\/p>\n
<\/p>\n
Detta \u00e4r den andra sidan av ACCESS EXCLUSIVE-l\u00e5sning, d\u00e4r vi ser specifikt vad den l\u00e5ser i tabellen. Den l\u00e5ser individuella rader i tabellen, vilket \u00e4r ganska intressant.<\/p>\n
<\/p>\n
Det h\u00e4r \u00e4r all grundl\u00e4ggande information som jag ville ge. Vi har pratat om l\u00e5s, transaktions-ID, virtuella transaktions-ID och permanenta transaktions-ID. <\/p>\n
<\/p>\n
<\/p>\n
Och nu ska vi g\u00e5 igenom exempel p\u00e5 l\u00e5s. Detta \u00e4r den mest intressanta delen. Vi kommer att titta p\u00e5 v\u00e4ldigt intressanta fall. Min uppgift i den h\u00e4r presentationen \u00e4r att ge er en b\u00e4ttre f\u00f6rst\u00e5else f\u00f6r vad Postgres faktiskt g\u00f6r n\u00e4r det f\u00f6rs\u00f6ker l\u00e5sa olika saker. Jag tycker att det \u00e4r mycket bra p\u00e5 att l\u00e5sa specifika delar. <\/p>\n
<\/p>\n
L\u00e5t oss titta p\u00e5 vissa exempel.<\/p>\n
<\/p>\n
<\/p>\n
Vi b\u00f6rjar med tabeller och en rad i tabellen. N\u00e4r jag s\u00e4tter in n\u00e5got visas ExclusiveLock, transaktions-ID och ExclusiveLock p\u00e5 tabellen. <\/p>\n
<\/p>\n
<\/p>\n
Vad h\u00e4nder om jag s\u00e4tter in ytterligare tv\u00e5 rader? Och nu har vi tre rader i v\u00e5r tabell. Jag satte in en rad och fick detta som utdata. Och om jag s\u00e4tter in ytterligare tv\u00e5 rader, vad \u00e4r konstigt h\u00e4r? H\u00e4r finns det en konstighet, f\u00f6r jag har lagt till tre rader till denna tabell, men jag har fortfarande tv\u00e5 rader i l\u00e5stabellen. Och det \u00e4r i grunden Postgres grundl\u00e4ggande beteende.<\/p>\n
<\/p>\n
M\u00e5nga tror att om du blockerar 100 rader i databasen, s\u00e5 kommer du beh\u00f6va skapa 100 l\u00e5spostningar. Om jag blockerar 1 000 rader p\u00e5 en g\u00e5ng, s\u00e5 beh\u00f6ver jag 1 000 s\u00e5dana f\u00f6rfr\u00e5gningar. Och om jag beh\u00f6ver blockera en miljon eller en miljard. Men om vi g\u00f6r s\u00e5, kommer det inte fungera s\u00e4rskilt bra. Om du har anv\u00e4nt ett system som skapar l\u00e5sposter f\u00f6r varje enskild rad s\u00e5 ser du att det \u00e4r komplicerat. F\u00f6r du m\u00e5ste definiera l\u00e5stabellen med en g\u00e5ng, och den kan bli \u00f6verfull. Men Postgres g\u00f6r inte s\u00e5. <\/p>\n
<\/p>\n
Och p\u00e5 det h\u00e4r bilden \u00e4r det mycket viktigt att det tydligt visas att det finns ytterligare ett system som arbetar inom MVCC, som l\u00e5ser enskilda rader. S\u00e5 n\u00e4r du blockerar miljarder rader, skapar Postgres inte en miljard separata l\u00e5sningar. Och det p\u00e5verkar prestandan mycket positivt. <\/p>\n
<\/p>\n
<\/p>\n
Hur \u00e4r det med uppdateringen? Jag uppdaterar just nu en rad, och du kanske m\u00e4rker att den omedelbart utf\u00f6rde tv\u00e5 olika operationer. Den blockerade tabellen, men den blockerade ocks\u00e5 indexet. Det var n\u00f6dv\u00e4ndigt att blockera indexet eftersom det finns unika begr\u00e4nsningar p\u00e5 denna tabell. Vi vill s\u00e4kerst\u00e4lla att ingen \u00e4ndrar det, s\u00e5 vi blockerar det.<\/p>\n
<\/p>\n
<\/p>\n
Vad h\u00e4nder om jag vill uppdatera tv\u00e5 rader? Och vi ser att den beter sig likadant. Vi genomf\u00f6r dubbelt s\u00e5 m\u00e5nga uppdateringar, men exakt samma antal radblockeringar. <\/p>\n
<\/p>\n
Om du undrar hur Postgres g\u00f6r detta, beh\u00f6ver du lyssna p\u00e5 mina presentationer om MVCC f\u00f6r att f\u00f6rst\u00e5 hur Postgres internt m\u00e4rker dessa rader som den \u00e4ndrar. Och Postgres har ett s\u00e4tt att g\u00f6ra detta p\u00e5, men det g\u00f6rs inte p\u00e5 tabellblockeringsniv\u00e5; det g\u00f6rs p\u00e5 en l\u00e4gre och mer effektiv niv\u00e5.<\/p>\n
<\/p>\n
<\/p>\n
Men vad h\u00e4nder om jag vill ta bort n\u00e5got? Om jag tar bort till exempel en rad och jag fortfarande har mina tv\u00e5 l\u00e5s kvar, \u00e4ven om jag skulle vilja ta bort dem allihop, kommer de fortfarande att finnas d\u00e4r.<\/p>\n
<\/p>\n
<\/p>\n
Och till exempel, om jag vill infoga 1 000 rader och sedan antingen ta bort eller l\u00e4gga till 1 000 rader, s\u00e5 skrivs de individuella raderna som jag l\u00e4gger till eller \u00e4ndrar inte h\u00e4r. De skrivs till en l\u00e4gre niv\u00e5 inne i sj\u00e4lva raden. Under presentationen om MVCC pratade jag om detta i detalj. Men det \u00e4r mycket viktigt, n\u00e4r du analyserar blockeringar, att s\u00e4kerst\u00e4lla att du har blockering p\u00e5 tabellniv\u00e5 och att du h\u00e4r inte ser hur individuella rader skrivs. <\/p>\n
<\/p>\n
<\/p>\n
Vad s\u00e4gs om explicit blockering?<\/p>\n
<\/p>\n
<\/p>\n
Om jag trycker p\u00e5 'uppdatera', s\u00e5 har jag tv\u00e5 l\u00e5sta rader. Och om jag v\u00e4ljer alla och trycker p\u00e5 'uppdatera \u00f6verallt', s\u00e5 har jag fortfarande tv\u00e5 blockinspelningar. <\/p>\n
<\/p>\n
<\/p>\n
Vi skapar inte separata poster f\u00f6r varje enskild rad. F\u00f6r annars sjunker prestandan, och det kan bli f\u00f6r mycket. Vi kan hamna i en obehaglig situation. <\/p>\n
<\/p>\n
<\/p>\n
Och samma sak g\u00e4ller om vi g\u00f6r p\u00e5 delad niv\u00e5, vi kan g\u00f6ra det 30 g\u00e5nger. <\/p>\n
<\/p>\n
<\/p>\n
Vi \u00e5terst\u00e4ller v\u00e5r tabell, raderar allt, och sedan l\u00e4gger vi igen till en rad.<\/p>\n
<\/p>\n
<\/p>\n
En annan typ av beteende som du ser i Postgres \u00e4r det mycket v\u00e4lk\u00e4nda och \u00f6nskv\u00e4rda beteendet \u2013 det \u00e4r att du kan utf\u00f6ra en update eller select. Och du kan g\u00f6ra detta samtidigt. Och select blockerar inte update och vice versa. Vi s\u00e4ger till l\u00e4saren att inte blockera den som skriver, och den som skriver blockerar inte l\u00e4saren. <\/p>\n
<\/p>\n
Jag ska visa dig ett exempel p\u00e5 detta. Jag kommer nu att g\u00f6ra ett val. Sedan kommer vi att g\u00f6ra en INSERT. Och du kommer att kunna se \u2013 694. Du kommer att se ID f\u00f6r transaktionen som gjorde denna ins\u00e4ttning. Och s\u00e5 h\u00e4r fungerar det. <\/p>\n
<\/p>\n
<\/p>\n
Och om jag nu tittar p\u00e5 min backend-ID, s\u00e5 har den blivit \u2013 695. <\/p>\n
<\/p>\n
<\/p>\n
Och jag kan se att 695 visas i min tabell. <\/p>\n
<\/p>\n
<\/p>\n
Och om jag g\u00f6r en uppdatering h\u00e4r s\u00e5 h\u00e4r, f\u00e5r jag ett annat fall. I detta fall \u00e4r 695 en exklusiv l\u00e5sning, och uppdateringen har samma beteende, men mellan dem uppst\u00e5r ingen konflikt, vilket \u00e4r ganska ovanligt. <\/p>\n
<\/p>\n
Och du kan m\u00e4rka att \u00f6verst \u00e4r det ShareLock, och l\u00e4ngst ner \u00e4r det ExclusiveLock. Och b\u00e5da transaktionerna blev framg\u00e5ngsrika.<\/p>\n
<\/p>\n
Du b\u00f6r lyssna p\u00e5 mitt f\u00f6redrag om MVCC f\u00f6r att f\u00f6rst\u00e5 hur detta sker. Men detta \u00e4r en illustration av att du kan g\u00f6ra detta samtidigt, dvs. g\u00f6ra SELECT och UPDATE p\u00e5 en g\u00e5ng.<\/p>\n
<\/p>\n
<\/p>\n
L\u00e5t oss \u00e5terst\u00e4lla och g\u00f6ra en operation igen. <\/p>\n
<\/p>\n
<\/p>\n
Om du f\u00f6rs\u00f6ker k\u00f6ra tv\u00e5 update samtidigt p\u00e5 samma rad, kommer det att blockeras. Och kom ih\u00e5g att jag sa att en l\u00e4sare inte blockerar en skrivare, och en skrivare blockerar inte en l\u00e4sare, men en skrivare blockerar en annan skrivare. Det vill s\u00e4ga, vi kan inte l\u00e5ta tv\u00e5 personer samtidigt uppdatera samma rad. De m\u00e5ste v\u00e4nta tills en av dem \u00e4r klar. <\/p>\n
<\/p>\n
<\/p>\n
Och f\u00f6r att illustrera detta kommer jag att titta p\u00e5 Lockdemo-tabellen. Och vi ska titta p\u00e5 en rad. P\u00e5 transaktion 698.<\/p>\n
<\/p>\n
Vi uppdaterade detta till 2. 699 \u2013 det f\u00f6rsta uppdateringen. Och det har g\u00e5tt igenom framg\u00e5ngsrikt eller s\u00e5 \u00e4r det i en v\u00e4ntande transaktion och v\u00e4ntar p\u00e5 att vi ska bekr\u00e4fta eller avbryta. <\/p>\n
<\/p>\n
<\/p>\n
Men titta p\u00e5 det h\u00e4r \u2013 2\/51 \u2013 det \u00e4r v\u00e5r f\u00f6rsta transaktion, v\u00e5r f\u00f6rsta session. 3\/112 \u2013 det \u00e4r den andra f\u00f6rfr\u00e5gan som d\u00f6k upp ovanifr\u00e5n och som \u00e4ndrade detta v\u00e4rde till 3. Och om du l\u00e4gger m\u00e4rke till, s\u00e5 blockerade den \u00f6vre sig sj\u00e4lv, vilken var 699. Men 3\/112 gav ingen blockering. I kolumnen Lock_mode st\u00e5r det att den v\u00e4ntar. Den v\u00e4ntar p\u00e5 699. Och om du kollar var 699 \u00e4r, s\u00e5 \u00e4r den h\u00f6gre upp. Och vad gjorde den f\u00f6rsta sessionen? Den skapade en exklusiv blockering p\u00e5 sitt eget transaktions-ID. Det \u00e4r s\u00e5 Postgres g\u00f6r. Den blockerar sitt eget transaktions-ID. Och om du vill v\u00e4nta p\u00e5 att n\u00e5gon ska bekr\u00e4fta eller avbryta, s\u00e5 m\u00e5ste du v\u00e4nta p\u00e5 att det finns en v\u00e4ntande transaktion. Och d\u00e4rf\u00f6r kan vi se en konstig rad. <\/p>\n
<\/p>\n
L\u00e5t oss titta igen. Till v\u00e4nster ser vi v\u00e5rt processerings-ID. I den andra kolumnen ser vi v\u00e5rt virtuella transaktions-ID, och i den tredje ser vi lock_type. Vad betyder det? I princip s\u00e4ger den att den blockerar transaktions-ID. Men l\u00e4gg m\u00e4rke till att det i alla rader l\u00e4ngst ner st\u00e5r relation. Och d\u00e4rf\u00f6r har du tv\u00e5 typer av blockeringar i tabellen. Det finns en relationblockering. Och det finns ocks\u00e5 en transactionid-blockering, d\u00e4r vi blockerar sj\u00e4lva, vilket exakt \u00e4r det som h\u00e4nder i den f\u00f6rsta raden eller l\u00e4ngst ner, d\u00e4r transactionid, d\u00e4r vi v\u00e4ntar p\u00e5 att 699 ska avsluta sin operation. <\/p>\n
<\/p>\n
Jag ser vad som h\u00e4nder h\u00e4r. Och h\u00e4r sker tv\u00e5 saker samtidigt. Du tittar p\u00e5 blockeringen av transaktions-ID i den f\u00f6rsta raden, som blockerar sig sj\u00e4lv. Och den blockerar sig sj\u00e4lv f\u00f6r att f\u00e5 folk att v\u00e4nta. <\/p>\n
<\/p>\n
Om du tittar p\u00e5 den sj\u00e4tte raden, s\u00e5 \u00e4r det samma post som den f\u00f6rsta. Och d\u00e4rf\u00f6r blockeras transaktionen 699. 700 blockerar ocks\u00e5 sig sj\u00e4lv. Och sedan i den nedersta raden kommer du se att vi v\u00e4ntar p\u00e5 att 699 ska avsluta sin operation.<\/p>\n
<\/p>\n
<\/p>\n
Och i lock_type, tuple ser du siffrorna. <\/p>\n
<\/p>\n
<\/p>\n
Du kan se att det \u00e4r 0\/10. Och det \u00e4r sidnumret, och \u00e4ven offset f\u00f6r denna specifika rad. <\/p>\n
<\/p>\n
<\/p>\n
Och du ser att det blir 0\/11 n\u00e4r vi uppdaterar. <\/p>\n
<\/p>\n
<\/p>\n
Men egentligen \u00e4r det 0\/10, eftersom denna operation v\u00e4ntar. Vi har m\u00f6jlighet att se att det \u00e4r den rad som jag v\u00e4ntar p\u00e5 att bekr\u00e4fta. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 snart vi bekr\u00e4ftade det och tryckte p\u00e5 commit, och n\u00e4r uppdateringen var klar, \u00e4r det h\u00e4r vad vi f\u00e5r igen. Transaktion 700 \u00e4r den enda l\u00e5sningen, den v\u00e4ntar inte l\u00e4ngre p\u00e5 n\u00e5gon annan eftersom den har blivit commitad. Den v\u00e4ntar bara p\u00e5 att transaktionen ska avslutas. S\u00e5 snart 699 \u00e4r klar v\u00e4ntar vi inte l\u00e4ngre p\u00e5 n\u00e5got. Och nu s\u00e4ger transaktion 700 att allt \u00e4r okej, att den har alla l\u00e5s som den beh\u00f6ver i alla till\u00e5tna tabeller. <\/p>\n
<\/p>\n
<\/p>\n
Och f\u00f6r att komplicera allt detta ytterligare skapar vi en till vy, som den h\u00e4r g\u00e5ngen kommer att ge oss en hierarki. Jag f\u00f6rv\u00e4ntar mig inte att ni f\u00f6rst\u00e5r denna fr\u00e5ga. Men det kommer att ge oss en tydligare bild av vad som h\u00e4nder. <\/p>\n
<\/p>\n
<\/p>\n
Det \u00e4r en rekursiv vy, som ocks\u00e5 har ett annat avsnitt. Och det returnerar sedan allt ihop. L\u00e5t oss anv\u00e4nda det. <\/p>\n
<\/p>\n
<\/p>\n
Vad h\u00e4nder om vi g\u00f6r tre samtidiga uppdateringar och s\u00e4ger att raden just nu \u00e4r tre. Och vi f\u00f6r\u00e4ndrar 3 till 4. <\/p>\n
<\/p>\n
<\/p>\n
Och h\u00e4r ser vi 4. Och transaktions-ID 702. <\/p>\n
<\/p>\n
<\/p>\n
Och sedan byter jag 4 till 5. Och 5 till 6, och 6 till 7. Och jag k\u00f6ar en rad personer som kommer att v\u00e4nta p\u00e5 att denna enskilda transaktion ska avslutas.<\/p>\n
<\/p>\n
<\/p>\n
Och allt blir tydligt. Vilken \u00e4r den f\u00f6rsta raden? Det \u00e4r 702. Det \u00e4r transaktions-ID som ursprungligen satte detta v\u00e4rde. Och vad har jag skrivit i kolumnen Granted? Jag har markeringar f<\/code>. Det \u00e4r mina uppdateringar, som (5, 6, 7), som inte kan godk\u00e4nnas eftersom vi v\u00e4ntar p\u00e5 att transaktions-ID 702 ska avslutas. D\u00e4r har vi en l\u00e5sning av transaktions-ID. Och det ger 5 transaktionsl\u00e5sning ID.<\/p>\n<\/p>\n
Och om ni tittar p\u00e5 704, p\u00e5 705, s\u00e5 st\u00e5r det fortfarande ingenting d\u00e4r, eftersom de fortfarande inte vet vad som h\u00e4nder. De skriver bara att de inte har en aning om vad som h\u00e4nder. Och de kommer helt enkelt att somna, eftersom de v\u00e4ntar p\u00e5 att n\u00e5gon ska avsluta och v\u00e4cka dem n\u00e4r det blir m\u00f6jligt att \u00e4ndra raden. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 h\u00e4r ser det ut. Det \u00e4r tydligt att de alla v\u00e4ntar p\u00e5 rad 12. <\/p>\n
<\/p>\n
<\/p>\n
Detta \u00e4r vad vi s\u00e5g h\u00e4r. H\u00e4r \u00e4r 0\/12. <\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 snart den f\u00f6rsta transaktionen \u00e4r godk\u00e4nd, kan ni h\u00e4r se hur hierarkin fungerar. Och nu blir allt klart. De alla blir rena. Och de \u00e4r faktiskt fortfarande i v\u00e4ntel\u00e4ge. <\/p>\n
<\/p>\n
<\/p>\n
Det h\u00e4r \u00e4r vad som h\u00e4nder. 702 g\u00f6r en commit. Och nu f\u00e5r 703 denna radl\u00e5sningsstatus, och sedan b\u00f6rjar 704 v\u00e4nta p\u00e5 att 703 ska g\u00f6ra en commit. Och 705 v\u00e4ntar ocks\u00e5 p\u00e5 detta. N\u00e4r allt detta avslutas st\u00e4dar de upp efter sig sj\u00e4lva. Jag vill p\u00e5peka att alla st\u00e4ller sig i k\u00f6. Det liknar verkligen en trafikstockning, d\u00e4r alla v\u00e4ntar p\u00e5 att den f\u00f6rsta bilen ska passera. Den f\u00f6rsta bilen stannar, och alla st\u00e4ller sig i en l\u00e5ng rad. Sedan r\u00f6r den sig, sedan kan n\u00e4sta bil k\u00f6ra fram och f\u00e5 sin l\u00e5sning och s\u00e5 vidare. <\/p>\n
<\/p>\n
<\/p>\n
Och om du tyckte att det h\u00e4r var tillr\u00e4ckligt komplicerat, s\u00e5 ska vi nu prata om deadlocks. Jag vet inte vem av er som har st\u00f6tt p\u00e5 dem. Det h\u00e4r \u00e4r ett ganska vanligt problem i databassystem. Men deadlocks \u00e4r det fall d\u00e5 en session v\u00e4ntar p\u00e5 att n\u00e5got ska utf\u00f6ras av en annan session. Samtidigt v\u00e4ntar den andra sessionen p\u00e5 att den f\u00f6rsta sessionen ska utf\u00f6ra n\u00e5got. <\/p>\n
<\/p>\n
Till exempel, om Ivan s\u00e4ger: \"Ge mig n\u00e5got\", och jag s\u00e4ger: \"Nej, jag ger dig det bara om du ger mig n\u00e5got annat\". Och han s\u00e4ger: \"Nej, jag ger dig inte det om du inte ger mig\". Och vi hamnar i en deadlock-situation. Jag \u00e4r s\u00e4ker p\u00e5 att Ivan inte skulle g\u00f6ra s\u00e5, men du f\u00f6rst\u00e5r po\u00e4ngen, vi har tv\u00e5 personer som vill ha n\u00e5got och de \u00e4r inte villiga att ge det f\u00f6rr\u00e4n den andra personen ger dem det de vill ha. H\u00e4r finns det ingen l\u00f6sning. <\/p>\n
<\/p>\n
I grund och botten beh\u00f6ver din databas uppt\u00e4cka detta. Och du m\u00e5ste sedan avsluta eller st\u00e4nga en av sessionerna, f\u00f6r annars kommer de att stanna d\u00e4r f\u00f6r alltid. Vi ser detta i databaser, vi ser det i operativsystem. Och \u00f6verallt d\u00e4r vi har parallella processer kan detta h\u00e4nda. <\/p>\n
<\/p>\n
<\/p>\n
Nu kommer vi att s\u00e4tta upp tv\u00e5 deadlocks. Vi s\u00e4tter 50 och 80. I den f\u00f6rsta raden kommer jag att g\u00f6ra en uppdatering fr\u00e5n 50 till 50. Jag f\u00e5r transaktionsnummer 710. <\/p>\n
<\/p>\n
<\/p>\n
Sedan kommer jag att \u00e4ndra 80 till 81, och 50 till 51. <\/p>\n
<\/p>\n
<\/p>\n
Och s\u00e5 h\u00e4r kommer det att se ut. D\u00e4rf\u00f6r har 710 en radl\u00e5sning, medan 711 v\u00e4ntar p\u00e5 bekr\u00e4ftelse. Vi s\u00e5g detta n\u00e4r vi uppdaterade. 710 \u00e4r \u00e4garen av v\u00e5r rad. Och 711 v\u00e4ntar p\u00e5 att 710 ska avsluta transaktionen.<\/p>\n
<\/p>\n
<\/p>\n
Och det st\u00e5r till och med p\u00e5 vilken specifik rad vi har en deadlock. Och h\u00e4r b\u00f6rjar det bli konstigt.<\/p>\n
<\/p>\n
<\/p>\n
Nu uppdaterar vi 80 till 80. <\/p>\n
<\/p>\n
<\/p>\n
Och h\u00e4r \u00e4r d\u00e4r deadlocks b\u00f6rjar. 710 v\u00e4ntar p\u00e5 svar fr\u00e5n 711, medan 711 v\u00e4ntar p\u00e5 710. Och det kommer att sluta illa. Det finns ingen utv\u00e4g h\u00e4r. Och de kommer att v\u00e4nta p\u00e5 varandras svar. <\/p>\n
<\/p>\n
<\/p>\n
Och det h\u00e4r kommer bara att b\u00f6rja f\u00f6rsena allt. Och vi vill inte ha det. <\/p>\n
<\/p>\n
<\/p>\n
Och i Postgres finns det s\u00e4tt att m\u00e4rka n\u00e4r detta h\u00e4nder. Och n\u00e4r det h\u00e4nder f\u00e5r du ett s\u00e5dant felmeddelande. Och det blir tydligt att en viss process v\u00e4ntar p\u00e5 SHARE LOCK fr\u00e5n en annan process, det vill s\u00e4ga en som blockeras av process 711. Och den processen v\u00e4ntade p\u00e5 att f\u00e5 SHARE LOCK p\u00e5 en viss transaktions-ID och blev blockerad av en viss process. S\u00e5 situationen \u00e4r en deadlock.<\/p>\n
<\/p>\n
<\/p>\n
Men finns det trev\u00e4gs-deadlocks? \u00c4r det m\u00f6jligt? Ja. <\/p>\n
<\/p>\n
<\/p>\n
Vi matar in dessa siffror i tabellen. Vi \u00e4ndrar 40 till 40, vi skapar en l\u00e5sning. <\/p>\n
<\/p>\n
<\/p>\n
Vi \u00e4ndrar 60 till 61, 80 till 81. <\/p>\n
<\/p>\n
<\/p>\n
Och sedan \u00e4ndrar vi 80, och sedan \u2013 boom! <\/p>\n
<\/p>\n
<\/p>\n
Och 714 v\u00e4ntar nu p\u00e5 715. 716 v\u00e4ntar p\u00e5 715. Och med det g\u00e5r det inte att g\u00f6ra n\u00e5got.<\/p>\n
<\/p>\n
<\/p>\n
H\u00e4r \u00e4r det inte l\u00e4ngre tv\u00e5 personer, h\u00e4r \u00e4r det redan tre personer. Jag vill ha n\u00e5got fr\u00e5n dig, den h\u00e4r vill ha n\u00e5got fr\u00e5n den tredje personen, och den tredje personen vill ha n\u00e5got fr\u00e5n mig. Och vi hamnar i en trev\u00e4gsv\u00e4ntan, eftersom vi alla v\u00e4ntar p\u00e5 att den andra personen ska avsluta vad de m\u00e5ste g\u00f6ra. <\/p>\n
<\/p>\n
<\/p>\n
Och Postgres vet p\u00e5 vilken rad detta h\u00e4nder. Och d\u00e4rf\u00f6r ger det dig f\u00f6ljande meddelande, som visar att du har ett problem d\u00e4r tre ing\u00e5ngar blockerar varandra. Och det finns inga begr\u00e4nsningar. Det kan vara i ett fall d\u00e4r 20 poster blockerar varandra. <\/p>\n
<\/p>\n
<\/p>\n
N\u00e4sta problem \u00e4r serializable. <\/p>\n
<\/p>\n
<\/p>\n
Om det \u00e4r en speciell serializable-l\u00e5sning.<\/p>\n
<\/p>\n
<\/p>\n
Och vi g\u00e5r tillbaka till 719. Den har en fullt normal utdata. <\/p>\n
<\/p>\n
<\/p>\n
Och du kan klicka f\u00f6r att g\u00f6ra en transaktion fr\u00e5n serializable.<\/p>\n
<\/p>\n
<\/p>\n
Och du f\u00f6rst\u00e5r att du nu har en annan typ av l\u00e5sning SA \u2013 det betyder serializable. <\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Och d\u00e4rf\u00f6r har vi en ny typ av l\u00e5sning som kallas SARieadLock, som \u00e4r en seriell l\u00e5sning och till\u00e5ter inmatning av serienummer.<\/p>\n
<\/p>\n
<\/p>\n
Och du kan ocks\u00e5 infoga unika index. <\/p>\n
<\/p>\n
<\/p>\n
I denna tabell har vi unika index.<\/p>\n
<\/p>\n
<\/p>\n
S\u00e5 om jag matar in siffran 2 h\u00e4r, s\u00e5 f\u00e5r jag 2. Men h\u00f6gst upp matar jag in \u00e4nnu en 2. Och du kan se att 721 har en exklusiv l\u00e5sning. Men nu v\u00e4ntar 722 p\u00e5 att 721 ska avsluta sin operation, eftersom den inte kan infoga 2 f\u00f6rr\u00e4n den vet vad som kommer att h\u00e4nda med 721. <\/p>\n
<\/p>\n
<\/p>\n
Och om vi g\u00f6r en subtransaction.<\/p>\n
<\/p>\n
<\/p>\n
H\u00e4r har vi 723.<\/p>\n
<\/p>\n
<\/p>\n
Och om vi sparar punkten och sedan uppdaterar den, f\u00e5r vi en ny transaktions-ID. Detta \u00e4r ytterligare ett beteende som du beh\u00f6ver k\u00e4nna till. Om vi \u00e5terf\u00f6r detta, avl\u00e4gsnas transaktions-ID:n. 724 f\u00f6rsvinner. Men nu f\u00e5r vi 725. <\/p>\n
<\/p>\n
Och vad f\u00f6rs\u00f6ker jag g\u00f6ra h\u00e4r? Jag f\u00f6rs\u00f6ker visa dig exempel p\u00e5 ovanliga l\u00e5s som du kan st\u00f6ta p\u00e5: oavsett om det handlar om serializable-l\u00e5s eller SAVEPOINT \u2013 det \u00e4r olika typer av l\u00e5s som kommer att dyka upp i l\u00e5s tabellen. <\/p>\n
<\/p>\n
<\/p>\n
Detta handlar om att skapa explicita (eller explicita) l\u00e5s, som har pg_advisory_lock. <\/p>\n
<\/p>\n
<\/p>\n
Och du ser att l\u00e5stypen h\u00e4r anges som advisory. Och h\u00e4r st\u00e5r det skrivet i r\u00f6tt \"advisory\". Och du kan samtidigt l\u00e5sa s\u00e5 h\u00e4r med pg_advisory_unlock.<\/p>\n
<\/p>\n
<\/p>\n
Och f\u00f6r att avsluta vill jag visa dig en annan sp\u00e4nnande sak. Jag kommer att skapa en annan typ. Men jag kommer att sammanfoga tabellen pg_locks med tabellen pg_stat_activity. Och varf\u00f6r vill jag g\u00f6ra detta? F\u00f6r att detta g\u00f6r att jag kan se och f\u00e5 en \u00f6versikt av alla aktuella sessioner och se vilka specifika l\u00e5s de v\u00e4ntar p\u00e5. Och detta \u00e4r ganska intressant n\u00e4r vi s\u00e4tter samman l\u00e5stabellen och fr\u00e5getabellen. <\/p>\n
<\/p>\n
<\/p>\n
Och h\u00e4r skapar vi pg_stat_view. <\/p>\n
<\/p>\n
<\/p>\n
Och vi uppdaterar raden med ett. Och h\u00e4r ser vi 724. Sedan uppdaterar vi v\u00e5r rad till tre. Och vad ser du h\u00e4r nu? Det \u00e4r f\u00f6rfr\u00e5gningar, dvs. du ser hela listan \u00f6ver f\u00f6rfr\u00e5gningar som listas i v\u00e4nster kolumn. Och sedan kan du se l\u00e5sen och vad de skapar p\u00e5 h\u00f6gra sidan. Och detta kan vara mer begripligt f\u00f6r dig, s\u00e5 du inte beh\u00f6ver g\u00e5 tillbaka till varje session varje g\u00e5ng och kolla \u2013 om du beh\u00f6ver g\u00e5 med i den eller inte. Det g\u00f6rs f\u00f6r oss. <\/p>\n
<\/p>\n
En annan funktion som \u00e4r mycket anv\u00e4ndbar \u00e4r pg_blocking_pids<\/code>Du har kanske aldrig h\u00f6rt talas om det. Vad g\u00f6r det? Det l\u00e5ter oss s\u00e4ga att f\u00f6r den h\u00e4r sessionen 11740, vilka specifika process-ID:n den f\u00f6rv\u00e4ntar sig. Och du kan se att 11740 f\u00f6rv\u00e4ntar sig 724. Och 724 \u00e4r h\u00f6gst upp. Och 11306 \u00e4r ditt process-ID. I princip g\u00e5r den h\u00e4r funktionen igenom din l\u00e5sningstabell. Och jag vet att det \u00e4r lite komplicerat, men du verkar f\u00f6rst\u00e5 det. I princip g\u00e5r den h\u00e4r funktionen igenom den h\u00e4r l\u00e5sningstabellen och f\u00f6rs\u00f6ker hitta var detta proces-ID finns, med h\u00e4nsyn till de l\u00e5sningar den v\u00e4ntar p\u00e5. Den f\u00f6rs\u00f6ker ocks\u00e5 r\u00e4kna ut vilket specifikt proces-ID som den process har som v\u00e4ntar p\u00e5 l\u00e5sningar. S\u00e5 du kan k\u00f6ra den h\u00e4r funktionen. pg_blocking_pids<\/code>.<\/p>\n<\/p>\n
Och det kan vara v\u00e4ldigt anv\u00e4ndbart. Vi lade till detta f\u00f6rst i version 9.6, s\u00e5 den h\u00e4r funktionen \u00e4r bara 5 \u00e5r gammal, men den \u00e4r mycket och verkligen anv\u00e4ndbar. Detsamma g\u00e4ller den andra fr\u00e5gan. Den visar exakt det vi beh\u00f6ver se. <\/p>\n
<\/p>\n
<\/p>\n
Det \u00e4r det jag ville prata med er om. Och som jag f\u00f6rv\u00e4ntade mig anv\u00e4nde vi all v\u00e5r tid, eftersom det var s\u00e5 m\u00e5nga bilder. Och bilderna finns tillg\u00e4ngliga f\u00f6r nedladdning. Jag vill tacka er f\u00f6r att ni kom hit. Jag \u00e4r s\u00e4ker p\u00e5 att ni kommer att uppskatta resten av konferensen, stort tack!<\/p>\n
<\/p>\n
Fr\u00e5gor:<\/p>\n
<\/p>\n
Till exempel, om jag f\u00f6rs\u00f6ker uppdatera rader, medan en annan session f\u00f6rs\u00f6ker ta bort hela tabellen. S\u00e5vitt jag f\u00f6rst\u00e5r skulle det beh\u00f6va finnas n\u00e5got som heter intent lock. Finns det n\u00e5got s\u00e5dant i Postgres?<\/em><\/p>\n<\/p>\n
<\/p>\n
Vi g\u00e5r tillbaka till b\u00f6rjan. Kanske minns du att n\u00e4r du g\u00f6r vad som helst, till exempel n\u00e4r du g\u00f6r en SELECT, s\u00e5 ger vi AccessShareLock. Och detta f\u00f6rhindrar att tabellen tas bort. S\u00e5 om du till exempel vill uppdatera en rad i tabellen eller ta bort en rad, s\u00e5 kan ingen ta bort hela tabellen samtidigt, eftersom du h\u00e5ller det h\u00e4r AccessShareLock \u00f6ver hela tabellen och \u00f6ver raden. Och n\u00e4r du \u00e4r klar kan de ta bort den. Men s\u00e5 l\u00e4nge du g\u00f6r n\u00e5got d\u00e4r, kan de inte g\u00f6ra det.<\/p>\n
<\/p>\n
L\u00e5t oss g\u00e5 igenom det en g\u00e5ng till. L\u00e5t oss ta exemplet med borttagning. Och du ser hur det finns en exklusiv l\u00e5s \u00f6ver hela tabellen p\u00e5 raden. <\/p>\n
<\/p>\n
Det skulle se ut som en exklusiv l\u00e5s, eller hur?<\/em><\/p>\n<\/p>\n
Ja, det verkar s\u00e5. Jag f\u00f6rst\u00e5r vad du menar. Du s\u00e4ger att om jag utf\u00f6r SELECT kommer jag att ha ShareExclusive, och om jag sedan \u00e4ndrar detta till Row Exclusive, blir det ett problem? Men \u00f6verraskande nog skapar detta inget problem. Det verkar som om jag \u00f6kar l\u00e5sningsgraden, men i grunden har jag en l\u00e5s som f\u00f6rhindrar borttagning. Och just nu, n\u00e4r jag g\u00f6r denna l\u00e5s starkare, f\u00f6rhindrar den fortfarande borttagning. S\u00e5 det handlar inte om att jag h\u00f6jer mig. Det vill s\u00e4ga, den f\u00f6rhindrade detta \u00e4ven n\u00e4r den var p\u00e5 en l\u00e4gre niv\u00e5, s\u00e5 n\u00e4r jag h\u00f6jer dess niv\u00e5 f\u00f6rhindrar den fortfarande borttagning av tabellen. <\/p>\n
<\/p>\n
Jag f\u00f6rst\u00e5r vad du menar. H\u00e4r finns inget fall av \u00f6kning av l\u00e5sningsgraden d\u00e4r du f\u00f6rs\u00f6ker frig\u00f6ra en l\u00e5s f\u00f6r att inf\u00f6ra en starkare. H\u00e4r \u00f6kar det bara generellt denna f\u00f6rhindran, s\u00e5 det orsakar ingen konflikt. Men det \u00e4r en bra fr\u00e5ga. Tack s\u00e5 mycket f\u00f6r att du st\u00e4llde den!<\/p>\n
<\/p>\n
Vad beh\u00f6ver vi g\u00f6ra f\u00f6r att undvika situationen med deadlock n\u00e4r vi har m\u00e5nga sessioner och ett stort antal anv\u00e4ndare?<\/em><\/p>\n<\/p>\n
Postgres uppt\u00e4cker automatiskt situationer med deadlock. Och det kommer automatiskt att ta bort en av sessionerna. Det enda s\u00e4ttet att undvika d\u00f6dl\u00e5sningssituationer \u00e4r att l\u00e5sa personer i samma ordning. S\u00e5 n\u00e4r du tittar p\u00e5 din applikation \u00e4r anledningen till deadlocks ofta... L\u00e5t oss s\u00e4ga att jag vill l\u00e5sa tv\u00e5 olika saker. En applikation l\u00e5ser tabell 1, och en annan applikation l\u00e5ser 2, och sedan tabell 1. Det enklaste s\u00e4ttet att undvika deadlocks \u00e4r att titta p\u00e5 din applikation och f\u00f6rs\u00f6ka se till att l\u00e5sningen sker i samma ordning i alla applikationer. Och det brukar ta bort 80 % av problemen, eftersom olika m\u00e4nniskor skriver dessa applikationer. Och om du l\u00e5ser dem i samma ordning, s\u00e5 st\u00f6ter du inte p\u00e5 d\u00f6dl\u00e5sningssituationen.<\/p>\n
<\/p>\n
Tack s\u00e5 mycket f\u00f6r din presentation! Du talade om vacuum full och om jag f\u00f6rst\u00e5r r\u00e4tt, s\u00e5 deformerar vacuum full ordningen p\u00e5 poster i en s\u00e4rskild lagring, s\u00e5 nuvarande poster f\u00f6rblir of\u00f6r\u00e4ndrade. Men varf\u00f6r tar vacuum full exklusiv l\u00e5sning och varf\u00f6r st\u00e5r det i konflikt med skrivoperationer?<\/em><\/p>\n<\/p>\n
Det \u00e4r en bra fr\u00e5ga. Anledningen \u00e4r att vacuum full tar tabellen. Och vi skapar i sj\u00e4lva verket en ny version av tabellen. Tabellen kommer att bli ny. Det inneb\u00e4r att det blir en helt ny version av tabellen. Problemet \u00e4r att n\u00e4r vi g\u00f6r detta, vill vi inte att folk ska l\u00e4sa den, f\u00f6r vi beh\u00f6ver att de ser den nya tabellen. D\u00e4rf\u00f6r kopplar det samman med den tidigare fr\u00e5gan. Om vi kunde l\u00e4sa samtidigt, skulle vi inte kunna flytta den och rikta folk till den nya tabellen. Vi skulle beh\u00f6va v\u00e4nta tills alla hade slutat l\u00e4sa denna tabell, och d\u00e4rf\u00f6r handlar det i grunden om en exklusiv l\u00e5sning.
<\/p>\n
\u00c4r det m\u00f6jligt att l\u00e4gga till locking timeout i Postgres? I Oracle kan jag till exempel skriva \"v\u00e4lj f\u00f6r uppdatering\" och v\u00e4nta 50 sekunder innan uppdateringen. Det fungerade bra f\u00f6r applikationen. Men i Postgres m\u00e5ste jag antingen g\u00f6ra det omedelbart och inte v\u00e4nta alls, eller v\u00e4nta till en viss tid.<\/em> <\/p>\n<\/p>\n
Ja, du kan v\u00e4lja timeout f\u00f6r dina l\u00e5s. Du kan ocks\u00e5 ge kommandot no way, som kommer att \u2026 om du inte kan f\u00e5 l\u00e5s omedelbart. S\u00e5 antingen lock timeout eller n\u00e5got annat som till\u00e5ter dig att g\u00f6ra det. Det g\u00f6rs inte p\u00e5 syntaktisk niv\u00e5. Det g\u00f6rs som en variabel p\u00e5 servern. Ibland g\u00e5r det inte att anv\u00e4nda.<\/p>\n
<\/p>\n
Kan du \u00f6ppna 75-sidan?<\/em> <\/p>\n<\/p>\n
Ja.<\/p>\n
<\/p>\n
<\/p>\n
Och min fr\u00e5ga \u00e4r f\u00f6ljande. Varf\u00f6r v\u00e4ntar b\u00e5da uppdateringsprocesserna p\u00e5 703?<\/em><\/p>\n<\/p>\n
Och det \u00e4r en utm\u00e4rkt fr\u00e5ga. Jag f\u00f6rst\u00e5r inte, f\u00f6rresten, varf\u00f6r Postgres g\u00f6r s\u00e5 h\u00e4r. Men n\u00e4r 703 skapades, f\u00f6rv\u00e4ntade den sig 702. Och n\u00e4r 704 och 705 dyker upp verkar det som att de inte vet vad de v\u00e4ntar p\u00e5, eftersom det fortfarande inte finns n\u00e5got d\u00e4r. Och Postgres g\u00f6r s\u00e5 h\u00e4r: n\u00e4r du inte kan f\u00e5 en l\u00e5s, s\u00e5 skriver den \"Vad \u00e4r meningen med att behandla er?\" eftersom du redan v\u00e4ntar p\u00e5 n\u00e5gon. S\u00e5 vi l\u00e5ter bara l\u00e5sningen h\u00e4nga i luften, den uppdaterar inte detta \u00f6ver huvud taget. Men vad h\u00e4nde h\u00e4r? S\u00e5 snart 702 fullf\u00f6ljde processen och 703 fick sin l\u00e5s, s\u00e5 \u00e5tergick systemet. Och sade att nu har vi tv\u00e5 personer som v\u00e4ntar. Och sedan uppdaterar vi dem tillsammans. Och vi anger att b\u00e5da v\u00e4ntar. <\/p>\n
<\/p>\n
Jag vet inte varf\u00f6r Postgres g\u00f6r s\u00e5 h\u00e4r. Men det finns ett problem som kallas f\u2026. Jag tror att det inte \u00e4r en term p\u00e5 svenska. Det \u00e4r n\u00e4r alla v\u00e4ntar p\u00e5 en l\u00e5s, \u00e4ven om det finns 20 instanser som v\u00e4ntar p\u00e5 l\u00e5set. Och pl\u00f6tsligt vaknar de alla samtidigt. Och alla b\u00f6rjar f\u00f6rs\u00f6ka reagera. Men systemet g\u00f6r s\u00e5 att alla v\u00e4ntar p\u00e5 703. Eftersom de alla v\u00e4ntar, och vi placerar dem omedelbart i k\u00f6. Och om n\u00e5gon annan ny f\u00f6rfr\u00e5gan dyker upp som skapades efter detta, till exempel 707, s\u00e5 kommer det att bli tomt igen. <\/p>\n
<\/p>\n
Och jag tror att detta g\u00f6rs f\u00f6r att man ska kunna s\u00e4ga att vid denna tidpunkt v\u00e4ntar 702 p\u00e5 703, och alla som kommer efter detta kommer inte ha n\u00e5gon post i detta f\u00e4lt. Men s\u00e5 snart den f\u00f6rsta som v\u00e4ntar l\u00e4mnar, och alla som v\u00e4ntade vid den tidpunkten innan uppdateringen f\u00e5r samma m\u00e4rke. Och d\u00e4rf\u00f6r tror jag att det h\u00e4r g\u00f6rs f\u00f6r att vi ska kunna bearbeta dem i ordning, s\u00e5 att de \u00e4r korrekt sorterade. <\/p>\n
<\/p>\n
Jag har alltid sett detta som ett ganska konstigt fenomen. Eftersom vi h\u00e4r till exempel inte listar dem \u00f6verhuvudtaget. Men jag tror att varje g\u00e5ng vi ger en ny l\u00e5s, s\u00e5 ser vi p\u00e5 alla som \u00e4r i v\u00e4ntande process. D\u00e5 st\u00e4ller vi dem alla i k\u00f6. Och sedan kommer vilken ny som helst som dyker upp, in i k\u00f6n f\u00f6rst n\u00e4r n\u00e4sta person har avslutat behandlingen. Mycket bra fr\u00e5ga. Tack s\u00e5 mycket f\u00f6r fr\u00e5gan!<\/p>\n
<\/p>\n
Jag tycker att det \u00e4r mycket mer logiskt n\u00e4r 705 v\u00e4ntar p\u00e5 704.<\/em> <\/p>\n<\/p>\n
Men problemet h\u00e4r \u00e4r det f\u00f6ljande. Tekniskt sett kan ni v\u00e4cka antingen den ena eller den andra. Och d\u00e4rf\u00f6r kommer vi att v\u00e4cka den ena eller den andra. Men vad h\u00e4nder i systemets arbete? Ni ser hur 703 i toppen blockerade sitt eget transaktions-ID. S\u00e5 fungerar Postgres. Och 703 blockeras av sitt eget transaktions-ID, s\u00e5 om n\u00e5gon vill v\u00e4nta, kommer de att v\u00e4nta p\u00e5 703. Och i grund och botten avslutar 703. Och f\u00f6rst efter att den har avslutats v\u00e4cks n\u00e5gon av processerna. Och vi vet inte vilken process som kommer att v\u00e4ckas f\u00f6rst. Sedan hanterar vi allt gradvis. Men det \u00e4r oklart vilken process som v\u00e4cks f\u00f6rst, eftersom det kan vara n\u00e5gon av dessa processer. I grund och botten hade vi en schemal\u00e4ggare som sa att vi nu kan v\u00e4cka vilken av dessa processer som helst. Vi v\u00e4ljer helt enkelt en slumpm\u00e4ssigt. D\u00e4rf\u00f6r m\u00e5ste b\u00e5da noteras, eftersom vi kan v\u00e4cka n\u00e5gon av dem. <\/p>\n
<\/p>\n
Och problemet \u00e4r att vi har CP-o\u00e4ndlighet. Och d\u00e4rf\u00f6r \u00e4r det helt m\u00f6jligt att vi kan v\u00e4cka den senare. Och om vi till exempel v\u00e4cker den senare, kommer vi att v\u00e4nta p\u00e5 den som just fick en blockering, s\u00e5 vi kan inte avg\u00f6ra vem som kommer att v\u00e4ckas f\u00f6rst. Vi skapar helt enkelt en s\u00e5dan situation, och systemet kommer att v\u00e4cka dem i godtycklig ordning. <\/p>\n
<\/p>\n
Det finns artiklar om l\u00e5s av Yegor Rogov<\/a><\/noindex>. Titta, de \u00e4r ocks\u00e5 intressanta och anv\u00e4ndbara. Temat \u00e4r sj\u00e4lvklart fruktansv\u00e4rt komplext. Tack s\u00e5 mycket, Bruce!<\/em><\/p>\nK\u00e4lla: 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