http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex><\/p>\n<\/p>\n
Privim. Cu ro\u0219u este eviden\u021biat num\u0103rul tranzac\u021biei. Aici este ar\u0103tat\u0103 func\u021bia SELECT pg_back. Aceasta returneaz\u0103 tranzac\u021bia mea \u0219i ID-ul acestei tranzac\u021bii. <\/p>\n
<\/p>\n
Un alt aspect, dac\u0103 v\u0103 place aceast\u0103 prezentare \u0219i dori\u021bi s\u0103 o rula\u021bi \u00een baza de date, pute\u021bi urma acest link marcat cu roz \u0219i desc\u0103rca SQL-ul pentru aceast\u0103 prezentare. O pute\u021bi rula pur \u0219i simplu \u00een PSQL-ul dvs. \u0219i toat\u0103 prezentarea va ap\u0103rea imediat pe ecranul dvs. Nu va con\u021bine culori, dar m\u0103car o vom putea vedea.<\/p>\n
<\/p>\n
<\/p>\n
\u00cen acest caz, vedem ID-ul tranzac\u021biei. Acesta este num\u0103rul pe care i l-am atribuit. Mai exist\u0103 un tip de ID de tranzac\u021bie \u00een Postgres, care se nume\u0219te ID virtual de tranzac\u021bie.<\/p>\n
<\/p>\n
\u0218i trebuie s\u0103 \u00een\u021belegem acest lucru. Este foarte important, altfel nu vom putea \u00een\u021belege blocajul \u00een Postgres.<\/p>\n
<\/p>\n
ID-ul virtual de tranzac\u021bie este ID-ul tranzac\u021biei care nu con\u021bine valori permanente. De exemplu, dac\u0103 execut o comand\u0103 SELECT, sunt foarte probabil s\u0103 nu modific baza de date, nu voi bloca nimic. De aceea, c\u00e2nd execut\u0103m un simplu SELECT, nu oferim acestui tip de tranzac\u021bie un ID permanent. \u00cei oferim doar un ID virtual.<\/p>\n
<\/p>\n
\u0218i aceasta \u00eembun\u0103t\u0103\u021be\u0219te performan\u021ba Postgres, oferind mai multe oportunit\u0103\u021bi pentru cur\u0103\u021bare, astfel ID-ul virtual de tranzac\u021bie const\u0103 din dou\u0103 numere. Primul num\u0103r \u00eenainte de slash este ID-ul backend-ului. Iar pe dreapta vedem un simplu contor.<\/p>\n
<\/p>\n
<\/p>\n
Prin urmare, dac\u0103 execut un query, spune c\u0103 ID-ul backend-ului este 2. <\/p>\n
<\/p>\n
<\/p>\n
Iar dac\u0103 execut o serie de astfel de tranzac\u021bii, vedem c\u0103 contorul cre\u0219te de fiecare dat\u0103 c\u00e2nd execut un query. De exemplu, c\u00e2nd execut query-uri 2\/10, 2\/11, 2\/12 etc. <\/p>\n
<\/p>\n
<\/p>\n
Re\u021bine\u021bi c\u0103 aici sunt dou\u0103 coloane. Pe st\u00e2nga vedem ID-ul virtual de tranzac\u021bie \u2013 2\/12. Iar pe dreapta avem ID-ul permanent de tranzac\u021bie. \u0218i acest c\u00e2mp este gol. Aceast\u0103 tranzac\u021bie nu modific\u0103 baza de date. Prin urmare, nu \u00eei atribui un ID permanent de tranzac\u021bie.<\/p>\n
<\/p>\n
<\/p>\n
De \u00eendat\u0103 ce execut comanda ANALYZE, acela\u0219i query \u00eemi ofer\u0103 un ID permanent de tranzac\u021bie. Observa\u021bi cum s-a schimbat acest lucru. Anterior nu aveam acest ID, acum a ap\u0103rut.<\/p>\n
<\/p>\n
<\/p>\n
A\u0219adar, iat\u0103 un alt query, o alt\u0103 tranzac\u021bie. Num\u0103rul virtual de tranzac\u021bie este 2\/13. \u0218i dac\u0103 solicit ID-ul permanent de tranzac\u021bie, atunci c\u00e2nd execut query-ul, \u00eel voi ob\u021bine. <\/p>\n
<\/p>\n
<\/p>\n
A\u0219adar, \u00eenc\u0103 o dat\u0103. Avem ID-ul virtual de tranzac\u021bie \u0219i ID-ul permanent de tranzac\u021bie. Doar \u00een\u021belege\u021bi acest aspect pentru a \u00een\u021belege comportamentul Postgres.<\/p>\n
<\/p>\n
<\/p>\n
Trecem la a treia sec\u021biune. Aici vom trece prin diferitele tipuri de bloc\u0103ri din Postgres. Nu este foarte interesant. Ultima sec\u021biune va fi mult mai captivant\u0103. Dar trebuie s\u0103 lu\u0103m \u00een considerare lucrurile de baz\u0103, altfel nu vom \u00een\u021belege ce va urma. <\/p>\n
<\/p>\n
Vom parcurge aceast\u0103 sec\u021biune, vom analiza fiecare tip de blocaj. \u0218i v\u0103 voi ar\u0103ta exemple despre cum sunt stabilite, cum func\u021bioneaz\u0103, v\u0103 voi ar\u0103ta c\u00e2teva interog\u0103ri pe care le pute\u021bi folosi pentru a vedea cum func\u021bioneaz\u0103 blocajul \u00een Postgres.<\/p>\n
<\/p>\n
<\/p>\n
Pentru a crea o interogare \u0219i a vedea ce se \u00eent\u00e2mpl\u0103 \u00een Postgres, trebuie s\u0103 emitim o interogare \u00een system view. \u00cen acest caz, pg_lock este eviden\u021biat cu ro\u0219u. Pg_lock este o tabel\u0103 sistem care ne arat\u0103 ce bloc\u0103ri sunt folosite acum \u00een Postgres.<\/p>\n
<\/p>\n
Cu toate acestea, \u00eemi este foarte greu s\u0103 v\u0103 ar\u0103t pg_lock \u00een sine, deoarece este destul de complex. De aceea, am creat un view care arat\u0103 pg_locks. \u0218i acesta efectueaz\u0103, de asemenea, o munc\u0103 pentru mine, care \u00eemi permite s\u0103 \u00een\u021beleg mai bine. Adic\u0103, exclude bloc\u0103rile mele, sesiunea mea etc. Este doar SQL standard \u0219i \u00eemi permite s\u0103 v\u0103 ar\u0103t mai bine ceea ce se \u00eent\u00e2mpl\u0103. <\/p>\n
<\/p>\n
<\/p>\n
O alt\u0103 problem\u0103 este c\u0103 acest view este foarte larg, a\u0219a c\u0103 a trebuit s\u0103 creez unul secundar \u2013 lockview2.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
A\u0219adar, am creat o tabel\u0103, care se nume\u0219te Lockdemo. \u0218i am creat acolo o linie. Aceasta este tabela noastr\u0103 de referin\u021b\u0103. \u0218i vom crea sec\u021biuni pentru a v\u0103 ar\u0103ta exemple de bloc\u0103ri. <\/p>\n
<\/p>\n
<\/p>\n
A\u0219adar, o linie, o coloan\u0103. Primul tip de blocare se nume\u0219te ACCESS SHARE. Aceasta este cea mai pu\u021bin restrictiv\u0103 blocare. \u00censeamn\u0103 c\u0103 practic nu intr\u0103 \u00een conflict cu alte bloc\u0103ri.<\/p>\n
<\/p>\n
\u0218i dac\u0103 vrem s\u0103 definim explicit blocarea, execut\u0103m comanda \u201elock table\u201d. \u0218i aceasta va bloca explicit, adic\u0103 \u00een modul ACCESS SHARE execut\u0103m lock table. \u0218i dac\u0103 lansez PSQL \u00een fundal, atunci astfel \u00eencep a doua sesiune din prima mea sesiune. Adic\u0103, ce voi face aici? Voi trece la cealalt\u0103 sesiune \u0219i \u00eei voi spune \u201earat\u0103-mi lockview pentru aceast\u0103 \u00eentrebare\u201d. \u0218i aici am AccessShareLock \u00een aceast\u0103 tabel\u0103. Aceasta este exact ceea ce am cerut. \u0218i el spune c\u0103 blocarea a fost atribuit\u0103. Foarte simplu. <\/p>\n
<\/p>\n
<\/p>\n
\u00cen continuare, dac\u0103 ne uit\u0103m \u00een a doua coloan\u0103, nu exist\u0103 nimic. Sunt goale. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i dac\u0103 execut comanda \u201eSELECT\u201d, aceasta este o modalitate implicit\u0103 (explicit\u0103) de a solicita AccessShareLock. A\u0219adar, eliberez tabela mea \u0219i lansez interogarea, iar interogarea returneaz\u0103 c\u00e2teva linii. \u0218i \u00een una dintre linii vedem AccessShareLock. Astfel, SELECT genereaz\u0103 AccessShareLock \u00een tabel\u0103. \u0218i nu conflictueaz\u0103 practic cu nimic, deoarece este o blocare de nivel sc\u0103zut. <\/p>\n
<\/p>\n
<\/p>\n
Ce se \u00eent\u00e2mpl\u0103 dac\u0103 execut SELECT \u0219i am trei tabele diferite? Anterior executam doar o tabel\u0103, acum execut trei: pg_class, pg_namespace \u0219i pg_attribute.<\/p>\n
<\/p>\n
<\/p>\n
\u0218i acum, c\u00e2nd m\u0103 uit la interogare, v\u0103d 9 AccessShareLocks \u00een cele trei tabele. De ce? \u00cen culoarea albastr\u0103 sunt eviden\u021biate cele trei tabele: pg_attribute, pg_class, pg_namespace. Dar pute\u021bi vedea, de asemenea, c\u0103 toate indicii defini\u021bi prin aceste tabele au de asemenea AccessShareLock.<\/p>\n
<\/p>\n
\u0218i aceasta este o blocare care practic nu conflictueaz\u0103 cu altele. \u0218i tot ce face este s\u0103 nu ne permit\u0103 s\u0103 reset\u0103m tabela, at\u00e2ta timp c\u00e2t o select\u0103m. Acest lucru are sens. Adic\u0103, dac\u0103 select\u0103m o tabel\u0103, aceasta ar disp\u0103rea \u00een acel moment, ar fi gre\u0219it, a\u0219a c\u0103 AccessShare \u2013 este o blocare de nivel inferior care ne spune \"nu \u0219terge\u021bi aceast\u0103 mas\u0103, c\u00e2t timp lucrez eu\".<\/strong>. \u00cen esen\u021b\u0103, aceasta este tot ceea ce face. <\/p>\n<\/p>\n
<\/p>\n
ROW SHARE este o blocare pu\u021bin diferit\u0103. <\/p>\n
<\/p>\n
<\/p>\n
S\u0103 lu\u0103m un exemplu. SELECT ROW SHARE este modalitatea de blocare a fiec\u0103rei linii individual.<\/strong>. Astfel, nimeni nu poate s\u0103 le \u0219tearg\u0103 sau s\u0103 le modifice \u00een timp ce le vizion\u0103m. <\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
Aici spunem c\u0103 blocarea este folosit\u0103 de noi.<\/p>\n
<\/p>\n
<\/p>\n
A\u0219adar, blocarea exclusiv\u0103 spune \u00een mod explicit c\u0103 este exclusiv\u0103. \u0218i, de asemenea, dac\u0103 \u0219terge\u021bi o linie din acest tabel, aceasta se va \u00eent\u00e2mpla, a\u0219a cum pute\u021bi observa. <\/p>\n
<\/p>\n
<\/p>\n
SHARE EXCLUSIVE \u2013 este o blocare mai lung\u0103.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Aceasta (ANALYZE) este comanda analizatorului care va fi utilizat\u0103.<\/p>\n
<\/p>\n
<\/p>\n
SHARE LOCK \u2013 pute\u021bi bloca explicit \u00een modul share.<\/p>\n
<\/p>\n
<\/p>\n
De asemenea, pute\u021bi crea un index unic. \u0218i acolo pute\u021bi vedea SHARE LOCK, care face parte din acestea. \u0218i blocheaz\u0103 tabela \u0219i stabile\u0219te pe ea o blocare SHARE LOCK.<\/p>\n
<\/p>\n
Implicit, SHARE LOCK pe tabel \u00eenseamn\u0103 c\u0103 alte persoane pot citi tabela, dar nimeni nu o poate modifica. \u0218i aceasta este ceea ce se \u00eent\u00e2mpl\u0103 atunci c\u00e2nd crea\u021bi un index unic.<\/strong><\/p>\n<\/p>\n
Dac\u0103 creez un index concurrent unic, atunci voi avea un alt tip de blocare, deoarece, dup\u0103 cum v\u0103 aminti\u021bi, utilizarea indexurilor concurrente reduce cerin\u021bele de blocare. \u0218i dac\u0103 folosesc o blocare normal\u0103, un index normal, atunci astfel voi \u00eempiedica scrierea \u00een indexul tabelului \u00een timpul cre\u0103rii acestuia. Dac\u0103 folosesc un index concurrent, atunci trebuie s\u0103 folosesc un alt tip de blocare. <\/p>\n
<\/p>\n
<\/p>\n
SHARE ROW EXCLUSIVE \u2013 din nou, aceasta poate fi specificat\u0103 explicit.<\/p>\n
<\/p>\n
<\/p>\n
Sau putem crea o regul\u0103, adic\u0103 s\u0103 lu\u0103m un caz specific \u00een care aceasta va fi utilizat\u0103.<\/p>\n
<\/p>\n
<\/p>\n
Blocarea EXCLUSIVE \u00eenseamn\u0103 c\u0103 nimeni altcineva nu poate modifica tabela. <\/p>\n
<\/p>\n
<\/p>\n
Aici vedem diferite tipuri de bloc\u0103ri. <\/p>\n
<\/p>\n
<\/p>\n
ACCESS EXCLUSIVE, de exemplu, este comanda de blocare. De exemplu, dac\u0103 face\u021bi CLUSTER table<\/code>, aceasta va \u00eensemna c\u0103 nimeni nu va putea scrie acolo. \u0218i blocheaz\u0103 nu doar tabela \u00een sine, ci \u0219i indicii de asemenea.<\/p>\n<\/p>\n
<\/p>\n
Aceasta este a doua pagin\u0103 a bloc\u0103rii ACCESS EXCLUSIVE, unde vedem foarte clar ce blocheaz\u0103 \u00een tabel. Blocheaz\u0103 r\u00e2nduri individuale din tabel, ceea ce este destul de interesant.<\/p>\n
<\/p>\n
Aceasta este toat\u0103 informa\u021bia de baz\u0103 pe care am vrut s\u0103 o ofer. Am discutat despre blocaje, despre ID-uri de tranzi\u021bie, am vorbit despre ID-uri virtuale de tranzi\u021bie, despre ID-uri de tranzi\u021bie permanente. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i acum vom trece la exemple de blocaje. Aceasta este cea mai interesant\u0103 parte. Vom analiza cazuri foarte interesante. Sarcina mea \u00een aceast\u0103 prezentare este s\u0103 v\u0103 ofer o idee mai bun\u0103 despre ceea ce face, de fapt, Postgres atunci c\u00e2nd \u00eencearc\u0103 s\u0103 blocheze anumite lucruri. Mi se pare c\u0103 se descurc\u0103 foarte bine s\u0103 blocheze p\u0103r\u021bi separate. <\/p>\n
<\/p>\n
Haide\u021bi s\u0103 examin\u0103m anumite exemple.<\/p>\n
<\/p>\n
<\/p>\n
Vom \u00eencepe cu tabelele \u0219i cu o linie \u00een tabel. C\u00e2nd introduc ceva, mi se afi\u0219eaz\u0103 ExclusiveLock, ID-ul tranzi\u021biei \u0219i ExclusiveLock-ul pentru tabel. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i ce se va \u00eent\u00e2mpla dac\u0103 introduc \u00eenc\u0103 dou\u0103 r\u00e2nduri? \u0218i acum avem trei r\u00e2nduri \u00een tabelul nostru. Am introdus un r\u00e2nd \u0219i am ob\u021binut acest rezultat. \u0218i dac\u0103 introduc \u00eenc\u0103 dou\u0103 r\u00e2nduri, ce este ciudat aici? Exist\u0103 o ciud\u0103\u021benie, deoarece am ad\u0103ugat trei r\u00e2nduri la acest tabel, dar am \u00eenc\u0103 dou\u0103 r\u00e2nduri \u00een tabelul de blocare. \u0218i acesta este, \u00een esen\u021b\u0103, comportamentul fundamental al Postgres.<\/p>\n
<\/p>\n
Mul\u021bi cred c\u0103 dac\u0103 \u00een baza de date blochezi 100 de r\u00e2nduri, va fi necesar s\u0103 creezi 100 de \u00eenregistr\u0103ri de blocare. Dac\u0103 blochez simultan 1.000 de r\u00e2nduri, atunci voi avea nevoie de 1.000 de astfel de comenzi. \u0218i dac\u0103 trebuie s\u0103 blochez un milion sau un miliard. Dar dac\u0103 facem asta, nu va func\u021biona foarte bine. Dac\u0103 ai folosit un sistem care creeaz\u0103 \u00eenregistr\u0103ri de blocare pentru fiecare r\u00e2nd \u00een parte, vezi c\u0103 este complicat. Pentru c\u0103 trebuie s\u0103 define\u0219ti din start un tabel de blocare, care ar putea fi dep\u0103\u0219it, dar Postgres nu face asta. <\/p>\n
<\/p>\n
\u0218i pe acest diapozitiv este foarte important s\u0103 se demonstreze c\u0103 exist\u0103 un alt sistem care func\u021bioneaz\u0103 \u00een interiorul MVCC, care blocheaz\u0103 r\u00e2nduri individuale. A\u0219adar, c\u00e2nd blochezi miliarde de r\u00e2nduri, Postgres nu creeaz\u0103 un miliard de comenzi separate pentru blocare. \u0218i acest lucru are un impact foarte pozitiv asupra performan\u021bei. <\/p>\n
<\/p>\n
<\/p>\n
Ce p\u0103rere ave\u021bi despre actualizare? Acum actualizez un r\u00e2nd \u0219i pute\u021bi observa c\u0103 a realizat instantaneu dou\u0103 opera\u021biuni diferite. A blocat \u00een acela\u0219i timp tabela, dar a blocat \u0219i indexul. Era necesar s\u0103 blocheze indexul deoarece exist\u0103 constr\u00e2ngeri unice pe aceast\u0103 tabel\u0103. Vrem s\u0103 ne asigur\u0103m c\u0103 nimeni nu \u00eel modific\u0103, a\u0219a c\u0103 \u00eel bloc\u0103m.<\/p>\n
<\/p>\n
<\/p>\n
Ce se \u00eent\u00e2mpl\u0103 dac\u0103 vreau s\u0103 actualizez dou\u0103 r\u00e2nduri? Observ\u0103m c\u0103 se comport\u0103 la fel. Facem de dou\u0103 ori mai multe actualiz\u0103ri, dar exact acela\u0219i num\u0103r de r\u00e2nduri blocate. <\/p>\n
<\/p>\n
Dac\u0103 sunte\u021bi curios cum face Postgres asta, trebuie s\u0103 asculta\u021bi prezent\u0103rile mele despre MVCC pentru a \u00een\u021belege cum Postgres marcheaz\u0103 intern r\u00e2ndurile pe care le modific\u0103. Postgres are o metod\u0103 prin care face acest lucru, dar nu o face la nivelul bloc\u0103rii tabelelor, ci la un nivel mai jos \u0219i mai eficient.<\/p>\n
<\/p>\n
<\/p>\n
\u0218i dac\u0103 vreau s\u0103 \u0219terg ceva? Dac\u0103 \u0219terg, de exemplu, un r\u00e2nd \u0219i am \u00eenc\u0103 cele dou\u0103 bloc\u0103ri, chiar dac\u0103 vreau s\u0103 le \u0219terg pe toate, ele tot vor fi prezente.<\/p>\n
<\/p>\n
<\/p>\n
De exemplu, dac\u0103 vreau s\u0103 inserez 1.000 de r\u00e2nduri, apoi s\u0103 \u0219terg sau s\u0103 adaug 1.000 de r\u00e2nduri, acele r\u00e2nduri individuale pe care le adaug sau le modific nu sunt scrise aici. Ele sunt scrise la un nivel mai jos, \u00een cadrul r\u00e2ndului. La prezentarea despre MVCC am vorbit despre asta \u00een detaliu. Dar este foarte important, c\u00e2nd analiza\u021bi bloc\u0103rile, s\u0103 v\u0103 asigura\u021bi c\u0103 ave\u021bi o blocare la nivel de tabel \u0219i c\u0103 aici nu vede\u021bi cum se efectueaz\u0103 scrierea r\u00e2ndurilor individuale. <\/p>\n
<\/p>\n
<\/p>\n
Ce zice\u021bi de blocarea explicitar\u0103?<\/p>\n
<\/p>\n
<\/p>\n
Dac\u0103 apas pe \u201eactualizeaz\u0103\u201d am dou\u0103 r\u00e2nduri blocate. Dac\u0103 le selectez pe toate \u0219i ap\u0103s pe \u201eactualizeaz\u0103 tot\u201d, \u00eemi r\u0103m\u00e2n \u00een continuare dou\u0103 \u00eenregistr\u0103ri blocate. <\/p>\n
<\/p>\n
<\/p>\n
Nu cre\u0103m \u00eenregistr\u0103ri separate pentru fiecare r\u00e2nd. Pentru c\u0103 atunci scade performan\u021ba, ar putea fi prea multe. \u0218i ne-am putea afla \u00eentr-o situa\u021bie nepl\u0103cut\u0103. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i acela\u0219i lucru se aplic\u0103 dac\u0103 facem shared, putem face asta de 30 de ori. <\/p>\n
<\/p>\n
<\/p>\n
Restaur\u0103m tabela noastr\u0103, \u0219tergem tot, apoi inser\u0103m din nou un r\u00e2nd.<\/p>\n
<\/p>\n
<\/p>\n
Un alt comportament pe care \u00eel vede\u021bi \u00een Postgres este un comportament foarte bine cunoscut \u0219i dorit \u2013 este faptul c\u0103 pute\u021bi efectua update sau select. \u0218i pute\u021bi face asta simultan. Iar select nu blocheaz\u0103 update \u0219i invers. Spunem cititorului s\u0103 nu blocheze cel care scrie, iar cel care scrie s\u0103 nu blocheze cititorul. <\/p>\n
<\/p>\n
V\u0103 voi ar\u0103ta un exemplu al acestui lucru. Voi face acum o selec\u021bie. Apoi vom efectua un INSERT. \u0218i apoi ve\u021bi putea vedea \u2013 694. Ve\u021bi putea vedea ID-ul tranzac\u021biei care a efectuat aceast\u0103 inserare. \u0218i astfel func\u021bioneaz\u0103. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i dac\u0103 acum m\u0103 uit la backend ID-ul meu, acesta a devenit \u2013 695. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i pot vedea c\u0103 695 apare \u00een tabelul meu. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i dac\u0103 fac o actualizare aici \u00een acest mod, atunci ob\u021bin un alt caz. \u00cen acest caz, 695 \u2013 blocheaz\u0103 exclusiv, iar update are un comportament similar, dar \u00eentre ele nu apare niciun conflict, ceea ce este destul de neobi\u0219nuit. <\/p>\n
<\/p>\n
\u0218i pute\u021bi observa c\u0103 sus \u2013 este ShareLock, iar jos \u2013 este ExclusiveLock. \u0218i ambele tranzac\u021bii au avut loc.<\/p>\n
<\/p>\n
\u0218i trebuie s\u0103 asculta\u021bi prezentarea mea \u00een MVCC pentru a \u00een\u021belege cum se \u00eent\u00e2mpl\u0103 acest lucru. Dar aceasta este o ilustrare a faptului c\u0103 pute\u021bi face asta simultan, adic\u0103 s\u0103 efectua\u021bi SELECT \u0219i UPDATE \u00een acela\u0219i timp.<\/p>\n
<\/p>\n
<\/p>\n
Hai s\u0103 reset\u0103m \u0219i s\u0103 facem o opera\u021bie din nou. <\/p>\n
<\/p>\n
<\/p>\n
Dac\u0103 \u00eencerca\u021bi s\u0103 rula\u021bi simultan dou\u0103 update-uri pe acela\u0219i r\u00e2nd, atunci va fi blocat. \u0218i aminti\u021bi-v\u0103, am spus c\u0103 cititorul nu blocheaz\u0103 scriitorul, iar scriitorul blocheaz\u0103 cititorul, dar un scriitor blocheaz\u0103 alt scriitor. Adic\u0103 nu putem face ca dou\u0103 persoane s\u0103 actualizeze simultan acela\u0219i r\u00e2nd. Trebuie s\u0103 a\u0219tept\u0103m p\u00e2n\u0103 c\u00e2nd unul dintre ei finalizeaz\u0103. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i pentru a ilustra acest lucru, m\u0103 voi uita la tabela Lockdemo. \u0218i vom observa un r\u00e2nd. La tranzac\u021bia 698.<\/p>\n
<\/p>\n
L-am actualizat la 2. 699 \u2013 aceasta este prima actualizare. \u0218i a trecut cu succes sau se afl\u0103 \u00eentr-o tranzac\u021bie \u00een a\u0219teptare \u0219i a\u0219teapt\u0103 s\u0103 confirm\u0103m sau s\u0103 anul\u0103m. <\/p>\n
<\/p>\n
<\/p>\n
Dar lua\u021bi \u00een considerare altceva \u2013 2\/51 \u2013 aceasta este prima noastr\u0103 tranzac\u021bie, prima noastr\u0103 sesiune. 3\/112 \u2013 aceasta este a doua cerere, care a ap\u0103rut deasupra \u0219i care a schimbat aceast\u0103 valoare \u00een 3. \u0218i dac\u0103 observa\u021bi, atunci cel de sus s-a blocat singur, care este 699. \u00cens\u0103 3\/112 nu a oferit o blocare. \u00cen coloana Lock_mode scrie c\u0103 a\u0219teapt\u0103. A\u0219teapt\u0103 699. \u0218i dac\u0103 v\u0103 uita\u021bi, unde este 699, este mai sus. \u0218i ce a f\u0103cut prima sesiune? A creat o blocare exclusiv\u0103 pe ID-ul s\u0103u de tranzac\u021bie. A\u0219a face Postgres. Blocheaz\u0103 propriul ID de tranzac\u021bie. \u0218i dac\u0103 vrei s\u0103 a\u0219tep\u021bi p\u00e2n\u0103 c\u00e2nd cineva confirm\u0103 sau anuleaz\u0103, trebuie s\u0103 a\u0219tep\u021bi p\u00e2n\u0103 exist\u0103 o tranzac\u021bie \u00een a\u0219teptare. \u0218i de aceea putem vedea o linie ciudat\u0103. <\/p>\n
<\/p>\n
S\u0103 ne uit\u0103m din nou. \u00cen st\u00e2nga vedem ID-ul nostru de procesare. \u00cen a doua coloan\u0103 vedem ID-ul nostru virtual de tranzac\u021bie, iar \u00een a treia vedem lock_type. Ce \u00eenseamn\u0103 asta? Practic, spune c\u0103 blocheaz\u0103 ID-ul de tranzac\u021bie. Dar observa\u021bi c\u0103 \u00een toate r\u00e2ndurile de jos scrie relation. \u0218i de aceea ave\u021bi dou\u0103 tipuri de blocare \u00een tabel\u0103. Exist\u0103 blocarea relation. De asemenea, exist\u0103 blocarea transactionid, unde ne bloc\u0103m noi \u00een\u0219ine, aceasta este exact ceea ce se \u00eent\u00e2mpl\u0103 \u00een primul r\u00e2nd sau \u00een cel mai de jos, unde transactionid, unde a\u0219tept\u0103m ca 699 s\u0103 \u00ee\u0219i finalizeze opera\u021biunea. <\/p>\n
<\/p>\n
M\u0103 uit la ce se \u00eent\u00e2mpl\u0103 aici. \u0218i aici se petrec \u00een acela\u0219i timp dou\u0103 lucruri. Te ui\u021bi la blocarea pe ID-ul de tranzac\u021bie din primul r\u00e2nd, care se blocheaz\u0103 singur\u0103. \u0218i se blocheaz\u0103 singur\u0103 pentru a-i face pe oameni s\u0103 a\u0219tepte. <\/p>\n
<\/p>\n
Dac\u0103 te ui\u021bi la a 6-a linie, este aceea\u0219i \u00eenregistrare ca \u0219i prima. \u0218i astfel tranzac\u021bia 699 este blocat\u0103. 700, de asemenea, se auto-blocheaz\u0103. \u0218i apoi \u00een r\u00e2ndul de jos vei vedea c\u0103 a\u0219tept\u0103m ca 699 s\u0103 \u00ee\u0219i finalizeze opera\u021biunea.<\/p>\n
<\/p>\n
<\/p>\n
\u0218i \u00een lock_type, tuple vezi numere. <\/p>\n
<\/p>\n
<\/p>\n
Po\u021bi vedea c\u0103 este 0\/10. \u0218i aceasta este pagina \u0219i, de asemenea, offset-ul acestei \u00eenregistr\u0103ri specifice. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i vezi c\u0103 devine 0\/11, c\u00e2nd actualiz\u0103m. <\/p>\n
<\/p>\n
<\/p>\n
Dar, de fapt \u2013 este 0\/10, pentru c\u0103 apare a\u0219teptarea acestei opera\u021biuni. Avem oportunitatea s\u0103 vedem c\u0103 aceasta este \u00eenregistrarea pe care o a\u0219tept s\u0103 fie confirmat\u0103. <\/p>\n
<\/p>\n
<\/p>\n
Odat\u0103 ce l-am confirmat \u0219i am ap\u0103sat commit, \u0219i c\u00e2nd actualizarea s-a terminat, aceasta este ceea ce ob\u021binem din nou. Transac\u021bia 700 este singura blocare, nu a\u0219teapt\u0103 pe nimeni altcineva, deoarece a fost confirmat\u0103. A\u0219teapt\u0103 doar ca transac\u021bia s\u0103 se finalizeze. Odat\u0103 ce transac\u021bia 699 se termin\u0103, nu mai a\u0219tept\u0103m nimic. \u0218i acum transac\u021bia 700 spune c\u0103 totul este \u00een regul\u0103, c\u0103 toate bloc\u0103rile necesare le are \u00een toate tabelele autorizate. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i ca s\u0103 complic\u0103m \u0219i mai mult lucrurile, cre\u0103m o alt\u0103 vedere, care de data aceasta ne va oferi o ierarhie. Nu m\u0103 a\u0219tept s\u0103 \u00een\u021belegi aceast\u0103 interogare. Dar ne va oferi o viziune mai clar\u0103 asupra a ceea ce se \u00eent\u00e2mpl\u0103. <\/p>\n
<\/p>\n
<\/p>\n
Aceasta este o vedere recursiv\u0103, care mai are \u0219i o alt\u0103 sec\u021biune. \u0218i apoi ne \u00eentoarce totul din nou. Hai s\u0103 folosim aceasta. <\/p>\n
<\/p>\n
<\/p>\n
Ce s-ar \u00eent\u00e2mpla dac\u0103 am face trei actualiz\u0103ri simultane \u0219i am spune c\u0103 r\u00e2ndul este acum egal cu trei. \u0218i vom schimba 3 \u00een 4. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i iat\u0103 ne vedem 4. \u0218i ID-ul tranzac\u021bional 702. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i apoi voi schimba 4 \u00een 5. Iar 5 \u00een 6, iar 6 \u00een 7. \u0218i \u00eemi creez o coad\u0103 de oameni care a\u0219teapt\u0103 ca aceast\u0103 singur\u0103 tranzac\u021bie s\u0103 se termine.<\/p>\n
<\/p>\n
<\/p>\n
\u0218i totul devine clar. Care este primul r\u00e2nd? Acesta este 702. Acesta este ID-ul tranzac\u021bional, care a ini\u021biat aceast\u0103 valoare. \u0218i ce am notat \u00een coloana Granted? Am m\u0103rci. f<\/code>. Acestea sunt actualiz\u0103rile mele, care (5, 6, 7) nu pot fi aprobate, deoarece a\u0219tept\u0103m ca ID-ul tranzac\u021bional 702 s\u0103 se finalizeze. Acolo avem o blocare a ID-ului tranzac\u021bional. Iar 5 devin bloc\u0103ri tranzac\u021bionale ID.<\/p>\n<\/p>\n
\u0218i dac\u0103 te ui\u021bi la 704, la 705, atunci acolo nu este nimic scris, deoarece ei \u00eenc\u0103 nu \u0219tiu ce se \u00eent\u00e2mpl\u0103. Ei doar scriu c\u0103 nu au idee ce se \u00eent\u00e2mpl\u0103. \u0218i vor merge la somn, deoarece a\u0219teapt\u0103 pe cineva s\u0103 finalizeze \u0219i s\u0103-i trezeasc\u0103 c\u00e2nd va ap\u0103rea oportunitatea de a schimba r\u00e2ndul. <\/p>\n
<\/p>\n
<\/p>\n
A\u0219a arat\u0103. Este clar c\u0103 to\u021bi a\u0219teapt\u0103 r\u00e2ndul 12. <\/p>\n
<\/p>\n
<\/p>\n
Acesta este ceea ce am v\u0103zut aici. Iat\u0103 0\/12. <\/p>\n
<\/p>\n
<\/p>\n
Deci, odat\u0103 ce prima tranzac\u021bie este aprobat\u0103, po\u021bi vedea aici cum func\u021bioneaz\u0103 ierarhia. \u0218i acum devine totul clar. To\u021bi devin liberi. \u0218i ei, de fapt, a\u0219teapt\u0103. <\/p>\n
<\/p>\n
<\/p>\n
Iat\u0103 ce se \u00eent\u00e2mpl\u0103. 702 se comite. \u0218i acum 703 prime\u0219te aceast\u0103 blocare a r\u00e2ndului, iar apoi 704 \u00eencepe s\u0103 a\u0219tepte c\u00e2nd 703 se va comite. \u0218i 705 a\u0219teapt\u0103 \u0219i el acest lucru. \u0218i c\u00e2nd totul se \u00eencheie, se elibereaz\u0103 singuri. \u0218i a\u0219 dori s\u0103 subliniez c\u0103 to\u021bi se aliniaz\u0103. \u0218i este foarte asem\u0103n\u0103tor cu situa\u021bia unui ambuteiaj, c\u00e2nd to\u021bi a\u0219teapt\u0103 prima ma\u0219in\u0103. Prima ma\u0219in\u0103 s-a oprit \u0219i toat\u0103 lumea se aliniaz\u0103 \u00eentr-o linie lung\u0103. Apoi se mi\u0219c\u0103, apoi urm\u0103toarea ma\u0219in\u0103 poate avansa \u0219i ob\u021bine blocarea sa etc. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i dac\u0103 vi s-a p\u0103rut c\u0103 acest lucru nu este suficient de complicat, acum vom discuta despre deadlocks. Nu \u0219tiu c\u00e2\u021bi dintre voi s-au \u00eent\u00e2lnit cu ei. Este o problem\u0103 destul de comun\u0103 \u00een sistemele de baze de date. Dar deadlocks sunt cazul c\u00e2nd o sesiune a\u0219teapt\u0103 ca o alt\u0103 sesiune s\u0103 execute ceva. Iar \u00een acel moment, cealalt\u0103 sesiune a\u0219teapt\u0103 ca prima sesiune s\u0103 execute ceva. <\/p>\n
<\/p>\n
De exemplu, dac\u0103 Ivan spune: \u201eD\u0103-mi ceva\u201d, iar eu spun: \u201eNu, \u021bi-l voi da doar dac\u0103 \u00eemi dai ceva altceva\u201d. Iar el spune: \u201eNu, nu \u00ee\u021bi voi da asta dac\u0103 nu \u00eemi dai tu\u201d. \u0218i ajungem \u00eentr-o situa\u021bie de deadlock. Sunt sigur c\u0103 Ivan nu ar face a\u0219a ceva, dar \u00een\u021belege\u021bi ideea, c\u0103 avem doi oameni care vor s\u0103 ob\u021bin\u0103 ceva \u0219i nu sunt dispu\u0219i s\u0103 dea p\u00e2n\u0103 c\u00e2nd cealalt\u0103 persoan\u0103 nu le d\u0103 ceea ce vor. \u0218i aici nu exist\u0103 o solu\u021bie. <\/p>\n
<\/p>\n
\u0218i, practic, baza dvs. de date trebuie s\u0103 identifice acest lucru. \u0218i apoi trebuie s\u0103 elimine sau s\u0103 \u00eenchid\u0103 una dintre sesiuni, pentru c\u0103 altfel vor r\u0103m\u00e2ne acolo pentru totdeauna. \u0218i vedem asta \u00een bazele de date, vedem asta \u00een sistemele de operare. \u0218i \u00een toate locurile unde avem procese paralele, acest lucru se poate \u00eent\u00e2mpla. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i acum vom crea dou\u0103 deadlocks. Vom folosi 50 \u0219i 80. \u00cen primul r\u00e2nd, voi efectua o actualizare de la 50 la 50. Voi ob\u021bine num\u0103rul tranzac\u021biei 710. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i apoi voi schimba 80 pe 81 \u0219i 50 pe 51. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i a\u0219a va ar\u0103ta. Deci 710 are blocarea r\u00e2ndului, iar 711 a\u0219teapt\u0103 confirmarea. Am v\u0103zut acest lucru c\u00e2nd am actualizat. 710 este proprietarul r\u00e2ndului nostru. Iar 711 a\u0219teapt\u0103 ca 710 s\u0103 finalizeze tranzac\u021bia.<\/p>\n
<\/p>\n
<\/p>\n
\u0218i este chiar scris pe ce r\u00e2nd exact avem deadlocks. \u0218i aici devine ciudat.<\/p>\n
<\/p>\n
<\/p>\n
Acum actualiz\u0103m 80 la 80. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i aici \u00eencepe problema blocajelor. 710 a\u0219teapt\u0103 un r\u0103spuns de la 711, iar 711 a\u0219teapt\u0103 de la 710. \u0218i acest lucru nu se va termina bine. \u0218i nu exist\u0103 o solu\u021bie. \u0218i ei vor a\u0219tepta s\u0103 primeasc\u0103 r\u0103spuns unul de la cel\u0103lalt. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i acest lucru va \u00eencepe s\u0103 \u00eent\u00e2rzie totul. \u0218i nu ne dorim asta. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i \u00een Postgres exist\u0103 modalit\u0103\u021bi de a observa c\u00e2nd se \u00eent\u00e2mpl\u0103 acest lucru. \u0218i c\u00e2nd se \u00eent\u00e2mpl\u0103, ob\u021bine\u021bi aceast\u0103 eroare. \u0218i din aceasta reiese c\u0103 un anumit proces a\u0219teapt\u0103 un SHARE LOCK de la un alt proces, adic\u0103 care este blocat de procesul 711. Iar acel proces a\u0219tepta s\u0103 fie acordat un SHARE LOCK pentru un anumit ID de tranzac\u021bie \u0219i a fost blocat de un anume proces. Prin urmare, avem o situa\u021bie de blocare moart\u0103.<\/p>\n
<\/p>\n
<\/p>\n
Dar exist\u0103 blocaje de tip trei? Este posibil? Da. <\/p>\n
<\/p>\n
<\/p>\n
Introducem aceste numere \u00een tabel. Schimb\u0103m 40 cu 40, facem blocaj. <\/p>\n
<\/p>\n
<\/p>\n
Schimb\u0103m 60 cu 61, 80 cu 81. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i apoi schimb\u0103m 80, iar apoi \u2013 bum! <\/p>\n
<\/p>\n
<\/p>\n
\u0218i 714 acum a\u0219teapt\u0103 715. 716 a\u0219teapt\u0103 715. \u0218i cu asta nu mai po\u021bi face nimic.<\/p>\n
<\/p>\n
<\/p>\n
Aici nu mai sunt doar dou\u0103 persoane, ci trei. Eu vreau ceva de la tine, acesta vrea ceva de la a treia persoan\u0103, iar a treia persoan\u0103 vrea ceva de la mine. \u0218i ajungem \u00eentr-o stare de a\u0219teptare circular\u0103, pentru c\u0103 to\u021bi a\u0219tept\u0103m ca cel\u0103lalt s\u0103 termine ceea ce trebuie s\u0103 fac\u0103. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i Postgres \u0219tie pe ce r\u00e2nd se \u00eent\u00e2mpl\u0103 asta. \u0218i din acest motiv, \u00ee\u021bi va oferi urm\u0103torul mesaj care arat\u0103 c\u0103 ai o problem\u0103, unde cele trei intr\u0103ri se blocheaz\u0103 reciproc. \u0218i nu exist\u0103 limit\u0103ri. Acest lucru se poate \u00eent\u00e2mpla \u00een cazul \u00een care 20 de \u00eenregistr\u0103ri se blocheaz\u0103 \u00eentre ele. <\/p>\n
<\/p>\n
<\/p>\n
Problema urm\u0103toare este serializabila. <\/p>\n
<\/p>\n
<\/p>\n
Dac\u0103 exist\u0103 un blocaj serializabil special.<\/p>\n
<\/p>\n
<\/p>\n
\u0218i revenim la 719. Are o ie\u0219ire complet normal\u0103. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i po\u021bi ap\u0103sa pentru a face o tranzac\u021bie din serializabil.<\/p>\n
<\/p>\n
<\/p>\n
\u0218i \u00ee\u021bi dai seama c\u0103 acum ai un alt tip de blocaj SA - aceasta \u00eenseamn\u0103 serializabil. <\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
\u0218i prin urmare avem un nou tip de blocaj numit SARieadLock, care este un blocaj serial \u0219i permite introducerea de numere seriale.<\/p>\n
<\/p>\n
<\/p>\n
\u0218i de asemenea, po\u021bi insera indec\u0219i unici. <\/p>\n
<\/p>\n
<\/p>\n
\u00cen acest tabel avem indec\u0219i unici.<\/p>\n
<\/p>\n
<\/p>\n
Prin urmare, dac\u0103 introduc aici num\u0103rul 2, am 2. Dar \u00een v\u00e2rful listei introduc \u00eenc\u0103 un 2. \u0218i po\u021bi vedea c\u0103 721 are un blocaj exclusiv. Dar acum 722 a\u0219teapt\u0103 ca 721 s\u0103 finalizeze opera\u021bia, pentru c\u0103 nu poate insera 2 p\u00e2n\u0103 c\u00e2nd nu \u0219tie ce se va \u00eent\u00e2mpla cu 721. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i dac\u0103 facem o subtranzac\u021bie.<\/p>\n
<\/p>\n
<\/p>\n
Iat\u0103-ne 723.<\/p>\n
<\/p>\n
<\/p>\n
Dac\u0103 p\u0103str\u0103m un punct \u0219i apoi \u00eel actualiz\u0103m, ob\u021binem un nou ID de tranzac\u021bie. Aceasta este \u00eenc\u0103 o caracteristic\u0103 pe care trebuie s\u0103 o cunoa\u0219te\u021bi. Dac\u0103 \u00eentoarcem acest lucru, ID-ul de tranzac\u021bie se pierde. 724 se pierde. Dar acum avem 725. <\/p>\n
<\/p>\n
\u0218i ce \u00eencerc eu s\u0103 fac aici? \u00cencerc s\u0103 v\u0103 ar\u0103t exemple de bloc\u0103ri neobi\u0219nuite pe care le pute\u021bi g\u0103si: fie c\u0103 sunt bloc\u0103ri serializabile sau SAVEPOINT \u2013 acestea sunt tipuri diferite de bloc\u0103ri care vor ap\u0103rea \u00een tabelul de bloc\u0103ri. <\/p>\n
<\/p>\n
<\/p>\n
Acesta este un exemplu de bloc\u0103ri explicite, care au pg_advisory_lock. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i ve\u021bi vedea c\u0103 tipul bloc\u0103rii este listat ca advisory. \u0218i este scris cu ro\u0219u \u201eadvisory\u201d. \u0218i pute\u021bi bloca simultan cu pg_advisory_unlock.<\/p>\n
<\/p>\n
<\/p>\n
\u0218i pentru a \u00eencheia, a\u0219 dori s\u0103 v\u0103 ar\u0103t \u00eenc\u0103 o chestie fascinant\u0103. Voi crea un alt tip. Dar voi conecta tabelul pg_locks cu tabelul pg_stat_activity. De ce vreau s\u0103 fac asta? Pentru c\u0103 \u00eemi va permite s\u0103 v\u0103d toate sesiunile curente \u0219i s\u0103 observ ce fel de bloc\u0103ri a\u0219teapt\u0103. \u0218i este suficient de interesant c\u00e2nd adun\u0103m laolalt\u0103 tabelul de bloc\u0103ri \u0219i tabelul de interog\u0103ri. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i aici cre\u0103m pg_stat_view. <\/p>\n
<\/p>\n
<\/p>\n
\u0218i actualiz\u0103m un r\u00e2nd cu unul. \u0218i aici vedem 724. Apoi actualiz\u0103m r\u00e2ndul nostru la trei. \u0218i ce observa\u021bi aici acum? Acestea sunt interog\u0103rile, adic\u0103 vede\u021bi \u00eentreaga list\u0103 de interog\u0103ri enumerate \u00een coloana din st\u00e2nga. Apoi, \u00een partea dreapt\u0103, pute\u021bi vedea bloc\u0103rile \u0219i ceea ce genereaz\u0103 acestea. \u0218i poate fi mai clar pentru voi, astfel \u00eenc\u00e2t s\u0103 nu fie necesar s\u0103 v\u0103 \u00eentoarce\u021bi de fiecare dat\u0103 la fiecare sesiune pentru a vedea dac\u0103 trebuie s\u0103 v\u0103 al\u0103tura\u021bi sau nu. Acest lucru se face pentru noi. <\/p>\n
<\/p>\n
O alt\u0103 func\u021bie care este foarte util\u0103 este pg_blocking_pids<\/code>Probabil c\u0103 nu a\u021bi auzit niciodat\u0103 de aceasta. Ce face? Ea ne permite s\u0103 spunem c\u0103 pentru aceast\u0103 sesiune 11740, ce ID-uri de procese a\u0219teapt\u0103. \u0218i pute\u021bi vedea c\u0103 11740 a\u0219teapt\u0103 724. Iar 724 este \u00een partea de sus. Prozesele ID sunt 11306. Practic, aceast\u0103 func\u021bie parcurge tabelul vostru de bloc\u0103ri. \u0218tiu c\u0103 este pu\u021bin complicat, dar reu\u0219i\u021bi s\u0103 \u00een\u021belege\u021bi. Practic, func\u021bia trece prin acest tabel de bloc\u0103ri \u0219i \u00eencearc\u0103 s\u0103 g\u0103seasc\u0103 unde este procesul ID, lu\u00e2nd \u00een considerare blocajele pe care le a\u0219teapt\u0103. De asemenea, \u00eencearc\u0103 s\u0103 calculeze ce proces ID are procesul care a\u0219teapt\u0103 blocajele. A\u0219adar, pute\u021bi rula aceast\u0103 func\u021bie. pg_blocking_pids<\/code>.<\/p>\n<\/p>\n
\u0218i asta poate fi foarte util. Am ad\u0103ugat asta doar \u00eencep\u00e2nd cu versiunea 9.6, a\u0219a c\u0103 aceast\u0103 func\u021bie are doar 5 ani, dar este extrem de util\u0103. \u0218i acela\u0219i lucru se aplic\u0103 \u0219i celei de-a doua interog\u0103ri. Arat\u0103 exact ceea ce trebuie s\u0103 vedem. <\/p>\n
<\/p>\n
<\/p>\n
Acesta este subiectul despre care am vrut s\u0103 discut cu voi. \u0218i, dup\u0103 cum m-am a\u0219teptat, ne-am folosit tot timpul, deoarece au fost at\u00e2t de multe slide-uri. Slide-urile sunt disponibile pentru desc\u0103rcare. A\u0219 dori s\u0103 v\u0103 mul\u021bumesc c\u0103 a\u021bi fost aici. Sunt sigur c\u0103 v\u0103 va pl\u0103cea restul conferin\u021bei, v\u0103 mul\u021bumesc mult!<\/p>\n
<\/p>\n
\u00centreb\u0103ri:<\/p>\n
<\/p>\n
De exemplu, dac\u0103 \u00eencerc s\u0103 actualizez linii, iar a doua sesiune \u00eencearc\u0103 s\u0103 \u0219tearg\u0103 \u00eentreaga mas\u0103. Din c\u00e2te \u00een\u021beleg, ar trebui s\u0103 existe ceva de genul intent lock. Exist\u0103 a\u0219a ceva \u00een Postgres?<\/em><\/p>\n<\/p>\n
<\/p>\n
S\u0103 ne \u00eentoarcem la \u00eenceput. Poate v\u0103 aminti\u021bi c\u0103 atunci c\u00e2nd face\u021bi orice, de exemplu, c\u00e2nd face\u021bi SELECT, emit un AccessShareLock. Acesta previne \u0219tergerea tabelului. A\u0219adar, dac\u0103, de exemplu, dori\u021bi s\u0103 actualiza\u021bi o linie din tabel sau s\u0103 \u0219terge\u021bi o linie, cineva nu poate \u0219terge \u00eentreaga mas\u0103 simultan cu asta, deoarece de\u021bine\u021bi acest AccessShareLock pe \u00eentreaga mas\u0103 \u0219i pe linie. \u0218i imediat ce a\u021bi terminat, pot s\u0103 o \u0219tearg\u0103. Dar c\u00e2t timp modifica\u021bi ceva acolo, nu vor putea face asta.<\/p>\n
<\/p>\n
Hai s\u0103 mai facem o dat\u0103. S\u0103 trecem la exemplul cu \u0219tergerea. \u0218i vezi cum pe linie este un lock exclusiv pe \u00eentreaga mas\u0103. <\/p>\n
<\/p>\n
Asta va ar\u0103ta ca un lock exclusiv, corect?<\/em><\/p>\n<\/p>\n
Da, asta pare a fi cazul. \u00cen\u021beleg despre ce vorbe\u0219ti. Spui c\u0103, dac\u0103 fac un SELECT, voi avea ShareExclusive, iar apoi transform acest lucru \u00eentr-o stare Row Exclusive, devine asta o problem\u0103? Dar, spre surprinderea mea, aceasta nu creeaz\u0103 o problem\u0103. Este asem\u0103n\u0103tor cu o cre\u0219tere a gradului de blocare, dar, \u00een esen\u021b\u0103, am un lock care \u00eempiedic\u0103 \u0219tergerea. \u0218i acum, c\u00e2nd fac acest lock mai puternic, acesta \u00eenc\u0103 \u00eempiedic\u0103 \u0219tergerea. A\u0219adar, nu este ca \u0219i c\u00e2nd m\u0103 ridic la un nivel superior. Adic\u0103, acesta prevenea deja asta \u0219i c\u00e2nd era la un nivel mai mic, a\u0219a c\u0103, atunci c\u00e2nd \u00eei \u00eenal\u021b nivelul, acesta \u00eenc\u0103 \u00eempiedic\u0103 \u0219tergerea tabelului. <\/p>\n
<\/p>\n
\u00cen\u021beleg despre ce vorbe\u0219ti. Aici nu este un caz de cre\u0219tere a gradului de blocare, \u00een care \u00eencerci s\u0103 renun\u021bi la o blocare pentru a introduce una mai puternic\u0103. Aici acesta pur \u0219i simplu cre\u0219te \u00een mod uniform aceast\u0103 prevenire, deci nu provoac\u0103 niciun conflict. Dar este o \u00eentrebare bun\u0103. \u00ce\u021bi mul\u021bumesc mult c\u0103 ai pus-o!<\/p>\n
<\/p>\n
Ce trebuie s\u0103 facem pentru a evita situa\u021bia de deadlock, c\u00e2nd avem multe sesiuni, un num\u0103r mare de utilizatori?<\/em><\/p>\n<\/p>\n
Postgres observ\u0103 automat situa\u021biile de deadlock. \u0218i va elimina automat una dintre sesiuni. Singura modalitate de a evita situa\u021biile de deadlock este s\u0103 bloci oamenii \u00een aceea\u0219i ordine. A\u0219adar, c\u00e2nd te ui\u021bi la aplica\u021bia ta, de obicei motivul pentru deadlocks\u2026 S\u0103 ne imagin\u0103m c\u0103 vreau s\u0103 blochez dou\u0103 lucruri diferite. O aplica\u021bie blocheaz\u0103 tabelul 1, iar cealalt\u0103 aplica\u021bie blocheaz\u0103 2, iar apoi tabelul 1. \u0218i cea mai simpl\u0103 modalitate de a evita deadlocks este s\u0103 te ui\u021bi la aplica\u021bia ta \u0219i s\u0103 \u00eencerci s\u0103 te asiguri c\u0103 blocarea se face \u00een aceea\u0219i ordine \u00een toate aplica\u021biile. \u0218i aceasta, de regul\u0103, elimin\u0103 80% din probleme, deoarece oameni diferi\u021bi scriu aceste aplica\u021bii. \u0218i dac\u0103 le blochezi \u00een aceea\u0219i ordine, nu te confrun\u021bi cu o situa\u021bie de deadlock.<\/p>\n
<\/p>\n
\u00ce\u021bi mul\u021bumesc mult pentru prezentarea ta! Ai vorbit despre vacuum full \u0219i, dac\u0103 \u00een\u021beleg corect, vacuum full deformeaz\u0103 ordinea \u00eenregistr\u0103rilor \u00eentr-un spa\u021biu de stocare separat, astfel \u00eenc\u00e2t p\u0103streaz\u0103 \u00eenregistr\u0103rile actuale neschimbate. De ce vacuum full necesit\u0103 o blocare exclusiv\u0103 \u0219i de ce interfereaz\u0103 cu opera\u021biunile de scriere?<\/em><\/p>\n<\/p>\n
Este este o \u00eentrebare bun\u0103. Motivul este c\u0103 vacuum full preia tabela. \u0218i, practic, cre\u0103m o nou\u0103 versiune a tabelei. Astfel, tabela va fi una nou\u0103. Rezult\u0103 c\u0103 aceasta va fi o versiune complet nou\u0103 a tabelei. Problema este c\u0103, atunci c\u00e2nd facem asta, nu vrem ca oamenii s\u0103 o citeasc\u0103, deoarece trebuie ca ei s\u0103 vad\u0103 noua tabel\u0103. A\u0219adar, aceasta se leag\u0103 de \u00eentrebarea anterioar\u0103. Dac\u0103 am putea citi \u00een acela\u0219i timp, nu am putea s\u0103 o mut\u0103m \u0219i s\u0103 \u00eendrum\u0103m oamenii spre noua tabel\u0103. Ar trebui s\u0103 a\u0219tept\u0103m ca toat\u0103 lumea s\u0103 termine de citit aceast\u0103 tabel\u0103 \u0219i, prin urmare, aceasta este, \u00een esen\u021b\u0103, o situa\u021bie de blocare exclusiv\u0103.
<\/p>\n
Este posibil s\u0103 adaugi un timeout pentru blocare \u00een Postgres? \u00cen Oracle, pot, de exemplu, s\u0103 scriu \u201eselect for update\u201d \u0219i s\u0103 a\u0219tept 50 de secunde p\u00e2n\u0103 la actualizare. Acest lucru era bun pentru aplica\u021bie. Dar \u00een Postgres trebuie fie s\u0103 faci asta imediat \u0219i s\u0103 nu a\u0219tep\u021bi deloc, fie s\u0103 a\u0219tep\u021bi p\u00e2n\u0103 la un moment dat.<\/em> <\/p>\n<\/p>\n
Da, po\u021bi alege un timeout pentru bloc\u0103rile tale, pentru locks. De asemenea, po\u021bi emite comanda no way, care va fi \u2026, dac\u0103 nu po\u021bi ob\u021bine blocarea imediat. A\u0219adar, fie lock timeout, fie altceva care \u00ee\u021bi va permite s\u0103 faci asta. Nu se face la nivel sintactic. Se face ca o variabil\u0103 pe server. Uneori nu poate fi utilizat\u0103.<\/p>\n
<\/p>\n
Po\u021bi deschide diapozitivul 75?<\/em> <\/p>\n<\/p>\n
Da.<\/p>\n
<\/p>\n
<\/p>\n
\u0218i \u00eentrebarea mea este urm\u0103toarea. De ce ambele procese de actualizare a\u0219teapt\u0103 703?<\/em><\/p>\n<\/p>\n
\u0218i aceasta este o \u00eentrebare excelent\u0103. Nu \u00een\u021beleg, de altfel, de ce Postgres face asta. Dar c\u00e2nd 703 a fost creat, acesta a a\u0219teptat 702. Iar c\u00e2nd 704 \u0219i 705 apar, se pare c\u0103 nu \u0219tiu ce a\u0219teapt\u0103, pentru c\u0103 nu este nimic acolo. \u0218i Postgres face asta astfel: c\u00e2nd nu po\u021bi ob\u021bine un blocaj, spune \u201eCare este sensul s\u0103 te procesez?\u201d, pentru c\u0103 tu oricum a\u0219tep\u021bi pe cineva. A\u0219adar, s\u0103-l l\u0103s\u0103m s\u0103 r\u0103m\u00e2n\u0103 \u00een suspans, nu-l actualizeaz\u0103 deloc. Dar ce s-a \u00eent\u00e2mplat aici? De \u00eendat\u0103 ce 702 a terminat procesul \u0219i 703 a ob\u021binut blocajul s\u0103u, sistemul s-a \u00eentors. \u0218i a spus c\u0103 acum avem dou\u0103 persoane care a\u0219teapt\u0103. \u0218i apoi s\u0103 le actualiz\u0103m \u00eempreun\u0103. \u0218i s\u0103 indic\u0103m c\u0103 ambele a\u0219teapt\u0103. <\/p>\n
<\/p>\n
Nu \u0219tiu de ce Postgres face a\u0219a. Dar exist\u0103 o problem\u0103 numit\u0103 f\u2026. Mi se pare c\u0103 acest termen nu exist\u0103 \u00een limba rom\u00e2n\u0103. Este atunci c\u00e2nd to\u021bi a\u0219teapt\u0103 un singur blocaj, chiar \u0219i atunci c\u00e2nd sunt 20 de instan\u021be care a\u0219teapt\u0103 blocajul. \u0218i dintr-o dat\u0103, to\u021bi se trezesc simultan. \u0218i to\u021bi \u00eencep s\u0103 \u00eencerce s\u0103 reac\u021bioneze. Dar sistemul face astfel \u00eenc\u00e2t to\u021bi a\u0219teapt\u0103 703. Pentru c\u0103 to\u021bi a\u0219teapt\u0103 \u0219i noi \u00eei a\u0219ez\u0103m imediat \u00eentr-o linie. \u0218i dac\u0103 apare o alt\u0103 cerere nou\u0103, care a fost formulat\u0103 dup\u0103 aceasta, de exemplu, 707, atunci va fi din nou un vid. <\/p>\n
<\/p>\n
\u0218i mi se pare c\u0103 acest lucru se face pentru a putea spune c\u0103 \u00een acest moment 702 a\u0219teapt\u0103 703, iar to\u021bi cei care vin dup\u0103 aceasta nu vor avea nicio \u00eenregistrare \u00een acest c\u00e2mp. Dar de \u00eendat\u0103 ce primul care a\u0219tepta pleac\u0103 \u0219i to\u021bi cei care a\u0219teptau \u00een acel moment \u00eenainte de actualizare primesc acela\u0219i marcaj. \u0218i din acest motiv, mi se pare c\u0103 acest lucru este \u00eenf\u0103ptuit pentru a putea procesa \u00een ordine, astfel \u00eenc\u00e2t s\u0103 fie corect organizate. <\/p>\n
<\/p>\n
\u00centotdeauna am privit asta ca pe un fenomen destul de straniu. Pentru c\u0103 aici, de exemplu, nu-i enumer\u0103m deloc. Dar, mi se pare c\u0103 de fiecare dat\u0103 c\u00e2nd d\u0103m un nou lock, ne uit\u0103m la to\u021bi cei care sunt \u00een proces de a\u0219teptare. Atunci, \u00eei a\u0219ez\u0103m pe to\u021bi \u00eentr-o linie. Iar orice nou venit care apare este inclus \u00een linie doar atunci c\u00e2nd urm\u0103toarea persoan\u0103 a terminat de procesat. O \u00eentrebare foarte bun\u0103. V\u0103 mul\u021bumesc foarte mult pentru \u00eentrebare!<\/p>\n
<\/p>\n
Mi se pare mult mai logic atunci c\u00e2nd 705 a\u0219teapt\u0103 704.<\/em> <\/p>\n<\/p>\n
Dar problema este c\u0103, din punct de vedere tehnic, pute\u021bi trezi fie unul, fie cel\u0103lalt. A\u0219adar, vom trezi unul sau altul. Dar ce se \u00eent\u00e2mpl\u0103 \u00een func\u021bionarea sistemului? Vede\u021bi cum 703, \u00een partea de sus, \u0219i-a blocat propriul ID de tranzac\u021bie. A\u0219a func\u021bioneaz\u0103 Postgres. \u0218i 703 se blocheaz\u0103 cu propriul ID de tranzac\u021bie, a\u0219a c\u0103, dac\u0103 cineva vrea s\u0103 a\u0219tepte, va a\u0219tepta 703. \u0218i, \u00een esen\u021b\u0103, 703 finalizeaz\u0103. \u0218i doar dup\u0103 ce se finalizeaz\u0103, un anumit proces se treze\u0219te. \u0218i nu \u0219tim care va fi acela. Apoi le proces\u0103m gradual. Dar nu este clar care proces se treze\u0219te primul, pentru c\u0103 poate fi oricare dintre aceste procese. Practic, am avut un planificator care spunea c\u0103 acum putem trezi oricare dintre aceste procese. Alegem pur \u0219i simplu unul la \u00eent\u00e2mplare. De aceea, ambele trebuie marcate, pentru c\u0103 putem trezi oricare dintre ele. <\/p>\n
<\/p>\n
\u0218i problema este c\u0103 avem CP-infinit. Astfel, este foarte probabil s\u0103 putem trezi unul mai recent. \u0218i, dac\u0103, de exemplu, vom trezi unul mai recent, ne vom a\u0219tepta la cel care tocmai a primit blocajul, a\u0219a c\u0103 nu definim cu exactitate cine va fi trezit primul. Cream pur \u0219i simplu o astfel de situa\u021bie, iar sistemul \u00eei va trezi \u00een ordine aleatorie. <\/p>\n
<\/p>\n
Exist\u0103 articole despre locks Egor Rogov<\/a><\/noindex>. Uita\u021bi-v\u0103, acestea sunt de asemenea interesante \u0219i utile. Tema este, desigur, extrem de complex\u0103. V\u0103 mul\u021bumesc foarte mult, Bruce!<\/em><\/p>\nSursa: 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
![\"Dezv\u0103luirea](\"\/wp-content\/uploads\/2020\/07\/1f75fbb0cb41c306c33c823ef55f7238.png\")
<\/p>\n