Trawsgrifiad o sgwrs Bruce Momjian yn 2020 "Datgloi Rheolwr Clo Postgres".
(Sylwer: Gallwch gael pob ymholiad SQL o'r sleidiau yn y ddolen hon: )
Helo! Mae'n wych bod yma yn Rwsia eto. Mae'n ddrwg gen i na allwn i ddod y llynedd, ond eleni mae gan Ivan a minnau gynlluniau mawr. Rwy'n gobeithio bod yma yn llawer amlach. Rwyf wrth fy modd yn dod i Rwsia. Byddaf yn ymweld â Tyumen, Tver. Rwy’n falch iawn y byddaf yn gallu ymweld â’r dinasoedd hyn.
Fy enw i yw Bruce Momjian. Rwy'n gweithio yn EnterpriseDB ac wedi bod yn gweithio gyda Postgres ers dros 23 mlynedd. Rwy'n byw yn Philadelphia, UDA. Rwy'n teithio tua 90 diwrnod y flwyddyn. Ac rwy'n mynychu tua 40 o gynadleddau. Fy , sy'n cynnwys y sleidiau y byddaf yn eu dangos i chi nawr. Felly, ar ôl y gynhadledd, gallwch eu llwytho i lawr o fy safle personol. Mae hefyd yn cynnwys tua 30 o gyflwyniadau. Ac mae yna hefyd fideos a nifer fawr o gofnodion blog, mwy na 500. Mae hwn yn adnodd eithaf addysgiadol. Ac os oes gennych ddiddordeb yn y deunydd hwn, yna fe'ch gwahoddaf i'w ddefnyddio.
Roeddwn i'n arfer bod yn athrawes, yn athro cyn i mi ddechrau gweithio gyda Postgres. Ac rwy'n falch iawn fy mod nawr yn gallu dweud wrthych chi beth rydw i'n mynd i'w ddweud wrthych chi. Dyma un o fy nghyflwyniadau mwyaf diddorol. Ac mae'r cyflwyniad hwn yn cynnwys 110 o sleidiau. Byddwn yn dechrau siarad â phethau syml, ac erbyn diwedd yr adroddiad bydd yn dod yn fwy a mwy cymhleth, a bydd yn dod yn eithaf cymhleth.
Mae hon yn sgwrs braidd yn annymunol. Nid blocio yw'r pwnc mwyaf poblogaidd. Rydyn ni am iddo ddiflannu yn rhywle. Mae fel mynd at y deintydd.
- Mae cloi yn broblem i lawer o bobl sy'n gweithio ar gronfeydd data ac sydd â phrosesau lluosog yn rhedeg ar yr un pryd. Mae angen eu blocio. Hynny yw, heddiw byddaf yn rhoi gwybodaeth sylfaenol i chi am rwystro.
- IDau trafodion. Mae hyn yn rhan braidd yn ddiflas o'r cyflwyniad, ond mae angen eu deall.
- Nesaf, byddwn yn siarad am y mathau o rwystro. Mae'n rhan eithaf mecanyddol.
- Ac yna byddwn yn rhoi rhai enghreifftiau o rwystro. A bydd yn eithaf anodd ei ddeall.
Gadewch i ni siarad am rwystro.
Mae ein terminoleg yn eithaf cymhleth. Faint ohonoch chi sy'n gwybod o ble mae'r darn hwn yn dod? Dau berson. Mae'n dod o gêm o'r enw Colossal Cave Adventure. Roedd hi’n gêm gyfrifiadurol yn seiliedig ar destun yn yr 80au, dwi’n meddwl. Yno bu'n rhaid mynd i'r ogof, i'r labyrinth a newidiodd y testun, ond roedd y cynnwys tua'r un peth bob tro. Dyna sut dwi'n cofio'r gêm yma.
Ac yma gwelwn enw'r cloeon a ddaeth atom o Oracle. Rydyn ni'n eu defnyddio.
Yma gwelwn dermau sy'n fy nrysu. Er enghraifft, RHANNWCH Y DIWEDDARAF ECXLUSIVE. Nesaf RHANNU ECXLUSIVE RAW. A dweud y gwir, nid yw'r enwau hyn yn glir iawn. Byddwn yn ceisio eu hystyried yn fwy manwl. Mae rhai yn cynnwys y gair "rhannu", sy'n golygu gwahanu. Mae rhai yn cynnwys y gair "exclusive" - unigryw. Mae rhai yn cynnwys y ddau air hyn. Hoffwn ddechrau gyda sut mae'r cloeon hyn yn gweithio.
Ac mae’r gair “mynediad” hefyd yn bwysig iawn. Ac mae'r geiriau "rhes" - llinell. Hynny yw, dosbarthiad mynediad, dosbarthiad rhes.
Problem arall y mae angen ei deall yn Postgres, na fyddaf yn anffodus yn gallu ymdrin â hi yn fy sgwrs, yw MVCC. Mae gennyf gyflwyniad ar wahân ar y pwnc hwn ar fy ngwefan. Ac os ydych chi'n meddwl bod y cyflwyniad hwn yn anodd, yna mae'n debyg mai MVCC yw fy un anoddaf. Ac os oes gennych ddiddordeb, gallwch ei weld ar y wefan. Gallwch wylio'r fideo.
Peth arall y mae angen i ni ei ddeall yw IDau trafodion. Ni all llawer o drafodion weithio heb ddynodwyr unigryw. Ac yma mae gennym esboniad o beth yw trafodiad. Mae gan Postgres ddwy system rhifo trafodion. Rwy'n gwybod nad yw'n ateb pert iawn.
Cofiwch hefyd y bydd y sleidiau'n eithaf anodd eu darllen, felly yr hyn sydd wedi'i amlygu mewn coch yw'r hyn y mae angen i chi roi sylw iddo.
Edrychwn. Mae rhif y trafodiad wedi'i amlygu mewn coch. Yma mae'r ffwythiant pg_back SELECT. Mae'n dychwelyd fy nhrafodion ac ID y trafodiad hwnnw.
Un peth arall, os ydych chi'n hoffi'r cyflwyniad hwn ac eisiau ei redeg yn eich cronfa ddata, yna gallwch chi ddilyn y ddolen hon wedi'i hamlygu mewn pinc a lawrlwytho'r SQL ar gyfer y cyflwyniad hwn. A gallwch chi ei redeg yn eich PSQL a bydd y cyflwyniad cyfan ar eich sgrin mewn dim o amser. Ni fydd yn cynnwys blodau, ond o leiaf gallwn ei weld.
Yn yr achos hwn, gwelwn ID y trafodiad. Dyma'r rhif y gwnaethom ei neilltuo iddi. Ac mae math arall o ID trafodiad yn Postgres o'r enw ID trafodiad rhithwir
Ac mae'n rhaid i ni ddeall hyn. Mae hyn yn bwysig iawn, fel arall ni fyddwn yn gallu deall cloi yn Postgres.
Mae ID trafodiad rhithwir yn ID trafodiad nad yw'n cynnwys gwerthoedd cyson. Er enghraifft, os ydw i'n rhedeg gorchymyn SELECT, yna mae'n debyg na fyddaf yn newid y gronfa ddata, ni fyddaf yn cloi unrhyw beth. Felly pan fyddwn yn rhedeg SELECT syml, nid ydym yn rhoi ID parhaol i'r trafodiad hwnnw. Dim ond rhith ID rydyn ni'n ei roi yno.
Ac mae hyn yn gwella perfformiad Postgres, yn gwella'r gallu i lanhau, felly mae'r ID trafodiad rhithwir yn cynnwys dau rif. Y rhif cyntaf cyn y slaes yw'r ID backend. Ac ar y dde dim ond cownter a welwn.
Felly, os byddaf yn rhedeg cais, mae'n dweud mai'r ID ôl-wyneb yw 2.
Ac os byddaf yn rhedeg cyfres o drafodion o'r fath, yna gwelwn fod y cownter yn cynyddu bob tro y byddaf yn rhedeg yr ymholiad. Er enghraifft, pan fyddaf yn rhedeg ymholiad 2/10, 2/11, 2/12 ac ati.
Cofiwch fod dwy golofn yma. Ar y chwith, gwelwn yr ID trafodiad rhithwir - 2/12. Ac ar y dde mae gennym ID trafodiad parhaol. Ac mae'r maes hwn yn wag. Ac nid yw'r trafodiad hwn yn addasu'r gronfa ddata. Felly, nid wyf yn neilltuo ID trafodiad parhaol iddo.
Cyn gynted ag y byddaf yn rhedeg y gorchymyn dadansoddi ((DADANSODDIAD)), mae'r un ymholiad yn rhoi ID trafodiad parhaol i mi. Gweld sut rydyn ni wedi newid. Yn flaenorol, nid oedd yr ID hwn gennyf, nawr mae gennyf.
Felly dyma gais arall, trafodiad arall. Rhif y trafodiad rhithwir yw 2/13. Ac os gofynnaf am ID trafodiad parhaol, yna pan fyddaf yn rhedeg y cais, byddaf yn ei gael.
Felly, un tro arall. Mae gennym ID trafodiad rhithwir ac ID trafodiad parhaol. Cymerwch y pwynt hwn i ddeall ymddygiad Postgres.
Symudwn ymlaen at y drydedd adran. Yma byddwn yn cerdded trwy'r gwahanol fathau o gloeon yn Postgres. Nid yw'n ddiddorol iawn. Bydd yr adran olaf yn llawer mwy diddorol. Ond mae'n rhaid i ni ystyried y pethau sylfaenol, oherwydd fel arall ni fyddwn yn deall beth fydd yn digwydd nesaf.
Byddwn yn mynd trwy'r adran hon, byddwn yn edrych ar bob math o flocio. A byddaf yn dangos enghreifftiau i chi o sut maen nhw'n cael eu gosod, sut maen nhw'n gweithio, yn dangos rhai ymholiadau i chi y gallwch chi eu defnyddio i weld sut mae blocio yn gweithio yn Postgres.
I greu ymholiad a gweld beth sy'n digwydd yn Postgres, mae angen i ni gyhoeddi'r ymholiad i'r olwg system. Yn yr achos hwn, mae pg_lock wedi'i amlygu mewn coch. Mae pg_lock yn dabl system sy'n dweud wrthym pa gloeon sy'n cael eu defnyddio ar hyn o bryd yn Postgres.
Fodd bynnag, mae'n anodd iawn i mi ddangos pg_lock i chi ar ei ben ei hun, oherwydd mae'n eithaf cymhleth. Felly creais olygfa sy'n dangos pg_locks. Ac mae hefyd yn gwneud rhywfaint o waith i mi sy'n fy ngalluogi i ddeall yn well. Hynny yw, nid yw'n cynnwys fy cloeon, fy sesiwn fy hun, ac ati. SQL safonol ydyw ac mae'n caniatáu ichi ddangos yn well beth sy'n digwydd.
Problem arall yw bod y farn hon yn eang iawn, felly mae'n rhaid i mi greu ail un - lockview2.
Ac mae'n dangos mwy o golofnau i mi o'r tabl. Ac un arall sy'n dangos gweddill y colofnau i mi. Mae hyn yn eithaf cymhleth, felly ceisiais ei gyflwyno mor syml â phosibl.
Felly, rydym wedi creu tabl o'r enw Lockdemo. Ac fe wnaethon ni greu un llinell yno. Dyma ein tabl sampl. A byddwn yn creu adrannau dim ond i ddangos enghreifftiau o flocio i chi.
Felly, un rhes, un golofn. Yr enw ar y math cyntaf o glo yw CYFRAN MYNEDIAD. Dyma'r blocio lleiaf cyfyngol. Mae hyn yn golygu nad yw bron yn gwrthdaro â chloeon eraill.
Ac os ydym am ddiffinio clo yn benodol, rydym yn rhedeg y gorchymyn "tabl clo". A bydd yn rhwystro'n benodol, h.y. yn y modd MYNEDIAD RHANNU, rydym yn rhedeg y bwrdd clo. Ac os byddaf yn dechrau PSQL yn y cefndir, yna rwy'n dechrau'r ail sesiwn o fy sesiwn gyntaf fel hyn. Hynny yw, beth fyddaf yn ei wneud yma? Rwy'n mynd i sesiwn arall ac yn dweud wrtho i "dangos y lockview ar gyfer y cais hwn i mi". Ac yma mae gen i AccessShareLock ar y bwrdd hwn. Dyma'r union beth y gofynnais amdano. Ac mae'n dweud bod y clo wedi'i neilltuo. Syml iawn.
Ymhellach, os edrychwn ar yr ail golofn, yna nid oes dim yno. Maen nhw'n wag.
Ac os ydw i'n rhedeg y gorchymyn "SELECT", yna dyma'r ffordd ymhlyg (eglur) i ofyn am AccessShareLock. Felly rwy'n rhyddhau fy nhabl ac yn rhedeg ymholiad ac mae'r ymholiad yn dychwelyd rhesi lluosog. Ac yn un o'r llinellau gwelwn AccessShareLock. Felly mae SELECT yn galw AccessShareLock ar y bwrdd. Ac nid yw'n gwrthdaro â bron unrhyw beth, oherwydd mae'n glo lefel isel.
Beth os ydw i'n rhedeg SELECT a bod gen i dri bwrdd gwahanol? Yn flaenorol, dim ond un bwrdd oeddwn i'n ei redeg, nawr rydw i'n rhedeg tri: pg_class, pg_namespace a pg_attribute.
Ac yn awr pan fyddaf yn edrych ar yr ymholiad rwy'n gweld 9 AccessShareLocks mewn XNUMX thabl. Pam? Mae tri thabl wedi'u hamlygu mewn glas: pg_attribute, pg_class, pg_namespace. Ond gallwch hefyd weld bod gan bob mynegai sy'n cael ei ddiffinio trwy'r tablau hyn AccessShareLock hefyd.
Ac mae hwn yn flocio nad yw'n gwrthdaro ag eraill yn ymarferol. A'r cyfan y mae'n ei wneud yw ein cadw rhag gollwng y bwrdd wrth i ni ei ddewis. Mae'n gwneud synnwyr. Hynny yw, os byddwn yn dewis tabl, mae'n diflannu ar y foment honno, yna mae hyn yn anghywir, felly Clo lefel isel yw AccessShare sy'n dweud wrthym "peidiwch â dileu'r tabl hwn tra byddaf yn gweithio". Yn y bôn, dyna'r cyfan mae hi'n ei wneud.
RHANNWCH ROW - Mae'r clo hwn ychydig yn wahanol.
Gadewch i ni gymryd enghraifft. DEWIS RHES RHANNWCH ffordd i gloi pob rhes yn unigol. Fel hyn ni all neb eu dileu na'u newid tra ein bod ni'n eu gwylio.
Felly, beth mae SHARE LOCK yn ei wneud? Gwelwn mai ID y trafodiad yw 681 ar gyfer y SELECT. Ac mae'n ddiddorol. Beth ddigwyddodd yma? Am y tro cyntaf rydym yn gweld y rhif yn y maes "Lock". Rydyn ni'n cymryd ID y trafodiad, ac mae'n dweud ei fod yn ei rwystro yn y modd unigryw. Y cyfan y mae'n ei wneud yw dweud bod gen i res sydd wedi'i chloi'n dechnegol rhywle yn y bwrdd. Ond nid yw'n dweud ble yn union. Byddwn yn edrych ar hyn yn fanylach ychydig yn ddiweddarach.
Yma rydym yn dweud bod y clo yn cael ei ddefnyddio gennym ni.
Felly, mae clo unigryw yn benodol (yn benodol) yn dweud ei fod yn gyfyngedig. A hefyd os ydych chi'n dileu rhes yn y tabl hwn, dyna sy'n digwydd, fel y gwelwch.
Mae SHARE EXCLUSIVE yn glo hirach.
Dyma (DADANSODDIAD) y gorchymyn dadansoddwr i'w ddefnyddio.
RHANNWCH LOCK - Gallwch chi gloi yn y modd rhannu yn benodol.
Gallwch hefyd greu mynegai unigryw. Ac yno gallwch weld SHARE LOCK, sy'n rhan ohonyn nhw. Ac mae'n cloi'r bwrdd ac yn gosod clo SHARE LOCK arno.
Mae'r rhagosodiad RHANNU LOCK ar fwrdd yn golygu y gall pobl eraill ddarllen y tabl, ond ni all neb ei addasu. A dyna'n union beth sy'n digwydd pan fyddwch chi'n creu mynegai unigryw.
Os byddaf yn creu mynegai cydamserol unigryw, yna bydd gennyf fath gwahanol o glo, oherwydd, cofiwch, mae defnyddio mynegeion ar yr un pryd yn lleihau'r gofyniad clo. Ac os byddaf yn defnyddio clo arferol, mynegai arferol, yna rwy'n atal ysgrifennu at fynegai'r tabl yn ystod ei greu. Os byddaf yn defnyddio mynegai cydamserol, yna mae angen i mi ddefnyddio math gwahanol o glo.
RHANNWCH RHES YN UNIGRYW - eto, gellir ei osod yn benodol (yn benodol).
Neu gallwn greu rheol, hynny yw, cymryd rhyw achos penodol y bydd yn cael ei ddefnyddio.
Mae clo EXCLUSIVE yn golygu na all neb arall newid y bwrdd.
Yma rydym yn gweld gwahanol fathau o gloeon.
Mae MYNEDIAD EXCLUSIVE, er enghraifft, yn orchymyn clo. Er enghraifft, os gwnewch CLUSTER table, yna bydd yn golygu na fydd neb yn gallu ysgrifennu yno. Ac mae'n cloi nid yn unig y bwrdd ei hun, ond y mynegeion hefyd.
Dyma ail dudalen y clo MYNEDIAD EXCLUSIVE lle gwelwn yn benodol yr hyn y mae'n ei gloi yn y tabl. Mae'n cloi rhesi bwrdd unigol, sy'n ddigon diddorol.
Dyna'r holl wybodaeth sylfaenol roeddwn i eisiau ei rhoi. Buom yn siarad am gloeon, am IDau trafodion, buom yn siarad am IDau trafodion rhithwir, am IDau trafodion parhaol.
Ac yn awr byddwn yn mynd drwy'r enghreifftiau blocio. Dyma'r rhan fwyaf diddorol. Cawn weld achosion diddorol iawn. A fy nod yn y cyflwyniad hwn yw rhoi gwell syniad i chi o'r hyn y mae Postgres yn ei wneud mewn gwirionedd pan fydd yn ceisio rhwystro pethau. Mae'n ymddangos i mi ei fod yn dda iawn am rwystro rhannau unigol.
Edrychwn ar rai enghreifftiau penodol.
Byddwn yn dechrau gyda byrddau ac un rhes fesul bwrdd. Pan fyddaf yn mewnosod rhywbeth, rwy'n cael ExclusiveLock, Transaction ID ac ExclusiveLock ar y bwrdd.
Beth fydd yn digwydd os byddaf yn mewnosod dwy res arall? Ac yn awr mae gan ein bwrdd dair rhes. Ac fe fewnosodais un rhes a chael hwn fel allbwn. Ac os ydw i'n mewnosod dwy res arall, beth sy'n rhyfedd yma? Mae rhyfeddod yma oherwydd fy mod wedi ychwanegu tair rhes at y tabl hwn, ond mae gennyf ddwy res yn y bwrdd clo o hyd. A dyma, mewn gwirionedd, ymddygiad sylfaenol Postgres.
Mae llawer o bobl yn meddwl, os ydych chi mewn cronfa ddata, yn cloi 100 rhes, yna bydd angen i chi greu 100 o gofnodion clo. Os byddaf yn blocio 1 o resi ar unwaith, yna bydd angen 000 o geisiadau o'r fath arnaf. Ac os oes angen miliwn neu biliwn arnaf i rwystro. Ond os gwnawn hyn, ni fydd yn gweithio'n dda iawn. Os ydych wedi defnyddio system sy'n creu cofnodion blocio ar gyfer pob rhes unigol, yna gallwch weld bod hyn yn gymhleth. Oherwydd bod angen i chi ddiffinio'r bwrdd clo ar unwaith, a all orlifo, ond nid yw Postgres yn gwneud hynny.
Ac mae'n bwysig iawn ar y sleid hon ei fod yn dangos yn glir bod yna system arall sy'n gweithio y tu mewn i MVCC sy'n blocio llinellau unigol. Felly pan fyddwch chi'n cloi biliynau o resi, nid yw Postgres yn creu biliwn o gyfarwyddiadau cloi ar wahân. Ac mae hyn yn dda iawn ar gyfer perfformiad.
Beth am ddiweddariad? Rwy'n diweddaru'r gyfres nawr a gallwch weld ei bod wedi gwneud dwy weithred wahanol ar unwaith. Roedd yn cloi'r bwrdd ar yr un pryd, ond roedd hefyd yn cloi'r mynegai. Ac roedd angen iddo gloi'r mynegai oherwydd bod cyfyngiadau unigryw ar y bwrdd hwnnw. Ac rydyn ni eisiau sicrhau nad oes neb yn ei newid, felly rydyn ni'n ei rwystro.
Beth sy'n digwydd os ydw i am ddiweddaru dwy res? A gwelwn ei fod yn ymddwyn yr un ffordd. Rydyn ni'n gwneud dwywaith cymaint o ddiweddariadau, ond yn union yr un nifer o linellau blocio.
Os ydych chi'n pendroni sut mae Postgres yn gwneud hyn, dylech wrando ar fy sgyrsiau MVCC i ddarganfod sut mae Postgres yn nodi'r llinellau hyn y mae'n eu newid yn fewnol. Ac mae gan Postgres ffordd o'i wneud, ond nid yw'n ei wneud ar lefel cloi'r bwrdd, mae'n ei wneud ar lefel is a mwy effeithlon.
Beth os ydw i eisiau dileu rhywbeth? Os byddaf yn dileu, er enghraifft, un rhes ac mae gennyf fy nau fewnbwn wrth y clo o hyd, a hyd yn oed os wyf am eu dileu i gyd, maent yn dal i fod yno.
Ac, er enghraifft, rwyf am fewnosod 1 o linellau, ac yna naill ai dileu neu ychwanegu 000 o linellau, yna'r llinellau unigol yr wyf yn eu hychwanegu neu'n eu newid, nid ydynt yn cael eu cofnodi yma. Maent wedi'u hysgrifennu ar lefel is o fewn y rhes ei hun. Ac yn ystod sgwrs yr MVCC, siaradais amdano’n fanwl. Ond mae'n bwysig iawn pan fyddwch chi'n dadansoddi cloeon i wneud yn siŵr bod gennych chi glo ar lefel bwrdd ac na allwch chi weld sut mae rhesi unigol yn cael eu hysgrifennu yma.
Beth am rwystro penodol?
Os byddaf yn clicio "adnewyddu" yna mae gennyf ddwy res wedi'u cloi. Ac os byddaf yn eu dewis i gyd ac yn clicio "diweddaru ym mhobman", yna mae gennyf ddau gofnod clo o hyd.
Nid ydym yn creu cofnodion ar wahân ar gyfer pob rhes unigol. Oherwydd bod perfformiad wedyn yn gostwng, efallai y bydd gormod ohono. Ac efallai y cawn ein hunain mewn sefyllfa annymunol.
A'r un peth, os ydym yn rhannu, gallwn wneud popeth 30 gwaith.
Rydym yn adfer ein bwrdd, yn dileu popeth, yna mewnosod un rhes eto.
Math arall o ymddygiad a welwch yn Postgres sy'n ymddygiad adnabyddus a dymunol iawn yw y gallwch chi wneud diweddariad neu ddetholiad. A gallwch chi ei wneud ar yr un pryd. Ac nid yw dewis yn rhwystro diweddariad a'r un peth i'r cyfeiriad arall. Rydyn ni'n dweud wrth y darllenydd am beidio â rhwystro'r awdur, ac nid yw'r awdur wedi rhwystro'r darllenydd.
Byddaf yn dangos enghraifft o hyn i chi. Byddaf yn gwneud dewis yn awr. Yna byddwn yn gwneud MEWNOSOD. Ac yna gallwch weld - 694. Gallwch weld ID y trafodiad a wnaeth y mewnosodiad hwn. A dyma sut mae'n gweithio.
Ac os edrychaf yn awr ar fy ID ôl-wyneb, mae wedi dod yn - 695.
A gallaf weld bod 695 yn ymddangos yn fy nhabl.
Ac os byddaf yn diweddaru yma fel hyn, yna byddaf yn cael achos gwahanol. Yn yr achos hwn, mae 695 yn glo unigryw, ac mae gan y diweddariad yr un ymddygiad, ond nid oes gwrthdaro rhyngddynt, sy'n eithaf anarferol.
A gallwch sylwi bod ShareLock ar y brig ac ar y gwaelod mae ExclusiveLock. A llwyddodd y ddau drafodiad.
Ac mae angen i chi wrando ar fy sgwrs yn MVCC i ddeall sut mae hyn yn digwydd. Ond mae hyn yn enghraifft o'r ffaith y gallwch chi ei wneud ar yr un pryd, h.y. DEWISWCH a DIWEDDARIAD ar yr un pryd.
Gadewch i ni ailosod a gwneud un llawdriniaeth eto.
Os ceisiwch redeg dau ddiweddariad ar yr un pryd ar yr un rhes, bydd yn rhwystro. A chofiwch, dywedais nad y darllenydd sy'n rhwystro'r llenor, ond awdur y darllenydd, ond mae un awdur yn blocio llenor arall. Hynny yw, ni allwn gael dau berson i ddiweddaru'r un rhes ar yr un pryd. Mae'n rhaid i chi aros nes bod un ohonyn nhw wedi gorffen.
Ac er mwyn darlunio hyn, edrychaf ar fwrdd Lockdemo. A byddwn yn edrych ar un rhes. Ar gyfer trafodiad 698.
Rydym wedi ei uwchraddio i 2. 699 yw'r diweddariad cyntaf. Ac roedd yn llwyddiannus neu mae mewn trafodiad ar y gweill yn aros i ni ymrwymo neu ganslo.
Ond edrychwch ar rywbeth arall - 2/51 yw ein trafodiad cyntaf, ein sesiwn gyntaf. 3/112 yw'r ail gais a ddaeth o'r brig a newid y gwerth hwnnw i 3. Ac os sylwch, mae'r un uchaf wedi cloi ei hun, sef 699. Ond ni roddodd 3/112 glo. Mae'r golofn Lock_mode yn dweud ei fod yn aros. Mae'n disgwyl 699. Ac os edrychwch lle mae 699, mae'n uwch. A beth wnaeth y sesiwn gyntaf? Creodd glo unigryw ar ei ID trafodiad ei hun. Dyma sut mae Postgres yn ei wneud. Mae'n blocio ei ID trafodiad ei hun. Ac os ydych chi am aros i rywun ymrwymo neu ganslo, yna mae'n rhaid i chi aros tra bod trafodiad yn yr arfaeth. Ac felly gallwn weld llinell ryfedd.
Gadewch i ni edrych eto. Ar y chwith gwelwn ein ID prosesu. Yn yr ail golofn gwelwn ein ID trafodiad rhithwir, ac yn y drydedd fe welwn y lock_type. Beth mae hyn yn ei olygu? Mewn gwirionedd, mae hi'n dweud ei bod hi'n blocio ID y trafodiad. Ond sylwch fod yn yr holl resi ar y gwaelod yn ysgrifenedig perthynas. Ac felly mae gennych ddau fath o gloeon ar y bwrdd. Mae clo perthynas. A hefyd mae clo trafodiad lle rydych chi'n cloi ar ein pennau ein hunain, dyna'n union beth sy'n digwydd ar y rhes gyntaf neu ar y gwaelod iawn lle mae'r trafodiad lle rydyn ni'n disgwyl i 699 orffen ei weithrediad.
Rwy'n gweld beth sy'n digwydd yma. Ac yma mae dau beth yn digwydd ar yr un pryd. Rydych chi'n edrych ar y clo ID trafodiad yn y rhes gyntaf, sy'n cloi ei hun. Ac mae hi'n blocio ei hun i gadw pobl i aros.
Os edrychwch ar y 6ed llinell, dyma'r un cofnod â'r gyntaf. Ac felly mae trafodiad 699 wedi'i rwystro. Mae 700 hefyd yn cloi ei hun. Ac yna yn y rhes waelod fe welwch ein bod yn aros i 699 gwblhau ei weithrediad.
Ac yn lock_type, tuple byddwch yn gweld rhifau.
Gallwch weld ei fod yn 0/10. A dyna rif y dudalen, a hefyd gwrthbwyso'r rhes benodol honno.
Ac rydych chi'n gweld beth sy'n dod yn 0/11 pan fyddwn yn diweddaru.
Ond mewn gwirionedd, mae'n 0/10, oherwydd mae disgwyliad ar gyfer y llawdriniaeth hon. Mae gennym gyfle i weld mai dyma’r ffrae yr wyf yn aros i’w chadarnhau.
Ar ôl i ni ei gadarnhau a phwyso ar ymrwymo, a phan fydd y diweddariad wedi'i orffen, dyma a gawn eto. Trafodyn 700 yw'r unig glo, nid yw'n aros am unrhyw un arall, oherwydd ei fod wedi ymrwymo. Mae'n aros i'r trafodiad gael ei gwblhau. Unwaith y bydd 699 yn dod i ben, nid ydym yn aros am unrhyw beth arall. Ac yn awr mae trafodiad 700 yn dweud bod popeth yn iawn, bod ganddo'r holl gloeon sydd eu hangen arno ym mhob bwrdd a ganiateir.
Ac i gymhlethu'r holl beth ymhellach, rydym yn creu safbwynt arall, a fydd y tro hwn yn rhoi hierarchaeth inni. Nid wyf yn disgwyl ichi ddeall y cais hwn. Ond bydd yn rhoi darlun cliriach inni o'r hyn sy'n digwydd.
Mae hon yn olwg ailadroddus sydd ag un adran arall hefyd. Ac yna mae'n dod â phopeth yn ôl at ei gilydd eto. Gadewch i ni ddefnyddio hyn.
Beth os byddwn yn gwneud tri diweddariad ar yr un pryd ac yn dweud bod y rhes bellach yn dri. A byddwn yn newid 3 i 4.
A dyma ni'n gweld 4. Ac ID trafodiad 702.
Ac yna byddaf yn cyfnewid 4 am 5. A 5 am 6, a 6 am 7. Ac rwy'n trefnu nifer o bobl i aros i'r un trafodiad hwn gael ei gwblhau.
Ac mae popeth yn dod yn glir. Beth yw'r rhes gyntaf? Dyma 702. Dyma'r ID trafodiad a osododd y gwerth hwn yn wreiddiol. Beth sydd gennyf yn y golofn Caniatáu? Mae gen i farciau f. Dyma fy diweddariadau na ellir eu cymeradwyo (5, 6, 7) oherwydd ein bod yn aros i ID trafodiad 702 ddod i ben. Yno mae gennym glo ID trafodion. Ac mae'n troi allan 5 trafodiad cloeon ID.
Ac os edrychwch ar 704, ar 705, nid oes dim wedi'i ysgrifennu yno eto, oherwydd ni wyddant beth sy'n digwydd eto. Maen nhw'n ysgrifennu nad oes ganddyn nhw unrhyw syniad beth sy'n digwydd. A byddan nhw jest yn mynd i gysgu, achos maen nhw'n aros i rywun orffen a byddan nhw'n cael eu deffro pan fydd hi'n bosib newid y rhes.
Dyma sut mae'n edrych. Mae’n amlwg eu bod i gyd yn aros am y 12fed llinell.
Dyma beth a welsom yma. Dyma 0/12.
Felly, unwaith y bydd y trafodiad cyntaf wedi'i gymeradwyo, gallwch weld sut mae'r hierarchaeth yn gweithio yma. Ac yn awr mae'r cyfan yn glir. Maent i gyd yn dod yn lân. Ac maent mewn gwirionedd yn dal i aros.
Dyma beth sy'n digwydd. 702 wedi ymrwymo. Ac yn awr mae 703 yn cael y clo rhes hwn, ac yna mae 704 yn dechrau aros i 703 ymrwymo. Ac mae'r 705 hefyd yn aros am hyn. A phan fydd hyn i gyd wedi'i gwblhau, maen nhw'n glanhau eu hunain. A hoffwn dynnu sylw at y ffaith bod pawb yn cyd-fynd. Ac mae'n debyg iawn i'r sefyllfa tagfeydd traffig lle mae pawb yn aros am y car cyntaf. Mae'r car cyntaf wedi stopio ac mae pawb yn sefyll mewn llinell hir. Yna mae'n symud, yna gall y car nesaf ddod ymlaen a chael ei bloc, ac ati.
Ac os yw'n ymddangos i chi nad yw'n ddigon anodd, yna byddwn yn awr yn siarad â chi am ddatgloi. Wn i ddim pa un ohonoch sydd wedi eu profi. Mae hon yn broblem eithaf cyffredin mewn systemau cronfa ddata. Ond methiannau llwyr yw pan fydd un sesiwn yn aros am sesiwn arall i wneud rhywbeth. Ac ar yr eiliad honno mae sesiwn arall yn aros am y sesiwn gyntaf i wneud rhywbeth.
Ac, er enghraifft, os dywed Ivan: “Rhowch rywbeth i mi,” a dywedaf: “Na, ni fyddaf ond yn ei roi i chi os byddwch yn rhoi rhywbeth arall i mi.” Ac mae'n dweud, "Na, ni fyddaf yn ei roi i chi os na fyddwch yn ei roi i mi." Ac rydym yn y pen draw mewn sefyllfa cloi. Rwy'n siŵr na fydd Ivan yn gwneud hynny, ond rydych chi'n cael y pwynt bod gennym ni ddau o bobl eisiau rhywbeth ac nad ydyn nhw'n barod i'w roi i ffwrdd nes bod y person arall yn rhoi'r hyn maen nhw ei eisiau iddyn nhw. Ac nid oes ateb.
Ac, mewn gwirionedd, mae angen i'ch cronfa ddata ganfod hyn. Ac yna mae angen i chi ddileu neu gau un o'r sesiynau, oherwydd fel arall byddant yn aros yno am byth. Ac rydym yn ei weld mewn cronfeydd data, rydym yn ei weld mewn systemau gweithredu. Ac ym mhob man lle mae gennym ni brosesau cyfochrog, gall hyn ddigwydd.
A byddwn yn rhoi dau deadlocks yn awr. Byddwn yn rhoi 50 a 80. Yn y rhes gyntaf, byddaf yn diweddaru o 50 i 50. Byddaf yn cael rhif trafodiad 710.
Ac yna byddaf yn newid 80 i 81, a 50 i 51.
A dyma sut olwg fydd arno. Ac felly mae gan 710 glo rhes, ac mae 711 yn aros am gadarnhad. Fe'i gwelsom pan wnaethom ddiweddaru. 710 - yw perchennog ein cyfres. Ac mae 711 yn aros am 710 i gwblhau'r trafodiad.
Ac mae hyd yn oed yn dweud ar ba res y mae gennym ni derfynau amser. A dyma lle mae'n dechrau mynd yn rhyfedd.
Nawr rydyn ni'n diweddaru 80 i 80.
A dyna lle mae'r terfynau amser yn dechrau. Mae 710 yn aros am ymateb gan 711, a 711 yn aros am 710. Ac ni fydd hynny'n dod i ben yn dda. Ac nid oes unrhyw ffordd allan o hyn. A byddan nhw'n disgwyl ymateb gan ei gilydd.
Ac mae'n dechrau oedi popeth. Ac nid ydym am hynny.
Ac mae gan Postgres ffyrdd o sylwi pan fydd hyn yn digwydd. A phan fydd hynny'n digwydd, fe gewch y gwall hwn. Ac o hyn mae'n amlwg bod proses o'r fath ac o'r fath yn aros am SHARE LOCK o broses arall, h.y., sy'n cael ei rhwystro gan y broses 711. Ac roedd y broses honno'n aros i SHARE LOCK gael ei roi i ID trafodiad o'r fath ac o'r fath a chael ei rwystro gan broses o'r fath. Felly, mae yna sefyllfa o rwystro marw.
A oes yna gloeon trwodd tair ffordd? A yw'n bosibl? Oes.
Rydyn ni'n gyrru'r niferoedd hyn i'r tabl. Rydyn ni'n newid 40 i 40, rydyn ni'n gwneud clo.
Newid 60 i 61, 80 i 81.
Ac yna rydym yn newid 80 ac yna ffyniant!
Ac mae 714 bellach yn aros am 715. Mae 716 yn aros am 715. A does dim byd i'w wneud am y peth.
Nid oes dau berson bellach, mae tri o bobl eisoes. Dw i eisiau rhywbeth gennych chi, mae hwn eisiau rhywbeth gan y trydydd person, ac mae'r trydydd person eisiau rhywbeth gen i. Ac rydyn ni'n gorfod aros tair ffordd oherwydd rydyn ni i gyd yn aros i'r person arall gwblhau'r hyn sy'n rhaid iddyn nhw ei wneud.
Ac mae Postgres yn gwybod ar ba res y mae'n digwydd. Ac felly bydd yn rhoi'r neges ganlynol i chi sy'n dangos bod gennych broblem lle mae'r tri mewnbwn yn rhwystro ei gilydd. Ac nid oes unrhyw gyfyngiadau. Gall hyn fod yn wir pan fydd 20 cofnod yn rhwystro ei gilydd.
Mae'r rhifyn nesaf yn gyfresol.
Os clo cyfresol arbennig.
A dychwelwn i 719. Mae ganddo fater cwbl arferol.
A gallwch chi wthio i wneud trafodiad o serializable.
Ac rydych chi'n deall bod gennych chi bellach fath gwahanol o flocio SA - mae hyn yn golygu cyfresol.
Ac felly mae gennym ni fath newydd o glo o'r enw SARieadLock, sy'n glo cyfresol ac yn caniatáu ichi nodi rhifau cyfresol.
A hefyd gallwch chi fewnosod mynegeion unigryw.
Yn y tabl hwn mae gennym fynegeion unigryw.
Felly os ydw i'n rhoi'r rhif 2 i mewn yma, dyna pam mae gen i 2. Ond ar y brig, rydw i'n rhoi 2 arall i mewn. A gallwch chi weld bod gan y 721 glo unigryw. Ond nawr mae 722 yn aros i 721 gwblhau ei weithrediad oherwydd ni all fewnosod 2 nes ei fod yn gwybod beth fydd yn digwydd i 721.
Ac os ydym yn gwneud subtransaction.
Yma mae gennym 723.
Ac os ydym yn arbed y pwynt ac yna'n ei ddiweddaru, yna byddwn yn cael ID trafodaethol newydd. Mae hwn yn ymddygiad arall y mae angen i chi fod yn ymwybodol ohono. Os byddwn yn dychwelyd hwnnw, yna mae'r ID trafodiad wedi diflannu. Mae 724 yn gadael. Ond nawr mae gennym ni 725.
A beth ydw i'n ceisio ei wneud yma? Rwy'n ceisio dangos enghreifftiau i chi o gloeon anarferol y gallwch ddod o hyd iddynt: boed yn gloeon cyfresol neu'n gloeon SAVEPOINT, mae'r rhain yn wahanol fathau o gloeon a fydd yn ymddangos yn y bwrdd clo.
Mae hyn yn creu cloeon amlwg (eglur), sydd â pg_advisory_lock.
A gallwch weld bod y math clo wedi'i restru yma fel cynghorol. Ac yma mae'n dweud “cynghorol” mewn coch. A gallwch chi rwystro gyda pg_advisory_unlock ar yr un pryd.
Ac i gloi, hoffwn ddangos un peth arall syfrdanol i chi. Byddaf yn creu golygfa arall. Ond byddaf yn ymuno â'r tabl pg_locks gyda'r tabl pg_stat_activity. A pham ydw i eisiau gwneud hyn? Oherwydd bydd yn caniatáu i mi edrych a gweld yr holl sesiynau cyfredol a gweld pa fath o gloeon maen nhw'n aros amdanynt. Ac mae'n ddigon diddorol pan rydyn ni'n rhoi bwrdd clo a bwrdd ymholiadau at ei gilydd.
A dyma ni'n creu pg_stat_view.
Ac rydym yn diweddaru'r rhes fesul un. A dyma ni'n gweld 724. Ac yna rydyn ni'n diweddaru ein rhes i dri. A beth welwch chi yma nawr? Ceisiadau yw'r rhain, h.y. rydych chi'n gweld y rhestr gyfan o geisiadau sydd wedi'u rhestru yn y golofn chwith. Ac yna ar yr ochr dde gallwch weld cloeon a beth maent yn ei greu. A gall fod yn fwy dealladwy i chi fel nad oes rhaid i chi fynd yn ôl i bob sesiwn bob tro i weld a oes angen i chi ymuno â hi ai peidio. Maen nhw'n ei wneud i ni.
Nodwedd arall sy'n ddefnyddiol iawn yw pg_blocking_pids. Mae'n debyg na chlywsoch chi erioed amdani. Beth mae hi'n gwneud? Mae'n caniatáu i ni ddweud hynny ar gyfer y sesiwn hon 11740 pa IDau proses y mae'n aros amdanynt. A gallwch weld bod 11740 yn disgwyl 724. Ac mae 724 ar y brig. A 11306 yw eich ID proses. Yn y bôn, mae'r swyddogaeth hon yn mynd dros eich bwrdd clo. Ac rwy'n gwybod ei fod ychydig yn gymhleth, ond rydych chi'n cael y syniad. Yn y bôn, mae'r swyddogaeth hon yn mynd trwy'r bwrdd clo hwn ac yn ceisio darganfod ble mae'r ID proses hwn, o ystyried y cloeon y mae'n aros amdanynt. Ac mae hefyd yn ceisio darganfod pa ID proses sydd gan y broses sy'n aros am y clo. Felly gallwch chi redeg y swyddogaeth hon pg_blocking_pids.
Ac mae hyn yn ddefnyddiol iawn. Dim ond ers fersiwn 9.6 rydyn ni wedi ychwanegu hwn, felly dim ond 5 oed yw'r nodwedd hon, ond mae'n ddefnyddiol iawn, iawn. Ac mae'r un peth yn wir am yr ail gais. Mae’n dangos yn union beth sydd angen i ni ei weld.
Dyma beth roeddwn i eisiau siarad â chi amdano. Ac fel roeddwn i'n disgwyl, fe wnaethon ni ddefnyddio ein holl amser oherwydd bod cymaint o sleidiau. Ac mae'r sleidiau ar gael i'w lawrlwytho. Hoffwn ddiolch i chi am fod yma. Rwy’n siŵr y byddwch yn mwynhau gweddill y gynhadledd, diolch yn fawr iawn!
Cwestiynau:
Er enghraifft, os ceisiaf ddiweddaru'r rhesi, a bod yr ail sesiwn yn ceisio dileu'r tabl cyfan. Hyd y deallaf, dylai fod rhywbeth fel clo bwriad. A oes y fath beth yn Postgres?
Dychwelwn i'r cychwyn cyntaf. Efallai y byddwch yn cofio pan fyddwch chi'n gwneud unrhyw beth, fel pan fyddwch chi'n gwneud SELECT, rydyn ni'n cyhoeddi AccessShareLock. Ac mae'n atal y bwrdd rhag cael ei ollwng. Felly os ydych chi, er enghraifft, eisiau diweddaru rhes mewn tabl neu ddileu rhes, yna ni all rhywun ddileu'r tabl cyfan ar yr un pryd, oherwydd eich bod yn dal yr AccessShareLock hwn dros y bwrdd cyfan a thros y rhes. Ac ar ôl i chi orffen, gallant gael gwared arno. Ond cyn belled â'ch bod yn newid rhywbeth yn uniongyrchol yno, ni fyddant yn gallu ei wneud.
Gadewch i ni ei wneud eto. Gadewch i ni symud ymlaen at yr enghraifft dileu. Ac rydych chi'n gweld sut mae gan y rhes glo unigryw dros y bwrdd cyfan.
Bydd yn edrych fel clo unigryw, iawn?
Ydy, mae'n edrych fel ei fod. Yr wyf yn deall yr hyn yr ydych yn sôn amdano. A ydych chi'n dweud, os ydw i'n gwneud SELECT yna mae gen i ShareExclusive ac yna rydw i'n ei roi mewn cyflwr Row Exclusive, a yw hynny'n dod yn broblem? Ond yn syndod nid yw hyn yn achosi problem. Mae fel cynyddu gradd y clo, ond yn y bôn mae gen i glo sy'n ei atal rhag cael ei ddileu. Ac yn awr, pan fyddaf yn gwneud y clo hwn yn fwy pwerus, mae'n dal i atal dileu. Felly nid yw fel fy mod yn mynd i fyny. H.y. roedd yn ei atal pan oedd ar lefel is hefyd, felly pan fyddaf yn ei ddyrchafu, mae'n dal i atal y bwrdd rhag cael ei ollwng.
Yr wyf yn deall yr hyn yr ydych yn sôn amdano. Nid oes unrhyw achos o gynyddu maint y blocio, lle rydych chi'n ceisio rhoi'r gorau i un bloc er mwyn cyflwyno un mwy pwerus. Yma mae'n cynyddu'r osgoi hwn ym mhobman, felly nid yw'n achosi unrhyw wrthdaro. Ond mae'n gwestiwn da. Diolch yn fawr iawn am ofyn!
Beth sydd angen i ni ei wneud er mwyn osgoi sefyllfa cloi pan fydd gennym lawer o sesiynau, nifer fawr o ddefnyddwyr?
Mae Postgres yn sylwi ar sefyllfaoedd cloi yn awtomatig. A bydd yn dileu un o'r sesiynau yn awtomatig. Yr unig ffordd i osgoi sefyllfa ddiddatrys yw rhwystro pobl yn yr un drefn. Felly pan fyddwch chi'n edrych ar eich cais, mae'n aml yn achosi terfynau amser... Gadewch i ni ddweud fy mod am rwystro dau beth gwahanol. Mae un cymhwysiad yn cloi tabl 1 a chymhwysiad arall yn cloi tabl 2 ac yna tabl 1. A'r ffordd hawsaf o osgoi cloi yw edrych ar eich cais a cheisio sicrhau bod y clo yn digwydd yn yr un drefn ym mhob cais. Ac mae hyn fel arfer yn dileu 80% o'r problemau, oherwydd bod pob math o bobl yn ysgrifennu'r ceisiadau hyn. Ac os ydych chi'n eu blocio yn yr un drefn, yna nid ydych chi'n rhedeg i mewn i sefyllfa cloi.
Diolch yn fawr iawn am eich perfformiad! Soniasoch am dan wactod ac, os deallaf yn iawn, mae ystofau llawn gwactod yn atal trefn cofnodion mewn storfa ar wahân, felly mae'n cadw'r cofnodion cyfredol heb eu newid. Pam mae gwactod llawn yn cymryd mynediad clo unigryw a pham mae'n gwrthdaro â gweithrediadau ysgrifennu?
Dyna gwestiwn da. Y rheswm yw bod gwactod llawn yn cymryd bwrdd. Ac rydym yn ei hanfod yn creu fersiwn newydd o'r tabl. A bydd y bwrdd yn newydd. Mae'n troi allan y bydd yn fersiwn hollol newydd o'r tabl. A'r broblem yw pan fyddwn yn gwneud hynny, nid ydym am i bobl ei ddarllen oherwydd rydym am iddynt weld y tabl newydd. Ac felly mae hyn yn cyd-fynd â'r cwestiwn blaenorol. Pe gallem ddarllen ar yr un pryd, yna ni fyddem yn gallu ei symud a chyfeirio pobl at fwrdd newydd. Byddai'n rhaid aros i bawb orffen darllen y tabl hwn, ac felly, yn ei hanfod, mae hon yn sefyllfa ddi-glo.
Rydyn ni'n dweud ein bod ni'n cloi o'r cychwyn cyntaf oherwydd rydyn ni'n gwybod y bydd angen clo unigryw arnom o'r diwedd er mwyn symud pawb i'r copi newydd. Felly mae'n bosibl y gallwn ei ddatrys. A dyma sut rydyn ni'n ei wneud gyda mynegeio ar yr un pryd. Ond mae hyn yn llawer anoddach i'w wneud. Ac mae hyn yn berthnasol iawn i'ch cwestiwn blaenorol am glo yn unig.
A yw'n bosibl ychwanegu terfyn amser cloi yn Postgres? Yn Oracle, gallaf, er enghraifft, ysgrifennu "dewis diweddaru" ac aros 50 eiliad cyn diweddaru. Roedd yn dda ar gyfer y cais. Ond yn Postgres, mae angen i mi naill ai wneud hyn ar unwaith a pheidio ag aros o gwbl, neu aros am beth amser.
Gallwch, gallwch ddewis amseru eich cloeon, eich cloeon. Gallwch hefyd gyhoeddi'r gorchymyn dim ffordd, a fydd yn ... os na allwch chi gael y clo ar unwaith. Felly, naill ai cloi terfyn amser, neu rywbeth arall a fydd yn caniatáu ichi wneud hyn. Ni wneir hyn ar y lefel gystrawen. Gwneir hyn fel newidyn ar y gweinydd. Weithiau ni ellir ei ddefnyddio.
Allwch chi agor sleid 75?
Ydw.
Ac mae fy nghwestiwn nesaf. Pam mae'r ddwy broses ddiweddaru yn aros am 703?
Ac mae hynny'n gwestiwn gwych. Dydw i ddim yn deall pam fod Postgres yn gwneud hyn, gyda llaw. Ond pan grëwyd 703, roedd yn aros am 702. A phan fydd 704 a 705 yn ymddangos, nid yw'n ymddangos eu bod yn gwybod beth maen nhw'n aros amdano, oherwydd nid oes dim byd yno eto. Ac mae Postgres yn ei wneud fel hyn: pan na allwch chi gael clo, mae'n dweud "Beth yw pwynt prosesu chi?", Oherwydd eich bod eisoes yn aros am rywun. Felly gadewch iddo hongian yn yr awyr, nid yw'n ei ddiweddaru o gwbl. Ond beth ddigwyddodd yma? Cyn gynted ag y cwblhaodd 702 y broses a derbyniodd 703 ei glo, dychwelodd y system yn ôl. A dywedodd fod gennym ni ddau o bobl nawr sy'n aros. Ac yna gadewch i ni eu diweddaru gyda'n gilydd. A nodwch fod disgwyl y ddau.
Wn i ddim pam mae Postgres yn gwneud hyn. Ond mae yna broblem o’r enw f …. Ymddengys i mi nad yw hwn yn derm yn Rwsieg. Dyma pryd mae pawb yn aros am un castell, hyd yn oed os oes 20 achos yn aros am y castell. Ac yn sydyn maen nhw i gyd yn deffro ar yr un pryd. Ac mae pawb yn dechrau ceisio ymateb. Ond mae'r system yn ei gwneud hi fel bod pawb yn aros am 703. Oherwydd eu bod i gyd yn aros, a byddwn yn eu gosod i gyd ar unwaith. Ac os bydd unrhyw gais newydd arall yn ymddangos a ffurfiwyd ar ôl hynny, er enghraifft, 707, yna bydd gwagle eto.
Ac ymddengys i mi fod hyn yn cael ei wneud er mwyn gallu dweud bod 702 ar hyn o bryd yn aros am 703, a phawb a ddaw ar ôl hynny, ni fydd ganddynt unrhyw fynediad yn y maes hwn. Ond cyn gynted ag y bydd y gweinydd cyntaf yn gadael, a phawb a oedd yn aros ar y foment honno cyn y diweddariad, yn derbyn yr un tocyn. Ac felly mae'n ymddangos i mi fod hyn yn cael ei wneud fel y gallwn brosesu mewn trefn, fel eu bod yn cael eu harchebu'n iawn.
Roeddwn bob amser yn edrych arno fel ffenomen eithaf rhyfedd. Oherwydd yma, er enghraifft, nid ydynt wedi'u rhestru o gwbl. Ond, mae'n ymddangos i mi, bob tro rydyn ni'n rhoi clo newydd, rydyn ni'n edrych ar bawb sydd yn y broses o aros. Yna rydyn ni'n eu gosod mewn llinell i gyd. Ac yna mae unrhyw un newydd sy'n dod i mewn yn cael ei giwio dim ond pan fydd y person nesaf wedi gorffen prosesu. Cwestiwn da iawn. Diolch yn fawr iawn am eich cwestiwn!
Mae'n ymddangos i mi yn llawer mwy rhesymegol pan fydd 705 yn disgwyl 704.
Ond y broblem yma yw'r canlynol. Yn dechnegol, gallwch chi ddeffro naill ai un neu'r llall. Ac felly rydyn ni'n deffro'r naill neu'r llall. Ond beth sy'n digwydd yng ngweithrediad y system? Gallwch weld sut mae 703 ar y brig wedi rhwystro ei ID trafodiad ei hun. Dyma sut mae Postgres yn gweithio. Ac mae 703 yn cael ei rwystro gan ei ID trafodiad ei hun, felly os yw rhywun eisiau aros, yna bydd yn aros am 703. Ac, mewn gwirionedd, mae 703 yn cwblhau. A dim ond ar ôl ei gwblhau, mae un o'r prosesau yn deffro. Ac nid ydym yn gwybod pa fath o broses fydd hi. Yna rydym yn prosesu popeth yn raddol. Ond nid yw'n glir pa broses sy'n deffro gyntaf, oherwydd gallai fod yn unrhyw un o'r prosesau hyn. Yn y bôn, roedd gennym amserlennydd a ddywedodd y gallem nawr ddeffro unrhyw un o'r prosesau hyn. Rydyn ni'n dewis un ar hap. Felly, dylid nodi'r ddau ohonynt, oherwydd gallwn ddeffro unrhyw un ohonynt.
A'r broblem yw bod gennym ni CP-anfeidredd. Ac felly, mae’n bur debyg y gallwn ddeffro’r un diweddarach. Ac os, er enghraifft, byddwn yn deffro yn ddiweddarach, yna byddwn yn aros am yr un sydd newydd dderbyn y clo, felly nid ydym yn penderfynu pwy yn union fydd yn cael ei ddeffro yn gyntaf. Rydym yn creu sefyllfa o'r fath yn unig, a bydd y system yn eu deffro ar hap.
Mae . Edrychwch, maen nhw hefyd yn ddiddorol ac yn ddefnyddiol. Mae'r pwnc, wrth gwrs, yn hynod gymhleth. Diolch yn fawr Bruce!
Ffynhonnell: hab.com