http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex><\/p>\n<\/p>\n
Vaadake. Punase v\u00e4rviga on esile t\u00f5stetud tehingu number. Siin on n\u00e4idatud funktsioon SELECT pg_back. See tagastab minu tehingu ja selle tehingu ID. <\/p>\n
<\/p>\n
Veel on oluline, kui teile meeldib see esitlus ja soovite selle oma andmebaasis k\u00e4ivitada, siis saate klikata sel roosaga esile t\u00f5stetud lingil ning alla laadida selle esituse SQL. Ja te saate lihtsalt k\u00e4ivitada selle oma PSQL-is ning kogu esitlus ilmub teile ekraanile viivitamatult. See ei sisalda v\u00e4rve, kuid v\u00e4hemalt saame selle siiski n\u00e4ha.<\/p>\n
<\/p>\n
<\/p>\n
Selles olukorras n\u00e4eme tehingu ID-d. See on number, mille me sellele m\u00e4\u00e4rasime. Ja Postgresis on veel \u00fcks tehingu ID t\u00fc\u00fcp, mida kutsutakse virtuaalseks tehingu ID-ks.<\/p>\n
<\/p>\n
Ja me peame seda m\u00f5istma. See on v\u00e4ga oluline, vastasel juhul ei suuda me Postgresis lukustamist m\u00f5ista.<\/p>\n
<\/p>\n
Virtuaalne tehingu ID on tehingu ID, mis ei sisalda p\u00fcsivaid v\u00e4\u00e4rtusi. N\u00e4iteks kui ma kasutan SELECT k\u00e4sku, siis t\u00f5en\u00e4oliselt ei muuda ma andmebaasi, ma ei blokeeri midagi. Seega, kui k\u00e4ivitame lihtsa SELECT-i, ei anna me sellele tehingule p\u00fcsivat ID-d. Anname sellele vaid virtuaalse ID.<\/p>\n
<\/p>\n
Ja see suurendab Postgresi j\u00f5udlust, parandades puhastamisv\u00f5imalusi, seega koosneb virtuaalne tehingu ID kahest numbrist. Esimene number enne kaldkriipsu on bakenidi ID. Ja paremal pool n\u00e4eme lihtsalt loendurit.<\/p>\n
<\/p>\n
<\/p>\n
Seega, kui ma k\u00e4ivitangi p\u00e4ringu, \u00fctleb see, et bakenidi ID on 2. <\/p>\n
<\/p>\n
<\/p>\n
Ja kui ma k\u00e4itan selliseid tehingute seeriat, siis n\u00e4eme, et loendur suureneb iga kord, kui ma p\u00e4ringu k\u00e4ivitada. N\u00e4iteks, kui ma k\u00e4itan p\u00e4ringut 2\/10, 2\/11, 2\/12 jne. <\/p>\n
<\/p>\n
<\/p>\n
Pange t\u00e4hele, et siin on kaks veergu. Vasakul n\u00e4eme virtuaalset tehingu ID-d \u2013 2\/12. Ja paremal on meil p\u00fcsiv tehingu ID. Ja see v\u00e4li on t\u00fchi. Ja see tehing ei muuda andmebaasi. Seega ei anna ma sellele p\u00fcsivat tehingu ID-d.<\/p>\n
<\/p>\n
<\/p>\n
Niipea kui ma k\u00e4itan anal\u00fc\u00fcsi k\u00e4sku (ANALYZE), annab sama p\u00e4ring mulle p\u00fcsiva tehingu ID. Vaadake, kuidas see on muutunud. Varem ei olnud mul seda ID-d, n\u00fc\u00fcd on see olemas.<\/p>\n
<\/p>\n
<\/p>\n
Nii et siin on veel \u00fcks p\u00e4ring, veel \u00fcks tehing. Virtuaalne tehingu number on 2\/13. Ja kui ma k\u00fcsin p\u00fcsivat tehingu ID-d, siis kui k\u00e4ivitan p\u00e4ringu, saan selle. <\/p>\n
<\/p>\n
<\/p>\n
Nii et veel kord. Meil on virtuaalne tehingu ID ja p\u00fcsiv tehingu ID. Lihtsalt m\u00f5istke seda, et m\u00f5ista Postgresi k\u00e4itumist.<\/p>\n
<\/p>\n
<\/p>\n
Liigume kolmandasse jaossa. Siin vaatleme erinevaid lukustust\u00fc\u00fcpe Postgresis. See ei ole v\u00e4ga huvitav. Kuid viimane jaos on palju huvitavam. Siiski peame vaatama p\u00f5hilisi asju, vastasel korral ei m\u00f5ista me seda, mis tuleb edasi. <\/p>\n
<\/p>\n
Me vaatame seda jaotust, iga lukustust\u00fc\u00fcbi vaatlemiseks. N\u00e4itan teile n\u00e4iteid, kuidas need seadistatakse, kuidas need t\u00f6\u00f6tavad, ning n\u00e4itan teile m\u00f5ningaid p\u00e4ringuid, mida saab kasutada lukustuse toimimise j\u00e4lgimiseks Postgresis.<\/p>\n
<\/p>\n
<\/p>\n
K\u00fcsimuse esitamiseks ja Postgresis toimuva j\u00e4lgimiseks peame k\u00fcsima s\u00fcsteemi vaate kaudu. Antud juhul on meil punase v\u00e4rviga esile toodud pg_lock. Pg_lock on s\u00fcsteemitabel, mis \u00fctleb meile, milliseid lukustusi kasutatakse Postgresis.<\/p>\n
<\/p>\n
Kuid mul on v\u00e4ga keeruline n\u00e4idata teile pg_lock'i iseenesest, kuna see on \u00fcsna keeruline. Seet\u00f5ttu olen loonud vaate, mis n\u00e4itab pg_locks'i. Samuti t\u00e4idab see minu jaoks teatud \u00fclesannet, mis aitab mul paremini m\u00f5ista. St see j\u00e4tab v\u00e4lja minu lukustused, minu enda seansi jne. See on lihtsalt tavaline SQL ja aitab mul n\u00e4idata, mis toimub. <\/p>\n
<\/p>\n
<\/p>\n
Teine probleem on see, et see vaade on v\u00e4ga lai, seet\u00f5ttu pean looma teise \u2013 lockview2.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Nii et l\u00f5ime tabeli nimega Lockdemo. Ja seal on \u00fcks rida. See on meie n\u00e4idistabel. Loomeme jaotisi lihtsalt selleks, et n\u00e4idata teile lukustuse n\u00e4iteid. <\/p>\n
<\/p>\n
<\/p>\n
Nii et \u00fcks rida, \u00fcks veerg. Esimene lukustust\u00fc\u00fcp on ACCESS SHARE. See on k\u00f5ige v\u00e4hem piirav lukustus. See t\u00e4hendab, et see ei konfliktis praktiliselt teiste lukustustega.<\/p>\n
<\/p>\n
Ja kui me tahame selgelt m\u00e4\u00e4ratleda blokeerimise, siis k\u00e4ivitame k\u00e4su \u00ablock table\u00bb. Ja see blokeerib selgelt, st ACCESS SHARE re\u017eiimis k\u00e4ivitame lock table. Ja kui ma k\u00e4ivitan PSQL taustal, siis k\u00e4ivitangi sel viisil teise seansi oma esimesest seansist. St mida ma siin teen? Ma l\u00e4hen teise seanssi ja \u00fctlen talle \u00abn\u00e4ita mulle lockview selle p\u00e4ringu jaoks\u00bb. Ja siin on mul AccessShareLock selles tabelis. See on t\u00e4pselt see, mida ma k\u00fcsisin. Ja ta \u00fctleb, et blokeering on antud. V\u00e4ga lihtne. <\/p>\n
<\/p>\n
<\/p>\n
Edasi, kui vaatame teist veergu, siis seal ei ole midagi. Need on t\u00fchjad. <\/p>\n
<\/p>\n
<\/p>\n
Ja kui ma k\u00e4ivitun k\u00e4su \u00abSELECT\u00bb, siis see on implitsiitne (selge) viis k\u00fcsida AccessShareLocki. Seet\u00f5ttu vabastan oma tabeli ja k\u00e4ivitun p\u00e4ringu, ja p\u00e4ring tagastab mitu rida. Ja \u00fches ridast n\u00e4eme AccessShareLocki. Nii et SELECT kutsub tabelis esile AccessShareLocki. Ja see ei konflikti praktiliselt millegagi, sest see on madala taseme blokeering. <\/p>\n
<\/p>\n
<\/p>\n
Mis juhtub, kui k\u00e4ivitan SELECT ja mul on kolm erinevat tabelit? Varem k\u00e4ivitasin ainult \u00fche tabeli, n\u00fc\u00fcd k\u00e4ivitan kolm: pg_class, pg_namespace ja pg_attribute.<\/p>\n
<\/p>\n
<\/p>\n
Ja n\u00fc\u00fcd, kui vaatan p\u00e4ringut, n\u00e4en kolme tabeli peale 9 AccessShareLocki. Miks? Sinise v\u00e4rviga on esile t\u00f5stetud kolm tabelit: pg_attribute, pg_class, pg_namespace. Kuid v\u00f5ite n\u00e4ha, et k\u00f5ik indeksid, mis on m\u00e4\u00e4ratletud nende tabelite kaudu, omavad samuti AccessShareLocki.<\/p>\n
<\/p>\n
Ja see on blokeering, mis praktiliselt ei konflikti teistega. Ja k\u00f5ik, mida ta teeb, on lihtsalt see, et ta ei luba meil tabelit kustutada, kuni me seda vaatame. See on m\u00f5istetav. St kui me valime tabeli, siis see hetkel kaob, see on vale, seega AccessShare on madala taseme lukustus, mis \u00fctleb meile \"\u00e4rge kustutage seda tabelit, kuni ma t\u00f6\u00f6tan\".<\/strong>. Sisuliselt on see k\u00f5ik, mida ta teeb. <\/p>\n<\/p>\n
<\/p>\n
ROW SHARE \u2013 see blokeering on veidi erinev. <\/p>\n
<\/p>\n
<\/p>\n
V\u00f5tame n\u00e4ite. SELECT ROW SHARE viib iga rea blokeerimise eraldi.<\/strong>. Nii et keegi ei saa neid kustutada ega muuta, kuni me neid vaatame. <\/p>\n<\/p>\n
<\/p>\n
<\/p>\n
Siin r\u00e4\u00e4gime, et lukustus on meie poolt kasutusel.<\/p>\n
<\/p>\n
<\/p>\n
Nii et, eksklusiivne lukustus \u00fctleb selgelt, et see on eksklusiivne. Ja samuti, kui kustutate rea selles tabelis, siis just see juhtub, nagu te v\u00f5ite n\u00e4ha. <\/p>\n
<\/p>\n
<\/p>\n
SHARE EXCLUSIVE \u2013 see on pikem lukustus.<\/strong><\/p>\n<\/p>\n
<\/p>\n
See (ANALYZE) on anal\u00fc\u00fcsi k\u00e4sk, mida kasutatakse.<\/p>\n
<\/p>\n
<\/p>\n
SHARE LOCK \u2013 v\u00f5ite ekspressiivselt lukustada jagamisre\u017eiimis.<\/p>\n
<\/p>\n
<\/p>\n
Saate luua ka unikaalse indeksi. Ja seal n\u00e4ete SHARE LOCKi, mis on osa sellest. Ja see lukustab tabeli ning seab sellele SHARE LOCK-i.<\/p>\n
<\/p>\n
Vaikimisi t\u00e4hendab SHARE LOCK tabelis, et teised inimesed v\u00f5ivad tabelit lugeda, kuid keegi ei saa seda muuta. Ja just see juhtub, kui loote unikaalse indeksi.<\/strong><\/p>\n<\/p>\n
Kui ma loon unikaalse concurrently indeksi, siis mul on teine t\u00fc\u00fcpi lukustus, sest nagu te m\u00e4letate, v\u00e4hendab concurrently indeksite kasutamine lukustusn\u00f5udeid. Ja kui kasutan tavalist lukustust, tavalist indeksit, siis takistan nii indeksi kirjutamist tabelisse selle loomise ajal. Kui kasutan concurrently indeksit, siis pean kasutama teist t\u00fc\u00fcpi lukustust. <\/p>\n
<\/p>\n
<\/p>\n
SHARE ROW EXCLUSIVE \u2013 j\u00e4lle saab seda m\u00e4\u00e4rata ekspressiivselt.<\/p>\n
<\/p>\n
<\/p>\n
V\u00f5i saame luua reegli, st v\u00f5tta mingi kindla juhu, mille puhul seda kasutatakse.<\/p>\n
<\/p>\n
<\/p>\n
EXCLUSIVE lukustus t\u00e4hendab, et keegi teine ei saa tabelit muuta. <\/p>\n
<\/p>\n
<\/p>\n
Siin n\u00e4eme erinevaid lukustusi. <\/p>\n
<\/p>\n
<\/p>\n
ACCESS EXCLUSIVE, n\u00e4iteks, on lukustus k\u00e4sk. N\u00e4iteks, kui teete CLUSTER table<\/code>, siis see t\u00e4hendab, et keegi ei saa sinna kirjutada. Ja see lukustab mitte ainult tabeli, vaid ka indeksid.<\/p>\n<\/p>\n
<\/p>\n
See on ACCESS EXCLUSIVE lukustuse teine leht, kus me n\u00e4eme konkreetselt, mida see tabelis lukustab. See lukustab eraldi rea tabelis, mis on p\u00e4ris huvitav.<\/p>\n
<\/p>\n
See k\u00f5ik p\u00f5hiteave, mida ma tahtsin anda. Oleme r\u00e4\u00e4kinud lukudest, tehingu ID-dest, virtuaalsetest tehingu ID-dest ja p\u00fcsivatest tehingu ID-dest. <\/p>\n
<\/p>\n
<\/p>\n
N\u00fc\u00fcd vaatame lukke n\u00e4idete kaudu. See on k\u00f5ige huvitavam osa. Uurime v\u00e4ga huvitavaid juhtumeid. Minu \u00fclesanne selles esituses on anda teile parem arusaam sellest, mida Postgres t\u00f5eliselt teeb, kui ta \u00fcritab lukustada erinevaid asju. Minu arvates oskab ta v\u00e4ga h\u00e4sti lukustada \u00fcksikuid osi. <\/p>\n
<\/p>\n
Vaatame konkreetseid n\u00e4iteid.<\/p>\n
<\/p>\n
<\/p>\n
Alustame tabelitest ja \u00fchest reast tabelis. Kui ma midagi sisestan, kuulen ExclusiveLock'i, tehingu ID-d ja ExclusiveLock'i tabelil. <\/p>\n
<\/p>\n
<\/p>\n
Aga mis juhtub, kui sisestan veel kaks rida? N\u00fc\u00fcd on meie tabelis kolm rida. Kui ma sisestan \u00fche rea ja saan sellise v\u00e4ljundi. Ja kui ma sisestan veel kaks rida, mis siin on veider? Siin on imelikkus, kuna ma lisasin kolm rida sellele tabelile, kuid mul on endiselt kaks rida lukustustabelis. Ja see on p\u00f5him\u00f5tteliselt Postgresi aluseline k\u00e4itumine.<\/p>\n
<\/p>\n
Paljud arvavad, et kui andmebaasis lukustad 100 rida, siis pead looma 100 lukustuse sissekannet. Kui ma lukustan korraga 1 000 rida, siis tahan 1 000 sellist p\u00e4ringut. Ja kui ma pean lukustama miljon v\u00f5i miljard. Kuid kui me seda teeme, siis see ei t\u00f6\u00f6ta h\u00e4sti. Kui oled kasutanud s\u00fcsteemi, mis loob lukustuse sissekande iga \u00fcksiku rea jaoks, siis n\u00e4ed, et see on keeruline. Sest pead kohe m\u00e4\u00e4rama lukustustabeli, mis v\u00f5ib t\u00e4ituda, aga Postgres nii ei tee. <\/p>\n
<\/p>\n
Ja slaidil on v\u00e4ga oluline, et siin n\u00e4idatakse selgelt, et on olemas veel \u00fcks s\u00fcsteem, mis t\u00f6\u00f6tab MVCC sees, mis lukustab \u00fcksikuid reade. Seega, kui lukustate miljardeid reade, ei loo Postgres miljardit eraldi lukustamise k\u00e4sku. Ja see m\u00f5jub v\u00e4ga h\u00e4sti j\u00f5udlusele. <\/p>\n
<\/p>\n
<\/p>\n
Aga kuidas on uuendustega? Ma praegu uuendan rida ja te v\u00f5ite m\u00e4rkida, et see tegi kohe kaks erinevat operatsiooni. Ta blokeeris tabeli samal ajal, aga ta blokeeris ka indeksi. Ja tal oli vaja blokeerida indeksi, kuna sellele tabelile on seatud unikaalsed piirangud. Ja me tahame veenduda, et keegi seda ei muuda, seet\u00f5ttu me selle blokeerime.<\/p>\n
<\/p>\n
<\/p>\n
Aga mis juhtub, kui ma tahan uuendada kahte rida? Ja me n\u00e4eme, et see k\u00e4itub samuti. Me teeme kaks korda rohkem uuendusi, kuid t\u00e4pselt sama palju ridade blokeeringuid. <\/p>\n
<\/p>\n
Kui teid huvitab, kuidas Postgres seda teeb, peate kuulama mu ettekandeid MVCC-st, et teada saada, kuidas Postgres sisemiselt t\u00e4histab neid rive, mida ta muudab. Ja Postgresel on viis, kuidas ta seda teeb, kuid ta ei tee seda tabelite blokeerimise tasemel, ta teeb seda madalamal ja efektiivsemal tasemel.<\/p>\n
<\/p>\n
<\/p>\n
Aga kui ma tahan midagi kustutada? Kui ma kustutan n\u00e4iteks \u00fche rida ja mul on ikkagi minu kaks algset blokeeringut, ning isegi kui ma tahaksin need k\u00f5ik eemaldada, on need ikkagi seal.<\/p>\n
<\/p>\n
<\/p>\n
Ja n\u00e4iteks, kui ma tahan lisada 1 000 rida ja siis kustutada v\u00f5i lisada veel 1 000 rida, siis need individuaalsed read, mida ma lisasin v\u00f5i muutsin, ei salvestata siia. Need salvestatakse madalamal tasemel seesama rida. Ja MVCC ettekandes r\u00e4\u00e4kisin ma sellest \u00fcksikasjalikult. Kuid on v\u00e4ga oluline, et anal\u00fc\u00fcsite blokeeringuid, et tagada, et teil on tabeli tasemel blokeering ja et siin ei ole n\u00e4ha, kuidas m\u00f5ned \u00fcksikud read salvestatakse. <\/p>\n
<\/p>\n
<\/p>\n
Aga kuidas on eksplicitse blokeerimisega?<\/p>\n
<\/p>\n
<\/p>\n
Kui ma vajutan 'uuenda', siis mul on kaks blokeeritud rida. Ja kui ma valin need k\u00f5ik ja vajutan 'uuenda k\u00f5ikjal', siis mul j\u00e4\u00e4b endiselt kaks blokeerimisrekordit. <\/p>\n
<\/p>\n
<\/p>\n
Me ei loo eraldi kirjeid iga\u00fche jaoks eraldi rida. Sest siis langeb j\u00f5udlus, seal v\u00f5ib olla liiga palju. Ja me v\u00f5ime sattuda ebamugavasse olukorda. <\/p>\n
<\/p>\n
<\/p>\n
Ja sama kehtib, kui me teeme shared, me v\u00f5ime teha k\u00f5igi 30 korda. <\/p>\n
<\/p>\n
<\/p>\n
Me taastame oma tabeli, k\u00f5ik eemaldame, siis lisame uuesti \u00fche rida.<\/p>\n
<\/p>\n
<\/p>\n
Teine k\u00e4itumisviis, mida n\u00e4ete Postgres'is, on v\u00e4ga h\u00e4sti tuntud ja soovitud k\u00e4itumine \u2013 saate teha update v\u00f5i select. Ja te saate neid teha samaaegselt. Select ei blokeeri update'id ja sama kehtib ka vastupidiselt. Me \u00fctleme, et lugeja ei blokeeri kirjutajat ja kirjutaja ei blokeeri lugejat. <\/p>\n
<\/p>\n
Ma n\u00e4itan teile selle n\u00e4idet. Ma teen praegu valiku. Seej\u00e4rel teeme INSERT. Ja te saate n\u00e4ha \u2013 694. Te n\u00e4ete tehingu ID-d, mis tegi selle insert'i. Ja see on see, kuidas see t\u00f6\u00f6tab. <\/p>\n
<\/p>\n
<\/p>\n
Ja kui ma n\u00fc\u00fcd vaatan oma tagaosa ID-d, siis see on \u2013 695. <\/p>\n
<\/p>\n
<\/p>\n
Ja ma n\u00e4en, et 695 ilmub minu tabelisse. <\/p>\n
<\/p>\n
<\/p>\n
Ja kui ma teen siin uuenduse, siis saan teise juhtumi. Sellisel juhul on 695 eksklusiivne lukustus ja update'l on sama k\u00e4itumine, kuid nende vahel ei teki konflikte, mis on piisavalt ebatavaline. <\/p>\n
<\/p>\n
Ja v\u00f5ite m\u00e4rgata, et \u00fcleval on ShareLock ja all on ExclusiveLock. Ja m\u00f5lemad tehingud said l\u00e4bi.<\/p>\n
<\/p>\n
Ja peate kuulama minu ettekannet MVCC teemal, et m\u00f5ista, kuidas see toimub. Kuid see on illustratsioon sellele, et saate neid samaaegselt teha, st samaaegselt teha SELECT ja UPDATE.<\/p>\n
<\/p>\n
<\/p>\n
Laske meil l\u00e4htestada ja teha veel \u00fcks tehing. <\/p>\n
<\/p>\n
<\/p>\n
Kui proovite samaaegselt k\u00e4ivitada kaks update'i samal real, siis see lukustub. Ja pidage meeles, et ma \u00fctlesin, et lugeja ei blokeeri kirjutajat, vaid kirjutaja blokeerib lugeja, kuid \u00fcks kirjutaja blokeerib teist kirjutajat. St me ei saa lasta kahte inimest samaaegselt uuendada sama rida. Peab ootama, kuni \u00fcks neist l\u00f5petab. <\/p>\n
<\/p>\n
<\/p>\n
Ja selle illustreerimiseks vaatan Lockdemo tabelit. Ja vaatame \u00fchte rida. Tehingut 698.<\/p>\n
<\/p>\n
Me uuendasime selle 2 peale. 699 \u2013 see on esimene uuendus. Ja see l\u00e4ks edukalt l\u00e4bi v\u00f5i see on ootel tehingus ja ootab, kuni me selle kinnitame v\u00f5i t\u00fchistame. <\/p>\n
<\/p>\n
<\/p>\n
Aga vaadake teist \u2013 2\/51 \u2013 see on meie esimene tehing, meie esimene sessioon. 3\/112 \u2013 see on teine p\u00e4ring, mis ilmus \u00fclal ja mis muutsid selle v\u00e4\u00e4rtuse kolme peale. Ja kui te m\u00e4rkate, siis \u00fclemine j\u00e4ttis ennast lukku, millel on ID 699. Kuid 3\/112 ei saanud lukku. Veerus Lock_mode on kirjutatud, et ta ootab. Ta ootab 699. Ja kui te vaatate, kus on 699, on ta \u00fcleval. Ja mida esimest sessiooni tegi? Ta l\u00f5i eksklusiivse lukku omaenda tehingu ID-l. Just nii teeb Postgres. Ta blokeerib oma tehingu ID. Ja kui te soovite Oodata, kuni keegi kinnitab v\u00f5i t\u00fchistab, siis peate ootama, kuni seal on ootel tehing. Ja seet\u00f5ttu saame n\u00e4ha kummalist rida. <\/p>\n
<\/p>\n
Vaadakem veel kord. Vasakul n\u00e4eme meie t\u00f6\u00f6tlemise ID-d. Teises veerus n\u00e4eme meie virtuaalse tehingu ID-d ja kolmandas n\u00e4eme lock_type'i. Mida see t\u00e4hendab? Fondamentaalselt \u00fctleb, et see blokeerib tehingu ID-d. Kuid m\u00e4rkige, et k\u00f5ikides ridades \u00fcleval on kirjutatud relation. Ja seet\u00f5ttu on teil tabelis kaks t\u00fc\u00fcpi blokeeringut. On relation-lukustus. Samuti on tehingu ID lukustus, kus me blokeerime ise, see on just see, mis toimub esimeses reas v\u00f5i k\u00f5ige alumises, kus transationid, kus me ootame, et 699 l\u00f5petaks oma operatsiooni. <\/p>\n
<\/p>\n
Mina vaatan, kuidas asjad l\u00e4hevad. Ja siin toimub samaaegselt kaks asja. Te vaatate lukustamist tehingu ID-l esimeses reas, mis blokeerib iseennast. Ja ta blokeerib iseennast, et sundida inimesi ootama. <\/p>\n
<\/p>\n
Kui te vaatate 6. rida, siis see sama kirje, mis on esimeses. Ja seet\u00f5ttu on tehing 699 blokeeritud. Samuti blokeerib 700 ennast. Ja siis n\u00e4ete alumises reas, et ootame, kuni 699 l\u00f5petab oma operatsiooni.<\/p>\n
<\/p>\n
<\/p>\n
Ja lock_type, tuple, n\u00e4ete numbreid. <\/p>\n
<\/p>\n
<\/p>\n
Te n\u00e4ete, et see on 0\/10. Ja see on lehe number, samuti ka selle konkreetse rea offset. <\/p>\n
<\/p>\n
<\/p>\n
Ja te n\u00e4ete, et see saab 0\/11, kui me uuendame. <\/p>\n
<\/p>\n
<\/p>\n
Aga tegelikult \u2013 see on 0\/10, kuna ootamine toimib selle operatsiooni kallal. Meil on v\u00f5imalus vaadata, et see on see rida, mida ma ootan, et kinnitada. <\/p>\n
<\/p>\n
<\/p>\n
Kui me selle kinnitasime ja commit-nuppu vajutasime, ning v\u00e4rskendus l\u00f5petas, saame me j\u00e4lle sama. Tehing 700 on ainus lukustus, ta ei oota enam kedagi, kuna see on commititud. Ta ootab vaid, kuni tehing l\u00f5petatakse. Kui 699 l\u00f5peb, ei oota me enam kedagi. Ja n\u00fc\u00fcd \u00fctleb tehing 700, et k\u00f5ik on korras, et k\u00f5ik vajalikud lukustused on tal k\u00f5ikides lubatud tabelites. <\/p>\n
<\/p>\n
<\/p>\n
Ja et seda k\u00f5ike veel keerulisemaks teha, loome me veel \u00fche vaate, mis seekord annab meile hierarhia. Ma ei oota, et te seda p\u00e4ringut m\u00f5istate. Kuid see annab meile selgema \u00fclevaate, mis toimub. <\/p>\n
<\/p>\n
<\/p>\n
See on rekursiivne vaade, millel on veel \u00fcks sektsioon. Ja see toob k\u00f5ik tagasi kokku. Kasutame seda. <\/p>\n
<\/p>\n
<\/p>\n
Mis juhtub, kui me teeme kolm samaaegset v\u00e4rskendust ja \u00fctleme, et rida on n\u00fc\u00fcd kolme v\u00f5rra suurem. Ja vahetame 3 4 vastu. <\/p>\n
<\/p>\n
<\/p>\n
Ja n\u00fc\u00fcd n\u00e4eme 4. Ja tehingu ID 702. <\/p>\n
<\/p>\n
<\/p>\n
Ja siis vahetan 4 5 vastu. Ja 5 6, ja 6 7. Ja ma panen ritta inimesed, kes ootavad, et see \u00fcks tehing \u00f5nnestuks.<\/p>\n
<\/p>\n
<\/p>\n
Ja k\u00f5ik muutub selgeks. Mis on esimene rida? See on 702. See on tehingu ID, mis algselt selle v\u00e4\u00e4rtuse seadmiseks m\u00e4\u00e4rati. Ja mis mul on kirjas veerus Granted? Mul on seal m\u00e4rgid. f<\/code>. Need on minu v\u00e4rskendused (5, 6, 7), mis ei saa kinnitust, sest me ootame, et tehingu ID 702 l\u00f5peks. Seal on meil tehingu ID lukustus. Ja kokku tuleb 5 tehingu lukustus ID-d.<\/p>\n<\/p>\n
Ja kui te vaatate 704, 705, siis seal ei ole veel midagi kirjas, sest nad ei tea veel, mis toimub. Nad lihtsalt kirjutavad, et ei tea, mis toimub. Ja nad l\u00e4hevad lihtsalt unne, sest nad ootavad, kuni keegi l\u00f5petab ja \u00e4ratab nad, kui tekib v\u00f5imalus rida vahetada. <\/p>\n
<\/p>\n
<\/p>\n
Nii see v\u00e4lja n\u00e4eb. Selge on see, et nad k\u00f5ik ootavad 12. rida. <\/p>\n
<\/p>\n
<\/p>\n
See on see, mida me siin n\u00e4gime. Siin on 0\/12. <\/p>\n
<\/p>\n
<\/p>\n
Nii et niipea, kui esimene tehing kinnitatakse, saate siin n\u00e4ha, kuidas hierarhia t\u00f6\u00f6tab. Ja n\u00fc\u00fcd on k\u00f5ik selge. Nad k\u00f5ik saavad puhtaks. Ja nad on tegelikult endiselt ootamas. <\/p>\n
<\/p>\n
<\/p>\n
Nii see l\u00e4heb. 702 on toimetamisel. N\u00fc\u00fcd saab 703 selle rea lukustuse ja p\u00e4rast seda hakkab 704 ootama, kuni 703 l\u00f5petab toimetamise. Ja 705 ootab samuti. Kui k\u00f5ik see on l\u00f5pule viidud, siis nad puhastavad end ise. Tahaksin m\u00e4rkida, et k\u00f5ik seisavad j\u00e4rjekorras. See meenutab olukorda ummikus, kus k\u00f5ik ootavad esimest autot. Esimene auto peatus ja k\u00f5ik j\u00e4rgnevad seisavad pikalt reas. Siis see liigub edasi, j\u00e4rgmine auto saab siis edasi liikuda ja oma lukustuse jne. <\/p>\n
<\/p>\n
<\/p>\n
Ja kui see tundub teile ebapiisavalt keeruline, r\u00e4\u00e4gime n\u00fc\u00fcd deadlockidest. Ma ei tea, kui palju teist on nende vastu puutunud. See on piisavalt levinud probleem andmebaasis\u00fcsteemides. Deadlockid tekivad siis, kui \u00fcks sessioon ootab, et teine sessioon midagi teeks. Samal ajal ootab teine sessioon, et esimene sessioon midagi teeks. <\/p>\n
<\/p>\n
Ja n\u00e4iteks, kui Ivan \u00fctleb: \"Anna mulle midagi\" ja mina \u00fctlen: \"Ei, ma annan sulle seda ainult siis, kui sa annad mulle midagi teist.\" Ja ta \u00fctleb: \"Ei, ma ei anna seda, kui sa ei anna mulle.\" J\u00f5uame murtud lukustuse olukorda. Olen kindel, et Ivan ei teeks nii, kuid te m\u00f5istate m\u00f5tte, et meil on kaks inimest, kes tahavad midagi saada ja nad ei ole valmis seda andma, kuni teine inimene neile seda ei anna. Ja siin ei ole lahendust. <\/p>\n
<\/p>\n
Eessential on, et teie andmebaas tuvastaks need olukorrad. Seej\u00e4rel tuleb eemaldada v\u00f5i l\u00f5petada \u00fcks sessioon, sest vastasel juhul j\u00e4\u00e4vad nad sinna igavesti. Me n\u00e4eme seda andmebaasides, operatsioonis\u00fcsteemides ja k\u00f5ikjal, kus meil on paralleelsed protsessid. <\/p>\n
<\/p>\n
<\/p>\n
Ja n\u00fc\u00fcd paigutame kaks deadlocki. Asetame 50 ja 80. Esimeses real loon v\u00e4rskenduse 50-le 50-ks. See toob v\u00e4lja tehingu numbri 710. <\/p>\n
<\/p>\n
<\/p>\n
Seej\u00e4rel muudan 80 81-ks ja 50 51-ks. <\/p>\n
<\/p>\n
<\/p>\n
Ja nii see v\u00e4lja n\u00e4eb. Seet\u00f5ttu on 710-l rea lukustus ja 711 ootab kinnitust. Oleme seda varem n\u00e4inud, kui v\u00e4rskendused toimusid. 710 on meie rea omanik. Ja 711 ootab, kuni 710 l\u00f5petab tehingu.<\/p>\n
<\/p>\n
<\/p>\n
Seal on isegi kirjas, millisel t\u00e4pselt real meil deadlock toimub. Ja siin hakkab see kummaliseks muutuma.<\/p>\n
<\/p>\n
<\/p>\n
N\u00fc\u00fcd v\u00e4rskendame 80 80-ks. <\/p>\n
<\/p>\n
<\/p>\n
Ja n\u00fc\u00fcd saavad alguse ummikud. 710 ootab 711 vastust, samas kui 711 ootab 710-d. See ei l\u00f5pe h\u00e4sti. Ja sellest pole v\u00e4ljap\u00e4\u00e4su. Nad ootavad \u00fcksteiselt vastust. <\/p>\n
<\/p>\n
<\/p>\n
See lihtsalt hakkab k\u00f5ike aeglustama. Me ei soovi seda. <\/p>\n
<\/p>\n
<\/p>\n
Postgresis on viise, kuidas m\u00e4rkida, kui see juhtub. Ja kui see juhtub, siis saad sellise veateate. Selgub, et \u00fcks protsess ootab SHARED LOCK-i teiselt protsessilt, st see, mis blokeerib 711. Ja see protsess ootas SHARED LOCK-i teatud tehingu ID jaoks ning oli blokeeritud mingi protsessi poolt. Nii et siin on olukord ummikus.<\/p>\n
<\/p>\n
<\/p>\n
Kas on olemas ka kolmeosalisi ummikuid? Kas see on v\u00f5imalik? Jah. <\/p>\n
<\/p>\n
<\/p>\n
Sisestame need numbrid tabelisse. Muudame 40 40-ks, teeme blokeeringu. <\/p>\n
<\/p>\n
<\/p>\n
Muudame 60 61-ks, 80 81-ks. <\/p>\n
<\/p>\n
<\/p>\n
K seej\u00e4rel muudame 80, ja siis - bum! <\/p>\n
<\/p>\n
<\/p>\n
N\u00fc\u00fcd ootab 714 715-d. 716 ootab 715-d. Ja seda ei saa enam parandada.<\/p>\n
<\/p>\n
<\/p>\n
Siin pole enam kahte inimesena, vaid kolm inimest. Ma tahan sinult midagi, see tahab kolmandalt inimeselt midagi, ja kolmas inimene tahab minult midagi. Ja meil on kolmepoolne ootus, sest k\u00f5ik ootame, kuni teine inimene l\u00f5petab selle, mida ta peab tegema. <\/p>\n
<\/p>\n
<\/p>\n
Postgres teab, millisel real see juhtub. Seega annab see teile j\u00e4rgmise s\u00f5numi, kus n\u00e4idatakse, et teil on probleem, kus kolm sisendit blokeerivad \u00fcksteist. Ja siin pole piiranguid. See v\u00f5ib juhtuda, kus 20 kirjet blokeerivad \u00fcksteist. <\/p>\n
<\/p>\n
<\/p>\n
J\u00e4rgmine probleem on serialiseeritavus. <\/p>\n
<\/p>\n
<\/p>\n
Kui on eriline serialiseeritav blokeering.<\/p>\n
<\/p>\n
<\/p>\n
Ja naaseme 719 juurde. Sellel on t\u00e4iesti normaalne v\u00e4ljund. <\/p>\n
<\/p>\n
<\/p>\n
Ja saate vajutada, et teha tehing serialiseeritava formaadiga.<\/p>\n
<\/p>\n
<\/p>\n
N\u00fc\u00fcd m\u00f5istate, et teil on teine blokk SA - see t\u00e4hendab serialiseeritav. <\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Seega on meil uus blokeeringu liik, mida nimetatakse SARieadLock, mis on j\u00e4rjekindel blokeering ja lubab sisestada seerianumbrid.<\/p>\n
<\/p>\n
<\/p>\n
Samuti v\u00f5ite sisestada unikaalseid indekseid. <\/p>\n
<\/p>\n
<\/p>\n
Selles tabelis on meil unikaalsed indeksid.<\/p>\n
<\/p>\n
<\/p>\n
Seega, kui ma sisestan siia numbri 2, siis mul on 2. Kuid k\u00f5ige \u00fclal oleval joonisel sisestan veel \u00fche 2. N\u00e4ete, et 721-l on eksklusiivne blokeering. Kuid n\u00fc\u00fcd ootab 722, et 721 l\u00f5petaks oma operatsiooni, sest ta ei saa 2-d sisestada, enne kui ei tea, mis juhtub 721-ga. <\/p>\n
<\/p>\n
<\/p>\n
Ja kui teeme alatehingu.<\/p>\n
<\/p>\n
<\/p>\n
Siin on meil 723.<\/p>\n
<\/p>\n
<\/p>\n
Ja kui me s\u00e4ilitame punkti ja siis v\u00e4rskendame seda, siis saame uue tehingu ID. See on veel \u00fcks k\u00e4itumismuster, millest peate teadma. Kui me selle tagasi anname, siis tehingu ID kaob. 724 kaob. Kuid n\u00fc\u00fcd on meil 725. <\/p>\n
<\/p>\n
Ja mida ma siin p\u00fc\u00fcan teha? P\u00fc\u00fcan n\u00e4idata teile n\u00e4iteid ebatavalisest lukustamisest, mida v\u00f5ite kohata: olgu need serializable lukud v\u00f5i SAVEPOINT - need on erinevad lukustamisv\u00f5imalused, mis ilmuvad lukustamisdiagrammi. <\/p>\n
<\/p>\n
<\/p>\n
See on eksplicitsete (selgete) lukustamiste loomine, kus asub pg_advisory_lock. <\/p>\n
<\/p>\n
<\/p>\n
Ja n\u00e4ete, et lukustamise t\u00fc\u00fcp on siin loetletud kui advisory. Ja siin on punasega kirjutatud \u201eadvisory\u201c. Ja te saate samaaegselt lukustada pg_advisory_unlock.<\/p>\n
<\/p>\n
<\/p>\n
Ja l\u00f5petuseks tahaksin teile n\u00e4idata veel \u00fchte h\u00e4mmastavat asja. Loome veel \u00fche t\u00fc\u00fcbi. Kuid vormin pg_locks tabeli pg_stat_activity tabeliga. Ja miks ma seda teha tahan? Sest see v\u00f5imaldab mul vaadata ja n\u00e4ha k\u00f5iki praegusi sessioone ning n\u00e4ha, milliseid lukke nad ootavad. Ja see on piisavalt huvitav, kui me kogume lukustamisdiagrammi ja p\u00e4ringute diagrammi kokku. <\/p>\n
<\/p>\n
<\/p>\n
Ja siin loome pg_stat_view. <\/p>\n
<\/p>\n
<\/p>\n
Ja me v\u00e4rskendame rida \u00fche v\u00f5rra. Ja siin n\u00e4eme 724. Seej\u00e4rel v\u00e4rskendame meie rea kolme peale. Ja mida te siit praegu n\u00e4ete? Need on p\u00e4ringud, st n\u00e4ete kogu p\u00e4ringute nimekirja, mis on loetletud vasakus veerus. Ja siis paremal pool n\u00e4ete lukustusi ja seda, mida need loovad. See v\u00f5ib olla teile arusaadav, et pole vajadust iga kord tagasi minna igasse sessiooni ja vaadata - kas on vaja liituda v\u00f5i mitte. Meie eest teevad nad seda. <\/p>\n
<\/p>\n
Veel \u00fcks v\u00e4ga kasulik funktsioon on pg_blocking_pids<\/code>. Te ei pruugi sellest kunagi kuulnud olla. Mida see teeb? See v\u00f5imaldab meil \u00f6elda, et seansi 11740 jaoks ootab see t\u00e4pselt neid protsessi ID'sid. Ja te n\u00e4ete, et 11740 ootab 724. Ja 724 on k\u00f5ige \u00fcleval. Ja 11306 on teie protsessi ID. Sisuliselt l\u00e4bib see funktsioon teie lukutustabelit. Ja ma tean, et see on veidi keeruline, kuid te m\u00f5istate seda. Sisuliselt l\u00e4bib see funktsioon selle lukutustabeli ja p\u00fc\u00fcab leida, kus see protsessi ID on, arvestades neid lukustusi, mida ta ootab. Samuti p\u00fc\u00fcab ta arvutada, milline protsessi ID on selle protsessi puhul, mis ootab lukustusi. Nii et te saate selle funktsiooni k\u00e4ivitada pg_blocking_pids<\/code>.<\/p>\n<\/p>\n
Ja see on v\u00e4ga kasulik. Me lisasime selle alles versioonist 9.6, seega on see funktsioon vaid 5 aastat vana, kuid see on v\u00e4ga ja v\u00e4ga kasulik. Sama kehtib ka teise p\u00e4ringu kohta. See n\u00e4itab t\u00e4pselt seda, mida me peame n\u00e4gema. <\/p>\n
<\/p>\n
<\/p>\n
See on see, millest ma tahtsin teiega r\u00e4\u00e4kida. Nagu ma ootasin, kulutasime kogu meie aja, sest slaide oli nii palju. Slaidid on allalaadimist ootamas. Ma tahan teid t\u00e4nada, et olite siin. Olen kindel, et teile meeldib konverentsi \u00fclej\u00e4\u00e4nud osa, suur t\u00e4nu!<\/p>\n
<\/p>\n
K\u00fcsimused:<\/p>\n
<\/p>\n
N\u00e4iteks, kui ma proovin ridu uuendada, ja teine sessioon proovib kogu tabelit kustutada. Niikaua kui ma aru saan, peaks seal olema midagi nagu intent lock. Kas Postgreses on midagi sellist?<\/em><\/p>\n<\/p>\n
<\/p>\n
Naaseme algusesse. V\u00f5ib-olla m\u00e4letate, et kui teete midagi, n\u00e4iteks SELECT, siis anname AccessShareLock'i. Ja see takistab tabeli kustutamist. Seega, kui soovite n\u00e4iteks tabelis rida uuendada v\u00f5i rida kustutada, ei saa keegi samal ajal kogu tabelit kustutada, sest te hoiate selle AccessShareLock'i kogu tabeli ja rea \u00fcle. Ja niipea kui olete l\u00f5petanud, saavad nad selle kustutada. Kuid seni, kuni te seal midagi muutate, ei saa nad seda teha.<\/p>\n
<\/p>\n
Teeme veel kord. Liigume kustutamise n\u00e4ite juurde. Ja te n\u00e4ete, kuidas reaal on eksklusiivne lukustus kogu tabeli \u00fcle. <\/p>\n
<\/p>\n
See n\u00e4eb v\u00e4lja nagu eksklusiivne lukustus, eks ole?<\/em><\/p>\n<\/p>\n
Jah, see n\u00e4eb v\u00e4lja nagu see. Ma m\u00f5istan, millest te r\u00e4\u00e4gite. Te \u00fctlete, et kui ma teen SELECT-i, siis on mul ShareExclusive, ja kui ma muudan selle Row Exclusive-iks, kas see tekib probleem? Kuid \u00fcllatavalt see ei tekita probleemi. See on nagu lukustustaseme t\u00f5stmine, kuid tegelikult on mul lukustus, mis takistab kustutamist. Ja n\u00fc\u00fcd, kui ma teen selle luku tugevamaks, takistab see endiselt kustutamist. Seega ei ole see nii, et ma t\u00f5usen \u00fcles. St. see takistas seda ja kui see oli madalamal tasemel, seega, kui ma t\u00f5stsin selle taset, takistab see endiselt tabeli kustutamist. <\/p>\n
<\/p>\n
Ma m\u00f5istan, millest te r\u00e4\u00e4gite. Siin ei ole olukorda, kus lukustustaset t\u00f5stetakse, kus te proovite loobuda \u00fchest lukustusest, et tutvustada v\u00f5imsamat. Siin see lihtsalt suurendab selle takistuse ulatust, seega see ei p\u00f5hjusta mingit konflikti. Aga see on hea k\u00fcsimus. Suur t\u00e4nu, et selle k\u00fcsisite!<\/p>\n
<\/p>\n
Mida peame tegema, et v\u00e4ltida deadlocki olukorda, kui meil on palju sessioone, suur kasutajate arv?<\/em><\/p>\n<\/p>\n
Postgres m\u00e4rkab automaatselt deadlocki olukordi. Ja automaatselt eemaldab \u00fche sessioonidest. Ainus viis, kuidas aidata v\u00e4ltida deadlocki, on blokeerida inimesi samas j\u00e4rjestuses. Seega, kui vaatate oma rakendust, on tihti deadlockide p\u00f5hjus... Oletame, et ma tahan blokeerida kaks erinevat asja. \u00dcks rakendus blokeerib tabeli 1, teine rakendus blokeerib 2 ja seej\u00e4rel tabeli 1. Ja k\u00f5ige lihtsam viis deadlockide v\u00e4ltimiseks on vaadata oma rakendust ja p\u00fc\u00fcda tagada, et blokeerimine toimub k\u00f5igis rakendustes samas j\u00e4rjekorras. Ja see tavaliselt eemaldab 80% probleemidest, sest erinevad inimesed kirjutavad neid rakendusi. Ja kui blokite neid samas j\u00e4rjekorras, ei satu te deadlocki olukorda.<\/p>\n
<\/p>\n
Suur t\u00e4nu teie ettekande eest! Te r\u00e4\u00e4kisite vacuum full-st ja kui ma \u00f5igesti m\u00f5istan, siis vacuum full deformeerib kirje j\u00e4rjekorda eraldi hoidlas, seega s\u00e4ilib praegune kirje muutumatuna. Aga miks vacuum full n\u00f5uab eksklusiivset lukustust ja miks see konflikteerub kirjutamisoperatsioonidega?<\/em><\/p>\n<\/p>\n
See on hea k\u00fcsimus. P\u00f5hjuseks on see, et vacuum full v\u00f5tab tabeli. Ja me sisuliselt loome uue versiooni tabelist. Ja tabel on uus. Seega on tegemist t\u00e4iesti uue versiooniga tabelist. Probleem seisneb selles, et kui me seda teeme, ei taha me, et inimesed seda loeksid, sest me vajame, et nad n\u00e4eksid uut tabelit. Seet\u00f5ttu on see seotud eelmise k\u00fcsimusega. Kui me saaksime lugeda samaaegselt, siis ei saaks me seda liigutada ja suunata inimesi uuele tabelile. Me peaksime ootama, kuni k\u00f5ik l\u00f5petavad selle tabeli lugemise, ja seet\u00f5ttu on tegelikult tegemist exclusiivse lukustusolukorraga.
<\/p>\n
Kas Postgres'is on v\u00f5imalik lisada lukustamise katkestusaega? Oracle'is v\u00f5in ma n\u00e4iteks kirjutada 'vali uuendamiseks' ja oodata 50 sekundit uuendamiseks. See oli rakenduse jaoks hea. Kuid Postgres'is pean ma selle kas kohe tegema ja mitte ootama, v\u00f5i ootama kuni teatud ajani.<\/em> <\/p>\n<\/p>\n
Jah, saate valida lukustamise katkestuaja oma lukustustele. Samuti saate anda k\u00e4su no way, mis \u2026, kui te ei saa kohe lukustust. Seega kas lukustamise katkestusaja v\u00f5i muu, mis v\u00f5imaldab teil seda teha. Seda ei tehta s\u00fcntaktilisel tasemel. Seda tehakse serveri muutuja tasemel. M\u00f5nikord ei saa seda kasutada.<\/p>\n
<\/p>\n
Kas saad avada 75. slaidi?<\/em> <\/p>\n<\/p>\n
Jah.<\/p>\n
<\/p>\n
<\/p>\n
Ja minu k\u00fcsimus on j\u00e4rgmine. Miks ootavad m\u00f5lemad uuendusprotsessid 703?<\/em><\/p>\n<\/p>\n
Ja see on t\u00f5esti hea k\u00fcsimus. Ma ei saa aru, miks Postgres seda teeb. Aga kui 703 loodi, oodati 702. Ja kui 704 ja 705 ilmuvad, siis n\u00e4ib, et nad ei tea, mida nad ootavad, sest seal pole veel midagi. Ja Postgres teeb seda nii: kui sa ei saa lukku, siis ta kirjutab \u201eMilleks sind t\u00f6\u00f6delda?\u201c, sest sa ikkagi ootad kedagi. Nii et anname tal lihtsalt \u00f5hus rippuda, ta ei uuenda seda \u00fcldse. Aga mis siin toimub? Kui 702 on protsessi l\u00f5petanud ja 703 on saanud oma luku, siis s\u00fcsteem naaseb tagasi. Ja \u00fctleb, et n\u00fc\u00fcd ootavad kaks inimest. Siis uuendame neid koos. Ja m\u00e4rkime, et m\u00f5lemad ootavad. <\/p>\n
<\/p>\n
Ma ei tea, miks Postgres nii teeb. Aga on probleem, mis on tuntud kui f\u2026. Tundub, et see ei ole vene termin. See on siis, kui k\u00f5ik ootavad \u00fchte lukku, isegi kui 20 instantsi ootab lukku. Ja \u00e4kki \u00e4rkavad nad k\u00f5ik \u00fcles korraga. Ja k\u00f5ik hakkavad p\u00fc\u00fcdma reageerida. Aga s\u00fcsteem teeb nii, et k\u00f5ik ootavad 703. Sest nad k\u00f5ik ootavad ja me panevad nad kohe ritta. Ja kui tuleb m\u00f5ni muu uus p\u00e4ring, mis on p\u00e4rast seda loodud, n\u00e4iteks 707, siis seal on taas t\u00fchjus. <\/p>\n
<\/p>\n
Ja mulle tundub, et see on tehtud selleks, et saaks \u00f6elda, et sellel etapil ootab 702 703, ja k\u00f5igil, kes p\u00e4rast seda tulevad, ei ole selles valdkonnas mitte mingit kirjet. Aga niipea, kui esimene ootaja lahkub, saavad k\u00f5ik, kes sel hetkel ootasid enne uuendust, sama m\u00e4rgise. Ja seet\u00f5ttu arvan, et see on tehtud selleks, et saaksime t\u00f6\u00f6delda j\u00e4rjekorras, et nad oleksid \u00f5igesti j\u00e4rjestatud. <\/p>\n
<\/p>\n
Ma olen alati vaadanud seda kui \u00fcsna kummalist fenomeni. Sest siin, n\u00e4iteks, ei loetle neid \u00fcldse. Aga mulle tundub, et iga kord, kui anname uue luku, vaatame me k\u00f5iki, kes on ooteprotsessis. Siis paneme nad k\u00f5ik j\u00e4rjekorda. Ja seej\u00e4rel, iga uus, mis tuleb, satub j\u00e4rjekorda ainult siis, kui j\u00e4rgmine inimene on l\u00f5petanud t\u00f6\u00f6tlemise. V\u00e4ga hea k\u00fcsimus. Ait\u00e4h k\u00fcsimise eest!<\/p>\n
<\/p>\n
Mulle tundub, et see on palju loogilisem, kui 705 ootab 704.<\/em> <\/p>\n<\/p>\n
Aga probleem on j\u00e4rgmine. Tehniliselt saate \u00e4ratada kas \u00fche v\u00f5i teise. Seega \u00e4ratame kas \u00fche v\u00f5i teise. Kuid mis toimub s\u00fcsteemi t\u00f6\u00f6s? N\u00e4ete, et 703 on \u00fclal blokeerinud omaenda tehingu ID. Nii t\u00f6\u00f6tab Postgres. Ja 703 blokeerib enda tehingu ID, seega kui keegi tahab oodata, siis ootab see 703. Ja p\u00f5him\u00f5tteliselt l\u00f5petab 703. Ja ainult p\u00e4rast selle l\u00f5petamist \u00e4rkab m\u00f5ni protsess. Ja me ei tea, milline neist protsessidest on. Siis t\u00f6\u00f6tame j\u00e4rk-j\u00e4rgult k\u00f5ik l\u00e4bi. Kuid pole selge, milline protsess \u00e4rkab esimesena, sest see v\u00f5ib olla \u00fcksk\u00f5ik milline neist protsessidest. P\u00f5him\u00f5tteliselt oli meil ajastaja, mis \u00fctles, et n\u00fc\u00fcd saame \u00e4ratada \u00fcksk\u00f5ik millise neist protsessidest. Valime lihtsalt \u00fche juhuslikult. Seet\u00f5ttu tuleb m\u00f5lemad \u00fcles m\u00e4rkida, sest me saan \u00e4ratada m\u00f5lemat. <\/p>\n
<\/p>\n
Ja probleem on see, et meil on CP-l\u00f5pmatus. Seega on t\u00e4iesti t\u00f5en\u00e4oline, et saame \u00e4ratada hilisema. Ja kui n\u00e4iteks \u00e4ratame hilisema, siis ootame seda, kes just sai blokeeringu, seega me ei m\u00e4\u00e4ra, kes t\u00e4pselt esimesena \u00e4ratatakse. Loome lihtsalt sellise olukorra, ja s\u00fcsteem \u00e4ratab neid juhuslikus j\u00e4rjekorras. <\/p>\n
<\/p>\n
Jah artiklid lukustustest Egor Rogovilt<\/a><\/noindex>. Vaadake, need on samuti huvitavad ja kasulikud. Teema on muidugi kohutavalt keeruline. Ait\u00e4h palju, Bruce!<\/em><\/p>\nAllikas: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2020 \u0433\u043e\u0434\u0430 \u0411\u0440\u044e\u0441\u0430 \u041c\u043e\u043c\u0436\u0438\u0430\u043d\u0430 "Unlocking the Postgres Lock Manager". (\u041f\u0440\u0438\u043c\u0435\u0447\u0430\u043d\u0438\u0435: \u0412\u0441\u0435 SQL \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438\u0437 \u0441\u043b\u0430\u0439\u0434\u043e\u0432 \u0432\u044b \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043f\u043e \u044d\u0442\u043e\u0439 \u0441\u0441\u044b\u043b\u043a\u0435: http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql) \u041f\u0440\u0438\u0432\u0435\u0442! \u0417\u0430\u043c\u0435\u0447\u0430\u0442\u0435\u043b\u044c\u043d\u043e \u0441\u043d\u043e\u0432\u0430 \u0431\u044b\u0442\u044c \u0437\u0434\u0435\u0441\u044c \u0432 \u0420\u043e\u0441\u0441\u0438\u0438. \u042f \u043f\u0440\u043e\u0448\u0443 \u043f\u0440\u043e\u0449\u0435\u043d\u0438\u0435, \u0447\u0442\u043e \u044f \u043d\u0435 \u0441\u043c\u043e\u0433 \u043f\u0440\u0438\u0435\u0445\u0430\u0442\u044c \u0432 \u043f\u0440\u043e\u0448\u043b\u043e\u043c \u0433\u043e\u0434\u0443, \u043d\u043e \u0432 \u044d\u0442\u043e\u043c \u0433\u043e\u0434\u0443 \u0443 \u0418\u0432\u0430\u043d\u0430 \u0438 \u0443 \u043c\u0435\u043d\u044f \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u043f\u043b\u0430\u043d\u044b. \u042f, \u043d\u0430\u0434\u0435\u044e\u0441\u044c, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":87955,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-87954","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Unlocking](\"\/wp-content\/uploads\/2020\/07\/1f75fbb0cb41c306c33c823ef55f7238.png\")
<\/p>\n