Postgres Lock Manager ကိုသော့ဖွင့်ခြင်း။ Bruce Momjian

Bruce Momjian ၏ 2020 ဟောပြောချက် "Postgres Lock Manager ကိုသော့ဖွင့်ခြင်း" ၏ စာသားမှတ်တမ်း။

(မှတ်ချက်- ဆလိုက်များမှ SQL queries အားလုံးကို ဤလင့်ခ်မှ ရယူနိုင်ပါသည်။ http://momjian.us/main/writings/pgsql/locking.sql)

မင်္ဂလာပါ! ရုရှားမှာ ထပ်နေရတာ အရမ်းကောင်းပါတယ်။ မနှစ်က မလာနိုင်ခဲ့လို့ တောင်းပန်ပါတယ်၊ ဒါပေမယ့် ဒီနှစ်မှာတော့ အိုင်ဗန်နဲ့ ကျွန်တော့်မှာ အစီအစဉ် ကြီးကြီးမားမားရှိတယ်။ ဒီထက် အများကြီး ပိုကြာကြာနေဖို့ မျှော်လင့်ပါတယ်။ ရုရှားကို လာရတာ ကြိုက်တယ်။ Tyumen၊ Tver ကိုသွားမယ်။ ဒီမြို့တွေကို လည်ပတ်ခွင့်ရလို့ အရမ်းဝမ်းသာပါတယ်။

ကျွန်တော့်နာမည် Bruce Momjian ပါ။ ကျွန်ုပ်သည် EnterpriseDB တွင်အလုပ်လုပ်ပြီး Postgres နှင့် 23 နှစ်ကျော်အလုပ်လုပ်ခဲ့သည်။ အမေရိကန်ပြည်ထောင်စု၊ Philadelphia မှာ နေထိုင်ပါတယ်။ ကျွန်တော် တစ်နှစ်ကို ရက် ၉၀ လောက် ခရီးသွားတယ်။ ပြီးတော့ ညီလာခံ ၄၀ လောက်တက်တယ်။ ငါ့ ဝဘ်ဆိုက်ယခုငါပြသမည့် slides များပါရှိသည်။ ထို့ကြောင့် ညီလာခံအပြီးတွင် ကျွန်ုပ်၏ကိုယ်ပိုင်ဝဘ်ဆိုဒ်မှ ၎င်းတို့ကို ဒေါင်းလုဒ်ဆွဲနိုင်ပါသည်။ ၎င်းတွင်တင်ဆက်မှု 30 ခန့်ပါ ၀ င်သည်။ ဗီဒီယိုများနှင့် ဘလော့ဂ်ထည့်သွင်းမှု အရေအတွက် 500 ကျော်လည်း ရှိပါသည်။ ၎င်းသည် မျှမျှတတ သတင်းအချက်အလက်ပေးသည့် အရင်းအမြစ်တစ်ခုဖြစ်သည်။ ဒီပစ္စည်းကို စိတ်ဝင်စားတယ်ဆိုရင်တော့ သုံးကြည့်ဖို့ ဖိတ်ခေါ်ပါတယ်။

Postgres နဲ့ အလုပ်မစခင် ဆရာ၊ ပါမောက္ခဖြစ်ဖူးတယ်။ ပြီးတော့ ငါမင်းကို အခုပြောပြမယ့်အရာကို ပြောပြနိုင်လို့ အရမ်းဝမ်းသာတယ်။ ဒါက ကျွန်တော့်ရဲ့ စိတ်ဝင်စားစရာ အကောင်းဆုံးတင်ဆက်မှုတွေထဲက တစ်ခုပါ။ ဤတင်ပြချက်တွင် ဆလိုက် 110 ပါရှိသည်။ ကျွန်ုပ်တို့သည် ရိုးရှင်းသောအရာများဖြင့် စတင်ပြောဆိုမည်ဖြစ်ပြီး အဆုံးတွင် အစီရင်ခံစာသည် ပို၍ပို၍ ရှုပ်ထွေးလာမည်ဖြစ်ပြီး၊ အလွန်ရှုပ်ထွေးလာပါမည်။

ဤသည်မှာ အဆင်မပြေသော စကားဝိုင်းတစ်ခုဖြစ်သည်။ Blocking သည် လူကြိုက်အများဆုံး အကြောင်းအရာမဟုတ်ပါ။ ဒါကို တစ်နေရာရာမှာ ပျောက်စေချင်တယ်။ သွားဆရာဝန်ဆီသွားသလိုပါပဲ။

1. လော့ခ်ချခြင်းသည် ဒေတာဘေ့စ်များတွင် အလုပ်လုပ်ပြီး တစ်ချိန်တည်းတွင် လုပ်ငန်းစဉ်များစွာ လုပ်ဆောင်နေသူများစွာအတွက် ပြဿနာတစ်ခုဖြစ်သည်။ ပိတ်ဆို့ဖို့ လိုတယ်။ ဆိုလိုသည်မှာ၊ ယနေ့ငါသည်သင်တို့ကိုပိတ်ဆို့ခြင်းဆိုင်ရာအခြေခံအသိပညာပေးမည်။
2. ငွေပေးငွေယူ ID များ ဤသည်မှာ တင်ပြမှု၏ ပျင်းစရာကောင်းသော အပိုင်းဖြစ်သော်လည်း နားလည်ရန် လိုအပ်သည်။
3. ပိတ်ဆို့ခြင်းအမျိုးအစားများအကြောင်း ဆက်လက်ဆွေးနွေးပါမည်။ ဒါက အတော်လေး စက်ပိုင်းဆိုင်ရာ အပိုင်းပါ။
4. အောက်တွင် ကျွန်ုပ်တို့သည် ပိတ်ဆို့ခြင်းဆိုင်ရာ ဥပမာအချို့ကို ပေးပါမည်။ နားလည်ရခက်ပါလိမ့်မယ်။

ပိတ်ဆို့ခြင်းအကြောင်း ပြောကြရအောင်။

ကျွန်တော်တို့ရဲ့ အသုံးအနှုန်းက တော်တော်ရှုပ်ထွေးပါတယ်။ ဒီကျမ်းပိုဒ်က ဘယ်ကလာတယ်ဆိုတာ မင်းဘယ်နှစ်ယောက်သိလဲ။ လူနှစ်ယောက်။ ၎င်းသည် Colossal Cave Adventure ဂိမ်းမှဖြစ်သည်။ အဲဒါက 80s တုန်းက text-based computer game လို့ ကျွန်တော်ထင်ပါတယ်။ အဲဒီ့မှာ သင်ဟာ ဂူတစ်ခု၊ ဝင်္ကပါထဲကို ဝင်ရမှာ ဖြစ်ပြီး စာသားက ပြောင်းသွားပေမယ့် အကြောင်းအရာကတော့ အချိန်တိုင်းနီးပါး အတူတူပါပဲ။ ဒီလိုနဲ့ ဒီဂိမ်းကို ကျွန်တော် မှတ်မိတယ်။

ပြီးတော့ Oracle က ငါတို့ဆီရောက်လာတဲ့ သော့ခလောက်တွေရဲ့ နာမည်ကို ဒီမှာ တွေ့တယ်။ အဲဒါတွေကို သုံးတယ်။

ဤတွင် ကျွန်ုပ်အား စိတ်ရှုပ်ထွေးစေသော အသုံးအနှုန်းများကို ကျွန်ုပ်တို့တွေ့မြင်ရသည်။ ဥပမာအားဖြင့်၊ SHARE UPDATE ECXLUSIVE။ နောက်တစ်ခုကတော့ RAW ECXLUSIVE ကို SHARE လိုက်ပါ။ ရိုးရိုးသားသားပြောရရင် ဒီနာမည်တွေက သိပ်မရှင်းဘူး။ ၎င်းတို့ကို အသေးစိတ်ထည့်သွင်းစဉ်းစားရန် ကျွန်ုပ်တို့ ကြိုးစားပါမည်။ အချို့သော စကားလုံးများတွင် ခွဲဝေရန် ဟူသော အဓိပ္ပါယ်ရှိသည်။ အချို့မှာ “သီးသန့်” ဟူသော စကားလုံးပါရှိသည်။ အချို့သော စကားလုံး နှစ်ခုလုံး ပါဝင်ပါသည်။ ဤသော့ခလောက်များ အလုပ်လုပ်ပုံဖြင့် စတင်လိုပါသည်။

“ဝင်ရောက်ခွင့်” ဟူသော စကားလုံးသည်လည်း အလွန်အရေးကြီးပါသည်။ ပြီးတော့ "အတန်း" ဟူသော စကားလုံးများသည် စာကြောင်းတစ်ခုဖြစ်သည်။ အဲဒါကတော့ access distribution၊ row distribution ဖြစ်ပါတယ်။

ကျွန်ုပ်၏ဟောပြောချက်တွင် ကံမကောင်းစွာဖြင့် မဖော်ပြနိုင်သည့် Postgres တွင် နားလည်ထားရမည့် နောက်ထပ်ပြဿနာတစ်ခုမှာ MVCC ဖြစ်သည်။ ကျွန်ုပ်၏ဝဘ်ဆိုဒ်တွင် ဤအကြောင်းအရာနှင့် ပတ်သက်၍ သီးခြားတင်ပြချက်တစ်ခုရှိသည်။ ဒီတင်ပြချက်က ခက်တယ်လို့ မင်းထင်ရင် MVCC က ငါ့အတွက် အခက်ဆုံးဖြစ်နိုင်ပါတယ်။ စိတ်ဝင်စားရင် website မှာကြည့်လို့ရပါတယ်။ ဗီဒီယိုကို ကြည့်ရှုနိုင်ပါတယ်။

နောက်ထပ်နားလည်ရန် လိုအပ်သည်မှာ ငွေပေးငွေယူ ID များဖြစ်သည်။ ငွေပေးငွေယူ အများအပြားသည် သီးသန့်ခွဲခြားသတ်မှတ်မှုများမရှိဘဲ အလုပ်မဖြစ်နိုင်ပါ။ ဤတွင် ကျွန်ုပ်တို့တွင် ငွေပေးငွေယူတစ်ခု၏ ရှင်းလင်းချက်တစ်ခုရှိသည်။ Postgres တွင် ငွေပေးငွေယူ နံပါတ်စနစ် နှစ်ခုရှိသည်။ ဒါက သိပ်လှတဲ့ ဖြေရှင်းချက်မဟုတ်ဘူးဆိုတာ ငါသိတယ်။

ဆလိုက်များသည် နားလည်ရန်အတော်လေးခက်ခဲမည်ကို သတိပြုပါ၊ ထို့ကြောင့် အနီရောင်ဖြင့် မီးမောင်းထိုးပြထားသည့်အရာသည် သင်သတိထားရမည့်အရာဖြစ်သည်။

http://momjian.us/main/writings/pgsql/locking.sql

ကြည့်ကျတာပေါ့။ ငွေပေးငွေယူနံပါတ်ကို အနီရောင်ဖြင့် မီးမောင်းထိုးပြထားသည်။ SELECT pg_back လုပ်ဆောင်ချက်ကို ဤနေရာတွင် ပြထားသည်။ ၎င်းသည် ကျွန်ုပ်၏ ငွေပေးငွေယူနှင့် ငွေပေးငွေယူ ID ကို ပြန်ပေးသည်။

နောက်ထပ်တစ်ချက်၊ သင်သည် ဤတင်ဆက်မှုကို နှစ်သက်ပြီး သင့်ဒေတာဘေ့စ်တွင် ၎င်းကို အသုံးပြုလိုပါက ပန်းရောင်ဖြင့် ဤလင့်ခ်သို့သွား၍ ဤတင်ဆက်မှုအတွက် SQL ကို ဒေါင်းလုဒ်လုပ်နိုင်ပါသည်။ သင်၏ PSQL တွင် ၎င်းကို ရိုးရိုးရှင်းရှင်း လုပ်ဆောင်နိုင်ပြီး တင်ပြမှုတစ်ခုလုံးသည် သင့်ဖန်သားပြင်ပေါ်တွင် ချက်ချင်းရောက်ရှိမည်ဖြစ်သည်။ ပန်းတွေမပါဝင်ပေမယ့် အနည်းဆုံးတော့ ငါတို့မြင်နိုင်ပါတယ်။

ဤကိစ္စတွင်ကျွန်ုပ်တို့သည်ငွေပေးငွေယူ ID ကိုတွေ့မြင်ရသည်။ ဒါက ကျွန်တော်တို့ သူ့ကို ပေးခဲ့တဲ့ နံပါတ်ပါ။ ထို့အပြင် Postgres တွင် virtual transaction ID ဟုခေါ်သော အခြားသော ငွေပေးငွေယူ ID အမျိုးအစားတစ်ခုရှိပါသည်။

ဒါကို ငါတို့နားလည်ရမယ်။ ဤအရာသည် အလွန်အရေးကြီးပါသည်၊ မဟုတ်ပါက Postgres တွင် လော့ခ်ချခြင်းကို ကျွန်ုပ်တို့ နားလည်နိုင်မည်မဟုတ်ပါ။

virtual ငွေပေးငွေယူ ID သည် အမြဲတမ်းတန်ဖိုးများမပါဝင်သည့် ငွေပေးငွေယူ ID တစ်ခုဖြစ်သည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်သည် SELECT အမိန့်ကို အသုံးပြုပါက၊ ကျွန်ုပ်သည် ဒေတာဘေ့စ်ကို ပြောင်းလဲမည်မဟုတ်ပါ၊ ကျွန်ုပ်သည် မည်သည့်အရာကိုမျှ လော့ခ်ချမည်မဟုတ်ပါ။ ထို့ကြောင့် ကျွန်ုပ်တို့သည် ရိုးရှင်းသော SELECT တစ်ခုကို လုပ်ဆောင်သောအခါ၊ ကျွန်ုပ်တို့သည် ထိုငွေပေးငွေယူကို ဆက်တိုက် ID မပေးပါ။ ကျွန်ုပ်တို့သည် ထိုနေရာတွင် သူ့အား virtual ID တစ်ခုသာပေးပါသည်။

၎င်းသည် Postgres စွမ်းဆောင်ရည်ကို ပိုမိုကောင်းမွန်စေပြီး သန့်ရှင်းရေးလုပ်ဆောင်နိုင်စွမ်းကို ပိုမိုကောင်းမွန်စေသည်၊ ထို့ကြောင့် virtual ငွေပေးငွေယူ ID တွင် နံပါတ်နှစ်ခုပါရှိသည်။ မျဥ်းစောင်းမတိုင်မီ ပထမဆုံးနံပါတ်သည် နောက်ခံ ID ဖြစ်သည်။ ညာဘက်မှာ ကောင်တာတစ်ခုပဲတွေ့တယ်။

ထို့ကြောင့်၊ ကျွန်ုပ်တောင်းဆိုမှုတစ်ခုလုပ်ဆောင်ပါက၊ backend ID သည် 2 ဟုဖော်ပြထားသည်။

ကျွန်ုပ်သည် ထိုသို့သော ငွေပေးငွေယူများကို ဆက်တိုက်လုပ်ဆောင်ပါက၊ မေးမြန်းမှုပြုလုပ်တိုင်း ကောင်တာတိုးလာသည်ကို ကျွန်ုပ်တို့တွေ့မြင်ရပါသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်သည် မေးခွန်းကို 2/10၊ 2/11၊ 2/12 စသည်ဖြင့် လုပ်ဆောင်သောအခါ၊

ဤနေရာတွင် ကော်လံနှစ်ခုရှိကြောင်း မှတ်သားထားပါ။ ဘယ်ဘက်တွင် virtual ငွေပေးငွေယူ ID - 2/12 ကိုကျွန်ုပ်တို့မြင်ရသည်။ ညာဘက်တွင် ကျွန်ုပ်တို့တွင် အမြဲတမ်း ငွေပေးငွေယူ ID တစ်ခုရှိသည်။ ဤအကွက်သည် ဗလာဖြစ်သည်။ ပြီးတော့ ဒီငွေပေးငွေယူက ဒေတာဘေ့စ်ကို မပြင်ဘူး။ ဒါကြောင့် အမြဲတမ်း ငွေပေးငွေယူ ID မပေးပါဘူး။

ခွဲခြမ်းစိတ်ဖြာမှု ကွန်မန်း ((ANALYZE)) ကို လုပ်ဆောင်ပြီးသည်နှင့် တူညီသော မေးမြန်းချက်သည် ကျွန်ုပ်အား အမြဲတမ်း ငွေပေးငွေယူ ID ကို ပေးပါသည်။ ဒါက ငါတို့အတွက် ဘယ်လိုပြောင်းလဲသွားလဲ ကြည့်လိုက်ပါ။ ငါ့မှာ အရင်က ဒီ ID မရှိပေမယ့် အခု ငါရပြီ။

ဒီတော့ ဒါက နောက်ထပ်တောင်းဆိုချက်တစ်ခု၊ နောက်တစ်ခုက ငွေပေးငွေယူပေါ့။ virtual ငွေပေးငွေယူနံပါတ်သည် 2/13 ဖြစ်သည်။ ဆက်လက်၍ ငွေပေးငွေယူ ID တစ်ခုတောင်းပါက၊ မေးမြန်းမှုကို လုပ်ဆောင်သည့်အခါ ၎င်းကို ရရှိမည်ဖြစ်သည်။

ဒီတော့ နောက်တစ်ကြိမ်။ ကျွန်ုပ်တို့တွင် ပကတိငွေပေးငွေယူ ID နှင့် အမြဲတစေ ငွေပေးငွေယူ ID တစ်ခုရှိသည်။ ဤအချက်ကို နားလည်ရုံဖြင့် Postgres အပြုအမူကို နားလည်ပါ။

တတိယအပိုင်းကို ဆက်သွားပါမယ်။ ဤတွင် ကျွန်ုပ်တို့သည် Postgres ရှိ သော့ခလောက်အမျိုးမျိုးကို ဖြတ်သန်းသွားပါမည်။ သိပ်စိတ်ဝင်စားစရာတော့ မဟုတ်ဘူး။ နောက်ဆုံးအပိုင်းက ပိုစိတ်ဝင်စားဖို့ကောင်းတယ်။ သို့သော် ကျွန်ုပ်တို့သည် အခြေခံအချက်များကို ထည့်သွင်းစဉ်းစားရမည်၊ မဟုတ်ပါက နောက်ဘာဖြစ်လာမည်ကို ကျွန်ုပ်တို့ နားလည်နိုင်မည်မဟုတ်သောကြောင့်ဖြစ်သည်။

ဤအပိုင်းကို ဖြတ်၍ သော့အမျိုးအစားတစ်ခုစီကို ကြည့်ပါမည်။ ၎င်းတို့ကို တပ်ဆင်ပုံ၊ ၎င်းတို့ အလုပ်လုပ်ပုံ နမူနာများကို သင့်အား ငါပြပါမည်။ Postgres တွင် လော့ခ်ချခြင်း အလုပ်လုပ်ပုံကို သင်အသုံးပြုနိုင်သည့် မေးခွန်းအချို့ကို သင့်အား ပြသပါမည်။

မေးခွန်းတစ်ခုဖန်တီးပြီး Postgres တွင်ဖြစ်ပျက်နေသည်ကိုကြည့်ရန်၊ စနစ်မြင်ကွင်းရှိ query ကိုထုတ်ရန်လိုအပ်သည်။ ဤကိစ္စတွင်၊ pg_lock ကို အနီရောင်ဖြင့် မီးမောင်းထိုးပြထားသည်။ Pg_lock သည် Postgres တွင် လက်ရှိအသုံးပြုနေသောသော့ခလောက်များကို ပြောပြသည့် စနစ်ဇယားတစ်ခုဖြစ်သည်။

သို့သော်၊ ၎င်းသည်အတော်လေးရှုပ်ထွေးသောကြောင့် pg_lock ကို သူ့ဘာသာသူပြသရန် ကျွန်ုပ်အတွက် အလွန်ခက်ခဲပါသည်။ ဒါကြောင့် pg_locks ကိုပြသတဲ့ မြင်ကွင်းတစ်ခုကို ငါဖန်တီးခဲ့တယ်။ ပြီးတော့ အဲဒါက ကျွန်မကို ပိုနားလည်နိုင်စေမယ့် အလုပ်တချို့လည်း လုပ်ပေးတယ်။ ဆိုလိုသည်မှာ၊ ၎င်းသည် ကျွန်ုပ်၏သော့ခတ်မှုများ၊ ကျွန်ုပ်၏ကိုယ်ပိုင် session စသည်တို့ကို မပါဝင်ပါ။ ၎င်းသည် စံ SQL မျှသာဖြစ်ပြီး ၎င်းသည် သင့်အား ဖြစ်ပျက်နေသည့်အရာများကို ပိုမိုကောင်းမွန်စွာပြသနိုင်စေပါသည်။

နောက်ပြဿနာတစ်ခုကတော့ ဒီမြင်ကွင်းက အရမ်းကျယ်တဲ့အတွက် ဒုတိယတစ်ခု - lockview2 ကို ဖန်တီးရပါမယ်။

ပြီးတော့ ဇယားထဲက ကော်လံတွေကို ပိုပြတယ်။ နောက်တစ်ခုက ကျန်တဲ့ကော်လံတွေကို ပြပေးတယ်။ ဒါက တော်တော်ရှုပ်ထွေးတာမို့ တတ်နိုင်သမျှ ရိုးရိုးရှင်းရှင်း တင်ပြဖို့ ကြိုးစားခဲ့တယ်။

ဒါကြောင့် Lockdemo လို့ ခေါ်တဲ့ ဇယားတစ်ခုကို ဖန်တီးခဲ့ပါတယ်။ ပြီးတော့ အဲဒီမှာ လိုင်းတစ်ခု ဖန်တီးတယ်။ ဤသည်မှာ ကျွန်ုပ်တို့၏ နမူနာဇယားဖြစ်သည်။ ပြီးတော့ သော့ခလောက်တွေကို နမူနာပြဖို့ အပိုင်းတွေကို ဖန်တီးပေးမှာပါ။

ဒီတော့ တစ်တန်း၊ တစ်ကြောင်း။ ပထမဆုံးသော့ခတ်အမျိုးအစားကို ACCESS SHARE ဟုခေါ်သည်။ ဤသည်မှာ ကန့်သတ်မှုအနည်းဆုံးဖြစ်သည်။ ဆိုလိုသည်မှာ ၎င်းသည် အခြားသော့ခလောက်များနှင့် လက်တွေ့ကျကျ မဆန့်ကျင်ကြောင်း ဆိုလိုသည်။

သော့ခတ်ခြင်းကို ပြတ်သားစွာ သတ်မှတ်လိုပါက၊ ကျွန်ုပ်တို့သည် “သော့ခတ်ဇယား” အမိန့်ကို လုပ်ဆောင်သည်။ ၎င်းသည် သိသာထင်ရှားစွာ ပိတ်ဆို့လိမ့်မည်၊ ဆိုလိုသည်မှာ ACCESS SHARE mode တွင် ကျွန်ုပ်တို့သည် သော့ခတ်ဇယားကို ဖွင့်ပေးပါသည်။ နောက်ခံတွင် PSQL ကို run ပါက၊ ကျွန်ုပ်၏ ပထမ session ကို ဤနည်းဖြင့် ဒုတိယ session ကို စတင်ပါသည်။ အဲဒါ ငါဒီမှာ ဘာလုပ်ရမလဲ။ အခြားစက်ရှင်တစ်ခုကိုသွား၍ "ဤတောင်းဆိုချက်အတွက် လော့ခ်ချခြင်းမြင်ကွင်းကို ပြပါ" ဟုပြောပါ။ ပြီးတော့ ဒီဇယားမှာ AccessShareLock ရှိတယ်။ ဒါကျွန်တော်တောင်းဆိုထားတဲ့အတိုင်းပါပဲ။ ဘလောက်ကို တာဝန်ပေးထားတယ်လို့ သူက ပြောပါတယ်။ အလွန်ရိုးရှင်းပါသည်။

ထို့အပြင် ဒုတိယကော်လံကိုကြည့်လျှင် ထိုနေရာတွင် ဘာမှမရှိပါ။ သူတို့ချည်းပဲ။

အကယ်၍ ကျွန်ုပ်သည် "SELECT" အမိန့်ကို လုပ်ဆောင်ပါက၊ ဤသည်မှာ AccessShareLock တောင်းဆိုရန် သွယ်ဝိုက်သော (ရှင်းလင်းသော) နည်းလမ်းဖြစ်သည်။ ထို့ကြောင့် ကျွန်ုပ်သည် ကျွန်ုပ်၏ဇယားကိုထုတ်ပြီး query ကို run ပြီး query သည် အတန်းများစွာကို ပြန်ပေးပါသည်။ ပြီးတော့ လိုင်းတစ်ခုထဲမှာ AccessShareLock ကိုတွေ့တယ်။ ထို့ကြောင့် SELECT သည် စားပွဲပေါ်ရှိ AccessShareLock ဟုခေါ်သည်။ အဆင့်နိမ့်သော့ခတ်ထားသောကြောင့် ၎င်းသည် မည်သည့်အရာနှင့်မျှ မဆန့်ကျင်ပါ။

SELECT တစ်ခုကို run ပြီး မတူညီသော table သုံးခုရှိလျှင်ကော။ ယခင်က ကျွန်တော်သည် ဇယားတစ်ခုသာ လုပ်ဆောင်ခဲ့သော်လည်း ယခုအခါ pg_class၊ pg_namespace နှင့် pg_attribute သုံးခုကို လုပ်ဆောင်နေပါသည်။

ယခုမေးခွန်းကိုကြည့်သောအခါ ဇယားသုံးကွက်တွင် AccessShareLocks 9 ခုတွေ့သည်။ အဘယ်ကြောင့်? ဇယားသုံးခုကို အပြာရောင်ဖြင့် မီးမောင်းထိုးပြထားသည်- pg_attribute၊ pg_class၊ pg_namespace။ သို့သော် ဤဇယားများမှသတ်မှတ်ထားသော အညွှန်းများအားလုံးတွင် AccessShareLock ပါ၀င်သည်ကို သင်တွေ့မြင်နိုင်သည်။

၎င်းသည် အခြားသူများနှင့် လက်တွေ့ကျကျ မဆန့်ကျင်နိုင်သောသော့တစ်ခုဖြစ်သည်။ ၎င်းသည် ကျွန်ုပ်တို့က ၎င်းကိုရွေးချယ်စဉ်တွင် ဇယားကို ပြန်လည်သတ်မှတ်ခြင်းမှ ကျွန်ုပ်တို့အား တားဆီးနိုင်မည်ဖြစ်သည်။ အဲဒါက အဓိပ္ပာယ်ရှိတယ်။ ဆိုလိုတာက ဇယားတစ်ခုကို ရွေးလိုက်ရင် အဲဒီခဏမှာ ပျောက်သွားတယ်၊ ဒါမှားတယ်။ AccessShare သည် "ကျွန်ုပ်အလုပ်လုပ်နေစဉ် ဤဇယားကို မချပါနှင့်" ဟု ကျွန်ုပ်တို့အား ပြောထားသည့် အဆင့်နိမ့်သောသော့ခတ်မှုတစ်ခုဖြစ်သည်။. တကယ်တန်းတော့ ဒါပဲ သူမလုပ်ဘူး။

ROW SHARE - ဤလော့ခ်သည် အနည်းငယ်ကွဲပြားသည်။

ဥပမာတစ်ခုယူကြည့်ရအောင်။ အတန်းတစ်ခုချင်းစီကို လော့ခ်ချခြင်းနည်းလမ်းကို SELECT ROW SHARE လုပ်ပါ။. ဤနည်းဖြင့် ၎င်းတို့ကို ကျွန်ုပ်တို့ကြည့်ရှုနေချိန်တွင် မည်သူမျှ ၎င်းတို့ကို ဖျက်နိုင်သည် သို့မဟုတ် ပြောင်းလဲနိုင်မည်မဟုတ်ပေ။

ဒါဆို SHARE LOCK က ဘာလုပ်မလဲ။ ငွေပေးငွေယူ ID သည် SELECT အတွက် 681 ဖြစ်သည်ကို ကျွန်ုပ်တို့တွေ့မြင်ရပါသည်။ ပြီးတော့ ဒါက စိတ်ဝင်စားစရာပါ။ ဒီမှာ ဘာဖြစ်သွားတာလဲ။ နံပါတ်ကို ပထမဆုံးမြင်ရသည့်အချိန်သည် “သော့ခတ်ခြင်း” အကွက်တွင်ဖြစ်သည်။ ကျွန်ုပ်တို့သည် ငွေပေးငွေယူ ID ကိုယူပြီး ၎င်းကို သီးသန့်မုဒ်တွင် ပိတ်ဆို့ထားသည်ဟု ဆိုသည်။ ဒါတွေအားလုံးက စားပွဲရဲ့ တစ်နေရာရာမှာ နည်းပညာအရ သော့ခတ်ထားတဲ့ အတန်းတစ်ခု ရှိတယ် လို့ ပြောပါတယ်။ ဒါပေမယ့် ဘယ်မှာလဲဆိုတာ အတိအကျ မပြောပါဘူး။ ဒါကို နောက်နည်းနည်းကြာမှ အသေးစိတ်ကြည့်ပါမယ်။

ဤနေရာတွင် သော့ကို ကျွန်ုပ်တို့ အသုံးပြုသည်ဟု ဆိုပါသည်။

ဒီတော့ သီးသန့်လော့ခ်က သီးသန့်ဖြစ်တယ်လို့ အတိအလင်းပြောထားတယ်။ ထို့အပြင် ဤဇယားရှိ အတန်းတစ်ခုကို ဖျက်ပါက၊ သင်မြင်သည့်အတိုင်း ဖြစ်လိမ့်မည်။

SHARE EXCLUSIVE သည် ပိုရှည်သောလော့ခ်တစ်ခုဖြစ်သည်။

၎င်းသည် အသုံးပြုမည့် (ANALYZE) Analyzer command ဖြစ်သည်။

SHARE LOCK - မျှဝေခြင်းမုဒ်တွင် ပြတ်သားစွာ လော့ခ်ချနိုင်သည်။

ထူးခြားသောအညွှန်းတစ်ခုကိုလည်း သင်ဖန်တီးနိုင်သည်။ ထိုနေရာတွင် ၎င်းတို့ထဲမှ အစိတ်အပိုင်းဖြစ်သည့် SHARE LOCK ကို တွေ့နိုင်သည်။ ပြီးတော့ စားပွဲကို သော့ခတ်ပြီး SHARE LOCK တစ်ခု တင်လိုက်တယ်။

ပုံသေအားဖြင့်၊ ဇယားတစ်ခုပေါ်ရှိ SHARE LOCK သည် အခြားသူများ ဇယားကိုဖတ်နိုင်သည်ဟု ဆိုလိုသော်လည်း မည်သူမျှ ၎င်းကိုမွမ်းမံနိုင်မည်ဖြစ်သည်။ ထူးခြားသောအညွှန်းတစ်ခုကို သင်ဖန်တီးသောအခါ ၎င်းသည် အတိအကျဖြစ်ပျက်သည်။

အကယ်၍ ကျွန်ုပ်သည် တစ်ပြိုင်နက်တည်း အညွှန်းကိန်းတစ်ခုကို ဖန်တီးပါက၊ သင်သည် မှတ်သားထားသည့်အတိုင်း တစ်ပြိုင်နက်တည်း အညွှန်းကိန်းများကို အသုံးပြုခြင်းဖြင့် လော့ခ်ချမှု လိုအပ်ချက်ကို လျော့နည်းစေသောကြောင့် ကျွန်ုပ်တွင် မတူညီသော လော့ခ်ချခြင်း အမျိုးအစားကို ရရှိမည်ဖြစ်သည်။ သာမာန်လော့ခ်တစ်ခု၊ ပုံမှန်အညွှန်းကိုအသုံးပြုပါက၊ ၎င်းကိုဖန်တီးနေချိန်တွင် ဇယားအညွှန်းသို့ စာရေးခြင်းကို တားဆီးပါမည်။ အကယ်၍ ကျွန်ုပ်သည် တစ်ပြိုင်နက်တည်း အညွှန်းကိန်းကို အသုံးပြုပါက၊ အခြားသော့ခတ်မှု အမျိုးအစားကို အသုံးပြုရန် လိုအပ်ပါသည်။

သီးသန့်အတန်းကို မျှဝေပါ - ၎င်းကို ထပ်မံ၍ ပြတ်သားစွာ (အတိအလင်း) သတ်မှတ်နိုင်ပါသည်။

သို့မဟုတ် ကျွန်ုပ်တို့သည် စည်းမျဉ်းတစ်ခုကို ဖန်တီးနိုင်သည်၊ ဆိုလိုသည်မှာ၊ ၎င်းကိုအသုံးပြုမည့် သီးခြားကိစ္စရပ်တစ်ခုကို ယူနိုင်သည်။

သီးသန့်သော့ခတ်ခြင်းဆိုသည်မှာ အခြားမည်သူမျှ ဇယားကို မပြောင်းလဲနိုင်ဟု ဆိုလိုသည်။

ဤတွင် ကျွန်ုပ်တို့သည် မတူညီသောသော့ခလောက်များကို တွေ့ရပါသည်။

ဥပမာအားဖြင့် ACCESS EXCLUSIVE သည် ပိတ်ဆို့ခြင်းအမိန့်တစ်ခုဖြစ်သည်။ ဥပမာ ပြောရရင် CLUSTER tableဒါဆိုရင် ဘယ်သူမှ အဲဒီနေရာမှာ ရေးနိုင်မှာမဟုတ်ဘူးလို့ ဆိုလိုတာပါ။ ၎င်းသည် ဇယားကိုယ်တိုင်သာမက အညွှန်းများကိုပါ သော့ခတ်ထားသည်။

ဤသည်မှာ ACCESS EXCLUSIVE ပိတ်ဆို့ခြင်း၏ ဒုတိယစာမျက်နှာဖြစ်ပြီး၊ ၎င်းသည် ဇယားတွင် ပိတ်ဆို့ထားသည်ကို ကျွန်ုပ်တို့တွေ့မြင်ပါသည်။ အတော်လေးစိတ်ဝင်စားဖို့ကောင်းသည်။

ဒါတွေအားလုံးက ကျွန်တော်ပေးချင်တဲ့ အခြေခံအချက်အလက်တွေပါ။ သော့ခတ်မှုများအကြောင်း၊ ငွေပေးငွေယူ ID များအကြောင်း၊ virtual ငွေပေးငွေယူ ID များအကြောင်း၊ အမြဲတမ်း ငွေပေးငွေယူ ID များအကြောင်း ဆွေးနွေးခဲ့ကြပါသည်။

ယခု ကျွန်ုပ်တို့သည် ပိတ်ဆို့ခြင်းဥပမာအချို့ကို ဖြတ်သန်းပါမည်။ ဒါက စိတ်ဝင်စားစရာအကောင်းဆုံးအပိုင်းပါ။ အလွန်စိတ်ဝင်စားစရာကောင်းတဲ့ ကိစ္စတွေကို လေ့လာကြည့်ပါမယ်။ ပြီးတော့ ဒီတင်ပြချက်မှာ ကျွန်တော့်ရဲ့ ရည်မှန်းချက်က တချို့အရာတွေကို ပိတ်ဆို့ဖို့ ကြိုးစားတဲ့အခါ Postgres အမှန်တကယ် ဘာတွေလုပ်နေတယ်ဆိုတာ ကောင်းကောင်းနားလည်ဖို့ပါပဲ။ အပိုင်းတွေကို ပိတ်ဆို့တာ အရမ်းကောင်းတယ်လို့ ကျွန်တော်ထင်ပါတယ်။

သီးခြားဥပမာအချို့ကို ကြည့်ကြပါစို့။

ကျွန်ုပ်တို့သည် ဇယားများနှင့် စားပွဲတစ်ခုတွင် အတန်းတစ်ခုဖြင့် စတင်ပါမည်။ ကျွန်ုပ်တွင် တစ်စုံတစ်ခုကို ထည့်သွင်းသောအခါတွင် ကျွန်ုပ်တွင် ExclusiveLock၊ ငွေပေးငွေယူ ID နှင့် ExclusiveLock တို့ကို ဇယားပေါ်တွင် ပြသထားသည်။

နောက်ထပ် အတန်းနှစ်ခု ထပ်ထည့်လိုက်ရင် ဘာဖြစ်မလဲ။ အခု ကျွန်တော်တို့ စားပွဲမှာ သုံးတန်းရှိတယ်။ ပြီးတော့ ကျွန်တော်က အတန်းတစ်ခုကို ထည့်သွင်းပြီး ဒါကို အထွက်တစ်ခုအနေနဲ့ ရခဲ့ပါတယ်။ အတန်းနှစ်ခုထပ်ထည့်ရင် အဲဒါက ဘာဆန်းလို့လဲ။ ဒီစားပွဲမှာ အတန်းသုံးတန်းထပ်ထည့်ထားပေမယ့် သော့ခတ်စားပွဲမှာ နှစ်တန်းကျန်နေတာကြောင့် ဒီနေရာမှာ ထူးဆန်းတာတစ်ခုရှိပါတယ်။ ဤသည်မှာ Postgres ၏ အခြေခံအကျဆုံး အပြုအမူဖြစ်သည်။

ဒေတာဘေ့စ်တစ်ခုတွင် သင်သည် အတန်း 100 ကိုလော့ခ်ချထားပါက၊ သော့ခတ်ထည့်သွင်းမှုများ 100 ကိုဖန်တီးရန် လိုအပ်မည်ဟု လူအများကထင်မြင်ကြသည်။ အတန်း 1 ကို တစ်ပြိုင်နက် ပိတ်ပါက၊ ထိုသို့သော မေးခွန်းပေါင်း 000 လိုအပ်ပါမည်။ ပိတ်ဆို့ရန် တစ်သန်း သို့မဟုတ် တစ်ဘီလီယံ လိုအပ်မည်ဆိုလျှင်၊ ဒါပေမယ့် ဒါကိုလုပ်ရင် သိပ်အလုပ်မဖြစ်ဘူး။ အတန်းတစ်ခုစီအတွက် ပိတ်ဆို့ထည့်သွင်းမှုများကို ဖန်တီးပေးသည့် စနစ်တစ်ခုကို သင်အသုံးပြုထားပါက ၎င်းသည် ရှုပ်ထွေးကြောင်း သင်တွေ့မြင်နိုင်ပါသည်။ အဘယ်ကြောင့်ဆိုသော် သင်သည် ပြည့်လျှံနိုင်သောသော့ခတ်ဇယားကို ချက်ချင်းသတ်မှတ်ရန် လိုအပ်သော်လည်း Postgres သည် ထိုသို့မလုပ်ပါ။

ပြီးတော့ ဒီဆလိုက်ရဲ့ တကယ်အရေးကြီးတာက MVCC အတွင်းမှာ အတန်းတစ်ခုစီကိုသော့ခတ်ထားတဲ့ အခြားစနစ်တစ်ခုရှိတယ်ဆိုတာ ရှင်းရှင်းလင်းလင်း သက်သေပြလိုက်တာပါပဲ။ ထို့ကြောင့် သင်သည် အတန်းပေါင်း ဘီလီယံပေါင်းများစွာကို လော့ခ်ချသောအခါ၊ Postgres သည် သီးခြားသော့ခတ်သည့်အမိန့်ပေါင်း တစ်ဘီလျံကို ဖန်တီးမည်မဟုတ်ပါ။ ပြီးတော့ ဒါက ကုန်ထုတ်စွမ်းအားကို အရမ်းကောင်းတယ်။

အပ်ဒိတ်တစ်ခုကော။ အတန်းကို ယခု အပ်ဒိတ်လုပ်နေပြီး ၎င်းသည် မတူညီသော လုပ်ဆောင်ချက်နှစ်ခုကို တစ်ပြိုင်နက် လုပ်ဆောင်ကြောင်း သင်တွေ့မြင်နိုင်ပါသည်။ ၎င်းသည် တစ်ချိန်တည်းတွင် ဇယားကို သော့ခတ်ထားသော်လည်း အညွှန်းကိုလည်း သော့ခတ်ထားသည်။ ထို့အပြင် ဤဇယားတွင် ထူးခြားသောကန့်သတ်ချက်များရှိနေသောကြောင့် အညွှန်းကို လော့ခ်ချရန် လိုအပ်သည်။ ပြီးတော့ အဲဒါကို ဘယ်သူကမှ မပြောင်းဘူးဆိုတာ သေချာစေချင်တဲ့အတွက် ပိတ်ဆို့တာပါ။

အတန်းနှစ်တန်းကို အပ်ဒိတ်လုပ်လိုပါက ဘာဖြစ်မလဲ။ သူလည်း အလားတူ ပြုမူသည်ကို ကျွန်ုပ်တို့မြင်သည်။ ကျွန်ုပ်တို့သည် အပ်ဒိတ်များထက် နှစ်ဆပြုလုပ်သော်လည်း သော့ခတ်ထားသော လိုင်းအရေအတွက်နှင့် အတိအကျတူပါသည်။

Postgres မည်သို့လုပ်ဆောင်သည်ကို သင်အံ့သြနေပါက၊ Postgres သည် ဤစာကြောင်းများအတွင်းတွင် မည်သို့ပြောင်းလဲသွားသည်ကို လေ့လာရန် MVCC တွင် ကျွန်ုပ်၏ဟောပြောချက်များကို နားထောင်ရန် လိုအပ်ပါသည်။ Postgres သည် ၎င်းကိုပြုလုပ်သည့်နည်းလမ်းတစ်ခုရှိသော်လည်း ၎င်းသည် စားပွဲသော့ခတ်မှုအဆင့်တွင် ၎င်းကိုမပြုလုပ်ဘဲ ၎င်းသည် နိမ့်ကျပြီး ပိုမိုထိရောက်သောအဆင့်တွင်ပြုလုပ်သည်။

တစ်ခုခုကို ဖျက်ချင်ရင် ဘယ်လိုလုပ်မလဲ။ ဥပမာအားဖြင့်၊ အတန်းတစ်တန်းကို ကျွန်ုပ်ဖျက်ပါက၊ ကျွန်ုပ်တွင် ကျွန်ုပ်၏ ပိတ်ဆို့ထည့်သွင်းမှု နှစ်ခုရှိနေသေးပြီး ၎င်းတို့အားလုံးကို ဖျက်လိုလျှင်ပင် ၎င်းတို့မှာ ရှိနေသေးသည်။

ဥပမာအားဖြင့်၊ ကျွန်ုပ်သည် လိုင်း ၁,၀၀၀ ကို ထည့်သွင်းလိုသည်၊ ထို့နောက် လိုင်း ၁,၀၀၀ ကို ဖျက်ပစ်ရန် သို့မဟုတ် ပေါင်းထည့်သည်၊ ထို့နောက် ကျွန်ုပ်ထည့်သော သို့မဟုတ် ပြောင်းလဲသော လိုင်းတစ်ခုချင်းကို ဤနေရာတွင် မှတ်တမ်းတင်မထားပါ။ ၎င်းတို့ကို စီးရီးအတွင်း အောက်ခြေအဆင့်တွင် ရေးသားထားသည်။ MVCC မိန့်ခွန်းမှာ ကျွန်တော် ဒီအကြောင်းကို အသေးစိတ်ပြောခဲ့ပါတယ်။ ဒါပေမယ့် စားပွဲအဆင့်မှာ လော့ခ်ချထားကြောင်း သေချာစေဖို့ သော့ခတ်မှုတွေကို ခွဲခြမ်းစိတ်ဖြာတဲ့အခါ အလွန်အရေးကြီးပြီး အတန်းတစ်တန်းချင်းစီကို ဒီနေရာမှာ မှတ်တမ်းတင်ထားပုံကို မမြင်မိဖို့ အရေးကြီးပါတယ်။

ပြတ်ပြတ်သားသား ပိတ်ဆို့ထားခြင်းကကော။

Refresh ကို နှိပ်လိုက်ရင် အတန်းနှစ်တန်းကို သော့ခတ်ထားတယ်။ ၎င်းတို့အားလုံးကို ရွေးချယ်ပြီး “နေရာတိုင်းတွင် မွမ်းမံပြင်ဆင်မည်” ကိုနှိပ်ပါက၊ ကျွန်ုပ်တွင် ပိတ်ဆို့ခြင်းမှတ်တမ်းနှစ်ခု ကျန်သေးသည်။

အတန်းတစ်ခုစီအတွက် သီးခြားမှတ်တမ်းများကို ကျွန်ုပ်တို့ မဖန်တီးပါ။ ဒါဆိုရင် ကုန်ထုတ်စွမ်းအား ကျဆင်းသွားတဲ့အတွက် အဲဒါတွေလည်း အများကြီး ဖြစ်နိုင်တယ်။ ကျွန်ုပ်တို့သည် မနှစ်မြို့ဖွယ်အခြေအနေတစ်ခုတွင် ကျွန်ုပ်တို့ကိုယ်ကိုတွေ့နိုင်သည်။

အတူတူပါပဲ၊ မျှဝေမယ်ဆိုရင် အကြိမ် 30 လုံး လုပ်နိုင်ပါတယ်။

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဇယားကို ပြန်လည်ရယူပြီး အရာအားလုံးကို ဖျက်ပြီးနောက် အတန်းတစ်ခုကို ထပ်မံထည့်သွင်းပါ။

အလွန်လူသိများပြီး အလိုရှိသောအပြုအမူဖြစ်သော Postgres တွင် သင်တွေ့မြင်ရသော နောက်ထပ်အပြုအမူတစ်ခုမှာ သင် update သို့မဟုတ် ရွေးချယ်မှုတစ်ခုပြုလုပ်နိုင်သည်။ ပြီးတော့ ဒါကို တစ်ချိန်တည်းမှာ သင်လုပ်နိုင်တယ်။ နှင့် select လုပ်မထားဘူး update ကိုပိတ်ဆို့ခြင်းနှင့်တူညီသောအရာကိုဆန့်ကျင်ဘက်ဦးတည်ချက်။ စာရေးဆရာကို မပိတ်ပင်ဖို့ စာဖတ်သူကို ကျနော်တို့ ပြောခဲ့သလို စာရေးဆရာကလည်း စာဖတ်သူကို မပိတ်ပင်ပါဘူး။

ဒါကို ဥပမာတစ်ခုပြမယ်။ ငါအခုရွေးချယ်မှုတစ်ခုလုပ်မယ်။ ပြီးရင် INSERT ကိုလုပ်ပါမယ်။ ထို့နောက်တွင် သင်သည် - 694 ကိုတွေ့မြင်နိုင်ပါသည်။ ဤထည့်သွင်းမှုကိုလုပ်ဆောင်ခဲ့သော ငွေပေးငွေယူ ID ကို သင်တွေ့နိုင်ပါသည်။ ဒါပဲအလုပ်လုပ်တယ်။

ကျွန်ုပ်၏ backend ID ကို ယခုကြည့်လျှင် 695 ဖြစ်နေပြီဖြစ်သည်။

ပြီးတော့ 695 က ငါ့စားပွဲမှာ ပေါ်လာတာကို ငါတွေ့နိုင်တယ်။

ဤကဲ့သို့ ဤနေရာတွင် အပ်ဒိတ်လုပ်ပါက၊ အခြားကိစ္စရပ်တစ်ခုကို ရရှိပါမည်။ ဤကိစ္စတွင်၊ 695 သည် သီးသန့်သော့ခတ်ထားပြီး အပ်ဒိတ်တွင် တူညီသောအမူအကျင့်ရှိသော်လည်း ၎င်းတို့ကြားတွင် ကွဲလွဲမှုမရှိကြောင်း၊ ၎င်းမှာ အထူးအဆန်းဖြစ်သည်။

အပေါ်ဘက်တွင် ShareLock ဖြစ်သည်၊ အောက်ခြေတွင် ExclusiveLock ဖြစ်သည်ကို သင်တွေ့နိုင်သည်။ ပြီးတော့ အရောင်းအဝယ်နှစ်ခုလုံး ပြေလည်သွားတယ်။

ပြီးတော့ ဒါက ဘယ်လိုဖြစ်တာလဲ နားလည်ဖို့ MVCC မှာ ငါ့ရဲ့ ဟောပြောချက်ကို နားထောင်ရမယ်။ သို့သော် ၎င်းသည် တစ်ချိန်တည်းတွင် သင်လုပ်ဆောင်နိုင်သည့် ပုံဥပမာတစ်ခုဖြစ်သည်၊ ဆိုလိုသည်မှာ SELECT နှင့် UPDATE ကို တစ်ချိန်တည်းတွင် ပြုလုပ်နိုင်သည်။

ပြန်လည်သတ်မှတ်ပြီး နောက်ထပ် လုပ်ဆောင်ချက်တစ်ခု လုပ်ကြပါစို့။

အတန်းတစ်ခုတည်းတွင် အပ်ဒိတ်နှစ်ခုကို တစ်ပြိုင်နက် လုပ်ဆောင်ရန် ကြိုးစားပါက ၎င်းကို ပိတ်ဆို့သွားမည်ဖြစ်သည်။ သတိရပါ၊ စာဖတ်သူသည် စာရေးဆရာကို မပိတ်ပင်၊ စာရေးဆရာသည် စာဖတ်သူကို မပိတ်ပင်၊ စာရေးဆရာက အခြားစာရေးဆရာကို ပိတ်ပင်သည်ဟု ကျွန်ုပ်ပြောခဲ့သည်ကို သတိရပါ။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့တွင် လူနှစ်ဦးသည် အတန်းတစ်ခုတည်းကို တစ်ချိန်တည်းတွင် အပ်ဒိတ်လုပ်၍မရပါ။ ၎င်းတို့ထဲမှ တစ်ခုပြီးသည်အထိ သင်စောင့်ရပါမည်။

ဒါကို သရုပ်ဖော်ဖို့အတွက် Lockdemo ဇယားကို ကြည့်ပါမယ်။ ပြီးတော့ အတန်းတစ်ခုကို ကြည့်မယ်။ အရောင်းအဝယ်တစ်ခုလျှင် ၆၉၈။

ကျွန်ုပ်တို့သည် ၎င်းကို 2 အဖြစ် အဆင့်မြှင့်တင်ထားသည်။ 699 သည် ပထမဆုံး update ဖြစ်သည်။ ၎င်းသည် အောင်မြင်သည် သို့မဟုတ် ဆိုင်းငံ့ထားသော ငွေလွှဲမှုတစ်ခုတွင် ရှိနေပြီး အတည်ပြုရန် သို့မဟုတ် ပယ်ဖျက်ရန် ကျွန်ုပ်တို့ကို စောင့်ဆိုင်းနေသည်။

သို့သော် အခြားအရာတစ်ခုကိုကြည့်ပါ - 2/51 သည် ကျွန်ုပ်တို့၏ပထမဆုံးငွေပေးငွေယူဖြစ်ပြီး ကျွန်ုပ်တို့၏ပထမဆုံးအစည်းအဝေးဖြစ်သည်။ 3/112 သည် ၎င်းတန်ဖိုးကို 3 သို့ပြောင်းပေးသည့် ထိပ်မှလာသော ဒုတိယတောင်းဆိုချက်ဖြစ်သည်။ သင်သတိပြုမိပါက၊ ထိပ်က 699 ဖြစ်သည့် သူ့အလိုလိုသော့ခတ်သွားခဲ့သည်။ သို့သော် 3/112 သည် သော့ကို မပေးပေ။ Lock_mode ကော်လံတွင် ၎င်းသည် စောင့်ဆိုင်းနေသည်ကို ဖော်ပြသည်။ 699 ကို မျှော်မှန်းထား ပြီး 699 သည် မည်သည့်နေရာတွင် ရှိသည်ကို ကြည့်ပါက ပိုမြင့်ပါသည်။ ပြီးတော့ ပထမ session ကဘာလုပ်တာလဲ။ သူမသည် သူမ၏ကိုယ်ပိုင် ငွေပေးငွေယူ ID တွင် သီးသန့်သော့ခတ်မှုကို ဖန်တီးခဲ့သည်။ Postgres လုပ်ပုံက ဒီလိုပါ။ ၎င်းသည် ၎င်း၏ကိုယ်ပိုင် ငွေပေးငွေယူ ID ကို ပိတ်ဆို့ထားသည်။ တစ်စုံတစ်ဦးကို အတည်ပြုရန် သို့မဟုတ် ပယ်ဖျက်ရန် သင်စောင့်ဆိုင်းလိုပါက၊ ဆိုင်းငံ့ထားသော ငွေလွှဲမှုတစ်ခုရှိနေစဉ်တွင် သင်စောင့်ဆိုင်းရန် လိုအပ်ပါသည်။ ဒါကြောင့် ထူးဆန်းတဲ့ မျဉ်းကြောင်းကို ကျွန်တော်တို့ မြင်နိုင်ပါတယ်။

ထပ်ကြည့်ရအောင်။ ဘယ်ဘက်တွင် ကျွန်ုပ်တို့၏ လုပ်ဆောင်ဆဲ ID ကို တွေ့ရပါသည်။ ဒုတိယကော်လံတွင် ကျွန်ုပ်တို့၏ virtual ငွေပေးငွေယူ ID ကိုမြင်ရပြီး တတိယကော်လံတွင် lock_type ကိုတွေ့ရပါမည်။ ဒါဘာကိုဆိုလိုတာပါလဲ? အခြေခံအားဖြင့် ၎င်းသည် ငွေပေးငွေယူ ID ကို ပိတ်ဆို့နေခြင်းဖြစ်သည်ဟု ၎င်းကဆိုသည်။ ဒါပေမယ့် အောက်ခြေမှာရှိတဲ့ အတန်းအားလုံးဟာ ဆက်စပ်နေတယ်လို့ သတိပြုမိပါစေ။ ထို့ကြောင့် သင့်စားပွဲပေါ်တွင် သော့ခတ်ခြင်း နှစ်မျိုးရှိသည်။ ဆက်စပ်သော့ခတ်တစ်ခုရှိသည်။ ထို့နောက်တွင် သင်ကိုယ်တိုင်ပိတ်ဆို့သည့်နေရာတွင် အရောင်းအ၀ယ်ပိတ်ဆို့ခြင်းရှိပါသည်၊ ၎င်းသည် ပထမတန်း သို့မဟုတ် အောက်ခြေတွင် ဖြစ်ပျက်နေသည့် အတိအကျဖြစ်သည်၊ ၎င်းသည် ၎င်း၏လုပ်ဆောင်ချက်ကို အပြီးသတ်ရန် ကျွန်ုပ်တို့ 699 ကို စောင့်ဆိုင်းသည့်နေရာတွင် အရောင်းအ၀ယ်ပြုလုပ်သည့် အောက်ခြေတွင် ဖြစ်ပျက်နေပါသည်။

ဒီမှာ ဘာဖြစ်သွားလဲ ကြည့်မယ်။ ပြီးတော့ ဒီမှာ နှစ်ခုက တပြိုင်တည်း ဖြစ်ပျက်နေတယ်။ သင်ကိုယ်တိုင် လော့ခ်ချသော ပထမတန်းရှိ ငွေပေးငွေယူ ID လော့ခ်ကို သင်ကြည့်ရှုနေပါသည်။ ပြီးတော့ လူတွေကို စောင့်ခိုင်းဖို့ သူမကိုယ်ကို ပိတ်ဆို့ထားတယ်။

6 လိုင်းကိုကြည့်မယ်ဆိုရင် ပထမစာကြောင်းနဲ့ အတူတူပါပဲ။ ထို့ကြောင့် ငွေပေးငွေယူ 699 ကို ပိတ်ထားသည်။ 700 မှာလည်း ကိုယ်တိုင်သော့ခတ်ထားတယ်။ ထို့နောက် အောက်ဆုံးအတန်းတွင် ကျွန်ုပ်တို့သည် ၎င်း၏လုပ်ဆောင်ချက်ကို အပြီးသတ်ရန် 699 ကို စောင့်ဆိုင်းနေသည်ကို တွေ့ရပါမည်။

ပြီးတော့ lock_type မှာ၊ tuple နံပါတ်တွေကို သင်တွေ့ရမှာပါ။

0/10 လို့ မြင်နိုင်ပါတယ်။ ဤသည်မှာ စာမျက်နှာနံပါတ်ဖြစ်ပြီး ဤအထူးအတန်း၏ အော့ဖ်ဆက်လည်းဖြစ်သည်။

ကျွန်ုပ်တို့ အပ်ဒိတ်လုပ်သောအခါ ၎င်းသည် 0/11 ဖြစ်လာသည်ကို သင်တွေ့မြင်ရသည်။

သို့သော် လက်တွေ့တွင် ၎င်းသည် 0/10 ဖြစ်သည်၊ အဘယ်ကြောင့်ဆိုသော် ဤလုပ်ဆောင်ချက်အတွက် စောင့်ဆိုင်းနေရသည်။ ဒီစီးရီးဟာ အတည်ပြုဖို့ စောင့်နေတဲ့ စီးရီးဖြစ်ကြောင်းကို ကျွန်တော်တို့ မြင်တွေ့ခွင့်ရခဲ့ပါတယ်။

အဲဒါကို အတည်ပြုပြီးတာနဲ့ commit ကို နှိပ်ပြီး အပ်ဒိတ် ပြီးသွားတဲ့အခါ၊ ဒါက ထပ်ပြီး ရရှိပါတယ်။ ငွေပေးငွေယူ 700 သည် တစ်ခုတည်းသောသော့ခတ်မှု၊ ကတိပြုထားသောကြောင့် အခြားမည်သူ့ကိုမျှ မစောင့်ပါ။ ၎င်းသည် ငွေပေးငွေယူ ပြီးမြောက်ရန် စောင့်ဆိုင်းနေပါသည်။ 699 ကုန်သွားသည်နှင့်တပြိုင်နက် ကျွန်ုပ်တို့ ဘာကိုမျှ မစောင့်တော့ပါ။ ယခုလည်း ငွေပေးငွေယူ 700 က ခွင့်ပြုထားသော စားပွဲများအားလုံးတွင် လိုအပ်သောသော့ခလောက်များ ပါ၀င်သည် ဟုဆိုသည်။

ဤအရာအားလုံးကို ပိုမိုရှုပ်ထွေးစေရန်အတွက်၊ ဤအချိန်သည် ကျွန်ုပ်တို့အား အထက်တန်းအဆင့်ကို ပေးစွမ်းမည့် အခြားရှုထောင့်တစ်ခုကို ဖန်တီးပါသည်။ ဒီတောင်းဆိုချက်ကို မင်းနားလည်ဖို့ ငါမမျှော်လင့်ပါဘူး။ ဒါပေမယ့် ဒါက ဘာတွေဖြစ်နေလဲဆိုတာကို ပိုရှင်းရှင်းလင်းလင်း မြင်နိုင်ပါလိမ့်မယ်။

ဤသည်မှာ အခြားကဏ္ဍတစ်ခုပါရှိသော ထပ်ခါထပ်ခါ မြင်ကွင်းတစ်ခုဖြစ်သည်။ ပြီးမှ အရာအားလုံးကို တစ်ဖန်ပြန်လည်ပေါင်းစည်းစေတယ်။ ဒါကို သုံးကြည့်ရအောင်။

အပ်ဒိတ်သုံးခုကို တပြိုင်နက်တည်းလုပ်ကာ အတန်းသည် ယခုသုံးကြောင်းပြောလျှင်ကော။ ပြီးတော့ 3 ကနေ 4 ကိုပြောင်းမယ်။

ဤနေရာတွင် ကျွန်ုပ်တို့သည် 4. နှင့် ငွေပေးငွေယူ ID 702 ကိုတွေ့သည်။

ပြီးတော့ 4 ကနေ 5 ကိုပြောင်းမယ်။ ပြီးတော့ 5 က 6 နဲ့ 6 က 7 ပါ။ ပြီးတော့ ဒီငွေလွှဲမှုတစ်ခုပြီးသွားဖို့အတွက် စောင့်မယ့်လူအတော်များများကို တန်းစီပါမယ်။

ပြီးတော့ အရာအားလုံးက ရှင်းသွားတယ်။ ပထမတန်းကဘာလဲ။ ၎င်းသည် 702 ဖြစ်သည်။ ဤတန်ဖိုးကို မူလသတ်မှတ်ထားသည့် ငွေပေးငွေယူ ID ဖြစ်သည်။ ကျွန်ုပ်၏ Granted ကော်လံတွင် ဘာကိုရေးထားသနည်း။ ငါ့မှာ အမှတ်တွေရှိတယ်။ f. ကျွန်ုပ်တို့သည် ငွေပေးငွေယူ ID 5 ကို အဆုံးသတ်ရန် စောင့်ဆိုင်းနေသောကြောင့် (6၊ 7၊ 702) ကို အတည်ပြု၍မရနိုင်သော ကျွန်ုပ်၏အပ်ဒိတ်များဖြစ်ပါသည်။ အဲဒီမှာ ကျွန်တော်တို့မှာ ငွေပေးငွေယူ ID ကို ပိတ်ဆို့ထားပါတယ်။ ၎င်းသည် ငွေပေးငွေယူ ID သော့ခတ်မှု 5 ခုကို ဖြစ်ပေါ်စေသည်။

704 ၊ 705 မှာကြည့်မယ်ဆိုရင် ဘာမှမရေးရသေးပါဘူး ၊ဘာတွေဖြစ်နေလဲမသိသေးလို့ပါ ။ သူတို့ဘာတွေဖြစ်နေလဲ မသိဘူးလို့ ရိုးရိုးလေးရေးတယ်။ ပြီးတော့ အတန်းပြောင်းဖို့ အခွင့်အရေးရလာတဲ့အခါ တစ်စုံတစ်ယောက် ပြီးဆုံးဖို့ စောင့်မျှော်နေတာကြောင့် သူတို့ အိပ်ပျော်သွားပါလိမ့်မယ်။

ဒါက ဘာပုံလဲ။ အားလုံး 12 တန်းကို စောင့်နေကြတယ်ဆိုတာ ရှင်းပါတယ်။

ဒါက ကျနော်တို့ ဒီမှာ မြင်တယ်။ ဒါကတော့ 0/12 ပါ။

ထို့ကြောင့် ပထမဆုံး ငွေပေးငွေယူကို အတည်ပြုပြီးသည်နှင့် အထက်အောက် မည်သို့လုပ်ဆောင်သည်ကို ဤနေရာတွင် ကြည့်ရှုနိုင်ပါသည်။ ယခုမူ အရာအားလုံး ရှင်းသွားပါပြီ။ သူတို့အားလုံး သန့်ရှင်းသွားကြသည်။ ပြီးတော့ သူတို့က တကယ်ကို စောင့်နေတုန်းပဲ။

ဤတွင်ဖြစ်ပျက်နေသည်။ ၇၀၂ ကတိကဝတ်။ ယခု 702 သည် ဤအတန်းလော့ခ်ကိုရရှိပြီး 703 သည် 704 ကို ကျူးလွန်ရန် စောင့်မျှော်နေပါသည်။ ပြီးတော့ 703 ကလည်း ဒါကို စောင့်နေတယ်။ ဤအရာအားလုံးပြီးသောအခါ၊ ပြီးတော့ လူတိုင်းတန်းစီနေတယ်ဆိုတာ ထောက်ပြချင်ပါတယ်။ လူတိုင်း ပထမဆုံးကားကို စောင့်နေကြသည့် ယာဉ်ကြောပိတ်ဆို့မှု အခြေအနေနှင့် အလွန်ဆင်တူပါသည်။ ပထမကားက ရပ်ပြီး လူတိုင်းက တန်းစီပြီး အရှည်ကြီး။ ထို့နောက် ရွေ့လျားပြီး နောက်ကားသည် ရှေ့သို့ မောင်းနှင်နိုင်ပြီး ၎င်း၏ ပိတ်ဆို့ခြင်း စသည်တို့ကို ရရှိနိုင်သည်။

၎င်းသည် သင့်အတွက် လုံလောက်သည်ဟု မရှုပ်ထွေးပါက၊ သော့ခတ်မှုများအကြောင်း သင့်အား ယခု ကျွန်ုပ်တို့ ဆွေးနွေးပါမည်။ ဘယ်သူတွေ ကြုံဖူးကြလဲ မသိဘူး။ ဤသည်မှာ ဒေတာဘေ့စ်စနစ်များတွင် အလွန်အသုံးများသော ပြဿနာဖြစ်သည်။ ဒါပေမယ့် session တစ်ခုက တစ်ခုခုလုပ်ဖို့ နောက် session တစ်ခုကို စောင့်နေတဲ့ အချိန်မှာတော့ deadlocks ပါပဲ။ ဤအခိုက်အတန့်တွင် အခြား session တစ်ခုသည် တစ်ခုခုလုပ်ဆောင်ရန် ပထမ session ကို စောင့်နေသည်။

ဥပမာအားဖြင့်၊ Ivan က “ငါ့ကို တစ်ခုခုပေးပါ” လို့ပြောရင် “မဟုတ်ဘူး၊ မင်းငါ့ကို တခြားတစ်ခုခုပေးရင် မင်းကို ငါပေးမယ်။” ပြီးတော့ သူက “မဟုတ်ဘူး၊ မင်းငါ့ကိုမပေးရင် ငါမပေးဘူး” ဟုပြောသည်။ ပြီး​တော့ ကျွန်​​တော်​တို့ က​တော့ မ​သေ​လောက်​တဲ့ အ​ခြေအ​နေ​မှာ ဆုံး​သွား​တယ်။ အိုင်ဗန်က ဒီလိုလုပ်မှာမဟုတ်ဘူးဆိုတာ သေချာပါတယ်၊ ဒါပေမယ့် တစ်စုံတစ်ခုကို လိုချင်တဲ့လူနှစ်ယောက်ရှိတယ်၊ တစ်ဖက်လူက သူတို့လိုချင်တာကို မပေးမချင်း ပေးဖို့အဆင်သင့်မဖြစ်သေးဘူးဆိုတဲ့ အဓိပ္ပါယ်ကို မင်းနားလည်ပါတယ်။ ပြီးတော့ ဖြေရှင်းချက်လည်း မရှိဘူး။

မရှိမဖြစ်လိုအပ်သည်မှာ၊ သင်၏ဒေတာဘေ့စ်သည် ၎င်းကိုသိရှိရန် လိုအပ်သည်။ ထို့နောက် ဆက်ရှင်များထဲမှ တစ်ခုကို ဖျက်ရန် သို့မဟုတ် ပိတ်ရန် လိုအပ်သည်၊ သို့မှ မဟုတ်ပါက ၎င်းတို့သည် ထိုနေရာတွင် ထာဝရ ရှိနေမည်ဖြစ်သည်။ ပြီးတော့ အဲဒါကို databases တွေမှာတွေ့တယ်၊ လည်ပတ်မှုစနစ်တွေမှာတွေ့တယ်။ ကျွန်ုပ်တို့သည် ပြိုင်တူလုပ်ငန်းစဉ်များရှိသည့် နေရာတိုင်းတွင်၊ ထိုသို့ဖြစ်နိုင်သည်။

ယခု ကျွန်ုပ်တို့သည် deadlock နှစ်ခုကို တပ်ဆင်ပါမည်။ 50 နှင့် 80 ကိုထည့်ပါမည်။ ပထမအတန်းတွင် 50 မှ 50 ကို update လုပ်ပါမည်။ ငွေလွှဲနံပါတ် 710 ကိုရပါမည်။

ပြီးတော့ 80 ကနေ 81 နဲ့ 50 ကနေ 51 ကိုပြောင်းမယ်။

ပြီးတော့ ဒါက ဘယ်လိုပုံစံဖြစ်မလဲ။ ထို့ကြောင့် 710 တွင် အတန်းတစ်တန်းပိတ်ဆို့ထားပြီး 711 သည် အတည်ပြုချက်ကို စောင့်ဆိုင်းနေသည်။ အပ်ဒိတ်လုပ်တုန်းက ဒါကိုတွေ့တယ်။ 710 သည် ကျွန်ုပ်တို့၏စီးရီးပိုင်ရှင်ဖြစ်သည်။ ပြီးတော့ 711 က 710 က ငွေလွှဲမှုပြီးအောင်စောင့်တယ်။

သော့ခတ်မှုများသည် မည်သည့်အတန်းတွင် ဖြစ်ပေါ်လာမည်ကိုပင် ဖော်ပြထားသည်။ ပြီးတော့ ဒီမှာ ထူးဆန်းလာတယ်။

ယခု ကျွန်ုပ်တို့သည် 80 မှ 80 ကို အဆင့်မြှင့်တင်နေပါသည်။

ပြီးတော့ ဒါက အသေအပျောက်များတဲ့ နေရာပါ။ 710 သည် 711 ထံမှ တုံ့ပြန်မှုကို စောင့်ဆိုင်းနေပြီး 711 သည် 710 ကို စောင့်နေသည်။ ၎င်းသည် ကောင်းမွန်စွာ ပြီးဆုံးမည်မဟုတ်ပါ။ ပြီးတော့ ဒီကနေ ထွက်လမ်းမရှိဘူး။ ပြီးတော့ တစ်ယောက်နဲ့တစ်ယောက် တုံ့ပြန်မှုကို မျှော်လင့်ကြလိမ့်မယ်။

ပြီးတော့ အရာအားလုံးကို နှောင့်နှေးစေလိမ့်မယ်။ ငါတို့က အဲဒါကို မလိုချင်ဘူး။

ပြီးတော့ Postgres မှာ ဒီလိုဖြစ်လာတဲ့အခါ သတိထားရမယ့်နည်းလမ်းတွေရှိပါတယ်။ ဒီလိုဖြစ်လာတဲ့အခါ၊ ဒီအမှားကို သင်ရလိမ့်မယ်။ ၎င်းမှ ဤကဲ့သို့နှင့် ဤလုပ်ငန်းစဉ်သည် 711 လုပ်ငန်းစဉ်ဖြင့် ပိတ်ဆို့ထားသော အခြားလုပ်ငန်းစဉ်မှ SHARE LOCK ကို စောင့်နေကြောင်း ထင်ရှားပါသည်။ ၎င်းလုပ်ငန်းစဉ်သည် ယင်းကဲ့သို့ SHARE LOCK တစ်ခုကို ပေးဆောင်ရန် စောင့်ဆိုင်းနေပြီး ထိုသို့သော ငွေပေးငွေယူ ID နှင့် ယင်းကဲ့သို့သော လုပ်ငန်းစဉ်များဖြင့် ပိတ်ဆို့ထားသည်။ ထို့ကြောင့် ဤနေရာတွင် မသေနိုင်သော အခြေအနေရှိသည်။

သုံးလမ်းပိတ်များ ရှိပါသလား။ အဲဒါဖြစ်နိုင်လား? ဟုတ်ကဲ့။

ကျွန်ုပ်တို့သည် ဤနံပါတ်များကို ဇယားတစ်ခုထဲသို့ ထည့်ပါ။ ကျွန်ုပ်တို့သည် 40 မှ 40 ကိုပြောင်းသည်၊ ပိတ်ဆို့သည်။

ကျွန်ုပ်တို့သည် 60 မှ 61၊ 80 မှ 81 သို့ပြောင်းသည်။

ပြီးတော့ ငါတို့ 80 ကိုပြောင်းပြီးတော့ boom!

ပြီးတော့ 714 က 715 ကိုစောင့်နေတယ်။ 716 က 715 ကိုစောင့်နေတယ်။ ပြီးတော့ အဲဒါနဲ့ ပတ်သက်ပြီး ဘာမှ မလုပ်နိုင်ဘူး။

ဒီမှာ လူနှစ်​​ယောက်​မရှိ​တော့ဘူး၊ ဒီမှာ လူသုံး​ယောက်​ရှိ​နေပြီ။ မင်းဆီက တစ်ခုခုလိုချင်တယ်၊ ဒီတစ်ယောက်က တတိယလူဆီက တစ်ခုခုလိုချင်တယ်၊ တတိယလူက ငါ့ဆီက တစ်ခုခုလိုချင်တယ်။ တစ်ဖက်လူက သူတို့လုပ်စရာကို ပြီးအောင်လုပ်ဖို့ စောင့်ဆိုင်းနေတာကြောင့် သုံးလမ်းခရီးနဲ့ ကျွန်တော်တို့ အဆုံးသတ်ပါတယ်။

ပြီးတော့ Postgres က ဘယ်အတန်းက ဒီလိုဖြစ်မလဲဆိုတာ သိတယ်။ ထို့ကြောင့် ၎င်းသည် သင့်အား အောက်ပါမက်ဆေ့ချ်ကို ပေးလိမ့်မည်၊ ၎င်းသည် သင့်တွင် inputs သုံးခု တစ်ခုနှင့်တစ်ခု ပိတ်ဆို့နေသည့် ပြဿနာတစ်ခုရှိကြောင်း ပြသသည်။ ပြီးတော့ ဒီမှာ ကန့်သတ်ချက်တွေ မရှိဘူး။ အကြောင်းအရာ 20 သည် တစ်ခုနှင့်တစ်ခု ပိတ်ဆို့နေသည့် ကိစ္စမျိုးလည်း ဖြစ်နိုင်သည်။

နောက်ပြဿနာက နံပါတ်စဉ်တပ်လို့ရတယ်။

special serializable ဆိုရင် lock ပါ။

ကျွန်ုပ်တို့သည် 719 သို့ ပြန်သွားရန်။ ၎င်း၏ထွက်ရှိမှုသည် ပုံမှန်ဖြစ်သည်။

ပြီးလျှင် serializable မှ ငွေပေးငွေယူပြုလုပ်ရန် နှိပ်နိုင်ပါသည်။

ယခု သင့်တွင် မတူညီသော SA သော့ခလောက်ရှိသည်ကို သင်သဘောပေါက်လိုက်သည် - ၎င်းသည် နံပါတ်စဉ်တပ်၍ရနိုင်သည်ဟု ဆိုလိုသည်။

ထို့ကြောင့် ကျွန်ုပ်တို့တွင် SARieadLock ဟုခေါ်သောသော့အမျိုးအစားအသစ်တစ်ခုရှိပြီး၊ ၎င်းသည် နံပါတ်စဉ်သော့ခတ်ပြီး နံပါတ်စဉ်များကိုထည့်သွင်းနိုင်စေမည်ဖြစ်သည်။

ထို့အပြင် သင်သည် ထူးခြားသော အညွှန်းများကို ထည့်သွင်းနိုင်သည်။

ဤဇယားတွင် ကျွန်ုပ်တို့တွင် ထူးခြားသောအညွှန်းများရှိသည်။

ဒီတော့ နံပါတ် 2 ကို ဒီနေရာမှာ ထည့်လိုက်ရင် 2 ရှိတယ်။ ဒါပေမယ့် အပေါ်ဆုံးမှာ နောက်ထပ် 2 ထပ်ထည့်လိုက်တယ်။ ပြီးတော့ 721 မှာ သီးသန့်သော့တစ်ခု ပါနေတာကို သင်တွေ့နိုင်တယ်။ ယခုမူ 722 သည် 721 တွင် 2 ကို ထည့်သွင်း၍မရသောကြောင့် 721 တွင် ဘာဖြစ်မည်ကို မသိမချင်း XNUMX ကို စောင့်ဆိုင်းနေပါသည်။

subtransaction လုပ်လျှင်လည်း၊

ဒီမှာ 723 ရှိတယ်။

အမှတ်ကို သိမ်းဆည်းပြီး ၎င်းကို အပ်ဒိတ်လုပ်ပါက၊ ငွေပေးငွေယူ ID အသစ်တစ်ခု ရရှိပါမည်။ ဒါက သင်သိထားသင့်တဲ့ နောက်ထပ် အပြုအမူပုံစံတစ်ခုပါ။ ၎င်းကို ပြန်ပေးလျှင် ငွေပေးငွေယူ ID ပျောက်သွားပါသည်။ 724 က ထွက်သွားတယ်။ ဒါပေမယ့် အခု 725 ရှိတယ်။

ဒါဆို ငါဒီမှာ ဘာလုပ်ဖို့ ကြိုးစားနေတာလဲ။ သင်တွေ့နိုင်သော ပုံမှန်မဟုတ်သောသော့ခလောက်များကို နမူနာပြရန် ကျွန်ုပ်ကြိုးစားနေပါသည်- ၎င်းသည် နံပါတ်စဉ်တပ်နိုင်သောသော့များ သို့မဟုတ် SAVEPOINT ဖြစ်စေ၊ ၎င်းတို့သည် သော့ခတ်ဇယားတွင် ပေါ်လာမည့် မတူညီသောသော့ခများဖြစ်သည်။

၎င်းသည် pg_advisory_lock ပါရှိသော တိကျသော (ရှင်းလင်းပြတ်သားသော) လော့ခ်များ ဖန်တီးခြင်းဖြစ်ပါသည်။

ပိတ်ဆို့ခြင်းအမျိုးအစားကို အကြံပေးအဖြစ် စာရင်းသွင်းထားကြောင်း သင်တွေ့မြင်ရသည်။ ဒီနေရာမှာ အနီရောင်နဲ့ “အကြံပေး” လို့ ပြောထားတယ်။ pg_advisory_unlock ဖြင့် ဤကဲ့သို့ ပိတ်ဆို့နိုင်သည်။

နိဂုံးချုပ်အနေနဲ့ ပြောရရင် နောက်ထပ် စိတ်လှုပ်ရှားစရာကောင်းတဲ့ အရာတစ်ခုကို ပြချင်ပါတယ်။ ငါနောက်ထပ်အမြင်ဖန်တီးမယ်။ ဒါပေမယ့် pg_stat_activity table နဲ့ pg_locks table မှာ ပါဝင်ပါမယ်။ ပြီးတော့ ငါဘာလို့ ဒီလိုလုပ်ချင်တာလဲ။ ဘာကြောင့်လဲ ဆိုတော့ ဒါက လက်ရှိ session အားလုံးကို ကြည့်နိုင်ပြီး သူတို့ စောင့်နေတဲ့ သော့ခလောက်တွေကို အတိအကျ သိနိုင်လို့ ဖြစ်ပါတယ်။ သော့ခတ်စားပွဲနှင့် စုံစမ်းမေးမြန်းမှုဇယားကို ပေါင်းစည်းလိုက်သောအခါ ၎င်းသည် အလွန်စိတ်ဝင်စားစရာကောင်းသည်။

ဤတွင် ကျွန်ုပ်တို့သည် pg_stat_view ကို ဖန်တီးသည်။

ပြီးတော့ အတန်းကို တစ်ခုပြီးတစ်ခု အပ်ဒိတ်လုပ်တယ်။ ပြီးတော့ ဒီမှာ 724 ကိုတွေ့တယ်။ ပြီးတော့ ကျွန်တော်တို့အတန်းကို သုံးမျိုးအထိ အပ်ဒိတ်လုပ်တယ်။ ပြီးတော့ အခု ဒီမှာ ဘာမြင်လဲ။ ဤအရာများသည် တောင်းဆိုချက်များဖြစ်သည်၊ ဆိုလိုသည်မှာ ဘယ်ဘက်ကော်လံတွင် ဖော်ပြထားသော တောင်းဆိုချက်စာရင်းတစ်ခုလုံးကို သင်တွေ့မြင်ရပါသည်။ ပြီးလျှင် ညာဘက်ခြမ်းတွင် ပိတ်ဆို့မှုများနှင့် ၎င်းတို့ဖန်တီးထားသည်ကို သင်တွေ့မြင်နိုင်သည်။ ပြီးတော့ သင်က session တစ်ခုစီကို အကြိမ်တိုင်း ပြန်သွားပြီး ပါဝင်ဖို့ လိုအပ်သည်ဖြစ်စေ မပါဝင်ဖို့ မလိုအပ်ဘဲ သင့်အတွက် ပိုရှင်းလင်းနိုင်ပါတယ်။ သူတို့က ငါတို့အတွက် လုပ်ပေးတာ။

အရမ်းအသုံးဝင်တဲ့ နောက်ထပ် Feature တစ်ခုပါ။ pg_blocking_pids. သူမအကြောင်းကို သင် တစ်ခါမှ မကြားဖူးတာ ဖြစ်နိုင်ပါတယ်။ သူမဘာလုပ်နေလဲ? ၎င်းသည် ကျွန်ုပ်တို့အား ဤ session 11740 အတွက် မည်သည့်တိကျသော လုပ်ငန်းစဉ် ID များကို စောင့်ဆိုင်းနေကြောင်းကို ပြောပြနိုင်စေပါသည်။ 11740 သည် 724 ကို စောင့်ဆိုင်းနေကြောင်း သင်တွေ့မြင်နိုင်သည်။ နှင့် 724 သည် ထိပ်ဆုံးတွင် ရှိနေသည်။ 11306 သည် သင်၏ လုပ်ငန်းစဉ် ID ဖြစ်သည်။ အဓိကအားဖြင့်၊ ဤလုပ်ဆောင်ချက်သည် သင်၏သော့ခတ်ဇယားကိုဖြတ်သွားပါသည်။ နည်းနည်းရှုပ်ထွေးတယ်ဆိုတာ ငါသိပါတယ်၊ ဒါပေမယ့် မင်းနားလည်နိုင်မှာပါ။ အခြေခံအားဖြင့် ဤလုပ်ဆောင်ချက်သည် ဤသော့ခတ်ဇယားကိုဖြတ်၍ စောင့်ဆိုင်းနေသောသော့ခလောက်များကို ဤလုပ်ငန်းစဉ် ID ပေးသည့်နေရာတွင် ရှာဖွေရန် ကြိုးစားသည်။ သော့ခတ်ခြင်းကို စောင့်ဆိုင်းနေသည့် လုပ်ငန်းစဉ်တွင် မည်သည့် လုပ်ငန်းစဉ် ID ရှိသည်ကို အဖြေရှာရန် ကြိုးပမ်းသည်။ ဒါကြောင့် ဒီလုပ်ဆောင်ချက်ကို သင်သုံးနိုင်ပါတယ်။ pg_blocking_pids.

ပြီးတော့ ဒါက အရမ်းအသုံးဝင်နိုင်ပါတယ်။ ၎င်းကို ဗားရှင်း 9.6 တွင်သာ ထည့်သွင်းထားသောကြောင့် ဤလုပ်ဆောင်ချက်သည် 5 နှစ်သာရှိသေးသော်လည်း ၎င်းသည် အလွန်အသုံးဝင်ပါသည်။ ဒုတိယတောင်းဆိုချက်မှာလည်း အလားတူပါပဲ။ ကျွန်ုပ်တို့ မြင်လိုသည်များကို အတိအကျပြသသည်။

ဒါက မင်းကို ပြောပြချင်ခဲ့တာ။ ငါမျှော်လင့်ထားသလိုပဲ၊ ဆလိုက်တွေအများကြီးရှိလို့ ငါတို့အချိန်တွေအကုန်ကုန်သွားတယ်။ ဆလိုက်များကို ဒေါင်းလုဒ်လုပ်နိုင်ပါသည်။ ဒီမှာရှိတဲ့အတွက် ကျေးဇူးတင်ချင်ပါတယ်။ ကျန်ကွန်ဖရင့်ကို နှစ်သက်မှာ သေချာပါတယ်၊ ကျေးဇူးတင်ပါတယ်။

မေးခွန်းများကို:

ဥပမာအားဖြင့်၊ အတန်းများကို အပ်ဒိတ်လုပ်ရန် ကြိုးစားနေပါက၊ ဒုတိယဆက်ရှင်သည် ဇယားတစ်ခုလုံးကို ဖျက်ရန် ကြိုးစားနေပါသည်။ ငါနားလည်သလောက်၊ ရည်ရွယ်ချက်သော့ခတ်ကဲ့သို့အရာတစ်ခုရှိသင့်သည်။ Postgres တွင် ထိုသို့သော အရာ ရှိပါသလား။

အစကတည်းက ပြန်သွားကြည့်ရအောင်။ သင်ဘာမဆိုလုပ်တဲ့အခါ ဥပမာ SELECT တစ်ခုလုပ်တဲ့အခါ၊ AccessShareLock ထုတ်ပေးတယ်ဆိုတာ သင်မှတ်မိနိုင်ပါတယ်။ ၎င်းသည် စားပွဲကို ပြုတ်ကျခြင်းမှ တားဆီးသည်။ ဥပမာအားဖြင့် သင်သည် ဇယားတစ်ခုရှိ အတန်းတစ်ခုကို အပ်ဒိတ်လုပ်လိုပါက သို့မဟုတ် အတန်းတစ်ခုကို ဖျက်လိုပါက၊ သင်သည် ဤ AccessShareLock ကို စားပွဲတစ်ခုလုံးနှင့် အတန်းပေါ်တွင် ကိုင်ထားသောကြောင့် ဇယားတစ်ခုလုံးကို တစ်ပြိုင်နက်တည်း တစ်စုံတစ်ယောက်က ဖျက်၍မရပါ။ သင်ပြီးသည်နှင့် ၎င်းတို့သည် ၎င်းကို ဖျက်နိုင်သည်။ ဒါပေမယ့် အဲဒီနေရာမှာ တစ်ခုခုကို သင် တိုက်ရိုက်ပြောင်းလဲနေချိန်မှာတော့ သူတို့ လုပ်နိုင်မှာ မဟုတ်ဘူး။

ထပ်လုပ်ရအောင်။ ဖျက်လိုက်တဲ့ ဥပမာကို ဆက်သွားရအောင်။ ပြီးတော့ စားပွဲတစ်ခုလုံးရဲ့ အပေါ်က အတန်းပေါ်မှာ သီးသန့်သော့ခတ်ထားတာကို သင်တွေ့ရမှာပါ။

၎င်းသည် သော့ခတ်သီးသန့်ကဲ့သို့ ဖြစ်နေမည် မဟုတ်လား။

ဟုတ်ပုံရတယ်။ မင်းပြောနေတာတွေကို ငါနားလည်တယ်။ ငါ SELECT တစ်ခုလုပ်ရင် ငါ့မှာ ShareExclusive ရှိပြီး အဲဒါကို Row Exclusive လုပ်မယ်ဆိုလို့ရှိရင် ပြဿနာဖြစ်လာမှာလား။ ဒါပေမယ့် အံ့သြစရာကောင်းတာက ဒါက ပြဿနာမဖြစ်ပါဘူး။ ၎င်းသည် လော့ခ်ချမှုဒီဂရီကို တိုးလာပုံပေါ်သော်လည်း အမှန်တကယ်အားဖြင့် ကျွန်ုပ်တွင် ဖျက်ခြင်းအား တားဆီးနိုင်သည့် သော့တစ်ခုရှိသည်။ ယခုလည်း ဤသော့ကို ကျွန်ုပ် ပိုအားကောင်းအောင် ပြုလုပ်သောအခါ၊ ၎င်းသည် ဖျက်ခြင်းကို တားဆီးဆဲဖြစ်သည်။ ဒီတော့ ငါတက်ရတာ မဟုတ်ဘူး။ ဆိုလိုသည်မှာ၊ ၎င်းသည် အောက်ခြေအဆင့်တွင် ရှိနေချိန်တွင် ၎င်းကို တားဆီးထားသောကြောင့် ၎င်းကို အဆင့်မြှင့်သည့်အခါ ၎င်းသည် ဇယားကို ဖျက်ပစ်ရန် တားဆီးထားဆဲဖြစ်သည်။

မင်းပြောနေတာတွေကို ငါနားလည်တယ်။ ပိုအားကောင်းသောတစ်ခုကိုမိတ်ဆက်ရန် သော့တစ်ခုစွန့်ရန် သင်ကြိုးစားနေသည့် ဤနေရာတွင် လော့ခ်တိုးခြင်းကိစ္စမရှိပါ။ ဤနေရာတွင် ၎င်းသည် ဘုတ်အဖွဲ့အနှံ့ ကြိုတင်ကာကွယ်ရေးကို တိုးမြှင့်ထားသောကြောင့် မည်သည့်ပဋိပက္ခမှ မဖြစ်စေပါ။ ဒါပေမယ့် မေးခွန်းကောင်းတစ်ခုပါပဲ။ အခုလိုမေးတဲ့အတွက် ကျေးဇူးအများကြီးတင်ပါတယ်။

ကျွန်ုပ်တို့တွင် စက်ရှင်များစွာ၊ အသုံးပြုသူအများအပြားရှိသောအခါ မပိတ်မိနိုင်သောအခြေအနေမှ ရှောင်ရှားနိုင်ရန် ကျွန်ုပ်တို့ ဘာလုပ်ရမည်နည်း။

Postgres သည် မသေနိုင်သော အခြေအနေများကို အလိုအလျောက် သတိထားမိသည်။ ၎င်းသည် ဆက်ရှင်များထဲမှ တစ်ခုကို အလိုအလျောက် ဖျက်သွားပါမည်။ အသေပိတ်ဆို့ခြင်းကို ရှောင်ရှားရန် တစ်ခုတည်းသောနည်းလမ်းမှာ တူညီသောအစီအစဥ်အတိုင်း လူများကို ပိတ်ဆို့ရန်ဖြစ်သည်။ ဒါကြောင့် သင့်လျှောက်လွှာကို ကြည့်လိုက်တဲ့အခါ မကြာခဏ သော့ပိတ်ရခြင်းရဲ့ အကြောင်းရင်း... မတူညီတဲ့ အရာနှစ်ခုကို ပိတ်ဆို့ချင်တယ်လို့ စိတ်ကူးကြည့်ကြပါစို့။ အပလီကေးရှင်းတစ်ခုသည် ဇယား 1 ကိုသော့ခတ်ကာ နောက်တစ်ခုက အပလီကေးရှင်းက 2 ကိုသော့ခတ်ပြီး ဇယား 1 ကိုပိတ်သည်။ အသေပိတ်မှုများကိုရှောင်ရှားရန် အလွယ်ကူဆုံးနည်းလမ်းမှာ သင့်အက်ပ်လီကေးရှင်းကိုကြည့်ရှုပြီး အပလီကေးရှင်းအားလုံးတွင် တူညီသောအစီအစဥ်အတိုင်း သော့ခတ်မှုဖြစ်ပေါ်ကြောင်း သေချာအောင်ကြိုးစားပါ။ အဘယ်ကြောင့်ဆိုသော် ၎င်းသည် များသောအားဖြင့် ပြဿနာများ၏ 80% ကို ဖယ်ရှားပေးသည်။ အကယ်၍ သင်သည် ၎င်းတို့အား တူညီသောအစီအစဥ်ဖြင့် ပိတ်ဆို့ပါက၊ သင်သည် သော့ပိတ်သော အခြေအနေနှင့် ကြုံတွေ့ရမည်မဟုတ်ပေ။

မင်းရဲ့စွမ်းဆောင်ရည်အတွက် အရမ်းကျေးဇူးတင်ပါတယ်။ မင်းက လေဟာနယ် အပြည့်အကြောင်း ပြောထားပြီး၊ ငါ မှန်ကန်စွာ နားလည်ပါက၊ လေဟာနယ် အပြည့်သည် သီးခြား သိုလှောင်မှုတွင် မှတ်တမ်းများ၏ အစီအစဥ်ကို ကွဲလွဲစေသောကြောင့် ၎င်းတို့သည် လက်ရှိ မှတ်တမ်းများကို မပြောင်းလဲဘဲ ထိန်းသိမ်းထားသည်။ လေဟာနယ်ပြည့်သည် အဘယ်ကြောင့် သီးသန့်သော့ခတ်ခွင့်ကို ရယူသနည်း၊ ၎င်းသည် စာရေးခြင်းလုပ်ငန်းနှင့် အဘယ်ကြောင့် ကွဲလွဲနေသနည်း။

အဲဒါ ကောင်းတဲ့မေးခွန်းပါ။ အကြောင်းရင်းကတော့ လေဟာနယ်အပြည့်နဲ့ စားပွဲကို ယူဆောင်သွားလို့ပါပဲ။ ကျွန်ုပ်တို့သည် အခြေခံအားဖြင့် ဇယား၏ ဗားရှင်းအသစ်ကို ဖန်တီးနေပါသည်။ ပြီးတော့ စားပွဲက အသစ်ဖြစ်လိမ့်မယ်။ ၎င်းသည် စားပွဲ၏ လုံးဝဗားရှင်းအသစ်ဖြစ်မည်ဟု ထွက်ပေါ်လာသည်။ ပြဿနာက ကျွန်တော်တို့ ဒါကိုလုပ်တဲ့အခါ ဇယားအသစ်ကို မြင်ဖို့ သူတို့ကို လိုအပ်တာကြောင့် လူတွေက အဲဒါကို မဖတ်စေချင်ဘူး။ ဒီတော့ ဒါက အရင်မေးခွန်းနဲ့ ဆက်စပ်နေတယ်။ အကယ်၍ ကျွန်ုပ်တို့သည် တစ်ချိန်တည်းတွင် စာဖတ်နိုင်လျှင် ၎င်းကို ရွှေ့ပြီး လူများကို စားပွဲအသစ်သို့ ညွှန်ပြနိုင်မည် မဟုတ်ပါ။ ဤဇယားကို ဖတ်ရှုရန် လူတိုင်းကို စောင့်ဆိုင်းရမည်ဖြစ်ပြီး၊ ထို့ကြောင့် ၎င်းသည် အဓိကအားဖြင့် သော့ခတ်သီးသန့် အခြေအနေတစ်ခုဖြစ်သည်။
အဆုံးတွင် လူတိုင်းကို ကော်ပီအသစ်သို့ ရွှေ့ရန်အတွက် သီးသန့်သော့ခလောက် လိုအပ်မည်ကို ကျွန်ုပ်တို့သိသောကြောင့် အစမှ လော့ခ်ချသည်ဟုသာ ကျွန်ုပ်တို့ပြောပါသည်။ အဲဒီတော့ ဒါကို ဖြေရှင်းနိုင်မယ်။ တစ်ပြိုင်နက်တည်း ညွှန်းကိန်းဖြင့် ဤနည်းကို ကျွန်ုပ်တို့ ပြုလုပ်ပါသည်။ ဒါပေမယ့် ဒါက လုပ်ရတာ ပိုခက်တယ်။ ပြီးတော့ ဒါက သော့ခတ်သီးသန့်အကြောင်း မင်းအရင်မေးခွန်းနဲ့ အရမ်းသက်ဆိုင်တယ်။

Postgres တွင် လော့ခ်ချချိန်လွန်ခြင်းကို ထည့်နိုင်ပါသလား။ Oracle တွင်၊ ဥပမာအားဖြင့်၊ ကျွန်ုပ်သည် "အပ်ဒိတ်လုပ်ရန်ရွေးချယ်ရန်" ဟုရေးပြီး မွမ်းမံခြင်းမပြုမီ စက္ကန့် 50 စောင့်နိုင်သည်။ လျှောက်လွှာအတွက် ကောင်းပါတယ်။ သို့သော် Postgres တွင်၊ ကျွန်ုပ်သည် ၎င်းကို ချက်ချင်းလုပ်ဆောင်ရန် လိုအပ်ပြီး လုံးဝမစောင့်ဆိုင်းဘဲ သို့မဟုတ် အချိန်အတိုင်းအတာတစ်ခုအထိ စောင့်ပါ။

ဟုတ်ကဲ့၊ သင့်သော့ခလောက်များ၊ သင့်သော့ခလောက်များတွင် အချိန်ကုန်သွားသည်ကို သင်ရွေးချယ်နိုင်ပါသည်။ သော့ကိုချက်ချင်းမရယူနိုင်ပါက no way command ကိုလည်းထုတ်နိုင်သည်။ ထို့ကြောင့်၊ သော့ခတ်ချိန်လွန်ခြင်း သို့မဟုတ် သင်ဤသို့လုပ်ဆောင်နိုင်စေမည့် အခြားအရာတစ်ခုဖြစ်သည်။ ဒါကို syntactic အဆင့်မှာ မလုပ်ပါဘူး။ ၎င်းကို ဆာဗာပေါ်တွင် ကိန်းရှင်တစ်ခုအဖြစ် လုပ်ဆောင်သည်။ တခါတရံ ဒါကို သုံးလို့မရပါဘူး။

slide 75 ကို သင်ဖွင့်နိုင်ပါသလား။

ဟုတ်ပါတယ်။

ပြီးတော့ ကျွန်တော့်မေးခွန်းက အောက်ပါအတိုင်းဖြစ်ပါတယ်။ အပ်ဒိတ်လုပ်ငန်းစဉ်နှစ်ခုလုံးသည် အဘယ်ကြောင့် 703 ကို မျှော်လင့်နေကြသနည်း။

ပြီးတော့ ဒါက မေးခွန်းကြီးတစ်ခုပါ။ Postgres ဘာကြောင့် ဒီလိုလုပ်တယ်ဆိုတာ ကျွန်တော် နားမလည်ပါဘူး။ ဒါပေမယ့် 703 ကို ဖန်တီးလိုက်တဲ့အခါ 702 ကို မျှော်လင့်နေပါတယ်။ 704 နဲ့ 705 ပေါ်လာတဲ့အခါမှာတော့ သူတို့ဘာကို မျှော်လင့်နေလဲဆိုတာကို မသိကြသေးသလိုပါပဲ။ Postgres သည် ဤနည်းအတိုင်းလုပ်ဆောင်သည်- သင်သော့ခတ်၍မရသောအခါ၊ သင်သည်တစ်စုံတစ်ဦးကိုစောင့်ဆိုင်းနေသောကြောင့် "သင့်ကိုလုပ်ဆောင်ရာတွင် အဘယ်အရာရှိသနည်း" ဟုရေးထားသည်။ ဒါကြောင့် အဲဒါကို လေထဲမှာ ထားထားလိုက်မယ်၊ အဲဒါကို လုံးဝ update လုပ်မှာ မဟုတ်ပါဘူး။ ဒါပေမယ့် ဒီမှာ ဘာဖြစ်သွားတာလဲ။ 702 လုပ်ငန်းစဉ်ပြီးသည်နှင့် 703 သည်၎င်း၏သော့ခတ်ခြင်းကိုလက်ခံရရှိသည်နှင့်တပြိုင်နက်စနစ်သည်ပြန်လည်ရောက်ရှိခဲ့သည်။ အခု ငါတို့မှာ စောင့်နေတဲ့ လူနှစ်ယောက် ရှိတယ် လို့ သူက ပြောပါတယ်။ ပြီးရင် အဲဒါတွေကို အတူတူ update လုပ်ကြရအောင်။ ပြီးတော့ နှစ်ယောက်စလုံး မျှော်လင့်နေတယ်ဆိုတာကို ညွှန်ပြကြပါစို့။

Postgres ဘာကြောင့် ဒီလိုလုပ်တာလဲ ကျွန်တော်မသိဘူး။ ဒါပေမယ့် f လို့ ခေါ်တဲ့ ပြဿနာတစ်ခုရှိတယ်။ ဒါက ရုရှားလိုအသုံးအနှုန်းမဟုတ်ဘူးလို့ ထင်ပါတယ်။ ရဲတိုက်ကို စောင့်နေတဲ့ အာဏာပိုင် အယောက် 20 ရှိရင်တောင် လူတိုင်းက ရဲတိုက်တစ်ခုကို စောင့်နေကြတဲ့အချိန်ပါပဲ။ ရုတ်တရက် သူတို့အားလုံး တစ်ပြိုင်နက် နိုးလာကြသည်။ ပြီးတော့ လူတိုင်းက တုံ့ပြန်ဖို့ ကြိုးစားလာကြတယ်။ ဒါပေမယ့် စနစ်က လူတိုင်းက 703 ကို စောင့်နေနိုင်အောင် လုပ်ပေးတယ်။ ဘာလို့လဲဆိုတော့ အားလုံးက စောင့်နေကြလို့၊ ငါတို့က သူတို့ကို ချက်ချင်းတန်းစီမယ်။ ဥပမာ၊ 707 ပြီးနောက် ထုတ်ပေးခဲ့သော အခြားတောင်းဆိုချက်အသစ်များ ပေါ်လာပါက၊ နောက်တစ်ကြိမ် လွတ်ခြင်းရှိလာပါမည်။

ဒီအဆင့်မှာ 702 က 703 ကို စောင့်နေတယ် လို့ ပြောနိုင် အောင် ပြီးသွား ပြီ လို့ ထင် ပြီး နောက် လာ တဲ့ သူ တွေ က ဒီ နယ်ပယ် မှာ ၀င် ခွင့် မရှိ ပါဘူး ။ သို့သော် ပထမစားပွဲထိုးထွက်သွားသည်နှင့် အပ်ဒိတ်မစတင်မီအချိန်တွင် စောင့်ဆိုင်းနေသူများအားလုံး တူညီသော တိုကင်ကို ရရှိကြသည်။ ဒါကြောင့် အဲဒါတွေကို စနစ်တကျ စီစဥ်ထားနိုင်အောင် စီမံဆောင်ရွက်ပေးနိုင်မယ်လို့ ထင်ပါတယ်။

ကျွန်တော် ဒါကို ထူးဆန်းတဲ့ ဖြစ်စဉ်တစ်ခုအဖြစ် အမြဲမြင်တယ်။ ဥပမာအားဖြင့်၊ ဤတွင်၊ ကျွန်ုပ်တို့သည် ၎င်းတို့ကို လုံး၀ မဖော်ပြထားသောကြောင့်ဖြစ်သည်။ ဒါပေမယ့် သော့အသစ်ပေးတိုင်း စောင့်ဆိုင်းနေတဲ့ သူတွေအားလုံးကို ကြည့်ရတာလို့ ထင်ရပါတယ်။ ပြီးရင် သူတို့အားလုံးကို တန်းစီတယ်။ ထို့နောက် ဝင်လာသည့်အသစ်မှန်သမျှသည် နောက်လူကို စီမံဆောင်ရွက်ပြီးသောအခါတွင်သာ တန်းစီထဲသို့ ရောက်သည်။ အရမ်းကောင်းတဲ့မေးခွန်းပါ။ သင့်မေးခွန်းအတွက် ကျေးဇူးအများကြီးတင်ပါတယ်။

705 က 704 ကို မျှော်လင့်တဲ့အခါ ပိုယုတ္တိရှိမယ်ထင်ပါတယ်။

ဒါပေမယ့် ဒီနေရာမှာ ပြဿနာက အောက်ပါအတိုင်း ဖြစ်ပါတယ်။ နည်းပညာအရ သင်သည် တစ်ခု သို့မဟုတ် အခြားတစ်ခုကို နှိုးနိုင်သည်။ ဒါမှ ငါတို့ နိုးလာလိမ့်မယ်။ ဒါပေမယ့် စနစ်မှာ ဘာဖြစ်သွားမလဲ။ အပေါ်ဆုံးမှ 703 သည် သူ၏ကိုယ်ပိုင် ငွေပေးငွေယူ ID ကို မည်သို့ပိတ်ဆို့ထားသည်ကို သင်တွေ့မြင်နိုင်ပါသည်။ ဤသည်မှာ Postgres အလုပ်လုပ်ပုံဖြစ်သည်။ 703 ကို ၎င်း၏ကိုယ်ပိုင် ငွေပေးငွေယူ ID ဖြင့် ပိတ်ဆို့ထားသောကြောင့် တစ်စုံတစ်ယောက်သည် စောင့်လိုပါက 703 ကို စောင့်ပါမည်။ အနှစ်သာရအားဖြင့် 703 သည် ပြီးမြောက်ပါသည်။ ၎င်းပြင်ပြီးမှသာ လုပ်ငန်းစဉ်များထဲမှ နိုးထလာမည်ဖြစ်သည်။ ပြီးတော့ ဒီဖြစ်စဉ်က ဘာဖြစ်မယ်ဆိုတာ အတိအကျ မသိရပါဘူး။ ပြီးရင်တော့ အရာအားလုံးကို ဖြည်းဖြည်းချင်း လုပ်ဆောင်ပါ။ သို့သော် မည်သည့် လုပ်ငန်းစဉ်ကို ဦးစွာ နိုးကြားရမည်ကို ရှင်းရှင်းလင်းလင်း မသိရသေးပေ။ အခြေခံအားဖြင့်၊ ကျွန်ုပ်တို့တွင် ဤလုပ်ငန်းစဉ်များအားလုံးကို ယခုနှိုးနိုင်ပြီဟု ပြောသည့် အချိန်ဇယားတစ်ခုရှိသည်။ ကျွန်တော်တို့က ကြုံသလို ရွေးလိုက်ရုံပါပဲ။ ဒါကြောင့် သူတို့နှစ်ယောက်လုံးကို နှိုးဆွပေးနိုင်တာကြောင့် သတိပြုဖို့ လိုပါတယ်။

ပြဿနာမှာ ကျွန်ုပ်တို့တွင် CP-infinity ရှိသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် နောက်ပိုင်းတွင် နိုးထလာနိုင်ဖွယ်ရှိသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် နောက်မှနိုးထလာပါက၊ ဘလောက်ကိုလက်ခံရရှိသူအား စောင့်ဆိုင်းရမည်ဖြစ်ပြီး၊ ထို့ကြောင့် မည်သူကအရင်နိုးထလာမည်ကို တိတိကျကျ မဆုံးဖြတ်နိုင်ပါ။ ကျွန်ုပ်တို့သည် ထိုကဲ့သို့သော အခြေအနေမျိုးကို ဖန်တီးပြီး စနစ်သည် ၎င်းတို့ကို ကျပန်းအစီအစဥ်ဖြင့် နှိုးဆွပေးမည်ဖြစ်သည်။

ရှိပါတယ် Egor Rogov ၏သော့ခတ်ခြင်းဆိုင်ရာဆောင်းပါးများ. ကြည့်ပါ၊ သူတို့လည်း စိတ်ဝင်စားစရာကောင်းပြီး အသုံးဝင်ပါတယ်။ ခေါင်းစဉ်၊ ဟုတ်ပါတယ်၊ အလွန်ရှုပ်ထွေးတယ်။ အရမ်းကျေးဇူးတင်ပါတယ် Bruce!

source: www.habr.com