Trascrizione di u discorsu 2020 di Bruce Momjian "Unlocking the Postgres Lock Manager".
(Nota: Tutte e dumande SQL da e diapositive ponu esse ottenute da stu ligame: )
Bonghjornu! Hè bellu di esse quì in Russia di novu. Mi dispiace di ùn avè micca pussutu vene l'annu passatu, ma questu annu Ivan è aghju grandi piani. Spergu di esse quì assai più spessu. Mi piace à vene in Russia. Aghju visitatu Tyumen, Tver. Sò assai cuntentu di pudè visità queste cità.
Mi chjamu Bruce Momjian. U travagliu in EnterpriseDB è aghju travagliatu cù Postgres per più di 23 anni. Vivu in Filadelfia, USA. Viaghjà circa 90 ghjorni à l'annu. È assistiu à circa 40 cunferenze. U mo , chì cuntene e diapositive chì avà vi mustraraghju. Dunque, dopu à a cunferenza pudete scaricà da u mo situ persunale. Contene ancu circa 30 presentazioni. Ci sò ancu video è un gran numaru di articuli blog, più di 500. Questu hè un risorsu abbastanza informativu. E s'è vo site interessatu in stu materiale, allora vi invitu à aduprà.
Era un maestru, un prufessore prima di cumincià à travaglià cù Postgres. È sò assai cuntentu chì avà da pudè dì ciò ch’e aghju da dì. Questa hè una di e mo presentazioni più interessanti. È sta presentazione cuntene 110 slides. Avemu da principià à parlà cù e cose simplici, è à a fine u rapportu diventerà più è più cumplessu, è diventerà abbastanza cumplessu.
Questa hè una conversazione piuttostu spiacevole. U bloccu ùn hè micca u sughjettu più populari. Vulemu chì questu sparisce in qualchì locu. Hè cum'è andà in u dentistu.
- U chjusu hè un prublema per parechje persone chì travaglianu in basa di dati è avè parechje prucessi in esecuzione à u stessu tempu. Hanu bisognu di bluccà. Questu hè, oghje vi daraghju cunniscenze basiche nantu à u bloccu.
- ID di transazzione. Questa hè una parte piuttostu noiosa di a presentazione, ma deve esse capitu.
- Dopu avemu da parlà di i tipi di bloccu. Questa hè una parte abbastanza meccanica.
- È quì sottu daremu alcuni esempi di bloccu. È sarà abbastanza difficiule à capisce.
Parlemu di u bloccu.
A nostra terminologia hè abbastanza cumplessa. Quanti di voi sapete da induve vene stu passaghju ? Dui parsoni. Questu hè da un ghjocu chjamatu Colossal Cave Adventure. Era un ghjocu di computer basatu in testu in l'anni 80, pensu. Ci duvia andà in una caverna, in un labirintu, è u testu cambiatu, ma u cuntenutu era apprussimatamente u listessu ogni volta. Hè cusì chì mi ricordu di stu ghjocu.
E quì vedemu u nome di i chjusi chì sò ghjunti à noi da Oracle. Avemu aduprà.
Quì vedemu termini chì mi cunfundenu. Per esempiu, SHARE UPDATE ECXLUSIVE. Next SHARE RAW ECXLUSIVE. Per esse onesto, sti nomi ùn sò micca assai chjaru. Avemu da pruvà à cunsiderà elli in più detail. Certi cuntenenu a parolla "sparte", chì significa separà. Certi cuntenenu a parolla "esclusiva". Certi cuntenenu sti dui parolle. Mi piacerebbe principià cù cumu funziona sti chjusi.
È a parolla "accessu" hè ancu assai impurtante. E e parolle "fila" sò una stringa. Questu hè, distribuzione di accessu, distribuzione di fila.
Un altru prublema chì deve esse capitu in Postgres, chì sfurtunatamenti ùn puderaghju micca copre in a mo discussione, hè MVCC. Aghju una presentazione separata nantu à questu tema nantu à u mo situ web. E se pensate chì sta presentazione hè dura, MVCC hè probabilmente u mo più duru. È se site interessatu, pudete fighjà nantu à u situ web. Pudete vede u video.
Un'altra cosa chì avemu bisognu di capiscenu hè l'ID di transazzione. Parechje transazzione ùn ponu micca travaglià senza identificatori unichi. E quì avemu una spiegazione di ciò chì hè una transazzione. Postgres hà dui sistemi di numerazione di transazzione. Sò chì questu ùn hè micca una suluzione assai bella.
Tenite ancu in mente chì e diapositive seranu abbastanza difficiuli di capiscenu, cusì ciò chì hè evidenziatu in rossu hè ciò chì deve esse attentu.
Videmu. U numeru di transazzione hè evidenziatu in rossu. A funzione SELECT pg_back hè mostrata quì. Ritorna a mo transazzione è l'ID di transazzione.
Una cosa più, se ti piace sta presentazione è vulete eseguisce nantu à a vostra basa di dati, pudete andà à stu ligame in rosa è scaricate l'SQL per sta presentazione. È pudete simpricimenti eseguisce in u vostru PSQL è tutta a presentazione sarà immediatamente nantu à a vostra pantalla. Ùn cuntene micca fiori, ma almenu pudemu vede.
In questu casu, vedemu l'ID di transazzione. Questu hè u numeru chì l'avemu assignatu. È ci hè un altru tipu di ID di transazzione in Postgres, chì hè chjamatu ID transazzione virtuale
È avemu da capisce questu. Questu hè assai impurtante, altri ùn pudemu micca capisce u bloccu in Postgres.
Un ID di transazzione virtuale hè un ID di transazzione chì ùn cuntene valori persistenti. Per esempiu, se eseguite un cumandamentu SELECT, allora probabilmente ùn cambiassi micca a basa di dati, ùn chjuderaghju nunda. Allora, quandu eseguimu un SELECT simplice, ùn demu micca à quella transazzione un ID persistente. Li demu solu una ID virtuale quì.
E questu migliurà u rendiment di Postgres, migliurà e capacità di pulizia, cusì l'ID di transazzione virtuale hè custituitu da dui numeri. U primu numeru prima di a barra hè l'ID backend. È à a diritta vedemu solu un contatore.
Dunque, se esegui una dumanda, dice chì l'ID backend hè 2.
È s'è aghju realizatu una seria di tali transazzioni, allora vedemu chì u contatore aumenta ogni volta chì eseguite una dumanda. Per esempiu, quandu eseguite a query 2/10, 2/11, 2/12, etc.
Tenite in mente chì ci sò dui culonni quì. A manca, vedemu l'ID transazzione virtuale - 2/12. È à a diritta avemu un ID di transazzione permanente. È stu campu hè viotu. È sta transazzione ùn cambia micca a basa di dati. Allora ùn li dete micca un ID di transazzione permanente.
Appena eseguite u cumandamentu di analisi ((ANALYZE)), a stessa dumanda mi dà un ID di transazzione permanente. Fighjate cumu questu hè cambiatu per noi. Ùn aghju micca questu ID prima, ma avà l'aghju.
Allora eccu una altra dumanda, una altra transazzione. U numeru di transazzione virtuale hè 2/13. È se dumandu un ID di transazzione persistente, allora quandu eseguite a dumanda, l'aghju da ottene.
Allora, una volta di più. Avemu un ID di transazzione virtuale è un ID di transazzione persistente. Basta à capisce stu puntu per capisce u cumpurtamentu di Postgres.
Passemu à a terza sezione. Quì andemu simpricimenti attraversu i diversi tipi di serrature in Postgres. Ùn hè micca assai interessante. L'ultima sezione serà assai più interessante. Ma avemu da cunsiderà e cose basi, perchè altrimenti ùn avemu micca capisce ciò chì succede dopu.
Andemu à traversu sta rùbbrica, avemu Mulateri Di L'esse in ogni tipu di serratura. È vi mustraraghju esempi di cumu sò stallati, cumu si travaglianu, vi mustraraghju alcune dumande chì pudete aduprà per vede cumu funziona u bloccu in Postgres.
Per creà una dumanda è vede ciò chì succede in Postgres, avemu bisognu di emette a dumanda in a vista di u sistema. In questu casu, pg_lock hè evidenziatu in rossu. Pg_lock hè una tavola di sistema chì ci dice chì i chjusi sò attualmente in usu in Postgres.
Tuttavia, hè assai difficiule per mè di mostrà pg_lock da ellu stessu perchè hè abbastanza cumplessu. Allora aghju creatu una vista chì mostra pg_locks. È ancu fà un travagliu per mè chì mi permette di capisce megliu. Questu hè, esclude i mo chjusi, a mo propria sessione, etc. Hè solu SQL standard è vi permette di vede megliu ciò chì succede.
Un altru prublema hè chì sta vista hè assai larga, cusì aghju da creà una seconda - lockview2.
È mi mostra più colonne da a tavula. È un altru chì mi mostra u restu di e culonne. Questu hè abbastanza cumplessu, cusì aghju pruvatu à presentà u più simplice pussibule.
Allora avemu creatu una tavola chjamata Lockdemo. È avemu creatu una linea quì. Questa hè a nostra tabella di mostra. È creeremu sezioni solu per mostrà esempi di serrature.
Dunque, una fila, una colonna. U primu tipu di serratura hè chjamatu ACCESS SHARE. Questu hè u bloccu menu restrittivu. Questu significa chì praticamenti ùn hè micca cunflittu cù altre serrature.
E s'è no vulemu definisce esplicitamente una serratura, avemu eseguitu u cumandimu "tavula di serratura". È ovviamente bluccà, vale à dì in u modu ACCESS SHARE lancemu a tavola di serratura. È se eseguiu PSQL in sfondate, allora principià a seconda sessione da a mo prima sessione in questu modu. Questu hè, chì faraghju quì ? Vaiu à una altra sessione è dicu "mostrami u lockview per sta dumanda". È quì aghju AccessShareLock in questa tavula. Questu hè esattamente ciò chì aghju dumandatu. È dice chì u bloccu hè statu assignatu. Assai sèmplice.
In più, si guardemu à a seconda colonna, allora ùn ci hè nunda. Sò vioti.
È se eseguite u cumandamentu "SELECT", allora questu hè u modu implicitu (esplicito) per dumandà AccessShareLock. Allora aghju liberatu a mo tavola è eseguite a dumanda è a dumanda torna parechje fila. È in una di e linee vedemu AccessShareLock. Cusì, SELECT chjama AccessShareLock nantu à a tavula. È ùn hè micca cunflittu cù quasi nunda perchè hè una serratura di livellu bassu.
E se eseguissi un SELECT è aghju trè tabelle diverse? In precedenza eseguiva solu una tavola, avà ne sò trè: pg_class, pg_namespace è pg_attribute.
È avà quandu mi fighjulà à a dumanda, vecu 9 AccessShareLocks in trè tavule. Perchè? Trè tavule sò evidenziate in blu: pg_attribute, pg_class, pg_namespace. Ma pudete ancu vede chì tutti l'indici chì sò definiti attraversu sti tavulini anu ancu AccessShareLock.
È questu hè un serratura chì praticamenti ùn hè micca cunflittu cù l'altri. È tuttu ciò chì face hè simplicemente impedisce di resettate a tavola mentre a selezziunà. Hè sensu. Questu hè, se selezziunà una tavola, sparisce in quellu mumentu, allora questu hè sbagliatu, cusì AccessShare hè una serratura di livellu bassu chì ci dice "ùn abbandunà micca sta tavola mentre aghju travagliatu". Essenzialmente, hè tuttu ciò chì face.
ROW SHARE - Questa serratura hè un pocu sfarente.
Pigliemu un esempiu. SELECT ROW SHARE metudu di chjude ogni fila individualmente. Questu modu nimu pò sguassate o cambià mentre li guardemu.
Allora chì face SHARE LOCK? Avemu vistu chì l'ID di transazzione hè 681 per SELECT. È questu hè interessante. Chì hè accadutu quì ? A prima volta chì vedemu u numeru hè in u campu "Lock". Pigliemu l'ID di transazzione è dice chì u blucca in modu exclusivu. Tuttu ciò chì face hè chì dice chì aghju una fila chì hè tecnicamente chjusa in un locu in a tavula. Ma ùn dice micca induve esattamente. Fighjuleremu questu in più detail un pocu dopu.
Quì dicemu chì a serratura hè aduprata da noi.
Dunque, una serratura esclusiva dice esplicitamente chì hè esclusiva. È ancu s'ellu sguassate una fila in questa tavula, allora questu hè ciò chì succede, cum'è pudete vede.
SHARE EXCLUSIVE hè una serratura più longa.
Questu hè u cumandamentu di l'analizzatore (ANALYZE) chì serà utilizatu.
SHARE LOCK - pudete chjappà esplicitamente in modu di sparte.
Pudete ancu creà un indice unicu. È quì pudete vede SHARE LOCK, chì face parte di elli. È chjude a tavula è mette un SHARE LOCK nantu à questu.
Per automaticamente, SHARE LOCK nantu à una tavula significa chì l'altri populi ponu leghje a tavola, ma nimu pò mudificà. È questu hè esattamente ciò chì succede quandu crea un indice unicu.
Se crea un indici unicu simultaneamente, allora avarà un altru tipu di bloccu perchè, cum'è vi ricordate, l'usu di l'indici simultaneamente riduce u requisitu di bloccu. È s'è aghju utilizatu un serratura normale, un indice normale, allora impedisceraghju cusì di scrive à l'indici di a tavola mentre hè creatu. Se aghju utilizatu un indici simultaneamente, allora aghju bisognu di utilizà un altru tipu di chjusi.
SHARE ROW EXCLUSIVE - dinò pò esse stabilitu esplicitamente (esplicitamente).
O pudemu creà una regula, vale à dì, piglià un casu specificu in quale serà utilizatu.
A serratura EXCLUSIVA significa chì nimu altru pò cambià a tavola.
Quì vedemu diversi tipi di serrature.
ACCESS EXCLUSIVE, per esempiu, hè un cumandamentu di bloccu. Per esempiu, sè vo fate CLUSTER table, tandu questu significarà chì nimu ùn puderà scrive quì. È chjude micca solu a tavula stessu, ma ancu l'indici.
Questa hè a seconda pagina di u bloccu ACCESS EXCLUSIVE, induve vedemu esattamente ciò chì blucca in a tavula. Blocca e fila di tavulinu individuali, chì hè abbastanza interessante.
Hè tutta l'infurmazioni basi chì vulia dà. Avemu parlatu di chjusi, di ID di transazzione, avemu parlatu di ID di transazzione virtuale, di ID di transazzione permanente.
È avà andemu à traversu qualchi esempi di bluccatu. Questa hè a parte più interessante. Fighjemu casi assai interessanti. È u mo scopu in questa presentazione hè di dà una megliu comprensione di ciò chì Postgres hè veramente fattu quandu prova di bluccà certe cose. Pensu chì hè assai bravu à bluccà e parti.
Fighjemu alcuni esempi specifichi.
Cumincià cù tavule è una fila in una tavula. Quandu aghju inseritu qualcosa chì aghju ExclusiveLock, Transaction ID è ExclusiveLock affissatu nantu à a tavula.
Chì succede s'ellu inserisci duie fila più? È avà a nostra tavula hà trè fila. E aghju inseritu una fila è aghju avutu questu cum'è output. È s'è aghju inseritu duie fila più, chì hè stranu in questu? Ci hè una cosa strana quì perchè aghju aghjustatu trè fila à sta tavula, ma aghju ancu duie fila in a tavola di serratura. È questu hè essenzialmente u cumpurtamentu fundamentale di Postgres.
Parechje persone pensanu chì se in una basa di dati chjude 100 fila, allora avete bisognu di creà 100 entrate di serratura. Se bloccu 1 fila in una volta, allora aghju bisognu di 000 tali dumande. È s'ellu ci vole un milione o un miliardo per bluccà. Ma se facemu questu, ùn hà micca travagliatu bè. Se avete usatu un sistema chì crea entrate di bloccu per ogni fila individuale, pudete vede chì questu hè cumplicatu. Perchè avete bisognu di definisce immediatamente una tavula di serratura chì pò soprappià, ma Postgres ùn face micca.
È ciò chì hè veramente impurtante di sta diapositiva hè chì dimostra chjaramente chì ci hè un altru sistema chì funziona in MVCC chì chjude e file individuali. Allora quandu chjude miliardi di fila, Postgres ùn crea micca un miliardi di cumandamenti di bloccu separati. È questu hà un effettu assai bonu nantu à a produtividade.
Chì ci hè un aghjurnamentu? Aghju aghjurnatu a fila avà, è pudete vede chì hà realizatu duie operazioni diverse à una volta. Chjave a tavula à u stessu tempu, ma ancu chjude l'indici. È avia bisognu di chjude l'indici perchè ci sò limitazioni uniche nantu à sta tavula. È vulemu assicurà chì nimu ùn cambia, cusì u bluccà.
Chì succede se vogliu aghjurnà duie fila? È vedemu chì si cumporta u listessu modu. Facemu duie volte più aghjurnamenti, ma esattamente u listessu numeru di linee di serratura.
Se vi dumandate cumu Postgres faci questu, avete bisognu à sente i mo discorsi nantu à MVCC per sapè cumu Postgres marca internamente queste linee chì cambia. È Postgres hà una manera in quale si face questu, ma ùn a face micca à u livellu di bloccu di a tavola, a face à un livellu più bassu è più efficiente.
E se vogliu sguassà qualcosa? Sè sguassate, per esempiu, una fila è aghju sempre i mo dui inputs di bluccatu, è ancu s'ellu vogliu sguassà tutti, sò sempre quì.
E, per esempiu, vogliu inserisce 1 linee, è dopu o sguassate o aghjunghje 000 linee, allora quelli ligne individuali chì aghju aghjustatu o cambiatu, ùn sò micca arregistrati quì. Sò scritti à un livellu più bassu in a serie stessa. È durante u discorsu MVCC aghju parlatu di questu in dettu. Ma hè assai impurtante quandu analizà i chjusi per assicurà chì site chjusu à u livellu di a tavula è chì ùn site micca vede cumu e file individuali sò registrate quì.
E u bloccu esplicitu?
Se cliccu nantu à rinfriscà, aghju duie file chjuse. È s'è aghju selezziunate tutti è cliccate "aghjurnà in ogni locu", allora aghju sempre dui records di bloccu.
Ùn creamu micca registri separati per ogni fila individuale. Perchè allora a produtividade cade, pò esse troppu. È pudemu truvà in una situazione spiacevoli.
E listessa cosa, se facemu spartutu, pudemu fà tuttu 30 volte.
Ripristinamu a nostra tavola, sguassate tuttu, dopu inserite una fila di novu.
Un altru cumpurtamentu chì vede in Postgres chì hè assai cunnisciutu è cumportamentu desideratu hè chì pudete fà una aghjurnazione o una selezzione. È pudete fà questu à u stessu tempu. E selezziunà ùn bluccà l'aghjurnamentu è a stessa cosa in a direzzione opposta. Dicemu à u lettore per ùn bluccà u scrittore, è u scrittore ùn hà micca bluccatu u lettore.
Vi mustraraghju un esempiu di questu. Faraghju una scelta avà. Dopu faremu l'INSERT. E poi pudete vede - 694. Pudete vede l'ID di a transazzione chì hà realizatu sta inserzione. È cusì funziona.
È se mi guardu à u mo ID backend avà, hè avà 695.
È possu vede 695 apparsu in a mo tavula.
È se aghju aghjurnatu quì cusì, allora aghju un casu diversu. In questu casu, 695 hè una serratura esclusiva, è l'aghjurnamentu hà u stessu cumpurtamentu, ma ùn ci hè micca cunflittu trà elli, chì hè abbastanza inusual.
È pudete vede chì in cima hè ShareLock, è in fondu hè ExclusiveLock. È e duie transazzione anu travagliatu.
È avete bisognu à sente u mo discorsu à MVCC per capisce cumu succede questu. Ma questu hè un'illustrazione chì pudete fà à u stessu tempu, vale à dì fà un SELECT è un UPDATE à u stessu tempu.
Resettamu è fate una altra operazione.
Se pruvate à eseguisce duie aghjurnamenti simultaneamente nantu à a listessa fila, serà bluccatu. È ricurdate, aghju dettu chì u lettore ùn blucca micca u scrittore, è u scrittore ùn blucca micca u lettore, ma un scrittore blucca un altru scrittore. Questu hè, ùn pudemu micca avè duie persone aghjurnà a listessa fila à u stessu tempu. Avete da aspittà finu à chì unu di elli finisci.
È per illustrà questu, fighjuleraghju à a tavola Lockdemo. È guardemu una fila. Per transazzione 698.
Avemu aghjurnatu questu à 2. 699 hè a prima aghjurnazione. È era successu o hè in una transazzione pendente è aspetta per noi per cunfirmà o annullà.
Ma fighjate à qualcosa altru - 2/51 hè a nostra prima transazzione, a nostra prima sessione. 3/112 hè a seconda dumanda chì hè vinuta da a cima chì hà cambiatu quellu valore à 3. E se avete nutatu, a cima si chjude, chì hè 699. Ma 3/112 ùn hà micca cuncessu u serratura. A colonna Lock_mode dice ciò chì aspetta. S'aspittava 699. È si fighjate induve 699 hè, hè più altu. È chì hà fattu a prima sessione ? Hà creatu un serratura esclusiva nantu à u so propiu ID di transazzione. Questu hè cumu si face Postgres. Blocca u so propiu ID di transazzione. È se vulete aspittà chì qualchissia per cunfirmà o annullà, allora avete bisognu à aspittà mentre ci hè una transazzione pendente. È hè per quessa chì pudemu vede una linea strana.
Fighjemu di novu. A manca vedemu u nostru ID di trasfurmazioni. In a seconda colonna vedemu u nostru ID transazzione virtuale, è in a terza vedemu lock_type. Chì significà questu? Essenzialmente ciò chì dice hè chì blucca l'ID di transazzione. Ma nutate chì tutte e fila in u fondu dicenu relazione. È cusì avete dui tipi di chjusi nantu à a tavula. Ci hè una serratura di relazione. E poi ci hè u bloccu di transazzione, induve si bluccà nantu à u vostru propiu, chì hè esattamente ciò chì succede in a prima fila o in u fondu, induve hè u transazzione, induve aspittemu 699 per finisce a so operazione.
Videraghju ciò chì succede quì. E quì duie cose succedenu simultaneamente. Avete cercatu un lock ID di transazzione in a prima fila chì si chjude. È si blocca per fà aspittà a ghjente.
Se fighjate à a 6a linea, hè a stessa entrata cum'è a prima. È dunque a transazzione 699 hè bluccata. 700 hè ancu autobloccante. È dopu in a fila di fondu vi vede chì aspettemu chì 699 finiscinu u so funziunamentu.
È in lock_type, tuple vi vede numeri.
Pudete vede chì hè 0/10. È questu hè u numeru di pagina, è ancu l'offset di sta fila particulare.
È vede chì diventa 0/11 quandu aghjurnemu.
Ma in realtà hè 0/10, perchè ci hè una aspittà per questa operazione. Avemu l'uppurtunità di vede chì questa hè a serie chì aghju aspittendu per cunfirmà.
Una volta l'avemu cunfirmatu è pressatu commit, è quandu l'aghjurnamentu hè finitu, questu hè ciò chì avemu torna. A transazzione 700 hè l'unicu serratura, ùn aspetta per nimu perchè hè stata impegnata. Simply aspetta chì a transazzione finisci. Una volta chì 699 hè finitu, ùn aspittemu più nunda. È avà a transazzione 700 dice chì tuttu hè bè, chì hà tutte e serrature chì hà bisognu in tutti i tavulini permessi.
È per fà questu tuttu ancu più cumplicatu, creamu una altra vista, chì sta volta ci furnisce una ghjerarchia. Ùn m'aspettu micca chì capisce sta dumanda. Ma questu ci darà una vista più chjara di ciò chì succede.
Questa hè una vista recursiva chì hà ancu una altra sezione. E poi riunisce tuttu di novu. Usemu questu.
E se facemu trè aghjurnamenti simultanei è dicemu chì a fila hè avà trè. È cambiemu da 3 à 4.
È quì vedemu 4. E transazzione ID 702.
E poi cambieraghju da 4 à 5. È da 5 à 6, è da 6 à 7. E aghju infilzatu un numeru di persone chì aspittàvanu chì sta transazzione finisci.
È tuttu diventa chjaru. Chì ghjè a prima fila ? Questu hè 702. Questu hè l'ID di transazzione chì hà stabilitu uriginale stu valore. Cosa hè scrittu in a mo colonna Granted? Aghju marcatu f. Eccu i mo aghjurnamenti chì (5, 6, 7) ùn ponu esse appruvati perchè aspettemu chì a transazzione ID 702 finisca. Ci avemu bluccatu ID transazzione. È questu risultatu in 5 serrature ID transazzione.
È s'è vo fighjate à 704, à 705, ùn ci hè ancu scrittu nunda, perchè ùn sanu micca ciò chì passa. Simply scrivenu chì ùn anu micca idea di ciò chì succede. È andaranu solu per dorme perchè aspettanu chì qualcunu finisci è si sveglia quandu ci hè l'uppurtunità di cambià fila.
Questu hè ciò chì pare. Hè chjaru chì sò tutti aspittendu a 12a linea.
Questu hè ciò chì avemu vistu quì. Eccu 0/12.
Allora una volta chì a prima transazzione hè appruvata, pudete vede quì cumu funziona a ghjerarchia. È avà tuttu diventa chjaru. Tutti diventanu puliti. È in realtà sò sempre aspittendu.
Eccu ciò chì succede. 702 impegni. È avà 703 riceve stu bloccu di fila, è dopu 704 cumencia à aspittà chì 703 si cummette. È u 705 aspetta ancu questu. È quandu tuttu questu hè cumpletu, si puliscenu. È vogliu nutà chì tutti sò in fila. È questu hè assai simili à una situazione in un trafficu di trafficu quandu tutti aspettanu a prima vittura. A prima vittura si ferma è ognunu si mette in fila. Allora si move, allora a prossima vittura pò guidà avanti è uttene u so bloccu, etc.
È s'ellu ùn vi pareva micca abbastanza cumplicatu, allora vi parleremu di i blocchi. Ùn sò micca sapè quale di voi li hà scontru. Questu hè un prublema abbastanza cumuni in i sistemi di basa di dati. Ma i blocchi sò quandu una sessione aspetta per una altra sessione per fà qualcosa. È in questu mumentu una altra sessione aspetta a prima sessione per fà qualcosa.
È, per esempiu, se Ivan dice: "Datemi qualcosa", è dicu: "No, vi daraghju solu s'è tù mi dai qualcosa d'altru". È ellu dice: "No, ùn ti daraghju micca sè ùn mi daraghju micca". È finiscemu in una situazione di bloccu. Sò sicuru chì Ivan ùn farà micca questu, ma avete capitu u significatu chì avemu dui persone chì volenu ottene qualcosa è ùn sò micca pronti à dà finu à chì l'altra persona li dà ciò chì volenu. È ùn ci hè micca suluzione.
È essenzialmente, a vostra basa di dati hà bisognu di detectà questu. È dopu avete bisognu di sguassà o chjude una di e sessioni, perchè altrimenti fermanu per sempre. È vedemu in basa di dati, vedemu in sistemi operativi. È in tutti i lochi induve avemu prucessi paralleli, questu pò succede.
È avà avemu da stallà dui blocchi. Puderemu 50 è 80. In a prima fila, aghju da aghjurnà da 50 à 50. Averaghju u numeru di transazzione 710.
E poi cambieraghju da 80 à 81, è da 50 à 51.
È questu hè ciò chì parerà. È cusì 710 hà una fila bluccata, è 711 aspetta a cunferma. Avemu vistu questu quandu avemu aghjurnatu. 710 hè u pruprietariu di a nostra serie. È 711 aspetta 710 per compie a transazzione.
È ancu dice in quale fila si verificanu i blocchi. È quì hè induve principia à esse stranu.
Avà aghjurnemu da 80 à 80.
È questu hè induve cumincianu i blocchi. 710 aspetta una risposta da 711, è 711 aspetta 710. È questu ùn finisce micca bè. È ùn ci hè manera di esce da questu. È aspittàranu una risposta da l'altru.
È appena principià à ritardà tuttu. È ùn vulemu micca cusì.
È Postgres hà modi per avvistà quandu questu succede. È quandu questu succede, avete stu errore. È da questu hè chjaru chì tali è un prucessu hè aspittendu per un SHARE LOCK da un altru prucessu, vale à dì, chì hè bluccatu da 711 prucessu. È quellu prucessu era aspittendu chì un SHARE LOCK sia datu nantu à una tale identificazione di transazzione è hè stata bluccata da un tali prucessu. Dunque, ci hè una situazione di bloccu quì.
Ci sò i blocchi à trè sensi? Hè pussibule ? Iè.
Insememu sti numeri in una tavula. Cambiamu da 40 à 40, facemu bluccatu.
Cambiamu da 60 à 61, da 80 à 81.
E poi cambiamu 80 è dopu boom !
È 714 aspetta avà u 715. U 716 aspetta u 715. È ùn si pò fà nunda.
Ùn ci sò più duie persone quì, ci sò digià trè persone quì. Vogliu qualcosa da voi, questu vole qualcosa da una terza persona, è a terza persona vole qualcosa da mè. È finiscemu in una attesa à trè vie perchè tutti aspettemu chì l'altra persona compie ciò chì deve fà.
È Postgres sapi in quale fila succede. È cusì vi darà u missaghju seguenti, chì mostra chì avete un prublema induve trè inputs sò bluccati. È ùn ci sò micca restrizioni quì. Questu pò esse u casu induve 20 entrate si bluccanu.
U prublema dopu hè serializable.
Se serratura serializabile speciale.
È turnemu à 719. A so pruduzzione hè abbastanza normale.
È pudete cliccà per fà a transazzione da serializable.
È capisci chì avà avete un altru tipu di serratura SA - significa serializable.
È cusì avemu un novu tipu di serratura chjamata SARieadLock, chì hè una serratura seriale è permette di entre in serial.
È ancu pudete inserisce indici unichi.
In questa tabella avemu indici unichi.
Allora si mette in u numeru 2 quì, cusì aghju un 2. Ma à a cima, aghju messu un altru 2 in. È pudete vede chì 721 hà un serratura esclusiva. Ma avà 722 aspetta chì 721 compie u so funziunamentu perchè ùn pò micca inserisce 2 finu à chì sà ciò chì succede à 721.
È si facemu subtransazzione.
Quì avemu 723.
È se salvemu u puntu è dopu aghjurnà, allora avemu un novu ID di transazzione. Questu hè un altru mudellu di cumpurtamentu chì avete bisognu di sapè. Se turnemu questu, allora l'ID di transazzione sparisce. 724 parte. Ma avà avemu 725.
Allora chì pruvu di fà quì? Pruvate di mostrà esempi di chjusi inusual chì pudete truvà: ch'ellu si tratti di chjusi serializzabili o SAVEPOINT, questi sò diversi tipi di chjusi chì appariscenu in a tavola di chjusi.
Questa hè a creazione di chjusi espliciti (espliciti), chì anu pg_advisory_lock.
È vede chì u tipu di bloccu hè listatu cum'è cunsigliu. E quì si dice "cunsigliu" in rossu. È pudete simultaneamente bluccà cusì cù pg_advisory_unlock.
È in cunclusioni, mi piacerebbe mustrà vi una cosa di più stupente. Crearaghju un'altra vista. Ma aghju unisce à a tavola pg_locks cù a tavola pg_stat_activity. E perchè vogliu fà questu? Perchè questu mi permetterà di vede è vede tutte e sessioni attuali è vede esattamente quale tipu di serratura stanu aspittendu. È questu hè abbastanza interessante quandu aghjustemu a tavola di serratura è a tavola di query.
È quì avemu creatu pg_stat_view.
È aghjurnemu a fila per unu. È quì vedemu 724. È dopu aghjurnà a nostra fila à trè. È chì vede quì avà ? Quessi sò dumande, vale à dì chì vede tutta a lista di e dumande chì sò listate in a colonna di manca. È dopu à u latu drittu pudete vede i blocchi è ciò chì creanu. È pò esse più chjaru per voi per chì ùn avete micca da vultà à ogni sessione ogni volta è vede s'ellu ci vole à unisce o micca. A facenu per noi.
Una altra funzione chì hè assai utile hè pg_blocking_pids. Probabilmente ùn avete mai intesu parlà di ella. Chì face ? Ci permette di dì chì per questa sessione 11740 chì ID di prucessu specifichi hè aspittendu. È pudete vede chì 11740 aspetta 724. È 724 hè in cima. È 11306 hè u vostru ID di prucessu. Essenzialmente, sta funzione passa per a vostra tavola di serratura. È sò chì hè un pocu cumplicatu, ma riesci à capisce. Essenzialmente sta funzione passa per questa tavola di serratura è prova di truvà induve stu ID di prucessu hè datu i serrature chì aspetta. È prova ancu di capisce quale ID di prucessu hà u prucessu chì aspetta a serratura. Allora pudete eseguisce sta funzione pg_blocking_pids.
È questu pò esse assai utile. Avemu aghjustatu solu in a versione 9.6, cusì sta funzione hè solu 5 anni, ma hè assai, assai utile. È u listessu vale à a seconda dumanda. Mostra esattamente ciò chì avemu bisognu di vede.
Hè ciò chì vulia parlà cun voi. È cum'è l'aspittava, avemu usatu tuttu u nostru tempu perchè ci era tanti slides. È i slides sò dispunibuli per scaricà. Vogliu ringrazià vi per esse quì. Sò sicuru chì vi piacerà u restu di a cunferenza, grazie mille !
Domande:
Per esempiu, sè vo circate di aghjurnà e fila, è a seconda sessione prova di sguassà tutta a tavola. Per ciò chì aghju capitu, ci deve esse qualcosa cum'è una serratura d'intenzione. Ci hè una cosa cusì in Postgres?
Riturnemu à u principiu. Pudete ricurdà chì quandu fate qualcosa, per esempiu, quandu fate un SELECT, emettemu un AccessShareLock. È questu impedisce a tavula da esse cascata. Allora se, per esempiu, vulete aghjurnà una fila in una tavula o sguassate una fila, allora qualchissia ùn pò micca sguassà tutta a tavola à u stessu tempu perchè tene stu AccessShareLock nantu à tutta a tavola è sopra a fila. È una volta chì avete finitu, ponu sguassà. Ma mentre cambiassi direttamente qualcosa quì, ùn puderanu micca fà.
Facemu di novu. Andemu à l'esempiu di sguassà. È vede cumu ci hè un serratura esclusiva nantu à a fila sopra tutta a tavola.
Questu serà cum'è una serratura esclusiva, nò?
Iè, pare. Capiscu di ciò chì parli. Stai dicendu chì se facciu un SELECT allora aghju un ShareExclusive è poi l'aghju fattu Row Exclusive, hè diventatu un prublema? Ma sorprendentemente questu ùn pone micca un prublema. Questu pare chì aumentà u gradu di serratura, ma essenzialmente aghju un serratura chì impedisce a cancellazione. È avà, quandu aghju fattu sta serratura più putente, impedisce ancu a cancellazione. Allora ùn hè micca cum'è ch'e aghju cullà. Vale à dì, hà impeditu di succede quandu era ancu à un livellu più bassu, cusì quandu aghju elevatu u so livellu impedisce ancu a tavula da esse eliminata.
Capiscu di ciò chì parli. Ùn ci hè micca casu di scalazione di serratura quì, induve pruvate di rinunzià una serratura per intruduce una più forte. Eccu solu aumenta sta prevenzione in tuttu u bordu, perchè ùn causa micca alcun cunflittu. Ma hè una bona quistione. Grazie mille per dumandà questu!
Chì ci vole à fà per evità una situazione di bloccu quandu avemu parechje sessioni, un gran numaru d'utilizatori ?
Postgres nota automaticamente situazioni di blocco. È sguasserà automaticamente una di e sessione. L'unicu modu per evità u bloccu mortu hè di bluccà e persone in u listessu ordine. Allora, quandu vi fighjate à a vostra applicazione, spessu u mutivu di i blocchi... Imaginemu chì vogliu bluccà duie cose diverse. Una applicazione chjude a tavula 1, è una altra applicazione chjude 2, è dopu a tavola 1. È u modu più faciule per evità i blocchi hè di guardà a vostra applicazione è pruvate d'assicurà chì u chjusu si faci in u listessu ordine in tutte l'applicazioni. È questu generalmente elimina u 80% di i prublemi, perchè ogni tipu di persone scrive queste applicazioni. È s'ellu li bluccate in u listessu ordine, ùn avete micca scontru una situazione di bloccu.
Grazie mille per a vostra prestazione! Avete parlatu di u vacuum full è, se capiscu bè, u vacuum full distorte l'ordine di i registri in un almacenamentu separatu, cusì mantenenu i registri attuali invariati. Perchè u vacuum full piglia l'accessu di serratura esclusiva è perchè hè in cunflittu cù operazioni di scrittura?
Hè una bona quistione. U mutivu hè chì u vacuum pienu piglia a tavola. È avemu essenzalmenti di creà una nova versione di a tavula. È a tavola serà nova. Risulta chì questu serà una versione completamente nova di a tavola. È u prublema hè chì quandu facemu questu, ùn vulemu micca chì a ghjente leghjia perchè avemu bisognu di vede a nova tavola. È cusì si cunnetta à a quistione precedente. Se pudemu leghje à u stessu tempu, ùn sariamu micca capaci di spustà è dirige a ghjente à una nova tavola. Avemu bisognu di aspittà chì tutti finiscinu di leghje sta tavola, è cusì hè essenzialmente una situazione esclusiva di serratura.
Dicemu solu chì chjudemu da u principiu perchè sapemu chì à a fine avemu bisognu di una serratura esclusiva per spustà tutti à a nova copia. Allora pudemu risolve questu. È facemu cusì cù l'indexazione simultanea. Ma questu hè assai più difficiule di fà. È questu hè assai legatu à a vostra dumanda precedente nantu à a serratura esclusiva.
Hè pussibule aghjunghje u timeout di bloccu à Postgres? In Oracle, possu, per esempiu, scrive "select to update" è aspittà 50 seconde prima di aghjurnà. Era bonu per l'applicazione. Ma in Postgres, sia bisognu di fà subitu è ùn aspittà micca, o aspittà finu à qualchì tempu.
Iè, pudete sceglie un timeout nantu à i vostri chjusi, nantu à i vostri chjusi. Pudete ancu emette un cumandamentu senza manera, chì serà ... se ùn pudete micca immediatamente ottene u serratura. Dunque, sia un timeout di serratura o qualcosa d'altru chì vi permetterà di fà questu. Questu ùn hè micca fattu à u livellu sintatticu. Questu hè fattu cum'è una variabile in u servitore. Calchì volta stu ùn pò esse usatu.
Pudete apre u slide 75?
Sì.
È a mo dumanda hè a seguente. Perchè i dui prucessi di aghjurnamentu aspettanu 703?
È questu hè una grande quistione. Ùn capiscu micca, per via, perchè Postgres faci questu. Ma quandu 703 hè statu creatu, s'aspittava 702. È quandu 704 è 705 appariscenu, pare ch'elli ùn sanu micca ciò ch'elli aspettanu perchè ùn ci hè nunda. È Postgres face cusì: quandu ùn pudete micca ottene una serratura, scrive "Chì hè u puntu di trasfurmà voi?", perchè avete digià aspittendu qualcunu. Allora l'avemu da lascià appesu in l'aria, ùn l'aghjurnà micca in tuttu. Ma chì hè accadutu quì? Appena 702 compie u prucessu è 703 ricivutu a so serratura, u sistema hà tornatu. È hà dettu chì avà avemu duie persone chì aspettanu. E poi aghjurnemu inseme. È indichemu chì i dui sò aspittendu.
Ùn sò micca sapè perchè Postgres faci questu. Ma ci hè un prublema chjamatu f... Mi pari chì questu ùn hè micca un termini in russo. Questu hè quandu tutti aspettanu un casteddu, ancu s'ellu ci sò 20 autorità chì aspettanu u castellu. È di colpu si sveglianu tutti à u listessu tempu. È tutti cumincianu à pruvà à reagisce. Ma u sistema face cusì chì tutti aspittàvanu 703. Perchè sò tutti aspittendu, è l'avemu subitu in linea tutti. È s'ellu ci hè una altra nova dumanda chì hè stata generata dopu à questu, per esempiu, 707, allora ci sarà di novu vacu.
È mi pare chì questu hè fattu per chì pudemu dì chì in questa tappa 702 hè aspittendu 703, è tutti quelli chì venenu dopu ùn anu micca entrata in questu campu. Ma appena u primu servitore parte, tutti quelli chì aspittàvanu in quellu mumentu prima di l'aghjurnamentu ricevenu u listessu token. È cusì pensu chì questu hè fattu in modu chì pudemu processà in ordine per ch'elli sò urdinati bè.
Aghju sempre vistu questu cum'è un fenomenu piuttostu stranu. Perchè quì, per esempiu, ùn avemu micca listessi in tuttu. Ma mi pari chì ogni volta chì duvemu una nova serratura, guardemu à tutti quelli chì sò in u prucessu di aspittà. Allora li mettemu tutti in fila. È dopu ogni novu chì entra solu in a fila quandu a prossima persona hà finitu di esse processatu. Assai bona dumanda. Grazie assai per a vostra dumanda!
Mi pari chì hè assai più logicu quandu 705 aspetta 704.
Ma u prublema quì hè u seguente. Tecnicamente, pudete svegliate unu o l'altru. È cusì ci sveglieremu unu o l’altru. Ma chì succede in u sistema? Pudete vede cumu 703 à a cima hà bluccatu u so propiu ID di transazzione. Questu hè cumu funziona Postgres. È 703 hè bluccatu da u so propiu ID di transazzione, perchè se qualchissia vole aspittà, allora aspittàranu per 703. È, in esencia, 703 cumpleta. È solu dopu à a so cumpiimentu, unu di i prucessi si sveglia. È ùn sapemu micca esattamente ciò chì serà stu prucessu. Allora processemu tuttu gradualmente. Ma ùn hè micca chjaru quale prucessu hè svegliatu prima, perchè puderia esse qualsiasi di sti prucessi. Essenzialmente, avemu avutu un pianificatore chì hà dettu chì pudemu avà svegliate qualsiasi di sti prucessi. Avemu solu sceglie unu à u casu. Allora i dui deve esse nutati perchè pudemu sveglià l'un l'altru.
È u prublema hè chì avemu CP-infinity. È per quessa, hè abbastanza prubabile chì pudemu sveglià u più tardi. E se, per esempiu, svegliemu u più tardi, aspitteremu quellu chì hè ghjustu ricevutu u bloccu, cusì ùn determinemu micca esattamente quale serà svegliatu prima. Creemu simpricimenti una tale situazione, è u sistema li svegliarà in un ordine aleatoriu.
Ci sò . Fighjate, sò ancu interessanti è utili. U tema, sicuru, hè terribilmente cumplessu. Grazie mille, Bruce!
Source: www.habr.com