Transcript ng 2020 talk ni Bruce Momjian na "Pag-unlock sa Postgres Lock Manager".
(Tandaan: Ang lahat ng SQL query mula sa mga slide ay maaaring makuha mula sa link na ito: )
Kamusta! Napakasaya na narito muli sa Russia. Ikinalulungkot kong hindi ako makakapunta noong nakaraang taon, ngunit sa taong ito ay may malalaking plano kami ni Ivan. Sana mas madalas ako dito. Gustung-gusto kong pumunta sa Russia. Bibisitahin ko ang Tyumen, Tver. Tuwang-tuwa ako na mabibisita ko ang mga lungsod na ito.
Ang pangalan ko ay Bruce Momjian. Nagtatrabaho ako sa EnterpriseDB at nagtatrabaho ako sa Postgres nang mahigit 23 taon. Nakatira ako sa Philadelphia, USA. Naglalakbay ako ng mga 90 araw sa isang taon. At dumalo ako sa mga 40 na kumperensya. Aking , na naglalaman ng mga slide na ipapakita ko ngayon sa iyo. Samakatuwid, pagkatapos ng kumperensya maaari mong i-download ang mga ito mula sa aking personal na website. Naglalaman din ito ng mga 30 presentasyon. Mayroon ding mga video at isang malaking bilang ng mga entry sa blog, higit sa 500. Ito ay isang medyo nagbibigay-kaalaman na mapagkukunan. At kung interesado ka sa materyal na ito, pagkatapos ay inaanyayahan kita na gamitin ito.
Dati akong guro, isang propesor bago ako nagsimulang magtrabaho sa Postgres. At lubos akong natutuwa na masasabi ko na ngayon sa iyo kung ano ang sasabihin ko sa iyo. Ito ay isa sa aking pinaka-kagiliw-giliw na mga presentasyon. At ang pagtatanghal na ito ay naglalaman ng 110 slide. Magsisimula tayong makipag-usap sa mga simpleng bagay, at sa pagtatapos ng ulat ay magiging mas kumplikado, at magiging medyo kumplikado.
Ito ay isang medyo hindi kasiya-siyang pag-uusap. Ang pagharang ay hindi ang pinakasikat na paksa. Nais naming mawala ito sa isang lugar. Parang pagpunta sa dentista.
- Ang pag-lock ay isang problema para sa maraming tao na nagtatrabaho sa mga database at maraming proseso na tumatakbo nang sabay. Kailangan nila ng pagharang. Ibig sabihin, ngayon ay bibigyan kita ng pangunahing kaalaman sa pagharang.
- Mga Transaction ID. Ito ay medyo boring na bahagi ng pagtatanghal, ngunit kailangan nilang maunawaan.
- Susunod na pag-uusapan natin ang tungkol sa mga uri ng pagharang. Ito ay isang medyo mekanikal na bahagi.
- At sa ibaba ay magbibigay kami ng ilang mga halimbawa ng pagharang. At ito ay magiging mahirap na maunawaan.
Pag-usapan natin ang pagharang.
Ang aming terminolohiya ay medyo kumplikado. Ilan sa inyo ang nakakaalam kung saan nagmula ang talatang ito? Dalawang tao. Ito ay mula sa isang laro na tinatawag na Colossal Cave Adventure. Ito ay isang text-based na laro sa computer noong dekada 80, sa tingin ko. Doon kailangan mong pumunta sa isang kuweba, sa isang labirint, at ang teksto ay nagbago, ngunit ang nilalaman ay halos pareho sa bawat oras. Ganyan ko naaalala ang larong ito.
At dito nakita namin ang pangalan ng mga kandado na dumating sa amin mula sa Oracle. Ginagamit namin sila.
Dito nakikita natin ang mga katagang nakakalito sa akin. Halimbawa, SHARE UPDATE ECXLUSIVE. Next SHARE RAW ECXLUSIVE. Sa totoo lang, hindi masyadong malinaw ang mga pangalang ito. Susubukan naming isaalang-alang ang mga ito nang mas detalyado. Ang ilan ay naglalaman ng salitang "share", na nangangahulugang paghihiwalay. Ang ilan ay naglalaman ng salitang "eksklusibo". Ang ilan ay naglalaman ng parehong mga salitang ito. Gusto kong magsimula sa kung paano gumagana ang mga lock na ito.
At ang salitang "access" ay napakahalaga din. At ang mga salitang "row" ay isang string. Iyon ay, pamamahagi ng access, pamamahagi ng hilera.
Ang isa pang isyu na kailangang unawain sa Postgres, na sa kasamaang-palad ay hindi ko masasagot sa aking usapan, ay ang MVCC. Mayroon akong hiwalay na presentasyon sa paksang ito sa aking website. At kung sa tingin mo ay mahirap ang pagtatanghal na ito, ang MVCC ay marahil ang aking pinakamahirap. At kung ikaw ay interesado, maaari mo itong panoorin sa website. Maaari mong panoorin ang video.
Ang isa pang bagay na kailangan nating maunawaan ay ang mga transaction ID. Hindi gagana ang maraming transaksyon nang walang mga natatanging identifier. At dito mayroon tayong paliwanag kung ano ang isang transaksyon. Ang mga postgres ay may dalawang sistema ng pagnunumero ng transaksyon. Alam kong hindi ito isang napakagandang solusyon.
Tandaan din na ang mga slide ay medyo mahirap maunawaan, kaya kung ano ang naka-highlight sa pula ay kung ano ang kailangan mong bigyang pansin.
Tingnan natin. Ang numero ng transaksyon ay naka-highlight sa pula. Ang SELECT pg_back function ay ipinapakita dito. Ibinabalik nito ang aking transaksyon at ang transaction ID.
Isa pang bagay, kung gusto mo ang pagtatanghal na ito at gusto mong patakbuhin ito sa iyong database, maaari kang pumunta sa link na ito na kulay pink at i-download ang SQL para sa presentasyong ito. At maaari mo lamang itong patakbuhin sa iyong PSQL at ang buong presentasyon ay makikita kaagad sa iyong screen. Hindi ito maglalaman ng mga bulaklak, ngunit hindi bababa sa nakikita natin ito.
Sa kasong ito, makikita natin ang transaction ID. Ito ang numerong itinalaga namin sa kanya. At may isa pang uri ng transaction ID sa Postgres, na tinatawag na virtual transaction ID
At dapat nating maunawaan ito. Napakahalaga nito, kung hindi, hindi namin mauunawaan ang pag-lock sa Postgres.
Ang virtual transaction ID ay isang transaction ID na hindi naglalaman ng mga persistent value. Halimbawa, kung magpatakbo ako ng SELECT command, malamang na hindi ko babaguhin ang database, hindi ako magla-lock ng anuman. Kaya kapag nagpatakbo kami ng simpleng SELECT, hindi namin binibigyan ang transaksyong iyon ng persistent ID. Binigyan lang namin siya ng virtual ID doon.
At pinapabuti nito ang pagganap ng Postgres, pinapabuti ang mga kakayahan sa paglilinis, kaya ang virtual transaction ID ay binubuo ng dalawang numero. Ang unang numero bago ang slash ay ang backend ID. At sa kanan ay isang counter lang ang nakikita namin.
Samakatuwid, kung magpatakbo ako ng isang kahilingan, sinasabi nito na ang backend ID ay 2.
At kung magpatakbo ako ng isang serye ng mga naturang transaksyon, makikita natin na tumataas ang counter sa tuwing nagpapatakbo ako ng query. Halimbawa, kapag pinatakbo ko ang query 2/10, 2/11, 2/12, atbp.
Tandaan na mayroong dalawang column dito. Sa kaliwa ay makikita natin ang virtual transaction ID β 2/12. At sa kanan mayroon kaming permanenteng transaction ID. At walang laman ang field na ito. At hindi binabago ng transaksyong ito ang database. Kaya hindi ko ito binibigyan ng permanenteng transaction ID.
Sa sandaling patakbuhin ko ang utos ng pagsusuri ((ANALYZE)), ang parehong query ay nagbibigay sa akin ng isang permanenteng ID ng transaksyon. Tingnan kung paano ito nagbago para sa atin. Wala akong ID na ito noon, ngunit ngayon ay mayroon na ako.
So eto na naman ang request, another transaction. Ang numero ng virtual na transaksyon ay 2/13. At kung humingi ako ng paulit-ulit na transaction ID, kapag pinatakbo ko ang query, makukuha ko ito.
Kaya, isang beses pa. Mayroon kaming virtual transaction ID at persistent transaction ID. Intindihin lang ang puntong ito para maunawaan ang gawi ng Postgres.
Pumunta kami sa ikatlong seksyon. Dito ay lalakad lang tayo sa iba't ibang uri ng mga kandado sa Postgres. Ito ay hindi masyadong kawili-wili. Ang huling seksyon ay magiging mas kawili-wili. Ngunit dapat nating isaalang-alang ang mga pangunahing bagay, dahil kung hindi ay hindi natin mauunawaan ang susunod na mangyayari.
Daan tayo sa seksyong ito, titingnan natin ang bawat uri ng lock. At magpapakita ako sa iyo ng mga halimbawa kung paano naka-install ang mga ito, kung paano gumagana ang mga ito, ipapakita ko sa iyo ang ilang mga query na magagamit mo upang makita kung paano gumagana ang pag-lock sa Postgres.
Upang gumawa ng query at makita kung ano ang nangyayari sa Postgres, kailangan naming ilabas ang query sa view ng system. Sa kasong ito, ang pg_lock ay naka-highlight sa pula. Ang Pg_lock ay isang system table na nagsasabi sa amin kung anong mga lock ang kasalukuyang ginagamit sa Postgres.
Gayunpaman, napakahirap para sa akin na ipakita sa iyo ang pg_lock nang mag-isa dahil ito ay medyo kumplikado. Kaya gumawa ako ng view na nagpapakita ng pg_locks. At gumagawa din ito ng ilang gawain para sa akin na nagbibigay-daan sa akin na mas maunawaan. Ibig sabihin, hindi nito kasama ang aking mga lock, sarili kong session, atbp. Ito ay karaniwang SQL lamang at nagbibigay-daan ito sa iyo na mas maipakita sa iyo kung ano ang nangyayari.
Ang isa pang problema ay ang view na ito ay napakalawak, kaya kailangan kong lumikha ng pangalawang isa - lockview2.
At ito ay nagpapakita sa akin ng higit pang mga column mula sa talahanayan. At isa pa na nagpapakita sa akin ng iba pang column. Ito ay medyo kumplikado, kaya sinubukan kong ipakita ito nang simple hangga't maaari.
Kaya gumawa kami ng table na tinatawag na Lockdemo. At gumawa kami ng isang linya doon. Ito ang aming sample table. At gagawa kami ng mga seksyon para lang magpakita sa iyo ng mga halimbawa ng mga kandado.
Kaya, isang hilera, isang hanay. Ang unang uri ng lock ay tinatawag na ACCESS SHARE. Ito ang pinakamababang paghihigpit sa pagharang. Nangangahulugan ito na halos hindi ito sumasalungat sa iba pang mga kandado.
At kung gusto naming tahasang tukuyin ang isang lock, pinapatakbo namin ang command na "lock table". At halatang haharangin nito, ibig sabihin, sa ACCESS SHARE mode, inilulunsad namin ang lock table. At kung magpapatakbo ako ng PSQL sa background, pagkatapos ay sisimulan ko ang pangalawang sesyon mula sa aking unang sesyon sa ganitong paraan. Ibig sabihin, anong gagawin ko dito? Pumunta ako sa isa pang session at sabihin dito "ipakita sa akin ang lockview para sa kahilingang ito." At narito mayroon akong AccessShareLock sa talahanayang ito. Ito talaga ang hiniling ko. At sinabi niya na ang block ay itinalaga. Napakasimple.
Dagdag pa, kung titingnan natin ang pangalawang hanay, kung gayon ay wala doon. Wala silang laman.
At kung patakbuhin ko ang utos na "PUMILI", ito ang implicit (tahasang) paraan upang humiling ng AccessShareLock. Kaya inilabas ko ang aking talahanayan at pinapatakbo ang query at ang query ay nagbabalik ng maraming mga hilera. At sa isa sa mga linya nakikita natin ang AccessShareLock. Kaya, tinawag ng SELECT ang AccessShareLock sa mesa. At hindi ito sumasalungat sa halos anumang bagay dahil ito ay isang mababang antas na lock.
Paano kung magpatakbo ako ng SELECT at magkaroon ng tatlong magkakaibang talahanayan? Dati isang table lang ang pinapatakbo ko, ngayon tatlo na ang pinapatakbo ko: pg_class, pg_namespace at pg_attribute.
At ngayon kapag tiningnan ko ang query, nakikita ko ang 9 AccessShareLocks sa tatlong talahanayan. Bakit? Tatlong talahanayan ang naka-highlight sa asul: pg_attribute, pg_class, pg_namespace. Ngunit makikita mo rin na ang lahat ng mga index na tinukoy sa pamamagitan ng mga talahanayang ito ay mayroon ding AccessShareLock.
At ito ay isang lock na halos hindi sumasalungat sa iba. At ang ginagawa lang nito ay pinipigilan lang kaming i-reset ang talahanayan habang pinipili namin ito. Ito ay may katuturan. Iyon ay, kung pumili tayo ng isang talahanayan, ito ay nawawala sa sandaling iyon, kung gayon ito ay mali, kaya Ang AccessShare ay isang mababang antas ng lock na nagsasabi sa amin na "huwag ihulog ang talahanayang ito habang nagtatrabaho ako". Essentially, iyon lang ang ginagawa niya.
ROW SHARE - Medyo iba ang lock na ito.
Kumuha tayo ng isang halimbawa. PUMILI NG ROW SHARE na paraan ng pag-lock ng bawat hilera nang paisa-isa. Sa ganitong paraan walang sinuman ang makakapagtanggal sa kanila o makakapagpabago sa kanila habang pinapanood namin sila.
Kaya ano ang ginagawa ng SHARE LOCK? Nakita namin na ang transaction ID ay 681 para sa SELECT. At ito ay kawili-wili. Anong nangyari dito? Ang unang pagkakataon na makita namin ang numero ay nasa field na "I-lock". Kinukuha namin ang transaction ID at sinasabi nitong hinaharangan ito sa exclusive mode. Ang ginagawa lang nito ay sinasabing mayroon akong isang hilera na teknikal na naka-lock sa isang lugar sa mesa. Ngunit hindi niya sinasabi kung saan eksakto. Titingnan natin ito nang mas detalyado sa ibang pagkakataon.
Dito natin sinasabi na ang lock ang ginagamit natin.
Kaya, ang isang eksklusibong lock ay tahasang nagsasabi na ito ay eksklusibo. At kung tatanggalin mo ang isang hilera sa talahanayang ito, ito ang mangyayari, tulad ng nakikita mo.
Ang SHARE EXCLUSIVE ay isang mas mahabang lock.
Ito ang (ANALYZE) analyzer command na gagamitin.
IBAHAGI LOCK - maaari mong tahasang i-lock sa share mode.
Maaari ka ring lumikha ng isang natatanging index. At doon mo makikita ang SHARE LOCK, na bahagi ng mga ito. At ni-lock nito ang mesa at nilagyan ito ng SHARE LOCK.
Bilang default, ang IBAHAGI LOCK sa isang talahanayan ay nangangahulugan na ang ibang mga tao ay maaaring basahin ang talahanayan, ngunit walang sinuman ang maaaring baguhin ito. At ito mismo ang nangyayari kapag lumikha ka ng isang natatanging index.
Kung gagawa ako ng kakaibang sabay-sabay na index, magkakaroon ako ng ibang uri ng pag-lock dahil, tulad ng naaalala mo, ang paggamit ng sabay-sabay na mga index ay binabawasan ang kinakailangan sa pag-lock. At kung gumamit ako ng isang normal na lock, isang normal na index, sa gayon ay mapipigilan ko ang pagsusulat sa index ng talahanayan habang ito ay nililikha. Kung gagamit ako ng sabay na index, kailangan kong gumamit ng ibang uri ng pag-lock.
SHARE ROW EXCLUSIVE β muli ito ay maaaring itakda nang tahasan (hayagan).
O maaari tayong gumawa ng panuntunan, ibig sabihin, kumuha ng partikular na kaso kung saan ito gagamitin.
Ang EKSKLUSIBONG pag-lock ay nangangahulugan na walang ibang makakapagpalit ng talahanayan.
Dito makikita natin ang iba't ibang uri ng mga kandado.
Ang ACCESS EXCLUSIVE, halimbawa, ay isang blocking command. Halimbawa, kung gagawin mo CLUSTER table, kung gayon ito ay nangangahulugan na walang makakasulat doon. At nakakandado ito hindi lamang sa talahanayan mismo, kundi pati na rin sa mga index.
Ito ang pangalawang pahina ng ACCESS EXCLUSIVE blocking, kung saan makikita natin kung ano mismo ang hinaharangan nito sa talahanayan. Nila-lock nito ang mga indibidwal na hanay ng talahanayan, na medyo kawili-wili.
Iyon lang ang pangunahing impormasyon na gusto kong ibigay. Napag-usapan namin ang tungkol sa mga lock, tungkol sa mga transaction ID, napag-usapan namin ang tungkol sa mga virtual transaction ID, tungkol sa mga permanenteng transaction ID.
At ngayon ay dadaan tayo sa ilang mga halimbawa ng pagharang. Ito ang pinakakawili-wiling bahagi. Titingnan natin ang mga napaka-kagiliw-giliw na mga kaso. At ang layunin ko sa pagtatanghal na ito ay bigyan ka ng mas mahusay na pag-unawa sa kung ano talaga ang ginagawa ng Postgres kapag sinusubukan nitong harangan ang ilang mga bagay. Sa tingin ko, napakahusay niyang humarang ng mga bahagi.
Tingnan natin ang ilang partikular na halimbawa.
Magsisimula tayo sa mga talahanayan at isang hilera sa isang mesa. Kapag nagpasok ako ng isang bagay, mayroon akong ExclusiveLock, Transaction ID at ExclusiveLock na ipinapakita sa mesa.
Ano ang mangyayari kung magpasok ako ng dalawa pang row? At ngayon may tatlong row ang table namin. At nagpasok ako ng isang hilera at nakuha ko ito bilang isang output. At kung magpasok ako ng dalawa pang row, ano ang kakaiba doon? May kakaiba dito dahil nagdagdag ako ng tatlong row sa table na ito, pero meron pa akong dalawang row sa lock table. At ito ay mahalagang ang pangunahing pag-uugali ng Postgres.
Maraming tao ang nag-iisip na kung sa isang database ay nagla-lock ka ng 100 row, kakailanganin mong lumikha ng 100 lock entries. Kung haharangin ko ang 1 row nang sabay-sabay, kakailanganin ko ng 000 ganoong query. At kung kailangan ko ng isang milyon o isang bilyon para harangin. Ngunit kung gagawin natin ito, hindi ito gagana nang maayos. Kung gumamit ka ng system na lumilikha ng mga blocking entries para sa bawat indibidwal na row, makikita mo na ito ay kumplikado. Dahil kailangan mong agad na tukuyin ang isang lock table na maaaring umapaw, ngunit hindi iyon ginagawa ng Postgres.
At ang talagang mahalaga sa slide na ito ay malinaw na ipinapakita nito na may isa pang sistema na tumatakbo sa loob ng MVCC na nagla-lock ng mga indibidwal na row. Kaya kapag nag-lock ka ng bilyun-bilyong row, hindi gumagawa ang Postgres ng isang bilyong hiwalay na locking command. At ito ay may napakagandang epekto sa pagiging produktibo.
Paano ang tungkol sa isang update? Ina-update ko ang row ngayon, at makikita mo na nagsagawa ito ng dalawang magkaibang operasyon nang sabay-sabay. Sabay lock nito sa table, pero nilock din nito ang index. At kailangan niyang i-lock ang index dahil may mga natatanging hadlang sa talahanayang ito. At gusto naming tiyakin na walang magbabago nito, kaya hinarangan namin ito.
Ano ang mangyayari kung gusto kong mag-update ng dalawang row? At nakikita natin na ganoon din ang ugali niya. Gumagawa kami ng doble sa dami ng mga update, ngunit eksaktong parehong bilang ng mga linya ng lock.
Kung nagtataka ka kung paano ito ginagawa ng Postgres, kakailanganin mong makinig sa aking mga pag-uusap sa MVCC upang malaman kung paano panloob na minarkahan ng Postgres ang mga linyang ito na nagbabago. At may paraan ang Postgres kung saan ito ginagawa, ngunit hindi nito ginagawa sa antas ng pag-lock ng mesa, ginagawa ito sa mas mababa at mas mahusay na antas.
Paano kung may gusto akong tanggalin? Kung tatanggalin ko, halimbawa, isang hilera at mayroon pa akong dalawang blocking input, at kahit na gusto kong tanggalin ang lahat, nandiyan pa rin sila.
At, halimbawa, gusto kong magpasok ng 1 na linya, at pagkatapos ay tanggalin o magdagdag ng 000 na mga linya, pagkatapos iyong mga indibidwal na linya na idinagdag o binago ko, hindi ito naitala dito. Ang mga ito ay nakasulat sa isang mas mababang antas sa loob ng serye mismo. At sa panahon ng talumpati ng MVCC ay napag-usapan ko ito nang detalyado. Ngunit napakahalaga kapag sinusuri mo ang mga kandado upang matiyak na nagla-lock ka sa antas ng talahanayan at hindi mo nakikita kung paano nire-record ang mga indibidwal na row dito.
Paano naman ang tahasang pagharang?
Kung iki-click ko ang pag-refresh, mayroon akong dalawang row na naka-lock. At kung pipiliin ko silang lahat at i-click ang "i-update kahit saan," mayroon pa rin akong dalawang talaan ng pagharang.
Hindi kami gumagawa ng hiwalay na mga tala para sa bawat indibidwal na hilera. Dahil pagkatapos ay bumaba ang pagiging produktibo, maaaring masyadong marami ito. At maaari nating matagpuan ang ating sarili sa isang hindi kasiya-siyang sitwasyon.
At ang parehong bagay, kung ibinahagi natin, magagawa natin itong lahat ng 30 beses.
Ibinabalik namin ang aming talahanayan, tanggalin ang lahat, pagkatapos ay muling magpasok ng isang hilera.
Ang isa pang pag-uugali na nakikita mo sa Postgres na kilalang-kilala at ninanais na pag-uugali ay ang maaari mong gawin ang isang pag-update o isang pili. At magagawa mo ito nang sabay-sabay. At piliin ay hindi harangan ang pag-update at ang parehong bagay sa kabaligtaran direksyon. Sinasabi namin sa mambabasa na huwag harangan ang manunulat, at hindi hinarangan ng manunulat ang mambabasa.
Ipapakita ko sa iyo ang isang halimbawa nito. pipili ako ngayon. Pagkatapos ay gagawin namin ang INSERT. At pagkatapos ay makikita mo - 694. Makikita mo ang ID ng transaksyon na nagsagawa ng pagpapasok na ito. At iyon ang paraan.
At kung titingnan ko ang aking backend ID ngayon, ito ay 695 na.
At nakikita kong 695 ang lumalabas sa table ko.
At kung mag-update ako dito ng ganito, ibang kaso ang makukuha ko. Sa kasong ito, ang 695 ay isang eksklusibong lock, at ang pag-update ay may parehong pag-uugali, ngunit walang salungatan sa pagitan nila, na medyo hindi pangkaraniwan.
At makikita mo na sa itaas ito ay ShareLock, at sa ibaba ay ExclusiveLock. At ang parehong mga transaksyon ay nagtrabaho.
At kailangan mong makinig sa aking talumpati sa MVCC upang maunawaan kung paano ito nangyayari. Ngunit ito ay isang ilustrasyon na maaari mong gawin ito nang sabay, ibig sabihin, gawin ang isang SELECT at isang UPDATE sa parehong oras.
I-reset natin at gumawa ng isa pang operasyon.
Kung susubukan mong magpatakbo ng dalawang update nang sabay-sabay sa parehong hilera, ito ay mai-block. At tandaan, sinabi ko na hindi hinaharang ng mambabasa ang manunulat, at hindi hinaharang ng manunulat ang mambabasa, ngunit hinaharangan ng isang manunulat ang isa pang manunulat. Ibig sabihin, hindi tayo maaaring mag-update ng dalawang tao sa parehong row nang sabay. Kailangan mong maghintay hanggang matapos ang isa sa kanila.
At upang mailarawan ito, titingnan ko ang talahanayan ng Lockdemo. At titingnan natin ang isang hilera. Bawat transaksyon 698.
Na-update namin ito sa 2. 699 ang unang update. At ito ay matagumpay o ito ay nasa isang nakabinbing transaksyon at naghihintay para sa amin upang kumpirmahin o kanselahin.
Ngunit tingnan ang iba pa - 2/51 ang aming unang transaksyon, ang aming unang session. Ang 3/112 ay ang pangalawang kahilingan na nagmula sa itaas na binago ang halagang iyon sa 3. At kung mapapansin mo, ang nasa itaas ay nag-lock mismo, na 699. Ngunit ang 3/112 ay hindi nagbigay ng lock. Sinasabi ng column na Lock_mode kung ano ang hinihintay nito. Inaasahan nito ang 699. At kung titingnan mo kung nasaan ang 699, ito ay mas mataas. At ano ang ginawa ng unang sesyon? Gumawa siya ng eksklusibong lock sa sarili niyang transaction ID. Ito ay kung paano ito ginagawa ng Postgres. Hinaharang nito ang sarili nitong transaction ID. At kung gusto mong maghintay na may magkumpirma o magkansela, kailangan mong maghintay habang may nakabinbing transaksyon. At kaya naman may nakikita tayong kakaibang linya.
Tingnan natin muli. Sa kaliwa ay makikita namin ang aming processing ID. Sa pangalawang column makikita namin ang aming virtual transaction ID, at sa pangatlo makikita namin ang lock_type. Ano ang ibig sabihin nito? Talagang kung ano ang sinasabi nito ay hinaharangan nito ang transaction ID. Ngunit pansinin na ang lahat ng mga hilera sa ibaba ay nagsasabi ng kaugnayan. At kaya mayroon kang dalawang uri ng mga kandado sa mesa. May lock ng relasyon. At pagkatapos ay nariyan ang transactionid blocking, kung saan nag-block ka nang mag-isa, na kung ano mismo ang nangyayari sa unang hilera o sa pinakaibaba, kung saan ang transactionid ay, kung saan naghihintay kami para sa 699 upang matapos ang operasyon nito.
Tingnan ko kung ano ang mangyayari dito. At narito ang dalawang bagay na nangyayari nang sabay-sabay. Tinitingnan mo ang isang transaction ID lock sa unang row na nagla-lock mismo. At hinaharangan niya ang sarili niya para maghintay ang mga tao.
Kung titingnan mo ang ika-6 na linya, ito ay kapareho ng entry sa una. At samakatuwid ang transaksyon 699 ay naharang. Self-locking din ang 700. At pagkatapos ay sa ibabang hilera makikita mo na hinihintay namin ang 699 upang matapos ang operasyon nito.
At sa lock_type, tuple makikita mo ang mga numero.
Makikita mong 0/10 ito. At ito ang numero ng pahina, at pati na rin ang offset ng partikular na row na ito.
At nakikita mong nagiging 0/11 ito kapag nag-update kami.
Ngunit sa katotohanan ito ay 0/10, dahil may paghihintay para sa operasyong ito. May pagkakataon tayong makita na ito ang seryeng hinihintay kong kumpirmahin.
Kapag nakumpirma na namin ito at pinindot ang commit, at kapag natapos na ang pag-update, ito ang muli naming makukuha. Ang Transaction 700 ay ang tanging lock, hindi ito naghihintay ng iba dahil ito ay ginawa. Naghihintay lamang ito para makumpleto ang transaksyon. Kapag naubos na ang 699, wala na tayong hinihintay. At ngayon ang transaksyon 700 ay nagsasabi na ang lahat ay maayos, na mayroon itong lahat ng mga kandado na kailangan nito sa lahat ng pinapayagang mga talahanayan.
At para gawing mas kumplikado ang buong bagay na ito, lumikha kami ng isa pang view, na sa pagkakataong ito ay magbibigay sa amin ng isang hierarchy. Hindi ko inaasahan na mauunawaan mo ang kahilingang ito. Ngunit ito ay magbibigay sa amin ng isang mas malinaw na pananaw sa kung ano ang nangyayari.
Ito ay isang recursive view na mayroon ding isa pang seksyon. At pagkatapos ay pinagsasama-sama muli ang lahat. Gamitin natin ito.
Paano kung gumawa tayo ng tatlong sabay-sabay na pag-update at sabihin na ang hilera ay tatlo na ngayon. At papalitan natin ang 3 sa 4.
At dito makikita natin ang 4. At transaction ID 702.
At pagkatapos ay papalitan ko ang 4 sa 5. At 5 sa 6, at 6 sa 7. At ipapapila ko ang ilang tao na maghihintay na matapos ang isang transaksyong ito.
At nagiging malinaw ang lahat. Ano ang unang hilera? Ito ay 702. Ito ang transaction ID na orihinal na nagtakda ng halagang ito. Ano ang nakasulat sa aking Granted column? May marka ako f. Ito ang mga update ko na (5, 6, 7) ay hindi maa-approve dahil hinihintay namin na matapos ang transaction ID 702. Doon ay mayroon kaming transaction ID blocking. At nagreresulta ito sa 5 transactional ID lock.
At kung titingnan mo ang 704, sa 705, wala pang nakasulat doon, dahil hindi pa nila alam kung ano ang nangyayari. Sumulat lang sila na wala silang ideya kung ano ang nangyayari. At matutulog na lang sila dahil may hinihintay silang matapos at gigisingin kapag may pagkakataong magpalit ng row.
Ito ang hitsura nito. Malinaw na naghihintay silang lahat sa ika-12 na linya.
Ito ang nakita namin dito. Narito ang 0/12.
Kaya kapag naaprubahan ang unang transaksyon, makikita mo dito kung paano gumagana ang hierarchy. At ngayon ang lahat ay nagiging malinaw. Lahat sila ay nagiging malinis. At talagang naghihintay pa rin sila.
Narito kung ano ang nangyayari. 702 commits. At ngayon, nakukuha ng 703 ang row lock na ito, at pagkatapos ay magsisimula ang 704 na maghintay para sa 703 na mag-commit. At hinihintay din ito ng 705. At kapag natapos na ang lahat ng ito, nililinis nila ang kanilang mga sarili. At nais kong ituro na ang lahat ay nakapila. At ito ay halos kapareho sa isang sitwasyon sa isang masikip na trapiko kapag ang lahat ay naghihintay para sa unang kotse. Huminto ang unang sasakyan at pumila ang lahat sa mahabang pila. Pagkatapos ay gumagalaw ito, pagkatapos ay ang susunod na kotse ay maaaring magmaneho pasulong at makuha ang bloke nito, atbp.
At kung ito ay tila hindi sapat na kumplikado sa iyo, pagkatapos ay makikipag-usap kami sa iyo ngayon tungkol sa mga deadlock. Hindi ko alam kung sino sa inyo ang nakatagpo sa kanila. Ito ay isang medyo karaniwang problema sa mga sistema ng database. Ngunit ang mga deadlock ay kapag ang isang session ay naghihintay para sa isa pang session upang gawin ang isang bagay. At sa sandaling ito isa pang sesyon ang naghihintay para sa unang sesyon na gumawa ng isang bagay.
At, halimbawa, kung sinabi ni Ivan: "Bigyan mo ako ng isang bagay," at sasabihin ko: "Hindi, ibibigay ko lang ito sa iyo kung bibigyan mo ako ng iba." At sinabi niya, "Hindi, hindi ko ito ibibigay sa iyo kung hindi mo ito ibibigay sa akin." At napupunta kami sa isang deadlock na sitwasyon. Sigurado ako na hindi ito gagawin ni Ivan, ngunit naiintindihan mo ang kahulugan na mayroon tayong dalawang tao na gustong makakuha ng isang bagay at hindi sila handang ibigay ito hangga't hindi naibibigay ng isa ang gusto nila. At walang solusyon.
At mahalagang, ang iyong database ay kailangang makita ito. At pagkatapos ay kailangan mong tanggalin o isara ang isa sa mga session, dahil kung hindi man ay mananatili sila doon magpakailanman. At nakikita natin ito sa mga database, nakikita natin ito sa mga operating system. At sa lahat ng lugar kung saan mayroon tayong parallel na proseso, ito ay maaaring mangyari.
At ngayon ay mag-i-install kami ng dalawang deadlock. Ilalagay namin ang 50 at 80. Sa unang hilera, mag-a-update ako mula 50 hanggang 50. Kukunin ko ang numero ng transaksyon na 710.
At pagkatapos ay babaguhin ko ang 80 sa 81, at 50 sa 51.
At ito ang magiging hitsura nito. At kaya ang 710 ay may nakaharang na hilera, at ang 711 ay naghihintay ng kumpirmasyon. Nakita namin ito noong nag-update kami. Ang 710 ang may-ari ng aming serye. At ang 711 ay naghihintay para sa 710 upang makumpleto ang transaksyon.
At sinasabi pa nito kung saang hilera nangyayari ang mga deadlock. At dito na nagsisimulang maging kakaiba.
Ngayon ay nag-a-update kami ng 80 hanggang 80.
At dito nagsisimula ang mga deadlock. Ang 710 ay naghihintay ng tugon mula sa 711, at ang 711 ay naghihintay para sa 710. At hindi ito magtatapos nang maayos. At walang paraan sa labas nito. At aasahan nila ang tugon mula sa isa't isa.
At magsisimula lang itong maantala ang lahat. At hindi namin gusto iyon.
At may mga paraan ang Postgres para mapansin kapag nangyari ito. At kapag nangyari ito, makukuha mo ang error na ito. At mula dito ay malinaw na ang ganito at ganoong proseso ay naghihintay ng SHARE LOCK mula sa isa pang proseso, ibig sabihin, na hinarangan ng proseso ng 711. At ang prosesong iyon ay naghihintay para sa isang SHARE LOCK na maibigay sa ganito at ganoong transaction ID at na-block ng ganito at ganoong proseso. Samakatuwid, mayroong isang deadlock na sitwasyon dito.
Mayroon bang three-way deadlocks? pwede ba? Oo.
Inilalagay namin ang mga numerong ito sa isang talahanayan. Binabago namin ang 40 hanggang 40, ginagawa namin ang pagharang.
Binago namin ang 60 sa 61, 80 sa 81.
At pagkatapos ay baguhin namin ang 80 at pagkatapos ay boom!
At ang 714 ay naghihintay na ngayon para sa 715. Ang ika-716 ay naghihintay para sa ika-715. At walang magagawa tungkol dito.
Wala nang dalawang tao dito, tatlo na ang tao dito. May gusto ako sa iyo, ang isang ito ay may gusto sa isang pangatlong tao, at ang pangatlong tao ay may gusto mula sa akin. And we end up in a three-way wait because we're all waiting for the other person to complete what they need to do.
At alam ng Postgres kung saang row ito nangyayari. At kaya bibigyan ka nito ng sumusunod na mensahe, na nagpapakita na mayroon kang problema kung saan ang tatlong input ay humaharang sa isa't isa. At walang mga paghihigpit dito. Maaaring ito ang kaso kung saan hinaharangan ng 20 entry ang isa't isa.
Ang susunod na problema ay serializable.
Kung espesyal na serializable lock.
At bumalik kami sa 719. Ang output nito ay medyo normal.
At maaari mong i-click upang gawing serializable ang transaksyon.
At napagtanto mo na mayroon ka na ngayong ibang uri ng SA lock - nangangahulugan itong serializable.
At kaya mayroon kaming bagong uri ng lock na tinatawag na SARieadLock, na isang serial lock at nagbibigay-daan sa iyong magpasok ng mga serial.
At maaari ka ring magpasok ng mga natatanging index.
Sa talahanayang ito mayroon kaming mga natatanging index.
Kaya kung inilagay ko ang numero 2 dito, kaya mayroon akong 2. Ngunit sa pinakatuktok, naglagay ako ng isa pang 2. At makikita mo na ang 721 ay may eksklusibong lock. Ngunit ngayon ang 722 ay naghihintay para sa 721 upang makumpleto ang operasyon nito dahil hindi nito maipasok ang 2 hangga't hindi nito nalalaman kung ano ang mangyayari sa 721.
At kung mag-subtransaction tayo.
Narito mayroon kaming 723.
At kung i-save namin ang punto at pagkatapos ay i-update ito, makakakuha kami ng bagong transaction ID. Ito ay isa pang pattern ng pag-uugali na kailangan mong malaman. Kung ibabalik namin ito, mawawala ang transaction ID. Aalis na ang 724. Ngunit ngayon mayroon kaming 725.
Kaya ano ang sinusubukan kong gawin dito? Sinusubukan kong magpakita sa iyo ng mga halimbawa ng hindi pangkaraniwang mga lock na maaari mong makita: ito man ay mga serializable na lock o SAVEPOINT, ito ay iba't ibang uri ng mga lock na lalabas sa lock table.
Ito ang paglikha ng tahasang (hayagang) mga lock, na mayroong pg_advisory_lock.
At makikita mo na ang uri ng pagharang ay nakalista bilang advisory. At dito nakasulat ang "advisory" sa pula. At maaari mong sabay na i-block ang tulad nito sa pg_advisory_unlock.
At sa konklusyon, nais kong ipakita sa iyo ang isa pang bagay na nakakagulat. Gagawa ako ng isa pang view. Ngunit sasali ako sa pg_locks table kasama ng pg_stat_activity table. At bakit ko gustong gawin ito? Dahil ito ay magpapahintulot sa akin na tingnan at makita ang lahat ng kasalukuyang session at makita kung anong uri ng mga kandado ang hinihintay nila. At ito ay medyo kawili-wili kapag pinagsama namin ang lock table at ang query table.
At dito lumikha kami ng pg_stat_view.
At isa-isa naming ina-update ang row. At dito nakikita natin ang 724. At pagkatapos ay ina-update natin ang ating row sa tatlo. At ano ang nakikita mo dito ngayon? Ito ay mga kahilingan, ibig sabihin, makikita mo ang buong listahan ng mga kahilingan na nakalista sa kaliwang column. At pagkatapos ay sa kanang bahagi makikita mo ang mga blockage at kung ano ang kanilang nilikha. At maaari itong maging mas malinaw para sa iyo upang hindi mo na kailangang bumalik sa bawat session sa bawat oras at tingnan kung kailangan mong sumali dito o hindi. Ginagawa nila ito para sa atin.
Ang isa pang tampok na lubhang kapaki-pakinabang ay pg_blocking_pids. Malamang hindi mo pa siya narinig. Ano ang ginagawa niya? Nagbibigay-daan ito sa amin na sabihin na para sa session na ito 11740 kung anong mga partikular na prosesong ID ang hinihintay nito. At makikita mo na ang 11740 ay naghihintay para sa 724. At ang 724 ay nasa pinakatuktok. At 11306 ang iyong process ID. Sa pangkalahatan, ang function na ito ay dumadaan sa iyong lock table. At alam kong medyo kumplikado ito, ngunit naiintindihan mo ito. Sa pangkalahatan, ang function na ito ay dumadaan sa lock table na ito at sinusubukang hanapin kung saan ang process ID na ito ay binibigyan ng mga lock na hinihintay nito. At sinusubukan din nitong malaman kung aling proseso ang ID ng proseso na naghihintay para sa lock. Kaya maaari mong patakbuhin ang function na ito pg_blocking_pids.
At ito ay maaaring maging lubhang kapaki-pakinabang. Idinagdag lang namin ito sa bersyon 9.6, kaya ang feature na ito ay 5 taong gulang lamang, ngunit ito ay napaka-kapaki-pakinabang. At ang parehong naaangkop sa pangalawang kahilingan. Ipinapakita nito kung ano mismo ang kailangan nating makita.
Ito ang gusto kong pag-usapan sa iyo. And as I expected, naubos lahat ng oras namin kasi ang daming slides. At ang mga slide ay magagamit para sa pag-download. Gusto kong magpasalamat sa iyong pagpunta dito. Sigurado akong magugustuhan mo ang natitirang kumperensya, maraming salamat!
Tanong:
Halimbawa, kung sinusubukan kong i-update ang mga row, at sinusubukan ng pangalawang session na tanggalin ang buong talahanayan. Sa pagkakaintindi ko, dapat may parang intent lock. Mayroon bang ganyan sa Postgres?
Bumalik tayo sa pinakasimula. Maaari mong tandaan na kapag gumawa ka ng anuman, halimbawa kapag gumawa ka ng SELECT, nag-isyu kami ng AccessShareLock. At pinipigilan nito ang pagbagsak ng talahanayan. Kaya't kung ikaw, halimbawa, ay gustong mag-update ng isang row sa isang table o magtanggal ng isang row, kung gayon ang isang tao ay hindi makakapagtanggal ng buong table nang sabay-sabay dahil hawak mo itong AccessShareLock sa buong table at sa ibabaw ng row. At kapag tapos ka na, maaari nilang tanggalin ito. Ngunit habang direktang binago mo ang isang bagay doon, hindi nila ito magagawa.
Ulitin natin. Lumipat tayo sa halimbawa ng tanggalin. At nakikita mo kung paano mayroong eksklusibong lock sa row sa itaas ng buong table.
Magmumukha itong lock exclusive, di ba?
Oo, parang ganun. Naiintindihan ko ang sinasabi mo. Sinasabi mo na kung gagawa ako ng SELECT then I have a ShareExclusive and then I make it Row Exclusive, nagiging problema ba iyon? Ngunit nakakagulat na hindi ito nagdudulot ng problema. Ito ay mukhang pagtaas ng lock degree, ngunit mahalagang mayroon akong lock na pumipigil sa pagtanggal. At ngayon, kapag ginawa kong mas malakas ang lock na ito, pinipigilan pa rin nito ang pagtanggal. Kaya hindi ako aakyat. Ibig sabihin, pinipigilan itong mangyari noong nasa mababang antas din ito, kaya kapag tinaasan ko ang antas nito ay pinipigilan pa rin nitong matanggal ang talahanayan.
Naiintindihan ko ang sinasabi mo. Walang lock escalation case dito, kung saan sinusubukan mong isuko ang isang lock para magpakilala ng mas malakas. Dito, pinapataas lang nito ang pag-iwas sa kabuuan, kaya hindi ito nagdudulot ng anumang salungatan. Ngunit ito ay isang magandang tanong. Maraming salamat sa pagtatanong nito!
Ano ang kailangan nating gawin upang maiwasan ang isang deadlock na sitwasyon kapag marami tayong session, isang malaking bilang ng mga user?
Awtomatikong napapansin ng mga postgres ang mga deadlock na sitwasyon. At awtomatiko nitong tatanggalin ang isa sa mga session. Ang tanging paraan upang maiwasan ang patay na pagharang ay upang harangan ang mga tao sa parehong pagkakasunud-sunod. Kaya kapag tiningnan mo ang iyong aplikasyon, kadalasan ang dahilan ng mga deadlocks... Isipin natin na gusto kong harangan ang dalawang magkaibang bagay. Nila-lock ng isang application ang talahanayan 1, at ang isa pang application ay nagla-lock ng 2, at pagkatapos ay ang talahanayan 1. At ang pinakamadaling paraan upang maiwasan ang mga deadlock ay tingnan ang iyong aplikasyon at subukang tiyakin na nangyayari ang pag-lock sa parehong pagkakasunud-sunod sa lahat ng mga application. At ito ay karaniwang nag-aalis ng 80% ng mga problema, dahil ang lahat ng uri ng mga tao ay sumulat ng mga application na ito. At kung i-block mo sila sa parehong pagkakasunud-sunod, hindi ka makakatagpo ng isang deadlock na sitwasyon.
Maraming salamat sa iyong pagganap! Napag-usapan mo ang tungkol sa puno ng vacuum at, kung naiintindihan ko nang tama, binabaluktot ng puno ng vacuum ang pagkakasunud-sunod ng mga tala sa magkahiwalay na imbakan, kaya pinapanatili nilang hindi nagbabago ang mga kasalukuyang tala. Bakit ang vacuum full ay tumatagal ng eksklusibong pag-access sa lock at bakit ito sumasalungat sa mga pagpapatakbo ng pagsulat?
Iyan ay isang magandang katanungan. Ang dahilan ay ang vacuum full ang kumukuha ng mesa. At talagang gumagawa kami ng bagong bersyon ng talahanayan. At magiging bago ang mesa. Ito ay lumalabas na ito ay magiging isang ganap na bagong bersyon ng talahanayan. At ang problema ay kapag ginawa natin ito, ayaw nating basahin ito ng mga tao dahil kailangan nating makita nila ang bagong talahanayan. At kaya ito ay kumokonekta sa nakaraang tanong. Kung makakapagbasa tayo ng sabay, hindi natin ito magagalaw at maidirekta ang mga tao sa isang bagong mesa. Kakailanganin nating hintayin na matapos ang lahat sa pagbabasa ng talahanayang ito, at sa gayon ito ay mahalagang eksklusibong lock na sitwasyon.
Sinasabi lang namin na nag-lock kami mula sa simula dahil alam namin na sa pinakadulo kakailanganin namin ng isang eksklusibong kandado upang ilipat ang lahat sa bagong kopya. Kaya't maaari nating malutas ito. At ginagawa namin ito sa ganitong paraan sa sabay-sabay na pag-index. Ngunit ito ay mas mahirap gawin. At ito ay lubos na nauugnay sa iyong nakaraang tanong tungkol sa eksklusibong lock.
Posible bang magdagdag ng pag-lock ng timeout sa Postgres? Sa Oracle, maaari kong, halimbawa, isulat ang "select to update" at maghintay ng 50 segundo bago mag-update. Ito ay mabuti para sa aplikasyon. Ngunit sa Postgres, kailangan kong gawin ito kaagad at hindi na maghintay, o maghintay ng ilang oras.
Oo, maaari kang pumili ng timeout sa iyong mga lock, sa iyong mga lock. Maaari ka ring mag-isyu ng no way command, na... kung hindi mo agad makuha ang lock. Samakatuwid, alinman sa isang lock timeout o iba pang bagay na magbibigay-daan sa iyong gawin ito. Hindi ito ginagawa sa antas ng syntactic. Ginagawa ito bilang isang variable sa server. Minsan hindi ito magagamit.
Maaari mo bang buksan ang slide 75?
Oo.
At ang tanong ko ay ang mga sumusunod. Bakit ang parehong mga proseso ng pag-update ay umaasa sa 703?
At ito ay isang mahusay na tanong. Hindi ko maintindihan, sa pamamagitan ng paraan, kung bakit ginagawa ito ng Postgres. Pero noong ginawa ang 703, inaasahan ang 702. At kapag lumabas ang 704 at 705, parang hindi nila alam kung ano ang inaasahan nila dahil wala pa. At ginagawa ito ng Postgres sa ganitong paraan: kapag hindi ka makakakuha ng lock, isinusulat nito ang "Ano ang punto sa pagproseso sa iyo?", dahil naghihintay ka na ng isang tao. Kaya hahayaan na lang natin itong sumabit sa ere, hindi na ito mag-a-update. Pero anong nangyari dito? Sa sandaling makumpleto ng 702 ang proseso at natanggap ng 703 ang lock nito, bumalik ang system. And she said na meron daw kaming dalawang tao na naghihintay. At pagkatapos ay sabay-sabay nating i-update ang mga ito. At ipahiwatig natin na pareho silang umaasa.
Hindi ko alam kung bakit ginagawa ito ng Postgres. Ngunit mayroong isang problema na tinatawag na fβ¦. Tila sa akin na ito ay hindi isang termino sa Russian. Ito ay kapag ang lahat ay naghihintay para sa isang kastilyo, kahit na mayroong 20 awtoridad na naghihintay para sa kastilyo. At bigla silang nagising ng sabay. At ang lahat ay nagsimulang mag-react. But the system makes it so that everyone is waiting for 703. Kasi lahat sila naghihintay, and we will immediately line them all up. At kung may lalabas na ibang bagong kahilingan na nabuo pagkatapos nito, halimbawa, 707, magkakaroon muli ng kawalan.
At sa palagay ko ito ay ginawa upang masabi natin na sa yugtong ito ay naghihintay ang 702 para sa 703, at ang lahat ng mga susunod na pagkatapos nito ay walang anumang entry sa larangang ito. Ngunit sa sandaling umalis ang unang waiter, lahat ng naghihintay sa sandaling iyon bago ang update ay makakatanggap ng parehong token. And so I think this is done para ma-process natin in order so that they are proper ordered.
Palagi kong tinitingnan ito bilang isang kakaibang kababalaghan. Dahil dito, halimbawa, hindi namin sila inilista sa lahat. Ngunit tila sa akin na sa tuwing magbibigay tayo ng bagong kandado, tinitingnan natin ang lahat ng nasa proseso ng paghihintay. Tapos pinapila namin silang lahat. At pagkatapos ang anumang bagong papasok ay mapupunta lamang sa pila kapag ang susunod na tao ay natapos nang maproseso. Napakagandang tanong. Maraming salamat sa iyong katanungan!
Tila sa akin ay mas lohikal kapag inaasahan ng 705 ang 704.
Ngunit ang problema dito ay ang mga sumusunod. Sa teknikal, maaari mong gisingin ang isa o ang isa pa. At sa gayon kami ay magigising sa isa o sa iba pa. Ngunit ano ang nangyayari sa sistema? Makikita mo kung paano hinarangan ng 703 sa pinakatuktok ang sarili niyang transaction ID. Ito ay kung paano gumagana ang Postgres. At ang 703 ay hinarangan ng sarili nitong transaction ID, kaya kung may gustong maghintay, maghihintay sila sa 703. At, sa esensya, 703 ang nakumpleto. At pagkatapos lamang makumpleto ang isa sa mga proseso ay gumising. At hindi namin alam kung ano ang eksaktong magiging prosesong ito. Pagkatapos ay unti-unti naming pinoproseso ang lahat. Ngunit hindi malinaw kung aling proseso ang unang nagising, dahil maaaring alinman sa mga prosesong ito. Sa totoo lang, mayroon kaming scheduler na nagsabing maaari na naming gisingin ang alinman sa mga prosesong ito. Pumili lang kami ng isa nang random. Kaya pareho silang kailangang pansinin dahil maaari nating gisingin ang alinman sa kanila.
At ang problema ay mayroon tayong CP-infinity. At samakatuwid, malamang na magising tayo sa susunod. At kung, halimbawa, gigisingin natin ang huli, hihintayin natin ang kakatanggap lang ng block, kaya hindi natin matukoy kung sino talaga ang unang gigising. Lumilikha lang kami ng ganoong sitwasyon, at gisingin sila ng system sa isang random na pagkakasunud-sunod.
Mayroon . Tingnan, ang mga ito ay kawili-wili at kapaki-pakinabang din. Ang paksa, siyempre, ay lubhang kumplikado. Maraming salamat, Bruce!
Pinagmulan: www.habr.com