{"id":87954,"date":"2020-07-12T01:42:48","date_gmt":"2020-07-11T23:42:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/unlocking-the-postgres-lock-manager-bryus-momzhian"},"modified":"2020-07-12T01:42:48","modified_gmt":"2020-07-11T23:42:48","slug":"unlocking-the-postgres-lock-manager-bryus-momzhian","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/unlocking-the-postgres-lock-manager-bryus-momzhian","title":{"rendered":"Odklepanje upravljalnika zaklepa Postgres. Bruce Momjian","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"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".<\/p>\n

<\/p>\n

\"Odklepanje<\/p>\n

<\/p>\n

(Opomba: Vse SQL poizvedbe s diapozitivov lahko dobite na tej povezavi: http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex>)<\/p>\n

<\/p>\n

Pozdravljeni! Odli\u010dno je ponovno biti tukaj v Rusiji. Opravi\u010dujem se, da se nisem mogel udele\u017eiti prej\u0161njega leta, vendar imata Ivan in jaz v tem letu velike na\u010drte. Upam, da bom tukaj veliko bolj pogosto. Rad imam obiske v Rusiji. Obiskal bom Tjumen in Tver. Veselim se, da bom obiskal ta mesta. <\/p>\n

<\/p>\n

Ime mi je Bruce Momjian. Delam v podjetju EnterpriseDB in z Postgresom delam \u017ee ve\u010d kot 23 let. \u017divim v Filadelfiji v ZDA. Potujem pribli\u017eno 90 dni na leto. Udele\u017eim se pribli\u017eno 40 konferenc. Moj spletni stran<\/a><\/noindex>, ki vsebuje diapozitive, ki vam jih bom zdaj pokazal. Zato si jih lahko po konferenci prenesete z moje osebne spletne strani. Na voljo je tudi pribli\u017eno 30 predstavitev. Na voljo so tudi videoposnetki in veliko zapisov v blogu, ve\u010d kot 500. To je zelo obse\u017een vir. In \u010de vas ta material zanima, vas vabim, da ga uporabite. <\/p>\n

<\/a><\/noindex><\/p>\n

Preden sem za\u010del delati s Postgresom, sem bil u\u010ditelj, profesor. In zelo sem vesel, da vam bom lahko sedaj predstavil to, kar bom predstavil. To je ena izmed mojih najbolj zanimivih predstavitev. Ta predstavitev vsebuje 110 diapozitivov. Za\u010deli bomo z enostavnimi stvarmi, dokler ne bo na koncu predavanje postalo vse bolj zapleteno in zahtevno.<\/p>\n

<\/p>\n

\"Odklepanje<\/p>\n

<\/p>\n

To je precej neprijetna tema. Zaklepanje ni najbolj priljubljena tema. \u017delimo, da bi ta pojav izginil. Je kot obisk zobozdravnika. <\/p>\n

<\/p>\n

\"Odklepanje<\/p>\n

<\/p>\n

    \n
  1. Zaklepanje predstavlja problem za veliko ljudi, ki delajo z bazami podatkov in imajo ve\u010d procesov, ki delujejo hkrati. Potrebujejo zaklepanje. Torej, danes vam bom dal osnovna znanja o zaklepanju. <\/li>\n
  2. Identifikatorji transakcij. To je precej dolgo\u010dasen del predstavitve, vendar ga je treba razumeti.<\/li>\n
  3. Nato se bomo pogovorili o vrstah zaklepanja. To je precej mehani\u010den del. <\/li>\n
  4. In nato bomo navedli nekaj primerov zaklepanja. To bo precej zapleteno za razumevanje. <\/li>\n<\/ol>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Pogovorimo se o zaklepanju.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Terminologija je pri nas precej zapletena. Koliko vas ve, od kod ta odlomek? Dva \u010dloveka. To je iz igre, ki se imenuje \u201eKolosalno pustolov\u0161\u010dino v jami\u201c. To je bila tekstovna ra\u010dunalni\u0161ka igra v 80. letih, mislim. Tam si moral iti v jamo, v labirint, in tekst se je spreminjal, vendar je vsebina ostala pribli\u017eno enaka vsakokrat. Tako se spomnim te igre. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In tukaj vidimo imena blokad, ki so pri\u0161le k nam iz Oracle. Uporabljamo jih. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Tukaj vidimo izraze, ki me zmedo. Na primer, SHARE UPDATE EXCLUSIVE. Nato SHARE RAW EXCLUSIVE. Priznam, da ti izrazi niso zelo razumljivi. Poskusili bomo, da jih podrobno obravnavamo. Nekateri vsebujejo besedo \u201eshare\u201c, kar pomeni \u2013 lo\u010diti se. Nekateri vsebujejo besedo \u201eexclusive\u201c \u2014 ekskluziven. V nekaterih sta prisotni obe besedi. Rad bi za\u010del s tem, kako te blokade delujejo. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Prav tako je zelo pomembna beseda \u201edostop\u201c \u2014 access. In beseda \u201erow\u201c \u2014 vrstica. Torej, razporeditev dostopa, razporeditev vrstic. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    \u0160e en problem, ki ga je treba razumeti v Postgresu, o katerem, na \u017ealost, ne bom mogel govoriti v svojem nastopu, je MVCC. Imam posebno predstavitev o tej temi na svoji spletni strani. In \u010de mislite, da je ta predstavitev zapletena, potem je MVCC verjetno moja najte\u017eja tema. In \u010de vas to zanima, lahko to pogledate na spletu. Poglejte lahko video. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    \u0160e ena stvar, ki jo moramo razumeti \u2013 to so identifikatorji transakcij. Mnoge transakcije ne morejo delovati brez edinstvenih identifikatorjev. In tukaj imamo razlago, kaj je transakcija. V Postgresu sta dve sistemi \u0161tevil\u010denja transakcij. Vem, da to ni zelo elegantna re\u0161itev. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Prav tako imejte v mislih, da bodo diapozitivi precej zapleteno razumljivi, zato je treba pozornost posvetiti tistemu, kar je izpostavljeno v rde\u010di barvi.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex><\/p>\n

    <\/p>\n

    Poglejmo. Rde\u010de je ozna\u010deno \u0161tevilko transakcije. Tukaj je prikazana funkcija SELECT pg_back. Vrne mojo transakcijo in ID te transakcije. <\/p>\n

    <\/p>\n

    Eden trenutek, \u010de vam je ta predstavitev v\u0161e\u010d in jo \u017eelite zagnati v svoji bazi podatkov, lahko preprosto kliknete na to povezavo, ozna\u010deno z roza barvo, in prenesete SQL za to predstavitev. Enostavno jo za\u017eenite v va\u0161em PSQL in celotna predstavitev se bo takoj prikazala na va\u0161em zaslonu. Ne bo vsebovala barv, vendar jo bomo vsaj lahko videli.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    V tem primeru vidimo ID transakcije. To je \u0161tevilka, ki smo ji dodelili. Obstaja tudi drug tip ID transakcije v Postgres, ki se imenuje virtualni ID transakcije.<\/p>\n

    <\/p>\n

    In to moramo razumeti. To je zelo pomembno, sicer ne bomo razumeli zaklepanja v Postgresu.<\/p>\n

    <\/p>\n

    Virtualni ID transakcije je ID transakcije, ki ne vsebuje stalnih vrednosti. Na primer, \u010de izvedem ukaz SELECT, verjetno ne bom spremenil baze podatkov, ne bom ni\u010desar zaklenil. Zato, ko izvedemo preprost SELECT, ne dodelimo tej transakciji stalnega ID. Dodelimo ji samo virtualni ID.<\/p>\n

    <\/p>\n

    To pove\u010duje u\u010dinkovitost Postgres, izbolj\u0161uje mo\u017enosti za \u010di\u0161\u010denje, zato virtualni ID transakcije sestavljata dve \u0161tevilki. Prva \u0161tevilka pred po\u0161evnico je ID backend-a. Na desni strani vidimo preprosto \u0161tevec.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Zato, ko izvedem poizvedbo, pove, da je ID backend-a - 2. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In \u010de izvedem serijo tak\u0161nih transakcij, vidimo, da se \u0161tevec vsakokrat pove\u010duje, ko izvedem poizvedbo. Na primer, ko izvedem poizvedbo 2\/10, 2\/11, 2\/12 itd. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Upo\u0161tevajte, da sta tukaj dve stolpci. Na levi strani vidimo virtualni ID transakcije - 2\/12. Na desni strani pa imamo stalni ID transakcije. To polje je prazno. Ta transakcija ne modificira baze podatkov. Zato ji ne dodelim stalnega ID transakcije.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Takoj ko izvedem ukaz analizirati (ANALYZE), mi ista poizvedba vrne stalni ID transakcije. Poglejte, kako se je to spremenilo. Prej nisem imel tega ID-ja, zdaj pa je pri\u0161el.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Tukaj imamo \u0161e eno poizvedbo, \u0161e eno transakcijo. Virtualna \u0161tevilka transakcije je 2\/13. In \u010de zahtevam stalni ID transakcije, ga bom prejel, ko bom izvedel poizvedbo. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Torej, \u0161e enkrat. Imamo virtualni ID transakcije in stalni ID transakcije. Preprosto razumite ta trenutek, da boste lahko razumeli vedenje Postgres.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Prehajamo k tretjemu poglavju. Tukaj bomo le pre\u0161li skozi razli\u010dne vrste zaklepov v Postgresu. To ni posebej zanimivo. Zadnji del bo veliko bolj zanimiv. Toda osnovne stvari moramo obravnavati, sicer ne bomo razumeli, kaj sledi. <\/p>\n

    <\/p>\n

    Pre\u0161li bomo skozi ta razdelek, si ogledali vsako vrsto zaklepa. Pokazal vam bom primere, kako se postavijo, kako delujejo, in vam pokazal nekatere poizvedbe, ki jih lahko uporabite, da vidite, kako zaklepanje deluje v Postgresu.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Da bi ustvarili poizvedbo in videli, kaj se dogaja v Postgresu, moramo izdati poizvedbo v sistemskem pogledu. V tem primeru je na\u0161 pg_lock ozna\u010den z rde\u010do. Pg_lock je sistemska tabela, ki nam pove, katere zaklepe trenutno uporablja Postgres.<\/p>\n

    <\/p>\n

    Kljub temu mi je zelo te\u017eko pokazati pg_lock samega, ker je to kar zapleteno. Zato sem ustvaril pogled, ki prikazuje pg_locks. Prav tako opravlja nekaj dela zame, da bolje razumem. To pomeni, da izklju\u010duje moje zaklepe, mojo sejo itd. To je preprost SQL in bolje vam omogo\u010da, da vidite, kaj se dogaja. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    \u0160e en problem je, da je ta pogled zelo \u0161irok, zato moram ustvariti drugega \u2013 lockview2.<\/p>\n

    <\/p>\n

    \"Odklepanje In prikazuje mi \u0161e dodatne stolpce iz tabele. In \u0161e enega, ki mi prikazuje ostale stolpce. To je kar zapleteno, zato sem se potrudil, da to predstavim \u010dim bolj preprosto. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Torej, ustvarili smo tabelo, ki se imenuje Lockdemo. In v njej smo ustvarili en zapis. To je na\u0161a primerna tabela. Ustvarili bomo razdelke, da vam preprosto poka\u017eemo primere zaklepov. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Torej, en zapis, en stolpec. Prvi tip zaklepa se imenuje ACCESS SHARE. To je najmanj omejujo\u010d zaklep. To pomeni, da prakti\u010dno ne konfliktira z ostalimi zaklepi.<\/p>\n

    <\/p>\n

    In \u010de \u017eelimo izrecno dolo\u010diti zaklepanje, za\u017eenemo ukaz \"lock table\". In ta o\u010ditno zaklene, tj. v na\u010dinu ACCESS SHARE za\u017eenemo lock table. In \u010de za\u017eenem PSQL v ozadju, za\u017eenem na ta na\u010din drugo sejo iz moje prve seje. Kaj torej tukaj naredim? Preklopim na drugo sejo in ji re\u010dem \"prika\u017ei mi lockview za to poizvedbo\". In tu imam AccessShareLock v tej tabeli. To je to\u010dno to, kar sem zahteval. In pravi, da je zaklepanje dodeljeno. Zelo preprosto. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Nato, \u010de pogledamo v drugo kolono, tam ni ni\u010d. So prazne. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In \u010de za\u017eenem ukaz \"SELECT\", je to implicitna (jasna) metoda za pridobitev AccessShareLock. Zato sprostim svojo tabelo in za\u017eenem poizvedbo, ki vrne ve\u010d vrstic. In v eni od vrstic vidimo AccessShareLock. Na ta na\u010din SELECT spro\u017ei AccessShareLock v tabeli. In ta ne povzro\u010da prakti\u010dno nobenega konflikta, saj gre za nizkolegleno zaklepanje. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Kaj pa, \u010de za\u017eenem SELECT in imam tri razli\u010dne tabele? Prej sem zagnal samo eno tabelo, zdaj pa za\u017eenem tri: pg_class, pg_namespace in pg_attribute.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In zdaj, ko pogledam poizvedbo, vidim 9 AccessShareLocks v treh tabelah. Zakaj? S tremi tabelami, ozna\u010denimi z blue: pg_attribute, pg_class, pg_namespace. Vendar pa lahko vidite, da vsi indeksi, dolo\u010deni skozi te tabele, prav tako imajo AccessShareLock.<\/p>\n

    <\/p>\n

    In to je zaklepanje, ki prakti\u010dno ne povzro\u010da konfliktov z drugimi. Vse, kar dela, je preprosto prepre\u010duje, da bi lahko izpraznili tabelo, medtem ko jo izbiramo. To ima smisel. Tj. \u010de izberemo tabelo in v tem trenutku izgine, potem je to narobe, zato. 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>. V bistvu, to je vse, kar po\u010dne. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    ROW SHARE \u2013 to zaklepanje je nekoliko druga\u010dno. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Poglejmo primer. SELECT ROW SHARE je na\u010din zaklepanja vsake vrstice posebej.<\/strong>. Tako nih\u010de ne more izbrisati ali spremeniti, medtem ko jih gledamo. <\/p>\n

    <\/p>\n

    \"OdklepanjeTorej, kaj dela SHARE LOCK? Vidimo, da je ID transakcije 681 za SELECT. In to je zanimivo. Kaj se je tukaj zgodilo? Prvi\u010d vidimo \u0161tevilko v polju \u201eLock\u201c. Vzamemo ID transakcije, in pove, da jo blokira v ekskluzivnem na\u010dinu. Vse, kar po\u010dne, je, da pravi, da imam vrstico, ki je tehni\u010dno blokirana nekje v tabeli. Ampak ne pove, kje natan\u010dno. Malo kasneje bomo to podrobneje obravnavali.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Tukaj govorimo, da se blokada uporablja od nas.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Torej, ekskluzivna blokada izrecno (explicitly) pove, da je ekskluzivna. In tudi, \u010de izbri\u0161ete vrstico v tej tabeli, se to tudi zgodi, kot lahko vidite. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    SHARE EXCLUSIVE \u2013 to je dalj\u0161a blokada.<\/strong><\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    To je (ANALYZE) ukaz analize, ki bo uporabljen.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    SHARE LOCK \u2013 lahko izrecno blokirate v na\u010dinu share.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Lahko tudi ustvarite edinstven indeks. In tam lahko vidite SHARE LOCK, ki je del tega. In blokira tabelo ter nanjo nastavi SHARE LOCK.<\/p>\n

    <\/p>\n

    Privzeto SHARE LOCK na tabeli pomeni, da lahko drugi berejo tabelo, vendar je nih\u010de ne more spreminjati. In prav to se zgodi, ko ustvarite edinstven indeks.<\/strong><\/p>\n

    <\/p>\n

    \u010ce ustvarim edinstven concurrently indeks, bom imel drug tip blokade, ker, kot se spomnite, uporaba concurrently indeksov zmanj\u0161uje zahteve po blokadi. In \u010de uporabljam normalno blokado, normalni indeks, potem tako prepre\u010dim zapisovanje v indeks tabelo med njenim ustvarjanjem. \u010ce uporabljam concurrently indeks, pa moram uporabiti drug tip blokade. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    SHARE ROW EXCLUSIVE \u2013 spet jo je mogo\u010de dolo\u010diti eksplicitno (explicitly).<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Ali lahko ustvarimo pravilo, tj. vzeti dolo\u010deno situacijo, v kateri bo uporabljena.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    EXCLUSIVE blokada pomeni, da noben drug ne more spreminjati tabele. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Tukaj vidimo razli\u010dne vrste blokad. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    ACCESS EXCLUSIVE, na primer, je ukaz blokade. Na primer, \u010de delate CLUSTER table<\/code>, to pomeni, da nih\u010de ne more tja zapisovati. In blokira ne le samo tabelo, ampak tudi indekse.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    To je druga stran blokade ACCESS EXCLUSIVE, kjer vidimo natan\u010dno, kaj blokira v tabeli. Blokira posamezne vrstice tabele, kar je dovolj zanimivo.<\/p>\n

    <\/p>\n

    To je vse osnovne informacije, ki sem jih hotel posredovati. Govorili smo o blokadah, ID transakcijah, govorili smo o virtualnih ID transakcijah, o stalnih ID transakcijah. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In zdaj se bomo podali skozi primere blokad. To je najzanimivej\u0161i del. Oglejali si bomo zelo zanimive primere. Moj cilj v tej predstavitvi je, da vam zagotovim bolj\u0161o predstavo o tem, kaj Postgres v resnici po\u010dne, ko posku\u0161a blokirati dolo\u010dene stvari. Zdi se mi, da zelo dobro blokira posamezne dele. <\/p>\n

    <\/p>\n

    Poglejmo nekatere specifi\u010dne primere.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Za\u010deli bomo s tabelami in eno vrstico v tabeli. Ko vstavim nekaj, se prika\u017ee ExclusiveLock, ID transakcije in ExclusiveLock na tabeli. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Kaj pa, \u010de vstavim \u0161e dve vrstici? Zdaj imamo v na\u0161i tabeli tri vrstice. Vstavil sem eno vrstico in dobil tole na izlazu. In \u010de vstavim \u0161e dve vrstici, kaj je tukaj \u010dudnega? Tuki je neobi\u010dajno, ker sem dodal tri vrstice v to tabelo, toda \u0161e vedno imam dve vrsti v tabeli blokad. In to je v bistvu temeljno vedenje Postgres.<\/p>\n

    <\/p>\n

    Mnogi menijo, da \u010de v bazi podatkov blokirate 100 vrstic, potem boste morali ustvariti 100 vnose blokad. \u010ce bom blokiral hkrati 1 000 vrstic, potem bom potreboval 1 000 takih zahtev. In \u010de moram blokirati milijon ali milijardo. Ampak, \u010de bomo to po\u010deli, ne bo delovalo dobro. \u010ce ste uporabljali sistem, ki ustvarja vnose blokad za vsako posamezno vrstico, vidite, da je to zapleteno. Ker morate takoj dolo\u010diti tabelo blokad, ki se lahko napolni, ampak Postgres tega ne po\u010dne. <\/p>\n

    <\/p>\n

    In na tem diapozitivu je zelo pomembno, da je jasno prikazano, da obstaja \u0161e en sistem, ki deluje znotraj MVCC, ki blokira posamezne vrstice. Zato, ko blokirate milijarde vrstic, Postgres ne ustvari milijarde posameznih ukazov za blokado. In to zelo pozitivno vpliva na zmogljivost. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Kaj pa posodobitev? Sedaj posodabljam vrstico in lahko opazite, da je hkrati izvedlo dve razli\u010dni operaciji. Hkrati je zaklenilo tabelo, vendar je tudi zaklenilo indeks. Indeks je bilo treba zakleniti zaradi edinstvenih omejitev v tej tabeli. \u017delimo se prepri\u010dati, da ga nih\u010de ne spremeni, zato ga zaklenemo.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Kaj se zgodi, \u010de \u017eelim posodobiti dve vrstici? In vidimo, da se obna\u0161a enako. Izvajamo dvakrat ve\u010d posodobitev, toda prav tako je enaka koli\u010dina zaklenjenih vrstic. <\/p>\n

    <\/p>\n

    \u010ce vas zanima, kako to po\u010dne Postgres, bi se morali udele\u017eiti mojih predstavitev o MVCC, da bi spoznali, kako Postgres notranje ozna\u010duje te vrstice, ki jih spreminja. Postgres ima na\u010din, kako to dose\u017ee, vendar to ne deluje na nivoju zaklepanja tabel, temve\u010d na bolj nizki in u\u010dinkoviti ravni.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Kaj pa, \u010de \u017eelim nekaj izbrisati? \u010ce izbrisem, na primer, eno vrstico in \u0161e vedno imam svoja dva vhoda za zaklep, in tudi \u010de \u017eelim izbrisati vse, vendar ostajajo tam prisotni.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In, na primer, \u017eelim vnesti 1.000 vrstic, nato pa ali izbrisati ali dodati 1.000 vrstic, te posamezne vrstice, ki jih dodajam ali spreminjam, se ne zapisujejo tukaj. Zapisane so na bolj nizki ravni znotraj same vrstice. In med predstavitvijo o MVCC sem o tem govoril podrobno. Vendar je zelo pomembno, ko analizirate zaklepe, da se prepri\u010date, da imate zaklep na nivoju tabel in da tukaj ne vidite, kako se zapisujejo posamezne vrstice. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Kaj pa eksplicitno zaklepanje?<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    \u010ce pritisnem 'posodobi', imam dve zaklenjeni vrstici. In \u010de jih vse ozna\u010dim in pritisnem 'posodobi vse', mi \u0161e vedno ostajata dve zapisa zaklepa. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Ne ustvarjamo lo\u010denih zapisov za vsako posamezno vrstico. Ker bi to zmanj\u0161alo zmogljivost, lahko pride do prekomernega \u0161tevila. In lahko se znajdemo v neprijetni situaciji. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In enako velja, \u010de delamo shared, lahko to po\u010dnemo 30-krat. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Obnovimo svojo tabelo, vse izbri\u0161emo, nato pa ponovno vstavimo eno vrstico.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Drug\u00fd typ spr\u00e1vania, ktor\u00fd vid\u00edte v Postgres, je ve\u013emi dobre zn\u00e1me a \u017eiaduce spr\u00e1vanie \u2013 to, \u017ee m\u00f4\u017eete vykon\u00e1va\u0165 update alebo select. A m\u00f4\u017eete to robi\u0165 s\u00fa\u010dasne. Select nezamkne update a naopak. Hovor\u00edme, \u017ee \u010d\u00edtaj\u00faci nezamkne toho, kto p\u00ed\u0161e, a ten, kto p\u00ed\u0161e, nezamkne \u010ditate\u013ea. <\/p>\n

    <\/p>\n

    Uk\u00e1\u017eem v\u00e1m pr\u00edklad tohto. Teraz urob\u00edm v\u00fdber. Potom vykon\u00e1me INSERT. A potom si budete m\u00f4c\u0165 pozrie\u0165 \u2013 694. Uvid\u00edte ID transakcie, ktor\u00e1 vykonala tento insert. A takto to funguje. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    A ak sa teraz pozriem na svoj backend ID, stalo sa \u2013 695. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    A m\u00f4\u017eem vidie\u0165, \u017ee 695 sa objavuje v mojej tabu\u013eke. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    A ak vykon\u00e1m aktualiz\u00e1ciu takto, dostanem in\u00fd pr\u00edpad. V takom pr\u00edpade je 695 v\u00fdhradn\u00e1 blok\u00e1cia, a update m\u00e1 rovnak\u00e9 spr\u00e1vanie, ale medzi nimi nevznik\u00e1 konflikt, \u010do je dos\u0165 nezvy\u010dajn\u00e9. <\/p>\n

    <\/p>\n

    A m\u00f4\u017eete si v\u0161imn\u00fa\u0165, \u017ee hore je ShareLock a dole je ExclusiveLock. A obidve transakcie sa uskuto\u010dnili.<\/p>\n

    <\/p>\n

    A treba si vypo\u010du\u0165 moju predn\u00e1\u0161ku o MVCC, aby ste pochopili, ako to prebieha. Ale toto je ilustr\u00e1cia toho, \u017ee m\u00f4\u017eete robi\u0165 obidve veci s\u00fa\u010dasne, t.j. s\u00fa\u010dasne vykon\u00e1va\u0165 SELECT a UPDATE.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Po\u010fme resetova\u0165 a znova vykona\u0165 jednu oper\u00e1ciu. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Ak sa pok\u00fasite spusti\u0165 s\u00fa\u010dasne dva updates na rovnakom riadku, zablokuje sa to. A pam\u00e4tajte, hovoril som, \u017ee \u010d\u00edtaj\u00faci nezamkne p\u00ed\u0161uceho, a p\u00ed\u0161uci nezamkne \u010d\u00edtaj\u00faceho, ale jeden p\u00ed\u0161uci zablokuje druh\u00e9ho p\u00ed\u0161uceho. T.j. nem\u00f4\u017eeme dovoli\u0165, aby dvaja \u013eudia s\u00fa\u010dasne aktualizovali ten ist\u00fd riadok. Mus\u00edme \u010daka\u0165, k\u00fdm jeden z nich skon\u010d\u00ed. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    A aby som to ilustroval, pozriem sa na tabu\u013eku Lockdemo. A pozrieme sa na jeden riadok. Na transakciu 698.<\/p>\n

    <\/p>\n

    Aktualizovali sme to na 2. 699 \u2013 to je prv\u00e1 aktualiz\u00e1cia. A t\u00e1 prebehla \u00faspe\u0161ne, alebo sa nach\u00e1dza vo vy\u010dk\u00e1vaj\u00facej transakcii a \u010dak\u00e1, k\u00fdm potvrd\u00edme alebo zru\u0161\u00edme. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Vendar poglejte \u0161e na drugo \u2013 2\/51 \u2013 to je na\u0161a prva transakcija, na\u0161a prva seja. 3\/112 \u2013 to je drugi zahtevek, ki se je prikazal zgoraj in spremenil to vrednost na 3. In \u010de opazite, je zgornji blokiral samega sebe, tistega 699. Toda 3\/112 ni zagotovil zaklepanja. V stolpcu Lock_mode pi\u0161e, da \u010daka. \u010caka na 699. In \u010de pogledate, kje je 699, je vi\u0161je. In kaj je prva seja naredila? Ustvarila je ekskluzivno zaklepanje na svojem lastnem ID-ju transakcije. Tako to dela Postgres. Blokira lastni ID transakcije. In \u010de \u017eelite \u010dakati, da nekdo potrdi ali prekli\u010de, morate \u010dakati, dokler je \u010dakanje na transakcijo. In zato lahko vidimo \u010duden vrstic. <\/p>\n

    <\/p>\n

    Poglejmo \u0161e enkrat. Na levi vidimo na\u0161e obdelovalno ID. V drugem stolpcu vidimo na\u0161 virtualni ID transakcije, v tretjem pa vidimo lock_type. Kaj to pomeni? V bistvu pravi, da blokira ID transakcije. Toda opazite, da je v vseh vrsticah spodaj napisano relation. In zato imate dva tipa zaklepanja v tabeli. Obstaja zaklepanje relation. Obstaja tudi zaklepanje transactionid, kjer blokirate sami, to\u010dno to se dogaja v prvi vrstici ali na dnu, kjer transationid, kjer \u010dakamo, da 699 zaklju\u010di svojo operacijo. <\/p>\n

    <\/p>\n

    Gledam, kaj se tukaj dogaja. In tukaj se hkrati dogajata dve stvari. Poglejte zaklepanje po ID-ju transakcije v prvi vrstici, ki blokira samo sebe. In blokira samo sebe, da prisili ljudi, da \u010dakajo. <\/p>\n

    <\/p>\n

    \u010ce pogledate 6. vrstico, je to ista zapis, kot prva. In zato je transakcija 699 blokirana. 700 se tudi sam blokira. In potem v spodnji vrstici boste videli, da \u010dakamo, da 699 zaklju\u010di svojo operacijo.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In v lock_type, tuple vidite \u0161tevilke. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Lahko vidite, da je to 0\/10. In to je \u0161tevilka strani, in tudi offset tega konkretnega vrstica. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In vidite, da postane 0\/11, ko posodobimo. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Toda v resnici \u2013 to je 0\/10, ker se dogaja \u010dakanje na to operacijo. Imamo prilo\u017enost pogledati, da je to tisti vrstica, ki jo \u010dakam, da potrdim. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Ko se to potrdi in pritisne commit, in ko se posodobitev kon\u010da, je to, kar dobimo spet. Transakcija 700 je edina zaklenitev, ne \u010daka ve\u010d nikogar, ker je bila odobrena. \u010caka samo, da se transakcija kon\u010da. Takoj ko se 699 kon\u010da, ne \u010dakamo ve\u010d na ni\u010d. In zdaj transakcija 700 pravi, da je vse v redu, da ima vse zaklenitve, ki jih potrebuje, v vseh dovoljenih tabelah. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In da bi \u0161e dodatno zapletli stvari, ustvarimo \u0161e en pogled, ki nam tokrat ponuja hierarhijo. Ne pri\u010dakujem, da boste razumeli to poizvedbo. Ampak to nam bo dalo jasnej\u0161i vpogled v to, kar se dogaja. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    To je rekurzivni pogled, ki ima \u0161e eno sekcijo. In potem znova vrne vse skupaj. Uporabimo to. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Kaj \u010de izvedemo tri so\u010dasne posodobitve in re\u010demo, da je vrstica zdaj enaka trem. In zamenjamo 3 z 4. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In tukaj vidimo 4. In ID transakcije 702. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Nato spremenim 4 v 5. In 5 v 6, ter 6 v 7. In formiram vrsto ljudi, ki bodo \u010dakali, da se ta ena transakcija kon\u010da.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In vse postane jasno. Katera je prva vrstica? To je 702. To je ID transakcije, ki je prvotno dolo\u010dil to vrednost. Kaj pa je napisano v stolpcu Granted? Imam oznake. f<\/code>. To so moje posodobitve, ki (5, 6, 7) ne morejo biti odobrene, ker \u010dakamo, da se transakcijski ID 702 kon\u010da. Imamo tam zaklenitev transakcijskega ID. In rezultat je 5 zaklenitev transakcijskih ID.<\/p>\n

    <\/p>\n

    In \u010de pogledate 704, 705, tam \u0161e ni ni\u010d napisanega, ker \u0161e ne vedo, kaj se dogaja. Preprosto pi\u0161ejo, da nimajo pojma, kaj se dogaja. In zgolj gredo v spanec, ker \u010dakajo, da nekdo kon\u010da in jih zbudi, ko se pojavi prilo\u017enost zamenjati vrstico. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    To je tako, kot izgleda. Jasno je, da vsi \u010dakajo na 12. vrstico. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    To je tisto, kar smo videli tukaj. Tukaj je 0\/12. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Tako da, ko je prva transakcija odobrena, lahko tukaj vidite, kako deluje hierarhija. In zdaj postane vse jasno. Vse postanejo \u010diste. In pravzaprav so \u0161e vedno v pri\u010dakovanju. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Tako se dogaja. 702 se zaklju\u010di. Zdaj 703 pridobi to blokado vrstice, nato 704 \u010daka, da se 703 zaklju\u010di. In 705 tudi to \u010daka. Ko se vse to zaklju\u010di, se o\u010distijo sami. Rad bi opozoril, da se vsi postavijo v vrsto. To je zelo podobno prometni situaciji, kjer vsi \u010dakajo na prvi avto. Prvi avto se ustavi, in vsi se formirajo v dolgo vrstico. Potem se premakne, nato lahko naslednji avto nadaljuje naprej in pridobi svojo blokado itd. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In \u010de se vam to zdi preprosto, bomo zdaj govorili o mrtvih blokadah. Ne vem, kdo izmed vas se je s tem \u017ee sre\u010dal. To je precej pogost problem v sistemih baze podatkov. Mrtve blokade so tisti primer, ko ena seja \u010daka, da nekaj izvede druga seja. In v tem trenutku druga seja \u010daka, da prva seja izvede nekaj. <\/p>\n

    <\/p>\n

    In na primer, \u010de Janez re\u010de: 'Daj mi nekaj', jaz pa re\u010dem: 'Ne, to ti dam le, \u010de mi da\u0161 nekaj drugega.' On pa re\u010de: 'Ne, ne bom ti dal, dokler mi ne da\u0161.' In tako se znajdemo v situaciji mrtve blokade. Prepri\u010dan sem, da Janez ne bi tako ravnal, ampak razumete bistvo: imamo dva \u010dloveka, ki \u017eelita nekaj pridobiti, vendar nista pripravljena dati, dokler jima drugi ne da tistega, kar \u017eelita. In tukaj ni re\u0161itve. <\/p>\n

    <\/p>\n

    V bistvu mora va\u0161a baza podatkov to odkriti. Nato je treba eno izmed sej odstraniti ali zapreti, ker sicer bodo tam ostale za vedno. To vidimo v bazah podatkov, to vidimo v operacijskih sistemih. In povsod, kjer imamo vzporedne procese, se to lahko zgodi. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Zdaj bomo postavili dve mrtvi blokadi. Postavili bomo 50 in 80. V prvi vrsti bom izvedel posodobitev z 50 na 50. Dobim \u0161tevilko transakcije 710. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Nato bom spremenil 80 v 81 in 50 v 51. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In tako bo to izgledalo. Zato ima 710 blokado vrstice, 711 pa \u010daka na potrditev. To smo videli, ko smo posodabljali. 710 je lastnik na\u0161e vrstice. 711 \u010daka, da 710 zaklju\u010di transakcijo.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Tudi navedeno je, na kateri vrstici se dogajajo mrtve blokade. In tukaj se za\u010dne stvari skrivati.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Zdaj posodabljamo 80 na 80. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In this is where deadlocks begin. 710 is waiting for a response from 711, and 711 is waiting for 710. This will not end well. There is no way out of this. They will be waiting for each other\u2019s responses. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    And this will just start causing delays. We don\u2019t want that. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Postgres has ways to detect when this happens. When it happens, you will receive such an error. It becomes clear that a process is waiting for a SHARE LOCK from another process, which is blocked by process 711. That process was waiting for a SHARE LOCK for a certain transaction ID and was blocked by another process. So we have a deadlock situation here.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Are there three-way deadlocks? Is this possible? Yes. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    We input these numbers into the table. We change 40 to 40, we make a lock. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    We change 60 to 61, 80 to 81. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Then we change 80, and then \u2013 boom! <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Now 714 is waiting for 715. 716 is waiting for 715. And there\u2019s nothing that can be done about it.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Here we have not two people but three. I want something from you, this one wants something from the third person, and the third person wants something from me. We end up in a three-way wait because we\u2019re all waiting for the other to finish what they need to do. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Postgres knows which row this is happening on. So it will give you the following message indicating that you have a problem where three entities are blocking each other. There are no constraints here. This can happen where 20 entries are blocking each other. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    The next problem is serializable. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    If there is a special serializable lock.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    And we return to 719. It has a completely normal output. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    And you can click to make a transaction serializable.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    You understand that you now have a different type of lock SA \u2013 it means serializable. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    And therefore we have a new type of lock called SARieadLock, which is a serial lock allowing to introduce serial numbers.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    And you can also insert unique indexes. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In this table we have unique indexes.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    So if I enter number 2 here, I have 2. But at the very top I insert another 2. And you can see that 721 has an exclusive lock. But now 722 is waiting for 721 to finish its operation because it cannot insert 2 until it knows what will happen with 721. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    And if we do a subtransaction.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Here we have 723.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In \u010de obdr\u017eimo to\u010dko in jo nato posodobimo, dobimo nov transakcijski ID. To je \u0161e en na\u010din obna\u0161anja, ki ga morate poznati. \u010ce to vrnemo, gre transakcijski ID. 724 se izgubi. Zdaj pa dobimo 725. <\/p>\n

    <\/p>\n

    In kaj posku\u0161am narediti tukaj? Posku\u0161am vam pokazati primere nenavadnih blokad, ki jih lahko najdete: bodisi serializable blokade bodisi SAVEPOINT \u2013 to so razli\u010dne vrste blokad, ki se bodo pojavile v tabeli blokad. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    To je ustvarjanje eksplicitnih (jasnih) blokad, ki imajo pg_advisory_lock. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In vidite, da je tip blokade tukaj naveden kot advisory. In tu je rde\u010de napisano 'advisory'. In hkrati lahko tako zaklenete s pg_advisory_unlock.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In za konec bi vam rad pokazal \u0161e eno fascinantno stvar. Ustvaril bom \u0161e eno vrsto. Ampak bomo povezali tabelo pg_locks s tabelo pg_stat_activity. In zakaj to \u017eelim narediti? Ker mi bo to omogo\u010dilo, da si ogledam in vidim vse trenutne seje ter katere blokade dejansko pri\u010dakujejo. To je precej zanimivo, ko zdru\u017eimo tabelo blokad in tabelo poizvedb. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In tukaj ustvarjamo pg_stat_view. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In posodobimo vrstico za eno. In tukaj vidimo 724. Nato zmanj\u0161amo na\u0161o vrstico na tri. In kaj vidite tukaj zdaj? To so poizvedbe, tj. vidite celoten seznam poizvedb, ki so navedene v levem stolpcu. Na desni strani pa lahko vidite blokade in tisto, kar ustvarjajo. In to je lahko bolj razumljivo za vas, da vam ni treba vsaki\u010d vrniti se k vsaki seji in preverjati \u2013 ali se ji pridru\u017eiti ali ne. To opravi namesto vas. <\/p>\n

    <\/p>\n

    \u0160e ena funkcija, ki je zelo uporabna \u2013 je pg_blocking_pids<\/code>Morda niste nikoli sli\u0161ali o tem. Kaj po\u010dne? Omogo\u010da nam, da re\u010demo, kateri natan\u010dni ID-ji procesov \u010daka za to sejo 11740. In lahko vidite, da 11740 \u010daka na 724. In 724 je na vrhu. 11306 je va\u0161 ID-proces. V bistvu ta funkcija preiskuje va\u0161o blokirno tabelo. In vem, da je to malo zapleteno, ampak uspete to razumeti. Ta funkcija prehaja skozi to blokirno tabelo in sku\u0161a najti, kje je ta ID procesa, ob upo\u0161tevanju blokad, ki jih \u010daka. Prav tako posku\u0161a izra\u010dunati, kateri ID procesa ima tisti proces, ki \u010daka na blokade. Zato lahko to funkcijo za\u017eenete. pg_blocking_pids<\/code>.<\/p>\n

    <\/p>\n

    In to je zelo koristno. Dodali smo to \u0161ele od razli\u010dice 9.6, zato ta funkcija obstaja le 5 let, a je zelo in zelo uporabna. Enako velja za drugi poizvedbo. Poka\u017ee natanko tisto, kar potrebujemo videti. <\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    To je tisto, o \u010demer sem \u017eelel govoriti z vami. In kot sem pri\u010dakoval, smo porabili vse na\u0161e \u010das, ker je bilo toliko diapozitivov. Diapozitivi so na voljo za prenos. Rad bi se vam zahvalil, da ste bili tukaj. Prepri\u010dan sem, da vam bo ostanek konference v\u0161e\u010d, najlep\u0161a hvala!<\/p>\n

    <\/p>\n

    Vpra\u0161anja:<\/p>\n

    <\/p>\n

    Na primer, \u010de posku\u0161am posodobiti vrstice, medtem ko druga seja posku\u0161a izbrisati celo tabelo. Kolikor razumem, bi moral biti tam kaj takega kot namera zaklep. Ali kaj takega obstaja v Postgresu?<\/em><\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    Vrnimo se na za\u010detek. Morda se spomnite, da kadar koli nekaj po\u010dnete, na primer, kadar izvajate SELECT, izdajamo AccessShareLock. In to prepre\u010duje brisanje tabele. Torej, \u010de na primer \u017eelite posodobiti vrstico v tabeli ali izbrisati vrstico, nekdo ne more isto\u010dasno izbrisati cele tabele, ker obdr\u017eite ta AccessShareLock nad celo tabelo in nad vrstico. In ko kon\u010date, lahko to izbri\u0161ejo. Ampak dokler neposredno spreminjate kaj, ne morejo tega storiti.<\/p>\n

    <\/p>\n

    Poglejmo \u0161e enkrat. Preverimo primer z brisanjem. In vidite, da obstaja ekskluzivni zaklep nad celo tabelo. <\/p>\n

    <\/p>\n

    To bi izgledalo kot ekskluzivni zaklep, kajne?<\/em><\/p>\n

    <\/p>\n

    Da, to izgleda kao to. Razumem o \u010demu govorite. Ka\u017eete da, ako izvr\u0161im SELECT, dobi\u0107u ShareExclusive, a zatim to prebacim u stanje Row Exclusive, postaje li to problem? Ali iznena\u0111uju\u0107e, to ne stvara problem. To je kao da se pove\u0107ava nivo zaklju\u010davanja, ali su\u0161tinski imam zaklju\u010davanje koje spre\u010dava brisanje. I sada, kada ovo zaklju\u010davanje u\u010dinim ja\u010dim, ono i dalje spre\u010dava brisanje. Zato nije da se penjem. T. e. spre\u010davao je to \u010dak i kada je bio na ni\u017eem nivou, tako da, kada pove\u0107am njegov nivo, on i dalje spre\u010dava brisanje tabele. <\/p>\n

    <\/p>\n

    Razumem o \u010demu govorite. Ovdje nema slu\u010daja pove\u0107anja nivoa zaklju\u010davanja, gde poku\u0161avate da se re\u0161ite jednog zaklju\u010davanja kako biste uneli ja\u010de. Ovdje se jednostavno svuda pove\u0107ava to spre\u010davanje, tako da ne izaziva nikakav sukob. Ali to je dobro pitanje. Hvala vam puno \u0161to ste ga postavili!<\/p>\n

    <\/p>\n

    \u0160ta treba da uradimo kako bismo izbegli situaciju deadlock-a kada imamo mnogo sesija, puno korisnika?<\/em><\/p>\n

    <\/p>\n

    Postgres automatski prime\u0107uje situacije deadlock-a. I automatski \u0107e ukloniti jednu od sesija. Jedini na\u010din da se izbegne situacija mrtvog zaklju\u010davanja je da blokirate ljude u istom redu. Dakle, kada pogledate va\u0161u aplikaciju, \u010desto je uzrok deadlock-a\u2026 Zamislimo da \u017eelim da blokiram dve razli\u010dite stvari. Jedna aplikacija blokira tabelu 1, a druga aplikacija blokira 2, a potom tabelu 1. Najjednostavniji na\u010din da izbegnete deadlock-e je da pogledate va\u0161u aplikaciju i poku\u0161ate da se uverite da se zaklju\u010davanje de\u0161ava u istom redosledu u svim aplikacijama. I to obi\u010dno uklanja 80% problema, jer razni ljudi pi\u0161u te aplikacije. I ako ih blokirate u istom redu, ne susre\u0107ete se sa situacijom deadlock-a.<\/p>\n

    <\/p>\n

    Hvala vam mnogo za va\u0161e izlaganje! Govorili ste o vacuum full i, ako pravilno razumem, vacuum full deformi\u0161e redosled zapisa u posebnom skladi\u0161tu, tako da zadr\u017eava trenutne zapise nepromenjenim. A za\u0161to vacuum full zahteva ekskluzivnu blokadu i za\u0161to sukobljava sa operacijama pisanja?<\/em><\/p>\n

    <\/p>\n

    To je dobro vpra\u0161anje. Razlog je, da vacuum full zajame tabelo. In dejansko ustvarjamo novo razli\u010dico tabele. In tabela bo nova. Tako da bo to popolnoma nova razli\u010dica tabele. Te\u017eava je v tem, da ne \u017eelimo, da ljudje berejo to, ker moramo omogo\u010diti, da vidijo novo tabelo. In tako se povezuje s prej\u0161njim vpra\u0161anjem. \u010ce bi lahko brali hkrati, ne bi mogli premikati in usmerjati ljudi na novo tabelo. \u010cakati bi morali, da vsakdo kon\u010da z branjem te tabele, zato gre dejansko za situacijo ekskluzivne zaklepanja.
    \nSamo re\u010demo, da zaklepamo od za\u010detka, ker vemo, da bomo na koncu potrebovali ekskluzivno zaklepanje, da premaknemo vse na novo kopijo. Zato to potencialno lahko razre\u0161imo. In tako to po\u010dnemo s so\u010dasnim indeksiranjem. A to je precej bolj zapleteno. In to se zelo nana\u0161a na va\u0161e prej\u0161nje vpra\u0161anje o ekskluzivnem zaklepanju.<\/p>\n

    <\/p>\n

    Ali je mogo\u010de dodati timeout zaklepanja v PostgreSQL? V Oraclu lahko, na primer, napi\u0161em 'izberi za posodobitev' in \u010dakam 50 sekund na posodobitev. To je bilo dobro za aplikacijo. Toda v PostgreSQL moram to storiti takoj in ne \u010dakati, ali pa \u010dakati do nekega \u010dasa.<\/em> <\/p>\n

    <\/p>\n

    Da, lahko izberete timeout za va\u0161e zaklepe. Prav tako lahko izdate ukaz no way, ki bo \u2026, \u010de zaklepa ne morete takoj dobiti. Torej, bodisi timeout zaklepanja, bodisi nekaj drugega, kar vam to omogo\u010da. To se ne izvaja na sintakti\u010dni ravni. To je izvedeno kot spremenljivka na stre\u017eniku. V\u010dasih tega ni mogo\u010de uporabiti.<\/p>\n

    <\/p>\n

    Lahko odprete 75. diapozitiv?<\/em> <\/p>\n

    <\/p>\n

    Da.<\/p>\n

    <\/p>\n

    \"Odklepanje<\/p>\n

    <\/p>\n

    In moje vpra\u0161anje je naslednje. Zakaj oba postopka posodobitve \u010dakajo na 703?<\/em><\/p>\n

    <\/p>\n

    In questo caso, \u00e8 un'ottima domanda. Non capisco, tra l'altro, perch\u00e9 Postgres faccia cos\u00ec. Ma quando \u00e8 stato creato il 703, si aspettava il 702. E quando appaiono i 704 e 705, sembra che non sappiano cosa aspettarsi, perch\u00e9 non c'\u00e8 ancora nulla. E Postgres fa cos\u00ec: quando non puoi ottenere un lock, scrive 'Qual \u00e8 il senso di elaborarti?', perch\u00e9 stai gi\u00e0 aspettando qualcun altro. Quindi lo lasciamo semplicemente in sospeso, non lo aggiorna affatto. Ma cosa \u00e8 successo qui? Non appena il 702 ha completato il processo e il 703 ha ottenuto il suo lock, il sistema \u00e8 tornato indietro. E ha detto che ora abbiamo due persone in attesa. E poi aggiorniamoli insieme. E indichiamo che entrambi sono in attesa. <\/p>\n

    <\/p>\n

    Non so perch\u00e9 Postgres faccia cos\u00ec. Ma c'\u00e8 un problema che si chiama f\u2026. Mi sembra che questo non sia un termine in italiano. \u00c8 quando tutti aspettano un lock, anche se ci sono 20 istanze che aspettano il lock. E all'improvviso si svegliano tutti contemporaneamente. E tutti iniziano a cercare di reagire. Ma il sistema fa in modo che tutti aspettino il 703. Perch\u00e9 stanno tutti aspettando, e li mettiamo subito in fila. E se appare qualsiasi altra nuova richiesta, che \u00e8 stata formata dopo, ad esempio, 707, ci sar\u00e0 di nuovo un vuoto. <\/p>\n

    <\/p>\n

    E mi sembra che ci\u00f2 sia fatto affinch\u00e9 si possa dire che a questo punto il 702 sta aspettando il 703, mentre tutti coloro che arriveranno dopo non avranno alcuna registrazione in questo campo. Ma non appena il primo in attesa se ne va, e tutti coloro che stavano aspettando in quel momento prima dell'aggiornamento ricevono lo stesso segnaposto. Ecco perch\u00e9 credo che sia fatto in modo che possiamo elaborare in ordine, affinch\u00e9 siano correttamente ordinati. <\/p>\n

    <\/p>\n

    Ho sempre visto questo come un fenomeno piuttosto strano. Perch\u00e9 qui, ad esempio, non li elenchiamo affatto. Ma mi sembra che ogni volta che diamo un nuovo lock, guardiamo tutti coloro che sono in attesa. Cos\u00ec li mettiamo tutti in fila. E poi chiunque arrivi, entra in coda solo quando la prossima persona ha finito di elaborarsi. Domanda molto interessante. Grazie mille per la domanda!<\/p>\n

    <\/p>\n

    Mi sembra molto pi\u00f9 logico quando il 705 aspetta il 704.<\/em> <\/p>\n

    <\/p>\n

    Toda te\u017eava je naslednja. Tehni\u010dno lahko zbudimo enega ali drugega. In zato bomo zbudili tistega ali drugega. Kaj pa se zgodi v delovanju sistema? Vidite, kako je 703 na vrhu blokiral svoj lasten ID transakcije. Tako deluje Postgres. In 703 se blokira z lastnim ID-jem transakcije, zato, \u010de \u017eeli nekdo \u010dakati, bo \u010dakal na 703. In, v bistvu, 703 zaklju\u010di. \u0160ele po njegovi dokon\u010danju se kateri koli od procesov zbudi. In ne vemo, kateri proces bo to. Potem postopoma vse obdelujemo. Ni pa jasno, kateri proces se najprej zbudi, saj je lahko kateri koli izmed teh procesov. V bistvu smo imeli na\u010drtovalec, ki je rekel, da zdaj lahko zbudimo kateri koli izmed teh procesov. Enostavno izberemo enega naklju\u010dno. Zato oba morata biti ozna\u010dena, ker lahko zbudimo katerega koli od njiju. <\/p>\n

    <\/p>\n

    In te\u017eava je v tem, da imamo CP-neskon\u010dnost. In zato je zelo verjetno, da bomo zbudili kasnej\u0161ega. In \u010de, na primer, zbudimo kasnej\u0161ega, potem bomo pri\u010dakovali tistega, ki je ravno prejel blokado, zato ne dolo\u010damo, kdo bo prvi zbudil. Ustvarjamo preprosto tako situacijo, sistem pa jih bo budil v naklju\u010dnem vrstnem redu. <\/p>\n

    <\/p>\n

    Je \u010dlanki o locks Egora Rogova<\/a><\/noindex>. Poglejte, tudi ti so zanimivi in koristni. Tema je seveda zelo zapletena. Hvala lepa, Bruce!<\/em><\/p>\n

    Izvor: 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\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Unlocking the Postgres Lock Manager. Bruce Momjian | ProHoster","description":"Razlaga poro\u010dila iz leta 2020 Brucea Momjiana \"Odklepanje upravljalnika zaklepov Postgres\".","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/unlocking-the-postgres-lock-manager-bryus-momzhian","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Unlocking the Postgres Lock Manager. \u0411\u0440\u044e\u0441 \u041c\u043e\u043c\u0436\u0438\u0430\u043d | ProHoster","og:description":"\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".","og:url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/unlocking-the-postgres-lock-manager-bryus-momzhian","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-07-11T23:42:48+00:00","article:modified_time":"2020-07-11T23:42:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"87954","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 13:40:34","updated":"2022-09-27 23:56:25","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/87954","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=87954"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/87954\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/87955"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=87954"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=87954"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=87954"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}