http:\/\/momjian.us\/main\/writings\/pgsql\/locking.sql<\/a><\/noindex><\/p>\n<\/p>\n
Vaatame. Punasega on esile t\u00f5stetud tehingu number. Siin on kuvatud funktsioon SELECT pg_back. See tagastab minu tehingu ja selle tehingu ID. <\/p>\n
<\/p>\n
Veel \u00fcks punkt \u2014 kui teile meeldib see esitlus ja soovite selle oma andmebaasi k\u00e4ivitada, siis saate minna l\u00e4bi selle roosa v\u00e4rviga esile t\u00f5stetud lingi ning alla laadida esituse SQL-i. Ja saate selle lihtsalt oma PSQL-is k\u00e4ivitada ning kogu esitlus ilmub teie ekraanile koheselt. See ei sisalda v\u00e4rve, kuid v\u00e4hemalt saame selle n\u00e4ha.<\/p>\n
<\/p>\n
<\/p>\n
Antud juhul n\u00e4eme tehingu ID-d. See on number, mille oleme talle m\u00e4\u00e4ranud. Ja Postgresis on veel \u00fcks tehingu ID t\u00fc\u00fcp, mida nimetatakse virtuaalseks tehingu ID-ks.<\/p>\n
<\/p>\n
Peame seda m\u00f5istma. See on v\u00e4ga oluline, vastasel juhul ei saa me Postgresis blokeeringut m\u00f5ista.<\/p>\n
<\/p>\n
Virtuaalne tehingu ID on tehingu ID, mis ei sisalda p\u00fcsivaid v\u00e4\u00e4rtusi. N\u00e4iteks, kui ma k\u00e4ivitan k\u00e4su SELECT, siis on t\u00f5en\u00e4oline, et ma ei muuda andmebaasi, ma ei blokeeri midagi. Seega, kui me k\u00e4ivitame lihtsa SELECT-i, ei anna me sellele tehingule p\u00fcsivat ID-d. Anname talle seal ainult virtuaalse ID.<\/p>\n
<\/p>\n
Ja see parandab Postgresi j\u00f5udlust ning t\u00e4iustab puhastusv\u00f5imalusi, mist\u00f5ttu virtuaalne tehingu ID koosneb kahest numbrist. Esimene number kaldkriipsu ees on tagasihoidliku ID. Ja paremal n\u00e4eme lihtsalt loendurit.<\/p>\n
<\/p>\n
<\/p>\n
Seet\u00f5ttu, kui k\u00e4itan p\u00e4ringu, \u00fctleb see, et tagasihoidlik ID on 2. <\/p>\n
<\/p>\n
<\/p>\n
Ja kui k\u00e4itan selliseid tehingute seeriaid, n\u00e4eme, et loendur suureneb iga kord, kui k\u00e4itan p\u00e4ringu. N\u00e4iteks, kui 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. See tehing ei muuda andmebaasi. Seet\u00f5ttu ei omista ma sellele p\u00fcsivat tehingu ID-d.<\/p>\n
<\/p>\n
<\/p>\n
Kuna olen k\u00e4ivitanud anal\u00fc\u00fcsimis k\u00e4su (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 see on olemas.<\/p>\n
<\/p>\n
<\/p>\n
Nii et siin on veel \u00fcks p\u00e4ring, veel \u00fcks tehing. Virtuaalne tehingu number \u2013 2\/13. Ja kui palun p\u00fcsivat tehingu ID-d, siis kui k\u00e4itan 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 punkti, et aru saada Postgres'i k\u00e4itumisest.<\/p>\n
<\/p>\n
<\/p>\n
Liigume kolmandasse sektsiooni. Siin k\u00e4ime lihtsalt l\u00e4bi erinevad lukustust\u00fc\u00fcbid Postgres'is. See pole v\u00e4ga huvitav. Viimane sektsioon tuleb palju huvitavam. Kuid me peame uurima p\u00f5hiasju, vastasel juhul ei saa me aru, mis edasi tuleb. <\/p>\n
<\/p>\n
Me vaatame selle sektsiooni l\u00e4bi, vaatame iga lukustust\u00fc\u00fcbi. Ja ma n\u00e4itan teile n\u00e4iteid, kuidas need kehtestatakse, kuidas need t\u00f6\u00f6tavad, ning tutvustan teile m\u00f5ned p\u00e4ringud, mida saab kasutada, et n\u00e4ha, kuidas lukustus Postgres'is t\u00f6\u00f6tab.<\/p>\n
<\/p>\n
<\/p>\n
K\u00fcsimuse esitamiseks ja selle n\u00e4gemiseks, mis Postgres'is toimub, peame esitama p\u00e4ringu s\u00fcsteemi vaatesse. Antud juhul on meil punasega esile t\u00f5stetud pg_lock. Pg_lock on s\u00fcsteemtablett, mis \u00fctleb meile, millised lukustused on hetkel Postgres'is kasutusel.<\/p>\n
<\/p>\n
Siiski on mul v\u00e4ga raske n\u00e4idata teile pg_lock'i endast, sest see on \u00fcsna keeruline. Seet\u00f5ttu l\u00f5in vaate, mis n\u00e4itab pg_locks'i. Ja see teeb ka minu jaoks teatud t\u00f6\u00f6d, mis aitab mul paremini m\u00f5ista. St. see v\u00e4listab minu lukustused, minu enda sessiooni jne. See on lihtsalt standardne SQL ja see v\u00f5imaldab paremini n\u00e4idata, mis toimub. <\/p>\n
<\/p>\n
<\/p>\n
Teine probleem on see, et see vaade on v\u00e4ga lai, seega pean looma teise \u2013 lockview2.<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Nii et l\u00f5ime tabeli nimega Lockdemo. Ja l\u00f5ime seal \u00fche rea. See on meie n\u00e4idistabel. Ja loome sektsioonid, et lihtsalt n\u00e4idata teile lukustuse n\u00e4iteid. <\/p>\n
<\/p>\n
<\/p>\n
Nii et \u00fcks rida, \u00fcks veerg. Esimene lukustust\u00fc\u00fcp nimetatakse ACCESS SHARE. See on k\u00f5ige v\u00e4hem piirav lukustus. See t\u00e4hendab, et see praktiliselt ei konflikti teiste lukustustega.<\/p>\n
<\/p>\n
Ja kui me tahame blokeerimist selgelt m\u00e4\u00e4ratleda, k\u00e4ivitame k\u00e4su \u00ablock table\u00bb. See blokeerib selgelt, st ACCESS SHARE re\u017eiimis k\u00e4ivitame lock table. Ja kui k\u00e4ivitan PSQL taustal, siis k\u00e4ivitan seega oma esimesest sessioonist teise seansi. Mida ma siin teen? Liigun teise seansi juurde ja \u00fctlen, et n\u00e4itaks mulle lockview antud p\u00e4ringu jaoks. Siin on mul AccessShareLock selles tabelis. See on just see, mida ma k\u00fcsisin. Ja ta \u00fctleb, et blokeering on m\u00e4\u00e4ratud. V\u00e4ga lihtne. <\/p>\n
<\/p>\n
<\/p>\n
Kui vaatame teist veergu, siis seal pole midagi. Need on t\u00fchjad. <\/p>\n
<\/p>\n
<\/p>\n
Ja kui ma k\u00e4ivitan k\u00e4su \u00abSELECT\u00bb, siis see on kaudne (ilmne) viis AccessShareLocki taotlemiseks. Seet\u00f5ttu vabastan oma tabeli ja k\u00e4ivitan p\u00e4ringu ning p\u00e4ring tagastab mitu rida. Ja \u00fches neist ridadest n\u00e4eme AccessShareLocki. Seega kutsub SELECT tabelis esile AccessShareLocki. Ja see ei konflikti praktiliselt millegagi, kuna on madala tasemega blokeering. <\/p>\n
<\/p>\n
<\/p>\n
Kuidas oleks, kui ma k\u00e4ivitan SELECTi ja mul on kolm erinevat tabelit? Varasemalt 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 ma vaatan p\u00e4ringut, n\u00e4en 9 AccessShareLocks kolme tabeliga. Miks? Sinise v\u00e4rviga on esile t\u00f5stetud kolm tabelit: pg_attribute, pg_class, pg_namespace. Kuid n\u00e4ete ka, et k\u00f5ik indekseerimised, mis on m\u00e4\u00e4ratletud nende tabelite kaudu, omavad samuti AccessShareLock'i.<\/p>\n
<\/p>\n
Ja tegemist on lukustusega, mis praktiliselt ei tekita konflikte teistega. K\u00f5ik, mida see teeb, on see, et see ei luba meil tabelit tagasi t\u00f5mmata, kuni me seda valime. See on m\u00f5istetav. St kui me valime tabeli ja see hetk \u00e4kki kaob, siis see oleks vale, seega 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>. P\u00f5him\u00f5tteliselt on see k\u00f5ik, mida ta teeb. <\/p>\n<\/p>\n
<\/p>\n
ROW SHARE on lukustus, mis erineb veidi. <\/p>\n
<\/p>\n
<\/p>\n
V\u00f5tame n\u00e4ite. SELECT ROW SHARE on lukustusmeetod, mis lukustab iga rida eraldi<\/strong>. Sel viisil ei saa keegi neid kustutada v\u00f5i muuta seni, 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 selle tabeli rea, siis see juhtub, nagu te n\u00e4ete. <\/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\u00fcsik\u00e4sk, mida kasutatakse.<\/p>\n
<\/p>\n
<\/p>\n
SHARE LOCK \u2013 saate seda selgelt lukustada jagamises.<\/p>\n
<\/p>\n
<\/p>\n
Saate ka luua unikaalse indeksi. Ja seal n\u00e4ete SHARE LOCK'i, mis on nende osa. Ja see lukustab tabeli ning seab sellele SHARE LOCK'i.<\/p>\n
<\/p>\n
Vaikimisi SHARE LOCK tabelis t\u00e4hendab, et teised inimesed saavad tabelit lugeda, kuid keegi ei saa seda modifitseerida. Just nii k\u00e4ibki, kui loote unikaalse indeksi.<\/strong><\/p>\n<\/p>\n
Kui ma loon unikaalse indeksi concurrently, siis mul on teine \u200b\u200bt\u00fc\u00fcp lukku, sest nagu te m\u00e4letate, v\u00e4hendab concurrently indeksite kasutamine lukustusn\u00f5udeid. Ja kui ma kasutan tavalist lukku, tavalist indeksit, takistab see kirjutamist indeksitabelisse selle loomise ajal. Kui ma kasutan concurrently indeksit, tuleb mul kasutada teistsugust lukku. <\/p>\n
<\/p>\n
<\/p>\n
SHARE ROW EXCLUSIVE \u2013 selle saab samuti m\u00e4\u00e4rata eksplicitset (selgelt).<\/p>\n
<\/p>\n
<\/p>\n
V\u00f5i v\u00f5ime luua reegli, st v\u00f5tta mingi kindel juhtum, millega 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 lukustuside t\u00fc\u00fcpe. <\/p>\n
<\/p>\n
<\/p>\n
ACCESS EXCLUSIVE, n\u00e4iteks, see on lukustamise 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 enda, vaid ka indeksid.<\/p>\n<\/p>\n
<\/p>\n
See on ACCESS EXCLUSIVE blokeerimise teine leht, kus me n\u00e4eme t\u00e4pselt, mida see tabelis blokeerib. See blokeerib tabeli \u00fcksikud read, mis on piisavalt huvitav.<\/p>\n
<\/p>\n
See on kogu p\u00f5hiteave, mida ma tahtsin anda. R\u00e4\u00e4kisime blokeeringutest, tehingu ID-dest, r\u00e4\u00e4kisime virtuaalsetest tehingu ID-dest ja p\u00fcsivatest tehingu ID-dest. <\/p>\n
<\/p>\n
<\/p>\n
Ja n\u00fc\u00fcd vaatame blokeerimise n\u00e4iteid. See on k\u00f5ige huvitavam osa. Vaatame v\u00e4ga huvitavaid juhtumeid. Ja minu \u00fclesanne selles ettekandes on anda teile parem \u00fclevaade sellest, mida Postgres tegelikult teeb, kui ta p\u00fc\u00fcab teisi asju blokeerida. Mul on tunne, et ta oskab v\u00e4ga h\u00e4sti blokeerida \u00fcksikuid osi. <\/p>\n
<\/p>\n
Vaatame kindlaid n\u00e4iteid.<\/p>\n
<\/p>\n
<\/p>\n
Alustame tabelitest ja \u00fchest reast tabelis. Kui ma midagi sisestan, kuvatakse mulle ExclusiveLock, tehingu ID ja ExclusiveLock tabelis. <\/p>\n
<\/p>\n
<\/p>\n
Ent\u00e4 mit\u00e4 tapahtuu, jos lis\u00e4\u00e4n viel\u00e4 kaksi rivi\u00e4? Nyt taulukossamme on kolme rivi\u00e4. Lis\u00e4sin yhden rivin ja sain t\u00e4llaisen tuloksen. Ja jos lis\u00e4\u00e4n viel\u00e4 kaksi rivi\u00e4, mik\u00e4 t\u00e4ss\u00e4 on outoa? T\u00e4ss\u00e4 on outous, sill\u00e4 olen lis\u00e4nnyt kolme rivi\u00e4 t\u00e4h\u00e4n taulukkoon, mutta minulla on silti vain kaksi rivi\u00e4 lukitus-taulukossa. Ja t\u00e4m\u00e4 on itse asiassa Postgresin perus k\u00e4ytt\u00e4ytyminen.<\/p>\n
<\/p>\n
Monet ajattelevat, ett\u00e4 jos tietokannassa lukitset 100 rivi\u00e4, niin tarvitset 100 lukitusmerkint\u00e4\u00e4. Jos lukitsen samanaikaisesti 1 000 rivi\u00e4, tarvitsen 1 000 t\u00e4llaista pyynt\u00f6\u00e4. Ja jos minun t\u00e4ytyy lukita miljoona tai miljardi. Mutta jos teemme niin, se ei toimi kovin hyvin. Jos olit k\u00e4ytt\u00e4nyt j\u00e4rjestelm\u00e4\u00e4, joka luo lukitusmerkinn\u00e4t jokaiselle erilliselle riville, huomaat, ett\u00e4 se on hankalaa. Koska sinun on m\u00e4\u00e4ritett\u00e4v\u00e4 heti lukitus-taulukko, joka voi ylitty\u00e4, mutta Postgres ei toimi niin. <\/p>\n
<\/p>\n
Ja sellel slaidil on v\u00e4ga oluline, et on selgelt n\u00e4ha, et on veel \u00fcks s\u00fcsteem, mis t\u00f6\u00f6tab MVCC sees, mis lukustab \u00fcksikuid ridu. Seega, kui lukustate miljardeid ridu, ei loo Postgres miljardit eraldi lukustuskommandot. See avaldab v\u00e4ga head m\u00f5ju j\u00f5udlusele. <\/p>\n
<\/p>\n
<\/p>\n
Aga kuidas on uuendustega? Ma uuendan praegu rida ja v\u00f5ite m\u00e4rgata, et see tegi kohe kaks erinevat operatsiooni. Ta lukustas samaaegselt tabeli, kuid lukustas ka indeksi. Ja tal oli vaja lukustada indeks, kuna sellel tabelil on unikaalsed piirangud. Soovime veenduda, et keegi seda ei muuda, seet\u00f5ttu me lukustame selle.<\/p>\n
<\/p>\n
<\/p>\n
Aga mis juhtub, kui tahan uuendada kahte rida? N\u00e4eme, et ta k\u00e4itub samamoodi. Teeme kaks korda rohkem uuendusi, kuid lukustame endiselt sama arvu ridu. <\/p>\n
<\/p>\n
Kui te soovite teada, kuidas Postgres seda teeb, siis peate kuulama minu ettekandeid MVCC-st, et m\u00f5ista, kuidas Postgres sisemiselt markeerib neid ridu, mida ta muudab. Ja Postgresil on meetod, millega ta seda teeb, kuid see ei toimu tabelite lukustamise tasemel; see toimub madalamal ja efektiivsemal tasemel.<\/p>\n
<\/p>\n
<\/p>\n
Ent kui ma tahan midagi kustutada? Kui ma kustutan n\u00e4iteks \u00fche rea, ja mul on ikka veel kaks lukustust, ja isegi kui ma tahan need k\u00f5ik kustutada, on need ikkagi olemas.<\/p>\n
<\/p>\n
<\/p>\n
Ja n\u00e4iteks, kui ma tahan sisestada 1 000 rida, ja siis kas kustutada v\u00f5i lisada veel 1 000 rida, siis need individuaalsed read, mida ma lisan v\u00f5i muudan, ei salvestata siia. Need salvestatakse madalamal tasemel, ridade enda sees. Ja MVCC ettekandes r\u00e4\u00e4kisin sellest \u00fcksikasjalikult. Kuid on v\u00e4ga oluline, et kui anal\u00fc\u00fcsite lukustusi, veenduge, et teil on tabeli taseme lukustus ning et te ei n\u00e4e siin, kuidas individuaalsete ridade salvestamine toimub. <\/p>\n
<\/p>\n
<\/p>\n
Aga kuidas on eksplicitse lukustamisega?<\/p>\n
<\/p>\n
<\/p>\n
Kui ma klikkin \u00abv\u00e4rskenda\u00bb, on mul kaks lukustatud rida. Ja kui ma valin need k\u00f5ik ja klikkin \u00abv\u00e4rskenda k\u00f5ikjal\u00bb, on mul ikkagi kaks lukustatud kirjet. <\/p>\n
<\/p>\n
<\/p>\n
Me ei loo eraldi kirjeid iga rida jaoks. 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 asi, kui me teeme jagatud, saame teha seda 30 korda. <\/p>\n
<\/p>\n
<\/p>\n
Me taastame oma tabeli, kustutame k\u00f5ik, seej\u00e4rel lisame uuesti \u00fche rea.<\/p>\n
<\/p>\n
<\/p>\n
Teine k\u00e4itumisviis, mida te n\u00e4ete Postgreses, on v\u00e4ga h\u00e4sti tuntud ja soovitav k\u00e4itumine \u2013 see on see, et saate t\u00e4ita uuendust v\u00f5i valimist. Ja saate seda teha samaaegselt. Ja valimine ei blokeeri uuendust ja sama on vastupidine. Me \u00fctleme lugejale, et \u00e4rge blokeerige kirjutajat, ja kirjutaja ei blokeeri lugejat. <\/p>\n
<\/p>\n
Ma n\u00e4itan teile selle n\u00e4idet. Ma teen n\u00fc\u00fcd valiku. Seej\u00e4rel teeme INSERTi. Ja te saate n\u00e4ha \u2013 694. Te n\u00e4ete tehingu ID-d, mis viis selle lisamise l\u00e4bi. Ja see on see, kuidas see t\u00f6\u00f6tab. <\/p>\n
<\/p>\n
<\/p>\n
Ja kui ma n\u00fc\u00fcd vaatan oma taustarakenduse ID-d, on see n\u00fc\u00fcd \u2013 695. <\/p>\n
<\/p>\n
<\/p>\n
Ja n\u00e4en, et 695 ilmub minu tabelisse. <\/p>\n
<\/p>\n
<\/p>\n
Ja kui ma v\u00e4rskendan seda siit nii, siis saan ma teise juhtumi. Sel juhul on 695 ainulaadne lukustus, ja uuel on sama k\u00e4itumine, kuid nende vahel ei teki konflikti, mis on \u00fcsna ebatavaline. <\/p>\n
<\/p>\n
Ja te v\u00f5ite m\u00e4rgata, et \u00fclalpool on ShareLock ja allpool on ExclusiveLock. Ja m\u00f5lemad tehingud toimisid.<\/p>\n
<\/p>\n
Ja peate kuulama minu esitluse MVCC-st, et m\u00f5ista, kuidas see toimub. Aga see illustreerib, et te saate seda teha samaaegselt, s.t. samal ajal teha SELECT ja UPDATE.<\/p>\n
<\/p>\n
<\/p>\n
L\u00e4hme tagasi ja teeme veel \u00fche tehingu. <\/p>\n
<\/p>\n
<\/p>\n
Kui proovite samaaegselt k\u00e4ivitada kaks uuendust samal real, siis see lukustub. Ja pidage meeles, et ma r\u00e4\u00e4kisin, et lugemise ajal ei blokeeri see kirja, kuid kirjutaja blokeerib lugejat, kuid \u00fcks kirjutaja blokeerib teise kirjutaja. S.t. me ei saa lasta kahel inimesel sama rida samaaegselt uuendada. Peame ootama, kuni \u00fcks neist l\u00f5petab. <\/p>\n
<\/p>\n
<\/p>\n
Ja selle \u00fcles n\u00e4itamiseks vaatan Lockdemo tabelit. Ja vaatame \u00fchte rida. Tehingut 698.<\/p>\n
<\/p>\n
Oleme selle uuendanud kuni 2. 699 - see on esimene uuendamine. Ja see on l\u00e4inud edukalt v\u00f5i see on ooteolekus ja ootab, kuni me kinnitame v\u00f5i t\u00fchistame. <\/p>\n
<\/p>\n
<\/p>\n
Aga vaadake midagi muud - 2\/51 - see on meie esimene tehing, meie esimene sessioon. 3\/112 - see on j\u00e4rgmine p\u00e4ring, mis ilmus \u00fcleval ja mis muutis selle v\u00e4\u00e4rtuse 3-ks. Ja kui te m\u00e4rkate, siis \u00fclemine blokeeris ise ennast, nimelt 699. Kuid 3\/112 ei andnud lukku. Lock_mode veerus on kirjas, et see ootab. See ootab 699. Ja kui vaatate, kus 699 on, siis see on \u00fcleval. Ja mida esimene sessioon tegi? Ta l\u00f5i eksklusiivse lukustuse omaenda tehingu ID-le. Just nii teeb Postgres. See blokeerib omaenda tehingu ID. Ja kui soovite oodata, kuni keegi kinnitab v\u00f5i t\u00fchistab, peate ootama, kuni on ooteolekus tehing. Ja seet\u00f5ttu saame n\u00e4ha kummalist rida. <\/p>\n
<\/p>\n
Vaadake veel kord. Vasakul n\u00e4eme meie t\u00f6\u00f6tlemise ID-d. Teises veerus on meie virtuaalne tehingu ID, kolmandas veerus aga lock_type. Mida see t\u00e4hendab? Tegelikult \u00fctleb see, et see blokeerib tehingu ID. Kuid pange t\u00e4hele, et k\u00f5ikides ridades allpool on m\u00e4rgitud relation. Seet\u00f5ttu on teil tabelis kaks t\u00fc\u00fcpi blokeeringut. On relation blokeering. Samuti on olemas transactionid blokeering, kus blokeerite iseseisvalt, see on t\u00e4pselt see, mis toimub esimeses reas v\u00f5i allpool, kus transactionid ootab, et 699 l\u00f5petaks oma operatsiooni. <\/p>\n
<\/p>\n
Ma vaatan, mis siin toimub. Ja siin toimuvad samal ajal kaks asja. Te vaatate tehingu ID-blokeeringut esimeses reas, mis blokeerib iseennast. Ja see blokeerib iseennast, et panna inimesi ootama. <\/p>\n
<\/p>\n
Kui vaatate 6. rida, siis see on sama kirje, mis esimene. Seet\u00f5ttu blokeeritakse tehing 699. 700 blokeerib samuti iseennast. Ja siis allosas n\u00e4ete, et me 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
Saate n\u00e4ha, et see on 0\/10. Ja see on lehek\u00fclje number, samuti selle konkreetse rea offset. <\/p>\n
<\/p>\n
<\/p>\n
Ja n\u00e4ete, et see muutub 0\/11, kui me uuendame. <\/p>\n
<\/p>\n
<\/p>\n
Aga tegelikult on see 0\/10, kuna see toiming on ootel. Meil on v\u00f5imalus n\u00e4ha, et see on see rida, mida ma ootan kinnitamiseks. <\/p>\n
<\/p>\n
<\/p>\n
Niikaua, kuni me selle kinnitame ja vajutame commit, ning kui uuendamine on finished, siis see, mida me taas saame. Tehing 700 on ainus lukustus, see ei oota kedagi, kuna see on juba commiteeritud. See lihtsalt ootab, et tehing l\u00f5petataks. Kui 699 l\u00f5peb, ei oota me enam kedagi. Ja n\u00fc\u00fcd \u00fctleb tehing 700, et k\u00f5ik on korras, et k\u00f5ik lukustused, mis vajalikud, on tal olemas k\u00f5ikides lubatud tabelites. <\/p>\n
<\/p>\n
<\/p>\n
Ja et seda k\u00f5ike veel keerukamaks muuta, loome veel \u00fche view, mis seekord annab meile hierarhia. Ma ei oota, et te selle p\u00e4ringu m\u00f5istaksite. Kuid see annab meile selgema \u00fclevaate sellest, mis toimub. <\/p>\n
<\/p>\n
<\/p>\n
See on rekursiivne view, millel on ka teine sektsioon. Ja see tagastab k\u00f5ik koos. Kasutame seda. <\/p>\n
<\/p>\n
<\/p>\n
Mis siis, kui teeme kolm samal ajal olevat uuendust ja \u00fctleme, et rida on n\u00fc\u00fcd kolm. Ja me muudame 3 neljaks. <\/p>\n
<\/p>\n
<\/p>\n
Ja n\u00e4eme numbrit 4. Ja tehingu ID on 702. <\/p>\n
<\/p>\n
<\/p>\n
Seej\u00e4rel vahetan 4 5 vastu. Ja 5 6, ning 6 7 vastu. Ma seon inimesed j\u00e4rjekorda, et oodata, kuni see \u00fcks tehing l\u00f5petatakse.<\/p>\n
<\/p>\n
<\/p>\n
K\u00f5ik muutub selgeks. Mis on esimene rida? See on 702. See on tehingu ID, mis algselt m\u00e4\u00e4ras selle v\u00e4\u00e4rtuse. Mis mul on Granted veerus? Mul on t\u00e4hised f<\/code>. Need on minu uuendused (5, 6, 7), mida ei saa heaks kiita, sest me ootame, kuni tehingu ID 702 l\u00f5petatakse. Siin on tehingu ID lukustus. Ja meil on 5 tehingu ID lukustust.<\/p>\n<\/p>\n
Ja kui vaatate 704 ja 705, siis seal pole veel midagi kirjas, sest nad ei tea veel, mis toimub. Nad kirjutavad lihtsalt, et ei ole aimugi, mis toimub. Ja nad l\u00e4hevad lihtsalt magama, sest nad ootavad, kuni keegi l\u00f5petab ja \u00e4ratab nad, kui v\u00f5imalus rida vahetada tekib. <\/p>\n
<\/p>\n
<\/p>\n
Nii see v\u00e4lja n\u00e4eb. Selge on, 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 on heaks kiidetud, 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 ikka veel ootel. <\/p>\n
<\/p>\n
<\/p>\n
Nii juhtub. 702 kinnitatakse. Ja n\u00fc\u00fcd 703 saab selle rea lukustuse, seej\u00e4rel hakkab 704 ootama, kuni 703 kinnitatakse. Ja 705 ootab samuti seda. Ja kui see k\u00f5ik on l\u00f5ppenud, puhastavad nad end ise. Tahaksin r\u00f5hutada, et k\u00f5ik j\u00e4rjekorda seadistatakse. See on v\u00e4ga sarnane olukorraga ummikus, kus k\u00f5ik ootavad esimest autot. Esimene auto peatub ja k\u00f5ik seisavad pikaks read. Siis see liigub edasi, j\u00e4rgmisel autol on v\u00f5imalus edasi s\u00f5ita ja saada oma lukustus jne. <\/p>\n
<\/p>\n
<\/p>\n
Ja kui see tundub teile ebapiisavalt keeruline, siis r\u00e4\u00e4gime n\u00fc\u00fcd deadlockidest. Ma ei tea, kes teist on nendega kokku puutunud. See on \u00fcsna levinud probleem andmebaasis\u00fcsteemides. Deadlockid on olukord, kus \u00fcks sessioon ootab, et midagi teeks teine sessioon. Ja samal ajal ootab teine sessioon, et esimene sessioon teeks midagi. <\/p>\n
<\/p>\n
Ja n\u00e4iteks, kui Ivan \u00fctleb: \"Anna mulle midagi,\" aga mina \u00fctlen: \"Ei, ma annaksin sul seda ainult siis, kui sa annaksid mulle midagi muud.\" Ja ta \u00fctleb: \"Ei, ma ei anna sulle seda, kui sa ei anna mulle midagi.\" Ja me satume surnud ummikusse. Ma olen kindel, et Ivan seda ei tee, aga sa saad aru m\u00f5ttest, et meil on kaks inimest, kes tahavad midagi saada ja nad ei ole valmis seda andma, kuni teine inimene neile ei anna, mida nad soovivad. Ja siin pole lahendust. <\/p>\n
<\/p>\n
Ja tegelikult peab teie andmebaas selle tuvastama. Ja siis on vaja eemaldada v\u00f5i sulgeda \u00fcks sessioon, sest vastasel juhul j\u00e4\u00e4vad nad sinna igaveseks. Ja me n\u00e4eme seda andmebaasides, me n\u00e4eme seda operatsioonis\u00fcsteemides. Ja k\u00f5igis kohtades, kus meil on paralleelsed protsessid, v\u00f5ib see juhtuda. <\/p>\n
<\/p>\n
<\/p>\n
Ja n\u00fc\u00fcd seame sisse kaks deadlocki. Seame \u00fche 50 ja teise 80. Esimeses reas teen uuenduse 50 pealt 50 peale. Mul tuleb transaktsiooni number 710. <\/p>\n
<\/p>\n
<\/p>\n
Ja siis vahetan 80 81 vastu ja 50 51 vastu. <\/p>\n
<\/p>\n
<\/p>\n
Ja nii see v\u00e4lja n\u00e4eb. Seet\u00f5ttu on 710 blokaadis rea, samas kui 711 ootab kinnitust. Me n\u00e4gime seda, kui uuendame. 710 on meie rea omanik. Ja 711 ootab, kuni 710 l\u00f5petab transaktsiooni.<\/p>\n
<\/p>\n
<\/p>\n
Ja isegi kirjutatakse, millises reas meil deadlock\u2019id toimuvad. Ja siin hakkab see kummaliseks minema.<\/p>\n
<\/p>\n
<\/p>\n
N\u00fc\u00fcd v\u00e4rskendame 80 80 peale. <\/p>\n
<\/p>\n
<\/p>\n
Ja siin hakkavad deadlock\u2019id pihta. 710 ootab vastust 711-lt, samas kui 711 ootab 710-lt. Ja see ei l\u00f5ppe h\u00e4sti. Ainult \u00fcks tee on, et nad ootavad \u00fcksteiselt vastust. <\/p>\n
<\/p>\n
<\/p>\n
See hakkab lihtsalt k\u00f5ike aeglustama. Ja me ei soovi seda. <\/p>\n
<\/p>\n
<\/p>\n
Postgreses on viise, kuidas m\u00e4rgata, kui see toimub. Ja kui see juhtub, saate sellise vea. Selge on see, et mingi protsess ootab SHARE LOCK\u2019i teiselt protsessilt, st see, keda blokeerib protsess 711. Ja see protsess ootas SHARE LOCK\u2019i teatud tehingu ID-le ja oli blokeeritud teise protsessi poolt. Seega oleme deadlock\u2019i olukorras.<\/p>\n
<\/p>\n
<\/p>\n
Kas on olemas ka kolmandat t\u00fc\u00fcpi deadlock\u2019id? Kas see on v\u00f5imalik? Jah. <\/p>\n
<\/p>\n
<\/p>\n
Sisestame need numbrid tabelisse. Me muudame 40 40-ks, loome blokeeringu. <\/p>\n
<\/p>\n
<\/p>\n
Muudame 60 61-ks, 80 81-ks. <\/p>\n
<\/p>\n
<\/p>\n
Siis muudame 80, ja seej\u00e4rel \u2013 bum! <\/p>\n
<\/p>\n
<\/p>\n
Ja n\u00fc\u00fcd ootab 714 715 vastust. 716 ootab 715-d. Ja sellega ei saa enam midagi teha.<\/p>\n
<\/p>\n
<\/p>\n
Siin ei ole enam kahte inimest, siin on juba kolm inimest. Ma tahan sinult midagi, see tahab midagi kolmandalt inimeselt, ja kolmas inimene tahab midagi minult. Ja me j\u00f5uame kolmnurkse ootuse olukorda, sest k\u00f5ik ootame, et teine inimene l\u00f5petaks, mida ta peab tegema. <\/p>\n
<\/p>\n
<\/p>\n
Ja Postgres teab, millisel real see toimub. Seet\u00f5ttu annab ta teile j\u00e4rgmise teate, mis n\u00e4itab, et teil on probleem, kus kolm sisendit blokeerivad \u00fcksteist. Ja siin ei ole piiranguid. See v\u00f5ib olla olukord, 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 serialiseeritavus 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 teostada transaction serialiseeritavuses.<\/p>\n
<\/p>\n
<\/p>\n
Ja te m\u00f5istate, et teil on n\u00fc\u00fcd teine \u200b\u200bt\u00fc\u00fcp blokeeringut SA - see t\u00e4hendab serialiseeritavat. <\/p>\n
<\/p>\n
<\/p>\n
<\/p>\n
Seet\u00f5ttu on meil uus t\u00fc\u00fcp blokeeringut, mida nimetatakse SARieadLock, mis on seerianumbrite blokeering ja v\u00f5imaldab seerianumbrite sisestamist.<\/p>\n
<\/p>\n
<\/p>\n
Samuti saate sisestada unikaalseid indekseid. <\/p>\n
<\/p>\n
<\/p>\n
Selles tabelis on meil unikaalsed indekssid.<\/p>\n
<\/p>\n
<\/p>\n
Seega, kui ma siia sisestan numbri 2, siis mul on 2. Kuid \u00fclalpool sisestan veel \u00fche 2. Ja te n\u00e4ete, et 721-l on ainulaadne lukustus. N\u00fc\u00fcd ootab 722, et 721 l\u00f5petaks oma toimingu, kuna ta ei saa 2-d sisestada, enne kui ei tea, mis 721-ga juhtub. <\/p>\n
<\/p>\n
<\/p>\n
Ja kui me teeme subtehingu.<\/p>\n
<\/p>\n
<\/p>\n
Siin on meil 723.<\/p>\n
<\/p>\n
<\/p>\n
Kui me salvestame punkti ja seej\u00e4rel seda v\u00e4rskendame, siis saame uue tehingu ID. See on veel \u00fcks k\u00e4itumise iseloom, 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 \u00fcritan teha? P\u00fc\u00fcan n\u00e4idata teile n\u00e4iteid ebatavalistest lukustustest, mida v\u00f5ite leida: olgu need serialiseeritavad lukustused v\u00f5i SAVEPOINT \u2013 need on erinevad lukustust\u00fc\u00fcbid, mis ilmuvad lukustuste tabelis. <\/p>\n
<\/p>\n
<\/p>\n
See on eksplitsiitsete (selgete) lukustuste loomine, mille puhul on pg_advisory_lock. <\/p>\n
<\/p>\n
<\/p>\n
Ja te n\u00e4ete, et lukustuse t\u00fc\u00fcp on siin loetletud kui n\u00f5uanne. Ja siin on punaselt kirjutatud \"n\u00f5uanne\". Ja te v\u00f5ite samaaegselt lukustada pg_advisory_unlockiga.<\/p>\n
<\/p>\n
<\/p>\n
Ja l\u00f5petuseks tahaksin teile n\u00e4idata veel \u00fcht \u00fcllatavat asja. Loomin veel \u00fche vaate. Kuid ma \u00fchendan tabeli pg_locks tabeliga pg_stat_activity. Ja miks ma seda teha tahan? Sest see v\u00f5imaldab mul vaadata ja n\u00e4ha k\u00f5iki aktiivseid sessioone ning milliste lukustusde nad ootavad. See on \u00fcsna huvitav, kui meil on koos lukustus tabel ja p\u00e4ringute tabel. <\/p>\n
<\/p>\n
<\/p>\n
Ja siin loome pg_stat_view. <\/p>\n
<\/p>\n
<\/p>\n
Ja v\u00e4rskendame rida \u00fche v\u00f5rra. Siin n\u00e4eme 724. Ja siis v\u00e4rskendame meie rida kolme v\u00f5rra. Ja mida te siin n\u00fc\u00fcd n\u00e4ete? Need on p\u00e4ringud, st n\u00e4ete kogu p\u00e4ringute nimekirja, mis on loetletud vasakus veerus. Ja siis paremal poolel n\u00e4ete lukustusi ja seda, mida nad loovad. Ja see v\u00f5ib olla teile selgem, et te ei pea iga kord tagasi minema iga sessiooni juurde ja vaatama, kas sellele tuleks liituda v\u00f5i mitte. Meie eest teevad seda. <\/p>\n
<\/p>\n
Veel \u00fcks funktsioon, mis on v\u00e4ga kasulik, on pg_blocking_pids<\/code>. Te olete t\u00f5en\u00e4oliselt sellest kunagi kuulnud. Mida see teeb? See v\u00f5imaldab meil \u00f6elda, milliseid protsesside ID-sid ootab seanss 11740. Ja te v\u00f5ite n\u00e4ha, et 11740 ootab 724. Ja 724 on k\u00f5ige peal. Ja 11306 on teie protsesside ID. Sisuliselt l\u00e4bib see funktsioon teie lukustustabelit. Ma tean, et see on veidi keeruline, kuid te suudate seda m\u00f5ista. Sisuliselt l\u00e4bib see funktsioon seda lukustustabelit ja p\u00fc\u00fcab leida, kus see protsessi ID asub, arvestades lukustusi, mida ta ootab. Ta \u00fcritab ka arvutada, milline protsesside ID on selle protsessi, mis ootab lukustust. Seet\u00f5ttu v\u00f5ite selle funktsiooni k\u00e4ivitada. pg_blocking_pids<\/code>.<\/p>\n<\/p>\n
Ja see osutub v\u00e4ga kasulikuks. Me lisasime selle alles versiooniga 9.6, seega on sellel funktsioonil vaid 5 aastat, aga 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. Ja nagu ma ootasinki, kasutasime kogu meie aega, kuna sl\u00e4ide oli nii palju. Ja sl\u00e4ide on allalaadimiseks saadaval. Soovin t\u00e4nada teid, et olite kohal. Olen kindel, et teile meeldib konverentsi \u00fclej\u00e4\u00e4nud osa, suur ait\u00e4h!<\/p>\n
<\/p>\n
K\u00fcsimused:<\/p>\n
<\/p>\n
N\u00e4iteks, kui \u00fcritan ridu uuendada, samal ajal kui teine sessioon p\u00fc\u00fcab kogu tabeli kustutada. Nii palju kui ma tean, peab seal olema midagi nagu intent lock. Kas see on olemas Postgreses?<\/em><\/p>\n<\/p>\n
<\/p>\n
K\u00e4ime tagasi algusesse. V\u00f5ib-olla m\u00e4letate, et kui teete midagi, n\u00e4iteks SELECT, siis laseme v\u00e4lja AccessShareLock'i. Ja see takistab tabeli kustutamist. Seega, kui soovite n\u00e4iteks uuendada rida tabelis v\u00f5i kustutada rida, ei saa keegi samal ajal kogu tabelit kustutada, sest te hoiate selle AccessShareLock'i kogu tabeli ja rea kohal. Ja kui olete l\u00f5petanud, saavad nad selle kustutada. Kuid seni, kuni te seal midagi muudate, ei saa nad seda teha.<\/p>\n
<\/p>\n
Teeme seda veel kord. Liigume kustutamise n\u00e4ite juurde. Ja n\u00e4ete, kuidas real on eksklusiivne lock kogu tabeli \u00fcle. <\/p>\n
<\/p>\n
Kas see n\u00e4eb v\u00e4lja nagu eksklusiivne lukustus, eks?<\/em><\/p>\n<\/p>\n
Jah, see n\u00e4eb t\u00f5epoolest v\u00e4lja nii. Ma saan aru, millest te r\u00e4\u00e4gite. Te \u00fctlete, et kui ma teen SELECT-i, siis on mul jagatud eksklusiivne lukustus, ja kui ma muudan selle rida eksklusiivseks, kas see on probleem? \u00dcllataval kombel ei tekita see probleemi. See on nagu lukustuse taseme t\u00f5stmine, kuid p\u00f5him\u00f5tteliselt on mul lukustus, mis takistab kustutamist. Ja n\u00fc\u00fcd, kui ma teen selle lukustuse tugevamaks, siis takistab see endiselt kustutamist. Seega see ei t\u00e4henda, et ma l\u00e4heksin k\u00f5rgemale. T. e. see takistas seda ka madalamal tasemel, seega, kui ma t\u00f5stan taset, takistab see endiselt tabeli kustutamist. <\/p>\n
<\/p>\n
Ma saan aru, millest te r\u00e4\u00e4gite. Siin ei ole lukustuse taseme t\u00f5stmise juhtumit, kus \u00fcritate loobuda \u00fchest lukustusest, et sisse viia tugevam. Siin toimub lihtsalt \u00fcle\u00fcldine takistuse suurendamine, seega see ei tekita mingit konflikti. Kuid see on hea k\u00fcsimus. Suur ait\u00e4h, et k\u00fcsisite!<\/p>\n
<\/p>\n
Mida me peame tegema, et v\u00e4ltida deadlock olukorda, kui meil on palju sessioone ja suur hulk kasutajaid?<\/em><\/p>\n<\/p>\n
Postgres tuvastab automaatselt deadlock'i olukorrad ja eemaldab automaatselt \u00fche sessiooni. Ainus v\u00f5imalus, mis aitab v\u00e4ltida murtud lukustusi, on blokeerida inimesi samas j\u00e4rjekorras. Seet\u00f5ttu, kui vaatate oma rakendusele, siis sageli on deadlock'i p\u00f5hjuseks\u2026 Kujutame ette, et ma tahan blokeerida kahte erinevat asja. \u00dcks rakendus blokeerib tabeli 1 ja teine rakendus blokeerib tabeli 2 ning seej\u00e4rel tabeli 1. Ja k\u00f5ige lihtsam viis deadlock'e v\u00e4ltida on vaadata oma rakendusele ja tagada, et lukustus toimub k\u00f5igis rakendustes sama j\u00e4rjekorra j\u00e4rgi. See eemaldab tavaliselt 80% probleemidest, sest erinevad inimesed kirjutavad neid rakendusi. Kui blokeerite need samas j\u00e4rjekorras, siis ei puutu te kokku deadlock'i olukordadega.<\/p>\n
<\/p>\n
Suur t\u00e4nu teie ettekande eest! R\u00e4\u00e4kisite vacuum full'ist ja kui ma \u00f5igesti aru saan, siis vacuum full deformeerib kirje j\u00e4rjekorda eraldi salvestuses, seega s\u00e4ilitavad praegused kirjed muutumatuna. Miks vacuum full aga v\u00f5tab eksklusiivse lukustuse ja miks see konfliktib kirjutamisoperatsioonidega?<\/em><\/p>\n<\/p>\n
See on hea k\u00fcsimus. P\u00f5hjuseks on see, et vacuum full haarab tabeli. Ja me loome p\u00f5him\u00f5tteliselt uue versiooni tabelist. Tabel on seega uus. Saame, et see on t\u00e4iesti uus versioon tabelist. Probleem on aga selles, et kui me seda teeme, ei taha me, et inimesed seda loeksid, kuna peame kindlustama, et nad n\u00e4evad uut tabelit. Seega seondub see varasema k\u00fcsimusega. Kui me saaksime samaaegselt lugeda, ei saaks me seda \u00fcmber paigutada ja suunata inimesi uuele tabelile. Me peaks ootama, kuni k\u00f5ik l\u00f5petavad selle tabeli lugemise, ja seet\u00f5ttu on see p\u00f5him\u00f5tteliselt eksklusiivsete lukustuse olukord.
<\/p>\n
Kas on v\u00f5imalik lisada locking timeout\u2019i Postgresis? Oracle\u2019is saan n\u00e4iteks kirjutada 'vali uuendamiseks' ja oodata 50 sekundit enne uuendamist. See t\u00f6\u00f6tas h\u00e4sti rakenduse jaoks. Kuid Postgresis pean seda kas tegema kohe ja mitte \u00fcldse ootama v\u00f5i ootama mingi aja.<\/em> <\/p>\n<\/p>\n
Jah, saate valida lukustuste, lockingute jaoks timeout\u2019i. Samuti saate anda k\u00e4su no way, mis \u2026, kui te ei saa kohe lukku. Seega on kas lock timeout v\u00f5i midagi muud, mis lubab teil seda teha. Seda ei tehta s\u00fcntaktilisel tasandil. See toimub serveri muutuja tasemel. M\u00f5nikord ei saa seda kasutada.<\/p>\n
<\/p>\n
Kas saate avada 75 slaidi?<\/em> <\/p>\n<\/p>\n
Jah.<\/p>\n
<\/p>\n
<\/p>\n
Ja minu j\u00e4rgmine k\u00fcsimus. Miks ootavad m\u00f5lemad uuendamisprotsessid 703?<\/em><\/p>\n<\/p>\n
See on suurep\u00e4rane k\u00fcsimus. Ma ei saa aru, miks Postgres seda teeb. Kui 703 loodi, oodati 702. Ja kui 704 ja 705 ilmuvad, tundub, et nad ei tea, mida nad ootavad, sest seal pole veel midagi. Postgres teeb seda j\u00e4rgmiste seaduste kohaselt: kui te ei saa lukku, \u00fctleb ta: \"Milleks teid \u00fcldse t\u00f6\u00f6tlema hakata?\" sest te juba ootate kedagi. Seet\u00f5ttu laseme tal lihtsalt \u00f5hku j\u00e4\u00e4da, ta ei uuenda seda \u00fcldse. Aga mis siin juhtus? Niipea kui 702 l\u00f5petas protsessi ja 703 sai oma lukustuse, naasis s\u00fcsteem tagasi. Ja \u00fctles, et n\u00fc\u00fcd on meid kaks, kes ootavad. Laseme neil seej\u00e4rel \u00fcheskoos uuendada. Ja m\u00e4rkime, et m\u00f5lemad ootavad. <\/p>\n
<\/p>\n
Ma ei tea, miks Postgres nii k\u00e4itub. Kuid on probleem, mida nimetatakse f.... Minu arvates ei ole see vene term\u00edn. See juhtub, kui k\u00f5ik ootavad \u00fcht lukku, isegi kui on 20 instantsi, kes ootavad lukku. Ja \u00e4kki nad k\u00f5ik \u00e4rkavad korraga. Ja k\u00f5ik hakkavad \u00fcritama reageerida. Kuid s\u00fcsteem teeb nii, et k\u00f5ik ootavad 703. Kuna nad k\u00f5ik ootavad, paneme nad kohe j\u00e4rjekorda. Ja kui ilmub m\u00f5ni uus p\u00e4ring, mis on tehtud p\u00e4rast seda, n\u00e4iteks 707, siis seal tuleb j\u00e4lle t\u00fchjus. <\/p>\n
<\/p>\n
Ja mulle tundub, et seda tehakse selleks, et saaks \u00f6elda, et sellel hetkel ootab 702 703, ja k\u00f5ik, kes tulevad p\u00e4rast seda, ei saa mingit kirjet selles v\u00e4ljas. Kuid 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, et saaksime j\u00e4rjest t\u00f6\u00f6delda, et nad oleksid \u00f5igesti j\u00e4rjekorras. <\/p>\n
<\/p>\n
Olen alati vaadanud seda kui \u00fcsna kummalist n\u00e4htust. Sest siin, n\u00e4iteks, me ei loetle neid \u00fcldse. Kuid mulle tundub, et iga kord, kui anname uue lukustuse, vaatame k\u00f5iki neid, kes ootamisprotsessis on. Siis joondame nad k\u00f5ik j\u00e4rjekorda. Ja siis p\u00e4\u00e4seb iga uus, kes saabub, j\u00e4rjekorda alles siis, kui j\u00e4rgmine inimene on l\u00f5petanud. V\u00e4ga hea k\u00fcsimus. Ait\u00e4h teile k\u00fcsimuse eest!<\/p>\n
<\/p>\n
Mulle tundub, et on palju loogilisem, kui 705 ootab 704.<\/em> <\/p>\n<\/p>\n
Kuid probleem on j\u00e4rgmine. Tehniliselt saate \u00e4ratada kas seda v\u00f5i seda. Ja seet\u00f5ttu \u00e4ratame kas \u00fche v\u00f5i teise. Aga mis toimub s\u00fcsteemi t\u00f6\u00f6s? N\u00e4ete, kuidas 703 \u00fclal blokeeris oma tehingu ID. See on see, kuidas Postgres t\u00f6\u00f6tab. Ja 703 on blokeeritud oma tehingu ID t\u00f5ttu, seega, kui keegi tahab oodata, siis ta ootab 703. Ja p\u00f5him\u00f5tteliselt l\u00f5petab 703. Ja alles p\u00e4rast selle l\u00f5petamist \u00e4ratatakse m\u00f5ni protsess. Me ei tea, milline t\u00e4pselt see protsess olema saab. Seej\u00e4rel t\u00f6\u00f6tleme j\u00e4rk-j\u00e4rgult k\u00f5ik. Kuid pole selge, milline protsess esimesena \u00e4ratatakse, sest see v\u00f5ib olla \u00fcksk\u00f5ik milline neist protsessidest. P\u00f5him\u00f5tteliselt oli meil ajakava, mis \u00fctles, et me v\u00f5ime n\u00fc\u00fcd \u00e4ratada \u00fcksk\u00f5ik millise neist protsessidest. Me valime lihtsalt \u00fche juhuslikult. Seet\u00f5ttu tuleb m\u00f5lemad m\u00e4rgistada, sest me v\u00f5ime \u00e4ratada \u00fcksk\u00f5ik millise neist. <\/p>\n
<\/p>\n
Probleem on selles, et meil on CP-l\u00f5pmatus. Seet\u00f5ttu on \u00fcsna t\u00f5en\u00e4oline, et saame \u00e4ratada hilisema. Ja kui me n\u00e4iteks \u00e4ratame hilisema, siis me ootame seda, kes just sai lukustuse. Seet\u00f5ttu me ei m\u00e4\u00e4ra, kes esimesena \u00e4ratatakse. Loome lihtsalt sellise olukorra ja s\u00fcsteem \u00e4ratab neid juhuslikus j\u00e4rjekorras. <\/p>\n
<\/p>\n
On Egor Rogovi lukustusartiklid<\/a><\/noindex>. Vaadake, need on samuti huvitavad ja kasulikud. Teema on muidugi ulme keeruline. Suur t\u00e4nu, 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
![\"Postgres](\"\/wp-content\/uploads\/2020\/07\/1f75fbb0cb41c306c33c823ef55f7238.png\")
<\/p>\n