Postgres ലോക്ക് മാനേജർ അൺലോക്ക് ചെയ്യുന്നു. ബ്രൂസ് മോംജിയാൻ

ബ്രൂസ് മോംജിയാന്റെ 2020 ലെ "പോസ്റ്റ്ഗ്രെസ് ലോക്ക് മാനേജർ അൺലോക്ക് ചെയ്യുന്നു" എന്ന സംഭാഷണത്തിന്റെ ട്രാൻസ്ക്രിപ്റ്റ്.

(ശ്രദ്ധിക്കുക: സ്ലൈഡുകളിൽ നിന്നുള്ള എല്ലാ SQL അന്വേഷണങ്ങളും ഈ ലിങ്കിൽ നിന്ന് ലഭിക്കും: http://momjian.us/main/writings/pgsql/locking.sql)

ഹലോ! റഷ്യയിൽ വീണ്ടും വന്നതിൽ സന്തോഷമുണ്ട്. കഴിഞ്ഞ വർഷം വരാൻ പറ്റാത്തതിൽ ഖേദിക്കുന്നു, ഈ വർഷം ഇവാനും എനിക്കും വലിയ പദ്ധതികളുണ്ട്. കൂടുതൽ തവണ ഇവിടെ ഉണ്ടായിരിക്കുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. എനിക്ക് റഷ്യയിൽ വരാൻ ഇഷ്ടമാണ്. ഞാൻ Tyumen, Tver സന്ദർശിക്കും. ഈ നഗരങ്ങൾ സന്ദർശിക്കാൻ കഴിഞ്ഞതിൽ എനിക്ക് അതിയായ സന്തോഷമുണ്ട്.

എന്റെ പേര് ബ്രൂസ് മോംജിയാൻ. ഞാൻ എന്റർപ്രൈസ് ഡിബിയിൽ ജോലിചെയ്യുന്നു, 23 വർഷത്തിലേറെയായി പോസ്റ്റ്ഗ്രേസിൽ പ്രവർത്തിക്കുന്നു. ഞാൻ അമേരിക്കയിലെ ഫിലാഡൽഫിയയിലാണ് താമസിക്കുന്നത്. ഞാൻ വർഷത്തിൽ 90 ദിവസത്തോളം യാത്ര ചെയ്യാറുണ്ട്. കൂടാതെ 40 ഓളം കോൺഫറൻസുകളിൽ ഞാൻ പങ്കെടുക്കുന്നു. Ente വെബ് സൈറ്റ്, അതിൽ ഞാൻ ഇപ്പോൾ കാണിക്കുന്ന സ്ലൈഡുകൾ അടങ്ങിയിരിക്കുന്നു. അതിനാൽ, കോൺഫറൻസിന് ശേഷം നിങ്ങൾക്ക് അവ എന്റെ സ്വകാര്യ വെബ്സൈറ്റിൽ നിന്ന് ഡൗൺലോഡ് ചെയ്യാം. 30 ഓളം അവതരണങ്ങളും ഇതിൽ അടങ്ങിയിരിക്കുന്നു. വീഡിയോകളും ധാരാളം ബ്ലോഗ് എൻട്രികളും ഉണ്ട്, 500-ലധികം. ഇത് തികച്ചും വിവരദായകമായ ഒരു ഉറവിടമാണ്. നിങ്ങൾക്ക് ഈ മെറ്റീരിയലിൽ താൽപ്പര്യമുണ്ടെങ്കിൽ, അത് ഉപയോഗിക്കാൻ ഞാൻ നിങ്ങളെ ക്ഷണിക്കുന്നു.

ഞാൻ പോസ്റ്റ്‌ഗ്രേസിൽ പ്രവർത്തിക്കാൻ തുടങ്ങുന്നതിനുമുമ്പ് ഞാൻ ഒരു അധ്യാപകനായിരുന്നു, ഒരു പ്രൊഫസറായിരുന്നു. ഞാൻ നിങ്ങളോട് പറയാൻ പോകുന്നത് ഇപ്പോൾ നിങ്ങളോട് പറയാൻ കഴിയുന്നതിൽ ഞാൻ വളരെ സന്തോഷവാനാണ്. ഇത് എന്റെ ഏറ്റവും രസകരമായ അവതരണങ്ങളിൽ ഒന്നാണ്. ഈ അവതരണത്തിൽ 110 സ്ലൈഡുകൾ അടങ്ങിയിരിക്കുന്നു. ഞങ്ങൾ ലളിതമായ കാര്യങ്ങളിൽ സംസാരിക്കാൻ തുടങ്ങും, അവസാനം റിപ്പോർട്ട് കൂടുതൽ കൂടുതൽ സങ്കീർണ്ണമാകും, അത് വളരെ സങ്കീർണ്ണമാകും.

ഇത് തികച്ചും അസുഖകരമായ സംഭാഷണമാണ്. തടയൽ ഏറ്റവും ജനപ്രിയമായ വിഷയമല്ല. ഇത് എവിടെയെങ്കിലും അപ്രത്യക്ഷമാകണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ദന്തഡോക്ടറുടെ അടുത്തേക്ക് പോകുന്നത് പോലെയാണ്.

1. ഡാറ്റാബേസുകളിൽ പ്രവർത്തിക്കുന്നവരും ഒരേ സമയം ഒന്നിലധികം പ്രക്രിയകൾ പ്രവർത്തിക്കുന്നവരുമായ ധാരാളം ആളുകൾക്ക് ലോക്കിംഗ് ഒരു പ്രശ്നമാണ്. അവർക്ക് തടയൽ ആവശ്യമാണ്. അതായത്, തടയുന്നതിനെക്കുറിച്ചുള്ള അടിസ്ഥാന അറിവ് ഇന്ന് ഞാൻ നിങ്ങൾക്ക് നൽകും.
2. ഇടപാട് ഐഡികൾ. ഇത് അവതരണത്തിന്റെ തികച്ചും വിരസമായ ഭാഗമാണ്, പക്ഷേ അവ മനസ്സിലാക്കേണ്ടതുണ്ട്.
3. അടുത്തതായി നമ്മൾ തടയുന്ന തരങ്ങളെക്കുറിച്ച് സംസാരിക്കും. ഇത് തികച്ചും മെക്കാനിക്കൽ ഭാഗമാണ്.
4. തടയുന്നതിനുള്ള ചില ഉദാഹരണങ്ങൾ ഞങ്ങൾ ചുവടെ നൽകും. അത് മനസ്സിലാക്കാൻ വളരെ ബുദ്ധിമുട്ടായിരിക്കും.

തടയുന്നതിനെക്കുറിച്ച് സംസാരിക്കാം.

നമ്മുടെ പദാവലി വളരെ സങ്കീർണ്ണമാണ്. നിങ്ങളിൽ എത്രപേർക്ക് ഈ ഭാഗം എവിടെ നിന്നാണ് വരുന്നതെന്ന് അറിയാം? രണ്ടു പേർ. ഇത് കൊളോസൽ കേവ് അഡ്വഞ്ചർ എന്ന ഗെയിമിൽ നിന്നുള്ളതാണ്. 80 കളിൽ ഇത് ഒരു ടെക്സ്റ്റ് അടിസ്ഥാനമാക്കിയുള്ള കമ്പ്യൂട്ടർ ഗെയിമായിരുന്നു, ഞാൻ കരുതുന്നു. അവിടെ നിങ്ങൾക്ക് ഒരു ഗുഹയിലേക്ക് പോകേണ്ടിവന്നു, ഒരു ലാബിരിന്തിലേക്ക്, വാചകം മാറി, പക്ഷേ ഉള്ളടക്കം ഓരോ തവണയും ഏതാണ്ട് സമാനമായിരുന്നു. അങ്ങനെയാണ് ഈ കളി ഞാൻ ഓർക്കുന്നത്.

ഒറാക്കിളിൽ നിന്ന് ഞങ്ങൾക്ക് വന്ന പൂട്ടുകളുടെ പേര് ഇവിടെ കാണാം. ഞങ്ങൾ അവ ഉപയോഗിക്കുന്നു.

എന്നെ ആശയക്കുഴപ്പത്തിലാക്കുന്ന പദങ്ങളാണ് ഇവിടെ കാണുന്നത്. ഉദാഹരണത്തിന്, EXLUSIVE അപ്‌ഡേറ്റ് പങ്കിടുക. അടുത്തത് റോ എക്‌സ്ലൂസീവ് പങ്കിടുക. സത്യം പറഞ്ഞാൽ, ഈ പേരുകൾ വളരെ വ്യക്തമല്ല. അവ കൂടുതൽ വിശദമായി പരിഗണിക്കാൻ ഞങ്ങൾ ശ്രമിക്കും. ചിലതിൽ "പങ്കിടുക" എന്ന വാക്ക് അടങ്ങിയിരിക്കുന്നു, അതായത് വേർതിരിക്കുക. ചിലതിൽ "എക്‌സ്‌ക്ലൂസീവ്" എന്ന വാക്ക് അടങ്ങിയിരിക്കുന്നു. ചിലതിൽ ഈ രണ്ടു വാക്കുകളും അടങ്ങിയിരിക്കുന്നു. ഈ ലോക്കുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് തുടങ്ങാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

കൂടാതെ "ആക്സസ്" എന്ന വാക്കും വളരെ പ്രധാനമാണ്. "വരി" എന്ന വാക്കുകൾ ഒരു സ്ട്രിംഗാണ്. അതായത്, പ്രവേശന വിതരണം, വരി വിതരണം.

പോസ്റ്റ്‌ഗ്രേസിൽ മനസ്സിലാക്കേണ്ട മറ്റൊരു പ്രശ്‌നം, നിർഭാഗ്യവശാൽ എന്റെ പ്രസംഗത്തിൽ എനിക്ക് ഉൾക്കൊള്ളാൻ കഴിയില്ല, MVCC ആണ്. എന്റെ വെബ്സൈറ്റിൽ ഈ വിഷയത്തിൽ എനിക്ക് ഒരു പ്രത്യേക അവതരണം ഉണ്ട്. ഈ അവതരണം കഠിനമാണെന്ന് നിങ്ങൾ കരുതുന്നുവെങ്കിൽ, MVCC ഒരുപക്ഷേ എന്റെ ഏറ്റവും പ്രയാസമേറിയതാണ്. നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ഇത് വെബ്സൈറ്റിൽ കാണാം. നിങ്ങൾക്ക് വീഡിയോ കാണാം.

നാം മനസ്സിലാക്കേണ്ട മറ്റൊരു കാര്യം ഇടപാട് ഐഡികളാണ്. അദ്വിതീയ ഐഡന്റിഫയറുകൾ ഇല്ലാതെ പല ഇടപാടുകളും പ്രവർത്തിക്കില്ല. ഒരു ഇടപാട് എന്താണെന്നതിന്റെ വിശദീകരണം ഇവിടെയുണ്ട്. പോസ്റ്റ്ഗ്രേസിന് രണ്ട് ഇടപാട് നമ്പറിംഗ് സംവിധാനങ്ങളുണ്ട്. ഇത് വളരെ മനോഹരമായ ഒരു പരിഹാരമല്ലെന്ന് എനിക്കറിയാം.

സ്ലൈഡുകൾ മനസിലാക്കാൻ വളരെ ബുദ്ധിമുട്ടാണ് എന്നതും ഓർക്കുക, അതിനാൽ ചുവപ്പ് നിറത്തിൽ ഹൈലൈറ്റ് ചെയ്തിരിക്കുന്നത് നിങ്ങൾ ശ്രദ്ധിക്കേണ്ട കാര്യമാണ്.

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

നമുക്ക് കാണാം. ഇടപാട് നമ്പർ ചുവപ്പിൽ ഹൈലൈറ്റ് ചെയ്തിരിക്കുന്നു. SELECT pg_back ഫംഗ്‌ഷൻ ഇവിടെ കാണിച്ചിരിക്കുന്നു. ഇത് എന്റെ ഇടപാടും ഇടപാട് ഐഡിയും തിരികെ നൽകുന്നു.

ഒരു കാര്യം കൂടി, നിങ്ങൾക്ക് ഈ അവതരണം ഇഷ്ടപ്പെടുകയും നിങ്ങളുടെ ഡാറ്റാബേസിൽ ഇത് പ്രവർത്തിപ്പിക്കാൻ ആഗ്രഹിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, നിങ്ങൾക്ക് പിങ്ക് നിറത്തിലുള്ള ഈ ലിങ്കിൽ പോയി ഈ അവതരണത്തിനായി SQL ഡൗൺലോഡ് ചെയ്യാം. നിങ്ങൾക്ക് ഇത് നിങ്ങളുടെ PSQL-ൽ പ്രവർത്തിപ്പിക്കാം, മുഴുവൻ അവതരണവും ഉടനടി നിങ്ങളുടെ സ്ക്രീനിൽ ദൃശ്യമാകും. അതിൽ പൂക്കൾ ഉണ്ടാകില്ല, പക്ഷേ നമുക്ക് അത് കാണാൻ കഴിയും.

ഈ സാഹചര്യത്തിൽ നമ്മൾ ഇടപാട് ഐഡി കാണുന്നു. ഇതാണ് ഞങ്ങൾ അവൾക്ക് നൽകിയ നമ്പർ. പോസ്റ്റ്‌ഗ്രേസിൽ മറ്റൊരു തരത്തിലുള്ള ഇടപാട് ഐഡിയുണ്ട്, അതിനെ വെർച്വൽ ട്രാൻസാക്ഷൻ ഐഡി എന്ന് വിളിക്കുന്നു

ഇത് നമ്മൾ മനസ്സിലാക്കുകയും വേണം. ഇത് വളരെ പ്രധാനമാണ്, അല്ലാത്തപക്ഷം Postgres-ൽ ലോക്ക് ചെയ്യുന്നത് നമുക്ക് മനസ്സിലാക്കാൻ കഴിയില്ല.

സ്ഥിരമായ മൂല്യങ്ങൾ അടങ്ങിയിട്ടില്ലാത്ത ഒരു ഇടപാട് ഐഡിയാണ് വെർച്വൽ ഇടപാട് ഐഡി. ഉദാഹരണത്തിന്, ഞാൻ ഒരു SELECT കമാൻഡ് പ്രവർത്തിപ്പിക്കുകയാണെങ്കിൽ, ഞാൻ മിക്കവാറും ഡാറ്റാബേസ് മാറ്റില്ല, ഞാൻ ഒന്നും ലോക്കുചെയ്യില്ല. അതിനാൽ ഞങ്ങൾ ഒരു ലളിതമായ SELECT റൺ ചെയ്യുമ്പോൾ, ആ ഇടപാടിന് ഞങ്ങൾ സ്ഥിരമായ ഒരു ഐഡി നൽകുന്നില്ല. അവിടെ ഞങ്ങൾ അവൾക്ക് ഒരു വെർച്വൽ ഐഡി മാത്രമാണ് നൽകുന്നത്.

ഇത് പോസ്റ്റ്‌ഗ്രേസിന്റെ പ്രകടനം മെച്ചപ്പെടുത്തുന്നു, ക്ലീനപ്പ് കഴിവുകൾ മെച്ചപ്പെടുത്തുന്നു, അതിനാൽ വെർച്വൽ ഇടപാട് ഐഡിയിൽ രണ്ട് നമ്പറുകൾ അടങ്ങിയിരിക്കുന്നു. സ്ലാഷിന് മുമ്പുള്ള ആദ്യത്തെ നമ്പർ ബാക്കെൻഡ് ഐഡിയാണ്. വലതുവശത്ത് ഞങ്ങൾ ഒരു കൗണ്ടർ കാണുന്നു.

അതിനാൽ, ഞാൻ ഒരു അഭ്യർത്ഥന നടത്തുകയാണെങ്കിൽ, ബാക്കെൻഡ് ഐഡി 2 ആണെന്ന് പറയുന്നു.

ഞാൻ അത്തരം ഇടപാടുകളുടെ ഒരു പരമ്പര നടത്തുകയാണെങ്കിൽ, ഓരോ തവണയും ഞാൻ ഒരു ചോദ്യം റൺ ചെയ്യുമ്പോൾ കൗണ്ടർ വർദ്ധിക്കുന്നതായി ഞങ്ങൾ കാണുന്നു. ഉദാഹരണത്തിന്, ഞാൻ അന്വേഷണം 2/10, 2/11, 2/12 മുതലായവ പ്രവർത്തിപ്പിക്കുമ്പോൾ.

ഇവിടെ രണ്ട് നിരകളുണ്ടെന്ന് ഓർമ്മിക്കുക. ഇടതുവശത്ത് നമ്മൾ വെർച്വൽ ട്രാൻസാക്ഷൻ ഐഡി കാണുന്നു - 2/12. വലതുവശത്ത് ഞങ്ങൾക്ക് ഒരു സ്ഥിരമായ ഇടപാട് ഐഡിയുണ്ട്. കൂടാതെ ഈ ഫീൽഡ് ശൂന്യമാണ്. ഈ ഇടപാട് ഡാറ്റാബേസിൽ മാറ്റം വരുത്തുന്നില്ല. അതിനാൽ ഞാൻ അതിന് ഒരു സ്ഥിരമായ ഇടപാട് ഐഡി നൽകുന്നില്ല.

ഞാൻ വിശകലന കമാൻഡ് ((വിശകലനം) റൺ ചെയ്യുമ്പോൾ, അതേ ചോദ്യം എനിക്ക് ഒരു സ്ഥിരമായ ഇടപാട് ഐഡി നൽകുന്നു. ഇത് നമുക്ക് എങ്ങനെ മാറിയെന്ന് നോക്കൂ. എനിക്ക് മുമ്പ് ഈ ഐഡി ഇല്ലായിരുന്നു, എന്നാൽ ഇപ്പോൾ എനിക്കത് ഉണ്ട്.

അതിനാൽ ഇതാ മറ്റൊരു അഭ്യർത്ഥന, മറ്റൊരു ഇടപാട്. വെർച്വൽ ഇടപാട് നമ്പർ 2/13 ആണ്. ഞാൻ ഒരു സ്ഥിരമായ ഇടപാട് ഐഡി ആവശ്യപ്പെടുകയാണെങ്കിൽ, ഞാൻ ചോദ്യം റൺ ചെയ്യുമ്പോൾ, എനിക്ക് അത് ലഭിക്കും.

അതിനാൽ, ഒരിക്കൽ കൂടി. ഞങ്ങൾക്ക് ഒരു വെർച്വൽ ഇടപാട് ഐഡിയും സ്ഥിരമായ ഒരു ഇടപാട് ഐഡിയും ഉണ്ട്. Postgres പെരുമാറ്റം മനസ്സിലാക്കാൻ ഈ പോയിന്റ് മനസ്സിലാക്കുക.

ഞങ്ങൾ മൂന്നാമത്തെ വിഭാഗത്തിലേക്ക് പോകുന്നു. ഇവിടെ നമ്മൾ പോസ്‌റ്റ്‌ഗ്രെസിലെ വിവിധ തരം ലോക്കുകളിലൂടെ നടക്കാം. ഇത് വളരെ രസകരമല്ല. അവസാന ഭാഗം കൂടുതൽ രസകരമായിരിക്കും. എന്നാൽ നമ്മൾ അടിസ്ഥാന കാര്യങ്ങൾ പരിഗണിക്കണം, കാരണം അടുത്തതായി എന്ത് സംഭവിക്കുമെന്ന് നമുക്ക് മനസ്സിലാകില്ല.

ഞങ്ങൾ ഈ വിഭാഗത്തിലൂടെ കടന്നുപോകും, ​​ഓരോ തരത്തിലുള്ള ലോക്കും ഞങ്ങൾ നോക്കും. അവ എങ്ങനെ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ട്, അവ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിന്റെ ഉദാഹരണങ്ങൾ ഞാൻ നിങ്ങൾക്ക് കാണിച്ചുതരാം, പോസ്റ്റ്‌ഗ്രേസിൽ ലോക്കിംഗ് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണാൻ നിങ്ങൾക്ക് ഉപയോഗിക്കാനാകുന്ന ചില അന്വേഷണങ്ങൾ ഞാൻ കാണിച്ചുതരാം.

ഒരു ചോദ്യം സൃഷ്ടിക്കുന്നതിനും Postgres-ൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് കാണുന്നതിനും, ഞങ്ങൾ സിസ്റ്റം കാഴ്ചയിൽ ചോദ്യം നൽകേണ്ടതുണ്ട്. ഈ സാഹചര്യത്തിൽ, pg_lock ചുവപ്പിൽ ഹൈലൈറ്റ് ചെയ്തിരിക്കുന്നു. Pg_lock എന്നത് പോസ്റ്റ്‌ഗ്രേസിൽ നിലവിൽ ഉപയോഗിക്കുന്ന ലോക്കുകൾ ഏതൊക്കെയാണെന്ന് നമ്മോട് പറയുന്ന ഒരു സിസ്റ്റം ടേബിളാണ്.

എന്നിരുന്നാലും, വളരെ സങ്കീർണ്ണമായതിനാൽ pg_lock സ്വയം കാണിക്കുന്നത് എനിക്ക് വളരെ ബുദ്ധിമുട്ടാണ്. അതിനാൽ ഞാൻ pg_locks കാണിക്കുന്ന ഒരു കാഴ്ച സൃഷ്ടിച്ചു. കൂടാതെ ഇത് എന്നെ നന്നായി മനസ്സിലാക്കാൻ അനുവദിക്കുന്ന ചില ജോലികളും ചെയ്യുന്നു. അതായത്, ഇത് എന്റെ ലോക്കുകൾ, എന്റെ സ്വന്തം സെഷൻ മുതലായവ ഒഴിവാക്കുന്നു. ഇത് സാധാരണ SQL മാത്രമാണ്, എന്താണ് സംഭവിക്കുന്നതെന്ന് നിങ്ങൾക്ക് നന്നായി കാണിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

മറ്റൊരു പ്രശ്നം, ഈ കാഴ്ച വളരെ വിശാലമാണ്, അതിനാൽ എനിക്ക് രണ്ടാമത്തേത് സൃഷ്ടിക്കേണ്ടതുണ്ട് - ലോക്ക്വ്യൂ2.

കൂടാതെ ഇത് പട്ടികയിൽ നിന്ന് കൂടുതൽ കോളങ്ങൾ കാണിക്കുന്നു. ബാക്കിയുള്ള കോളങ്ങൾ എനിക്ക് കാണിക്കുന്ന മറ്റൊന്ന്. ഇത് വളരെ സങ്കീർണ്ണമാണ്, അതിനാൽ കഴിയുന്നത്ര ലളിതമായി അവതരിപ്പിക്കാൻ ഞാൻ ശ്രമിച്ചു.

അങ്ങനെ ഞങ്ങൾ Lockdemo എന്നൊരു പട്ടിക ഉണ്ടാക്കി. ഞങ്ങൾ അവിടെ ഒരു വരി സൃഷ്ടിച്ചു. ഇതാണ് ഞങ്ങളുടെ മാതൃകാ പട്ടിക. ലോക്കുകളുടെ ഉദാഹരണങ്ങൾ കാണിക്കുന്നതിനായി ഞങ്ങൾ വിഭാഗങ്ങൾ സൃഷ്ടിക്കും.

അതിനാൽ, ഒരു വരി, ഒരു നിര. ആദ്യത്തെ തരം ലോക്കിനെ ആക്‌സസ് ഷെയർ എന്ന് വിളിക്കുന്നു. ഇതാണ് ഏറ്റവും കുറഞ്ഞ നിയന്ത്രിത തടയൽ. ഇത് പ്രായോഗികമായി മറ്റ് ലോക്കുകളുമായി പൊരുത്തപ്പെടുന്നില്ല എന്നാണ് ഇതിനർത്ഥം.

ഒരു ലോക്ക് വ്യക്തമായി നിർവചിക്കണമെങ്കിൽ, ഞങ്ങൾ "ലോക്ക് ടേബിൾ" കമാൻഡ് പ്രവർത്തിപ്പിക്കുന്നു. അത് വ്യക്തമായും തടയും, അതായത് ആക്‌സസ് ഷെയർ മോഡിൽ ഞങ്ങൾ ലോക്ക് ടേബിൾ സമാരംഭിക്കുന്നു. ഞാൻ പശ്ചാത്തലത്തിൽ PSQL പ്രവർത്തിപ്പിക്കുകയാണെങ്കിൽ, എന്റെ ആദ്യ സെഷനിൽ നിന്ന് ഞാൻ ഈ രീതിയിൽ രണ്ടാമത്തെ സെഷൻ ആരംഭിക്കുന്നു. അതായത്, ഞാൻ ഇവിടെ എന്ത് ചെയ്യും? ഞാൻ മറ്റൊരു സെഷനിലേക്ക് പോയി "ഈ അഭ്യർത്ഥനയ്ക്കുള്ള ലോക്ക് വ്യൂ എന്നെ കാണിക്കൂ" എന്ന് പറഞ്ഞു. ഈ പട്ടികയിൽ എനിക്ക് ആക്സസ്ഷെയർലോക്ക് ഉണ്ട്. ഇതുതന്നെയാണ് ഞാൻ ആവശ്യപ്പെട്ടതും. കൂടാതെ ബ്ലോക്ക് ഏൽപ്പിച്ചിട്ടുണ്ടെന്നും അദ്ദേഹം പറയുന്നു. വളരെ ലളിതം.

കൂടാതെ, രണ്ടാമത്തെ കോളം നോക്കിയാൽ, അവിടെ ഒന്നുമില്ല. അവ ശൂന്യമാണ്.

ഞാൻ "SELECT" കമാൻഡ് പ്രവർത്തിപ്പിക്കുകയാണെങ്കിൽ, AccessShareLock അഭ്യർത്ഥിക്കുന്നതിനുള്ള വ്യക്തമായ (വ്യക്തമായ) മാർഗമാണിത്. അതിനാൽ ഞാൻ എന്റെ ടേബിൾ റിലീസ് ചെയ്‌ത് ചോദ്യം റൺ ചെയ്യുന്നു, ചോദ്യം ഒന്നിലധികം വരികൾ നൽകുന്നു. ഒരു വരിയിൽ നമ്മൾ AccessShareLock കാണുന്നു. അങ്ങനെ, SELECT ടേബിളിൽ AccessShareLock എന്ന് വിളിക്കുന്നു. ലോ-ലെവൽ ലോക്കായതിനാൽ ഫലത്തിൽ യാതൊന്നിനോടും ഇത് വൈരുദ്ധ്യമില്ല.

ഞാൻ ഒരു SELECT പ്രവർത്തിപ്പിക്കുകയും മൂന്ന് വ്യത്യസ്ത ടേബിളുകൾ ഉണ്ടെങ്കിൽ എന്ത് ചെയ്യും? മുമ്പ് ഞാൻ ഒരു ടേബിൾ മാത്രമാണ് പ്രവർത്തിപ്പിച്ചിരുന്നത്, ഇപ്പോൾ ഞാൻ മൂന്ന് പ്രവർത്തിക്കുന്നു: pg_class, pg_namespace, pg_attribute.

ഇപ്പോൾ ഞാൻ ചോദ്യം നോക്കുമ്പോൾ, മൂന്ന് ടേബിളുകളിലായി 9 AccessShareLocks ഞാൻ കാണുന്നു. എന്തുകൊണ്ട്? മൂന്ന് പട്ടികകൾ നീല നിറത്തിൽ ഹൈലൈറ്റ് ചെയ്തിരിക്കുന്നു: pg_attribute, pg_class, pg_namespace. എന്നാൽ ഈ ടേബിളുകളിലൂടെ നിർവചിച്ചിരിക്കുന്ന എല്ലാ സൂചികകൾക്കും AccessShareLock ഉണ്ടെന്നും നിങ്ങൾക്ക് കാണാൻ കഴിയും.

ഇത് പ്രായോഗികമായി മറ്റുള്ളവരുമായി വൈരുദ്ധ്യമില്ലാത്ത ഒരു ലോക്കാണ്. പട്ടിക തിരഞ്ഞെടുക്കുമ്പോൾ അത് റീസെറ്റ് ചെയ്യുന്നതിൽ നിന്ന് ഞങ്ങളെ തടയുക മാത്രമാണ് ഇത് ചെയ്യുന്നത്. അർത്ഥവത്താണ്. അതായത്, ഞങ്ങൾ ഒരു പട്ടിക തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ, അത് ആ നിമിഷം അപ്രത്യക്ഷമാകും, അപ്പോൾ ഇത് തെറ്റാണ്, അതിനാൽ "ഞാൻ ജോലി ചെയ്യുന്ന സമയത്ത് ഈ ടേബിൾ ഉപേക്ഷിക്കരുത്" എന്ന് ഞങ്ങളോട് പറയുന്ന ലോ ലെവൽ ലോക്കാണ് AccessShare. അടിസ്ഥാനപരമായി, അവൾ ചെയ്യുന്നത് അത്രമാത്രം.

റോ ഷെയർ - ഈ ലോക്ക് അൽപ്പം വ്യത്യസ്തമാണ്.

നമുക്ക് ഒരു ഉദാഹരണം എടുക്കാം. ഓരോ വരിയും വ്യക്തിഗതമായി ലോക്ക് ചെയ്യുന്നതിനുള്ള വരി പങ്കിടൽ രീതി തിരഞ്ഞെടുക്കുക. ഇത്തരത്തിൽ നമ്മൾ കാണുമ്പോൾ ആർക്കും അവ ഇല്ലാതാക്കാനോ മാറ്റാനോ കഴിയില്ല.

അപ്പോൾ SHARE LOCK എന്താണ് ചെയ്യുന്നത്? SELECT എന്നതിനായുള്ള ഇടപാട് ഐഡി 681 ആണെന്ന് ഞങ്ങൾ കാണുന്നു. ഇത് രസകരമാണ്. ഇവിടെ എന്താണ് സംഭവിച്ചത്? നമ്മൾ ആദ്യമായി നമ്പർ കാണുന്നത് "ലോക്ക്" ഫീൽഡിലാണ്. ഞങ്ങൾ ഇടപാട് ഐഡി എടുക്കുന്നു, അത് എക്‌സ്‌ക്ലൂസീവ് മോഡിൽ തടയുകയാണെന്ന് പറയുന്നു. മേശയിൽ എവിടെയോ സാങ്കേതികമായി പൂട്ടിയ ഒരു വരി എനിക്കുണ്ടെന്ന് പറയുക മാത്രമാണ് അത് ചെയ്യുന്നത്. എന്നാൽ എവിടെയാണെന്ന് അദ്ദേഹം കൃത്യമായി പറയുന്നില്ല. ഞങ്ങൾ ഇത് കുറച്ച് കഴിഞ്ഞ് കൂടുതൽ വിശദമായി നോക്കാം.

ലോക്ക് നമ്മൾ ഉപയോഗിക്കുന്നതാണെന്ന് ഇവിടെ ഞങ്ങൾ പറയുന്നു.

അതിനാൽ, ഒരു എക്സ്ക്ലൂസീവ് ലോക്ക് അത് എക്സ്ക്ലൂസീവ് ആണെന്ന് വ്യക്തമായി പറയുന്നു. കൂടാതെ, നിങ്ങൾ ഈ പട്ടികയിലെ ഒരു വരി ഇല്ലാതാക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ ഇതാണ് സംഭവിക്കുക.

SHARE EXCLUSIVE ദൈർഘ്യമേറിയ ലോക്കാണ്.

ഇതാണ് (വിശകലനം) അനലൈസർ കമാൻഡ് ഉപയോഗിക്കുന്നത്.

ഷെയർ ലോക്ക് - നിങ്ങൾക്ക് ഷെയർ മോഡിൽ വ്യക്തമായി ലോക്ക് ചെയ്യാം.

നിങ്ങൾക്ക് ഒരു അദ്വിതീയ സൂചിക സൃഷ്ടിക്കാനും കഴിയും. അവിടെ നിങ്ങൾക്ക് അവരുടെ ഭാഗമായ SHARE LOCK കാണാം. അത് മേശ പൂട്ടി അതിൽ ഒരു SHARE LOCK ഇടുന്നു.

ഡിഫോൾട്ടായി, ഒരു മേശയിലെ ലോക്ക് പങ്കിടുക എന്നതിനർത്ഥം മറ്റുള്ളവർക്ക് പട്ടിക വായിക്കാൻ കഴിയും, എന്നാൽ ആർക്കും അത് പരിഷ്‌ക്കരിക്കാൻ കഴിയില്ല എന്നാണ്. നിങ്ങൾ ഒരു അദ്വിതീയ സൂചിക സൃഷ്ടിക്കുമ്പോൾ ഇത് തന്നെയാണ് സംഭവിക്കുന്നത്.

ഞാൻ ഒരു അദ്വിതീയ സമകാലിക സൂചിക സൃഷ്ടിക്കുകയാണെങ്കിൽ, എനിക്ക് മറ്റൊരു തരത്തിലുള്ള ലോക്കിംഗ് ഉണ്ടാകും, കാരണം നിങ്ങൾ ഓർക്കുന്നതുപോലെ, ഒരേസമയം സൂചികകൾ ഉപയോഗിക്കുന്നത് ലോക്കിംഗ് ആവശ്യകത കുറയ്ക്കുന്നു. ഞാൻ ഒരു സാധാരണ ലോക്ക്, ഒരു സാധാരണ സൂചിക ഉപയോഗിക്കുകയാണെങ്കിൽ, അത് സൃഷ്ടിക്കുമ്പോൾ പട്ടിക സൂചികയിലേക്ക് എഴുതുന്നത് ഞാൻ തടയും. ഞാൻ ഒരു കൺകറന്റ്ലി ഇൻഡക്സ് ഉപയോഗിക്കുകയാണെങ്കിൽ, എനിക്ക് മറ്റൊരു തരം ലോക്കിംഗ് ഉപയോഗിക്കേണ്ടതുണ്ട്.

വരി എക്സ്ക്ലൂസീവ് പങ്കിടുക - വീണ്ടും അത് വ്യക്തമായി (വ്യക്തമായി) സജ്ജമാക്കാൻ കഴിയും.

അല്ലെങ്കിൽ നമുക്ക് ഒരു നിയമം സൃഷ്ടിക്കാൻ കഴിയും, അതായത്, അത് ഉപയോഗിക്കുന്ന ഒരു പ്രത്യേക കേസ് എടുക്കുക.

EXCLUSIVE ലോക്കിംഗ് എന്നാൽ മറ്റാർക്കും പട്ടിക മാറ്റാൻ കഴിയില്ല എന്നാണ്.

വിവിധ തരത്തിലുള്ള പൂട്ടുകൾ ഇവിടെ കാണാം.

ACCESS EXCLUSIVE, ഉദാഹരണത്തിന്, ഒരു തടയൽ കമാൻഡ് ആണ്. ഉദാഹരണത്തിന്, നിങ്ങൾ ചെയ്താൽ CLUSTER table, അപ്പോൾ ആർക്കും അവിടെ എഴുതാൻ കഴിയില്ല എന്നാണ് ഇതിനർത്ഥം. ഇത് പട്ടികയെ മാത്രമല്ല, സൂചികകളെയും പൂട്ടുന്നു.

ഇത് ആക്‌സസ് എക്‌സ്‌ക്ലൂസീവ് ബ്ലോക്കിംഗിന്റെ രണ്ടാമത്തെ പേജാണ്, ഇവിടെ അത് കൃത്യമായി എന്താണ് തടയുന്നതെന്ന് പട്ടികയിൽ കാണാം. ഇത് വ്യക്തിഗത പട്ടിക വരികൾ പൂട്ടുന്നു, അത് വളരെ രസകരമാണ്.

ഞാൻ നൽകാൻ ആഗ്രഹിച്ച അടിസ്ഥാന വിവരങ്ങൾ അത്രയേയുള്ളൂ. ഞങ്ങൾ ലോക്കുകളെക്കുറിച്ചും ഇടപാട് ഐഡികളെക്കുറിച്ചും വെർച്വൽ ഇടപാട് ഐഡികളെക്കുറിച്ചും സ്ഥിരമായ ഇടപാട് ഐഡികളെക്കുറിച്ചും സംസാരിച്ചു.

ഇപ്പോൾ നമ്മൾ ചില തടയൽ ഉദാഹരണങ്ങളിലൂടെ കടന്നുപോകും. ഇതാണ് ഏറ്റവും രസകരമായ ഭാഗം. ഞങ്ങൾ വളരെ രസകരമായ കേസുകൾ നോക്കും. ഈ അവതരണത്തിലെ എന്റെ ലക്ഷ്യം ചില കാര്യങ്ങൾ തടയാൻ ശ്രമിക്കുമ്പോൾ പോസ്റ്റ്‌ഗ്രേസ് യഥാർത്ഥത്തിൽ എന്താണ് ചെയ്യുന്നതെന്ന് നിങ്ങൾക്ക് നന്നായി മനസ്സിലാക്കുക എന്നതാണ്. ഭാഗങ്ങൾ തടയുന്നതിൽ അദ്ദേഹം വളരെ നല്ലവനാണെന്ന് ഞാൻ കരുതുന്നു.

ചില പ്രത്യേക ഉദാഹരണങ്ങൾ നോക്കാം.

ഞങ്ങൾ പട്ടികകളും ഒരു പട്ടികയിലെ ഒരു വരിയും ഉപയോഗിച്ച് ആരംഭിക്കും. ഞാൻ എന്തെങ്കിലും തിരുകുമ്പോൾ, ടേബിളിൽ എക്‌സ്‌ക്ലൂസീവ് ലോക്ക്, ട്രാൻസാക്ഷൻ ഐഡി, എക്‌സ്‌ക്ലൂസീവ് ലോക്ക് എന്നിവ പ്രദർശിപ്പിക്കും.

ഞാൻ രണ്ട് വരികൾ കൂടി ചേർത്താൽ എന്ത് സംഭവിക്കും? ഇപ്പോൾ ഞങ്ങളുടെ ടേബിളിൽ മൂന്ന് വരികളുണ്ട്. ഞാൻ ഒരു വരി തിരുകുകയും ഇത് ഒരു ഔട്ട്പുട്ടായി ലഭിക്കുകയും ചെയ്തു. ഞാൻ രണ്ട് വരികൾ കൂടി ചേർത്താൽ, അതിൽ എന്താണ് വിചിത്രം? ഇവിടെ ഒരു വിചിത്രമായ കാര്യമുണ്ട്, കാരണം ഞാൻ ഈ ടേബിളിൽ മൂന്ന് വരികൾ ചേർത്തിട്ടുണ്ട്, പക്ഷേ എനിക്ക് ഇപ്പോഴും ലോക്ക് ടേബിളിൽ രണ്ട് വരികളുണ്ട്. ഇത് പ്രധാനമായും പോസ്റ്റ്ഗ്രേസിന്റെ അടിസ്ഥാന സ്വഭാവമാണ്.

ഒരു ഡാറ്റാബേസിൽ നിങ്ങൾ 100 വരികൾ ലോക്ക് ചെയ്യുകയാണെങ്കിൽ, നിങ്ങൾ 100 ലോക്ക് എൻട്രികൾ സൃഷ്ടിക്കേണ്ടതുണ്ടെന്ന് പലരും കരുതുന്നു. ഞാൻ ഒരേസമയം 1 വരികൾ തടയുകയാണെങ്കിൽ, എനിക്ക് അത്തരം 000 ചോദ്യങ്ങൾ ആവശ്യമായി വരും. തടയാൻ എനിക്ക് ഒരു ദശലക്ഷം അല്ലെങ്കിൽ ഒരു ബില്യൺ ആവശ്യമുണ്ടെങ്കിൽ. എന്നാൽ നമ്മൾ ഇത് ചെയ്താൽ, അത് നന്നായി പ്രവർത്തിക്കില്ല. ഓരോ വരിയിലും തടയൽ എൻട്രികൾ സൃഷ്ടിക്കുന്ന ഒരു സിസ്റ്റം നിങ്ങൾ ഉപയോഗിച്ചിട്ടുണ്ടെങ്കിൽ, ഇത് സങ്കീർണ്ണമാണെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും. കാരണം, കവിഞ്ഞൊഴുകാൻ കഴിയുന്ന ഒരു ലോക്ക് ടേബിൾ നിങ്ങൾ ഉടനടി നിർവചിക്കേണ്ടതുണ്ട്, പക്ഷേ Postgres അത് ചെയ്യുന്നില്ല.

ഈ സ്ലൈഡിനെ സംബന്ധിച്ച് ശരിക്കും പ്രധാനപ്പെട്ടത്, MVCC-ക്കുള്ളിൽ വ്യക്തിഗത വരികൾ പൂട്ടുന്ന മറ്റൊരു സിസ്റ്റം ഉണ്ടെന്ന് ഇത് വ്യക്തമായി തെളിയിക്കുന്നു എന്നതാണ്. അതിനാൽ നിങ്ങൾ കോടിക്കണക്കിന് വരികൾ ലോക്ക് ചെയ്യുമ്പോൾ, Postgres ഒരു ബില്യൺ പ്രത്യേക ലോക്കിംഗ് കമാൻഡുകൾ സൃഷ്ടിക്കുന്നില്ല. ഇത് ഉൽപ്പാദനക്ഷമതയിൽ വളരെ നല്ല സ്വാധീനം ചെലുത്തുന്നു.

ഒരു അപ്‌ഡേറ്റിന്റെ കാര്യമോ? ഞാൻ ഇപ്പോൾ വരി അപ്‌ഡേറ്റ് ചെയ്യുകയാണ്, അത് ഒരേസമയം രണ്ട് വ്യത്യസ്ത പ്രവർത്തനങ്ങൾ നടത്തിയതായി നിങ്ങൾക്ക് കാണാൻ കഴിയും. അത് ഒരേ സമയം ടേബിൾ ലോക്ക് ചെയ്തു, പക്ഷേ അത് സൂചികയും പൂട്ടി. ഈ പട്ടികയിൽ അദ്വിതീയമായ നിയന്ത്രണങ്ങൾ ഉള്ളതിനാൽ അയാൾക്ക് സൂചിക ലോക്ക് ചെയ്യേണ്ടതുണ്ട്. ആരും അത് മാറ്റുന്നില്ലെന്ന് ഉറപ്പാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു, അതിനാൽ ഞങ്ങൾ ഇത് തടയുന്നു.

എനിക്ക് രണ്ട് വരികൾ അപ്‌ഡേറ്റ് ചെയ്യണമെങ്കിൽ എന്ത് സംഭവിക്കും? അവൻ അതേ രീതിയിൽ പെരുമാറുന്നതായി നാം കാണുന്നു. ഞങ്ങൾ ഇരട്ടി അപ്‌ഡേറ്റുകൾ ചെയ്യുന്നു, എന്നാൽ അതേ എണ്ണം ലോക്ക് ലൈനുകൾ.

പോസ്റ്റ്‌ഗ്രേസ് ഇത് എങ്ങനെ ചെയ്യുന്നുവെന്ന് നിങ്ങൾ ആശ്ചര്യപ്പെടുന്നുണ്ടെങ്കിൽ, പോസ്റ്റ്‌ഗ്രേസ് ഈ വരികൾ എങ്ങനെ ആന്തരികമായി അടയാളപ്പെടുത്തുന്നു എന്നറിയാൻ MVCC-യെക്കുറിച്ചുള്ള എന്റെ സംഭാഷണങ്ങൾ നിങ്ങൾ ശ്രദ്ധിക്കേണ്ടതുണ്ട്. പോസ്റ്റ്‌ഗ്രേസിന് ഇത് ചെയ്യുന്നതിന് ഒരു മാർഗമുണ്ട്, പക്ഷേ ഇത് ടേബിൾ ലോക്കിംഗ് തലത്തിൽ ചെയ്യുന്നില്ല, അത് താഴ്ന്നതും കൂടുതൽ കാര്യക്ഷമവുമായ തലത്തിലാണ് ചെയ്യുന്നത്.

എനിക്ക് എന്തെങ്കിലും ഇല്ലാതാക്കണമെങ്കിൽ എന്തുചെയ്യും? ഞാൻ ഇല്ലാതാക്കുകയാണെങ്കിൽ, ഉദാഹരണത്തിന്, ഒരു വരിയും എന്റെ രണ്ട് തടയൽ ഇൻപുട്ടുകളും ഇപ്പോഴും എനിക്കുണ്ട്, അവയെല്ലാം ഇല്ലാതാക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നുവെങ്കിലും, അവ ഇപ്പോഴും അവിടെയുണ്ട്.

കൂടാതെ, ഉദാഹരണത്തിന്, എനിക്ക് 1 വരികൾ ചേർക്കണം, തുടർന്ന് 000 വരികൾ ഇല്ലാതാക്കുകയോ ചേർക്കുകയോ ചെയ്യണം, തുടർന്ന് ഞാൻ ചേർക്കുന്നതോ മാറ്റുന്നതോ ആയ വ്യക്തിഗത വരികൾ ഇവിടെ രേഖപ്പെടുത്തില്ല. പരമ്പരയ്ക്കുള്ളിൽ തന്നെ താഴ്ന്ന നിലയിലാണ് അവ എഴുതിയിരിക്കുന്നത്. എംവിസിസി പ്രസംഗത്തിൽ ഞാൻ ഇതിനെക്കുറിച്ച് വിശദമായി സംസാരിച്ചു. എന്നാൽ നിങ്ങൾ ലോക്കുകൾ വിശകലനം ചെയ്യുമ്പോൾ, നിങ്ങൾ ടേബിൾ ലെവലിലാണ് ലോക്ക് ചെയ്യുന്നതെന്നും വ്യക്തിഗത വരികൾ ഇവിടെ രേഖപ്പെടുത്തുന്നത് എങ്ങനെയെന്ന് നിങ്ങൾ കാണുന്നില്ലെന്നും ഉറപ്പാക്കേണ്ടത് വളരെ പ്രധാനമാണ്.

വ്യക്തമായ തടയൽ സംബന്ധിച്ചെന്ത്?

ഞാൻ പുതുക്കുക ക്ലിക്ക് ചെയ്താൽ, എനിക്ക് രണ്ട് വരികൾ ലോക്ക് ചെയ്തിരിക്കുന്നു. ഞാൻ അവയെല്ലാം തിരഞ്ഞെടുത്ത് "എല്ലായിടത്തും അപ്‌ഡേറ്റ് ചെയ്യുക" ക്ലിക്ക് ചെയ്താൽ, എനിക്ക് ഇപ്പോഴും രണ്ട് തടയൽ റെക്കോർഡുകൾ ഉണ്ട്.

ഓരോ വ്യക്തിഗത വരികൾക്കും ഞങ്ങൾ പ്രത്യേക റെക്കോർഡുകൾ സൃഷ്ടിക്കുന്നില്ല. ഉൽപ്പാദനക്ഷമത കുറയുന്നതിനാൽ, അത് വളരെയധികം ഉണ്ടാകാം. കൂടാതെ, ഒരു അസുഖകരമായ അവസ്ഥയിൽ നാം നമ്മെത്തന്നെ കണ്ടെത്തിയേക്കാം.

ഒരേ കാര്യം, നമ്മൾ ഷെയർ ചെയ്താൽ 30 തവണ ചെയ്യാം.

ഞങ്ങൾ ഞങ്ങളുടെ പട്ടിക പുനഃസ്ഥാപിക്കുന്നു, എല്ലാം ഇല്ലാതാക്കുന്നു, തുടർന്ന് ഒരു വരി വീണ്ടും ചേർക്കുക.

പോസ്റ്റ്‌ഗ്രേസിൽ നിങ്ങൾ കാണുന്ന മറ്റൊരു പെരുമാറ്റം വളരെ നന്നായി അറിയപ്പെടുന്നതും ആവശ്യമുള്ളതുമായ സ്വഭാവമാണ്, നിങ്ങൾക്ക് ഒരു അപ്‌ഡേറ്റ് ചെയ്യാനോ തിരഞ്ഞെടുക്കാനോ കഴിയും എന്നതാണ്. നിങ്ങൾക്ക് ഇത് ഒരേ സമയം ചെയ്യാൻ കഴിയും. കൂടാതെ തിരഞ്ഞെടുക്കുക അപ്‌ഡേറ്റ് തടയുന്നില്ല, വിപരീത ദിശയിലുള്ള അതേ കാര്യം. എഴുത്തുകാരനെ തടയരുതെന്ന് ഞങ്ങൾ വായനക്കാരോട് പറയുന്നു, എഴുത്തുകാരൻ വായനക്കാരനെ തടഞ്ഞിട്ടില്ല.

ഇതിന്റെ ഒരു ഉദാഹരണം ഞാൻ നിങ്ങൾക്ക് കാണിച്ചുതരാം. ഞാൻ ഇപ്പോൾ ഒരു തിരഞ്ഞെടുപ്പ് നടത്തും. അതിനുശേഷം ഞങ്ങൾ INSERT ചെയ്യും. തുടർന്ന് നിങ്ങൾക്ക് കാണാം - 694. ഈ ഉൾപ്പെടുത്തൽ നടത്തിയ ഇടപാടിന്റെ ഐഡി നിങ്ങൾക്ക് കാണാൻ കഴിയും. അങ്ങനെയാണ് ഇത് പ്രവർത്തിക്കുന്നത്.

ഞാൻ ഇപ്പോൾ എന്റെ ബാക്കെൻഡ് ഐഡി നോക്കുകയാണെങ്കിൽ, അത് ഇപ്പോൾ 695 ആണ്.

എന്റെ ടേബിളിൽ 695 പ്രത്യക്ഷപ്പെടുന്നത് എനിക്ക് കാണാം.

ഞാൻ ഇവിടെ ഇതുപോലെ അപ്‌ഡേറ്റ് ചെയ്‌താൽ, എനിക്ക് മറ്റൊരു കേസ് ലഭിക്കും. ഈ സാഹചര്യത്തിൽ, 695 ഒരു എക്സ്ക്ലൂസീവ് ലോക്ക് ആണ്, അപ്ഡേറ്റിന് സമാന സ്വഭാവമുണ്ട്, എന്നാൽ അവയ്ക്കിടയിൽ ഒരു വൈരുദ്ധ്യവുമില്ല, അത് തികച്ചും അസാധാരണമാണ്.

മുകളിൽ ഷെയർലോക്കും താഴെ എക്‌സ്‌ക്ലൂസീവ് ലോക്കും ആണെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും. കൂടാതെ രണ്ട് ഇടപാടുകളും വിജയിച്ചു.

ഇത് എങ്ങനെ സംഭവിക്കുന്നുവെന്ന് മനസിലാക്കാൻ നിങ്ങൾ എംവിസിസിയിലെ എന്റെ പ്രസംഗം ശ്രദ്ധിക്കേണ്ടതുണ്ട്. എന്നാൽ ഇത് നിങ്ങൾക്ക് ഒരേ സമയം ചെയ്യാൻ കഴിയുമെന്നതിന്റെ ഒരു ചിത്രീകരണമാണ്, അതായത് ഒരേ സമയം ഒരു SELECT ഉം അപ്‌ഡേറ്റും ചെയ്യുക.

നമുക്ക് റീസെറ്റ് ചെയ്ത് ഒരു ഓപ്പറേഷൻ കൂടി ചെയ്യാം.

ഒരേ വരിയിൽ ഒരേസമയം രണ്ട് അപ്‌ഡേറ്റുകൾ പ്രവർത്തിപ്പിക്കാൻ നിങ്ങൾ ശ്രമിക്കുകയാണെങ്കിൽ, അത് തടയപ്പെടും. പിന്നെ ഓർക്കുക, ഞാൻ പറഞ്ഞത് വായനക്കാരൻ എഴുത്തുകാരനെ തടയില്ല, എഴുത്തുകാരൻ വായനക്കാരനെ തടയുന്നില്ല, എന്നാൽ ഒരു എഴുത്തുകാരൻ മറ്റൊരു എഴുത്തുകാരനെ തടയുന്നു. അതായത്, ഒരേ സമയം ഒരേ വരിയിൽ രണ്ട് പേർ അപ്ഡേറ്റ് ചെയ്യാൻ ഞങ്ങൾക്ക് കഴിയില്ല. അവയിലൊന്ന് പൂർത്തിയാകുന്നതുവരെ നിങ്ങൾ കാത്തിരിക്കണം.

ഇത് വ്യക്തമാക്കുന്നതിന്, ഞാൻ ലോക്ക്ഡെമോ പട്ടികയിലേക്ക് നോക്കാം. ഞങ്ങൾ ഒരു വരി നോക്കും. ഓരോ ഇടപാടിനും 698.

ഞങ്ങൾ ഇത് 2 ആയി അപ്ഡേറ്റ് ചെയ്തു. 699 ആണ് ആദ്യ അപ്ഡേറ്റ്. അത് വിജയിച്ചു അല്ലെങ്കിൽ അത് തീർച്ചപ്പെടുത്താത്ത ഇടപാടിലാണ്, ഞങ്ങൾ സ്ഥിരീകരിക്കുന്നതിനോ റദ്ദാക്കുന്നതിനോ കാത്തിരിക്കുകയാണ്.

എന്നാൽ മറ്റെന്തെങ്കിലും നോക്കൂ - 2/51 ഞങ്ങളുടെ ആദ്യത്തെ ഇടപാടാണ്, ഞങ്ങളുടെ ആദ്യ സെഷനാണ്. മുകളിൽ നിന്ന് വന്ന രണ്ടാമത്തെ അഭ്യർത്ഥനയാണ് 3/112 എന്നത് ആ മൂല്യം 3 ആയി മാറ്റി. നിങ്ങൾ ശ്രദ്ധിച്ചാൽ, മുകളിൽ ഉള്ളത് സ്വയം ലോക്ക് ചെയ്തു, അത് 699 ആണ്. എന്നാൽ 3/112 ലോക്ക് അനുവദിച്ചില്ല. ലോക്ക്_മോഡ് കോളം എന്താണ് കാത്തിരിക്കുന്നതെന്ന് പറയുന്നു. ഇത് 699 ആണ് പ്രതീക്ഷിക്കുന്നത്. 699 എവിടെയാണെന്ന് നോക്കിയാൽ അത് ഉയർന്നതാണ്. ആദ്യ സെഷൻ എന്താണ് ചെയ്തത്? അവൾ സ്വന്തം ഇടപാട് ഐഡിയിൽ ഒരു പ്രത്യേക ലോക്ക് സൃഷ്ടിച്ചു. പോസ്റ്റ്‌ഗ്രേസ് ഇത് ചെയ്യുന്നത് ഇങ്ങനെയാണ്. ഇത് സ്വന്തം ഇടപാട് ഐഡി തടയുന്നു. ആരെങ്കിലും സ്ഥിരീകരിക്കുന്നതിനോ റദ്ദാക്കുന്നതിനോ കാത്തിരിക്കണമെങ്കിൽ, ഒരു ഇടപാട് തീർപ്പാക്കാത്തപ്പോൾ നിങ്ങൾ കാത്തിരിക്കേണ്ടതുണ്ട്. അതുകൊണ്ടാണ് വിചിത്രമായ ഒരു വരി നമുക്ക് കാണാൻ കഴിയുന്നത്.

ഒന്നുകൂടി നോക്കാം. ഇടതുവശത്ത് ഞങ്ങളുടെ പ്രോസസ്സിംഗ് ഐഡി കാണുന്നു. രണ്ടാമത്തെ കോളത്തിൽ നമ്മുടെ വെർച്വൽ ട്രാൻസാക്ഷൻ ഐഡിയും മൂന്നാമത്തേതിൽ നമ്മൾ lock_type-ഉം കാണുന്നു. എന്താണിതിനർത്ഥം? പ്രധാനമായും അത് പറയുന്നത് ഇടപാട് ഐഡി തടയുന്നു എന്നതാണ്. എന്നാൽ താഴെയുള്ള എല്ലാ വരികളും റിലേഷൻ എന്ന് പറയുന്നത് ശ്രദ്ധിക്കുക. അതിനാൽ നിങ്ങൾക്ക് മേശപ്പുറത്ത് രണ്ട് തരം ലോക്കുകൾ ഉണ്ട്. ഒരു റിലേഷൻ ലോക്ക് ഉണ്ട്. തുടർന്ന് ട്രാൻസാക്സാനിഡ് തടയൽ ഉണ്ട്, അവിടെ നിങ്ങൾ സ്വയം തടയുന്നു, ഇത് ആദ്യ വരിയിലോ ഏറ്റവും താഴെയോ സംഭവിക്കുന്നത്, ട്രാൻസാക്ഷനിഡ് എവിടെയാണ്, 699 അതിന്റെ പ്രവർത്തനം പൂർത്തിയാക്കാൻ ഞങ്ങൾ കാത്തിരിക്കുന്നു.

ഇവിടെ എന്താണ് സംഭവിക്കുന്നതെന്ന് ഞാൻ കാണും. ഇവിടെ രണ്ട് കാര്യങ്ങൾ ഒരേസമയം സംഭവിക്കുന്നു. ആദ്യ വരിയിൽ തന്നെ ലോക്ക് ചെയ്യുന്ന ഒരു ട്രാൻസാക്ഷൻ ഐഡി ലോക്ക് ആണ് നിങ്ങൾ നോക്കുന്നത്. ആളുകളെ കാത്തിരിക്കാൻ അവൾ സ്വയം തടയുന്നു.

ആറാമത്തെ വരിയിൽ നോക്കിയാൽ ആദ്യത്തേതിന്റെ അതേ എൻട്രി തന്നെ. അതിനാൽ ഇടപാട് 6 തടഞ്ഞു. 699 സെൽഫ് ലോക്കിംഗും ആണ്. 700 അതിന്റെ പ്രവർത്തനം പൂർത്തിയാക്കാൻ ഞങ്ങൾ കാത്തിരിക്കുകയാണെന്ന് ചുവടെയുള്ള വരിയിൽ നിങ്ങൾ കാണും.

ലോക്ക്_ടൈപ്പിൽ, ട്യൂപ്പിൾ നിങ്ങൾ നമ്പറുകൾ കാണുന്നു.

ഇത് 0/10 ആണെന്ന് നിങ്ങൾക്ക് കാണാം. ഇതാണ് പേജ് നമ്പർ, കൂടാതെ ഈ പ്രത്യേക വരിയുടെ ഓഫ്സെറ്റും.

ഞങ്ങൾ അപ്‌ഡേറ്റ് ചെയ്യുമ്പോൾ അത് 0/11 ആയി മാറുന്നത് നിങ്ങൾ കാണുന്നു.

എന്നാൽ വാസ്തവത്തിൽ ഇത് 0/10 ആണ്, കാരണം ഈ പ്രവർത്തനത്തിന് ഒരു കാത്തിരിപ്പുണ്ട്. ഞാൻ സ്ഥിരീകരിക്കാൻ കാത്തിരിക്കുന്ന പരമ്പരയാണ് ഇതെന്ന് കാണാൻ ഞങ്ങൾക്ക് അവസരമുണ്ട്.

ഞങ്ങൾ അത് സ്ഥിരീകരിച്ച് കമ്മിറ്റ് അമർത്തിക്കഴിഞ്ഞാൽ, അപ്‌ഡേറ്റ് പൂർത്തിയാകുമ്പോൾ, ഇതാണ് ഞങ്ങൾക്ക് വീണ്ടും ലഭിക്കുന്നത്. ഇടപാട് 700 മാത്രമാണ് ലോക്ക്, അത് പ്രതിജ്ഞാബദ്ധമായതിനാൽ മറ്റാരെയും കാത്തിരിക്കുന്നില്ല. ഇടപാട് പൂർത്തിയാകുന്നതുവരെ ഇത് കാത്തിരിക്കുന്നു. 699 റൺസ് പുറത്തായാൽ പിന്നെ ഞങ്ങൾ ഒന്നിനും കാത്തിരിക്കില്ല. ഇപ്പോൾ ഇടപാട് 700 പറയുന്നത് എല്ലാം ശരിയാണെന്നും അനുവദനീയമായ എല്ലാ ടേബിളുകളിലും അതിന് ആവശ്യമായ എല്ലാ ലോക്കുകളും ഉണ്ടെന്നും.

ഈ മുഴുവൻ കാര്യവും കൂടുതൽ സങ്കീർണ്ണമാക്കുന്നതിന്, ഞങ്ങൾ മറ്റൊരു കാഴ്ച സൃഷ്ടിക്കുന്നു, അത് ഇത്തവണ ഞങ്ങൾക്ക് ഒരു ശ്രേണി നൽകും. ഈ അഭ്യർത്ഥന നിങ്ങൾ മനസ്സിലാക്കുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നില്ല. എന്നാൽ എന്താണ് സംഭവിക്കുന്നതെന്നതിന്റെ വ്യക്തമായ കാഴ്ച ഇത് നമുക്ക് നൽകും.

ഇതൊരു ആവർത്തന കാഴ്ചയാണ്, ഇതിന് മറ്റൊരു വിഭാഗവും ഉണ്ട്. എന്നിട്ട് അത് എല്ലാം വീണ്ടും ഒരുമിച്ച് കൊണ്ടുവരുന്നു. നമുക്ക് ഇത് ഉപയോഗിക്കാം.

ഒരേസമയം മൂന്ന് അപ്‌ഡേറ്റുകൾ നടത്തി വരി ഇപ്പോൾ മൂന്ന് എന്ന് പറഞ്ഞാൽ എന്ത് ചെയ്യും. ഞങ്ങൾ 3 മുതൽ 4 വരെ മാറ്റും.

ഇവിടെ നമ്മൾ 4. ഇടപാട് ഐഡി 702 കാണുന്നു.

എന്നിട്ട് ഞാൻ 4 ആക്കി 5 ആയി മാറ്റും. 5 മുതൽ 6 വരെ, 6 മുതൽ 7 വരെ. കൂടാതെ ഈ ഒരു ഇടപാട് അവസാനിക്കാൻ കാത്തിരിക്കുന്ന നിരവധി ആളുകളെ ഞാൻ അണിനിരത്തും.

ഒപ്പം എല്ലാം വ്യക്തമാകും. ആദ്യ വരി ഏതാണ്? ഇത് 702 ആണ്. യഥാർത്ഥത്തിൽ ഈ മൂല്യം സജ്ജീകരിച്ച ഇടപാട് ഐഡി ഇതാണ്. എന്റെ ഗ്രാന്റ് കോളത്തിൽ എന്താണ് എഴുതിയിരിക്കുന്നത്? എനിക്ക് മാർക്കുണ്ട് f. ഇടപാട് ഐഡി 5 അവസാനിക്കുന്നതിനായി ഞങ്ങൾ കാത്തിരിക്കുന്നതിനാൽ (6, 7, 702) അംഗീകരിക്കാൻ കഴിയാത്ത എന്റെ അപ്‌ഡേറ്റുകളാണിത്. അവിടെ ഞങ്ങൾക്ക് ട്രാൻസാക്ഷൻ ഐഡി തടയൽ ഉണ്ട്. ഇത് 5 ഇടപാട് ഐഡി ലോക്കുകളിൽ കലാശിക്കുന്നു.

നിങ്ങൾ 704, 705-ൽ നോക്കുകയാണെങ്കിൽ, ഇതുവരെ അവിടെ ഒന്നും എഴുതിയിട്ടില്ല, കാരണം എന്താണ് സംഭവിക്കുന്നതെന്ന് അവർക്ക് ഇതുവരെ അറിയില്ല. എന്താണ് സംഭവിക്കുന്നതെന്ന് തങ്ങൾക്ക് അറിയില്ല എന്ന് അവർ എഴുതുന്നു. വരികൾ മാറ്റാൻ അവസരമുള്ളപ്പോൾ ആരെങ്കിലും പൂർത്തിയാക്കാനും ഉണർത്താനും കാത്തിരിക്കുന്നതിനാൽ അവർ ഉറങ്ങാൻ പോകും.

ഇങ്ങനെയാണ് കാണുന്നത്. അവരെല്ലാം 12-ാം വരിക്കായി കാത്തിരിക്കുകയാണെന്ന് വ്യക്തം.

ഇതാണ് നമ്മൾ ഇവിടെ കണ്ടത്. ഇതാ 0/12.

അതിനാൽ ആദ്യത്തെ ഇടപാട് അംഗീകരിച്ചുകഴിഞ്ഞാൽ, ശ്രേണി എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് നിങ്ങൾക്ക് ഇവിടെ കാണാം. ഇപ്പോൾ എല്ലാം വ്യക്തമാകും. അവയെല്ലാം ശുദ്ധമാകും. അവർ ഇപ്പോഴും കാത്തിരിക്കുകയാണ്.

ഇവിടെ എന്താണ് സംഭവിക്കുന്നത്. 702 കമ്മിറ്റ് ചെയ്യുന്നു. ഇപ്പോൾ 703 ന് ഈ വരി ലോക്ക് ലഭിക്കുന്നു, തുടർന്ന് 704 703 ലേക്ക് കാത്തിരിക്കാൻ തുടങ്ങുന്നു. 705 ഇതിനായി കാത്തിരിക്കുകയാണ്. ഇതെല്ലാം പൂർത്തിയാകുമ്പോൾ, അവർ സ്വയം വൃത്തിയാക്കുന്നു. ഒപ്പം എല്ലാവരും അണിനിരക്കുന്നുണ്ടെന്ന് സൂചിപ്പിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. എല്ലാവരും ആദ്യത്തെ കാറിനായി കാത്തിരിക്കുമ്പോൾ ട്രാഫിക് ജാമിലെ ഒരു സാഹചര്യത്തിന് ഇത് വളരെ സമാനമാണ്. ആദ്യത്തെ കാർ നിർത്തി, എല്ലാവരും ഒരു നീണ്ട നിരയിൽ അണിനിരക്കുന്നു. തുടർന്ന് അത് നീങ്ങുന്നു, തുടർന്ന് അടുത്ത കാറിന് മുന്നോട്ട് ഓടിക്കാനും അതിന്റെ ബ്ലോക്ക് നേടാനും കഴിയും.

ഇത് നിങ്ങൾക്ക് വേണ്ടത്ര സങ്കീർണ്ണമല്ലെന്ന് തോന്നിയാൽ, ഞങ്ങൾ ഇപ്പോൾ നിങ്ങളുമായി ബന്ധപ്പെട്ട പ്രശ്‌നങ്ങളെക്കുറിച്ച് സംസാരിക്കും. നിങ്ങളിൽ ആരാണ് അവരെ നേരിട്ടതെന്ന് എനിക്കറിയില്ല. ഡാറ്റാബേസ് സിസ്റ്റങ്ങളിൽ ഇത് വളരെ സാധാരണമായ ഒരു പ്രശ്നമാണ്. എന്നാൽ ഒരു സെഷൻ മറ്റൊരു സെഷനുവേണ്ടി എന്തെങ്കിലും ചെയ്യാൻ കാത്തിരിക്കുമ്പോഴാണ് ഡെഡ്‌ലോക്ക്. ഈ നിമിഷം മറ്റൊരു സെഷൻ ആദ്യ സെഷൻ എന്തെങ്കിലും ചെയ്യാൻ കാത്തിരിക്കുകയാണ്.

ഉദാഹരണത്തിന്, ഇവാൻ പറഞ്ഞാൽ: “എനിക്ക് എന്തെങ്കിലും തരൂ,” ഞാൻ പറയുന്നു: “ഇല്ല, നിങ്ങൾ എനിക്ക് മറ്റെന്തെങ്കിലും നൽകിയാൽ മാത്രമേ ഞാൻ അത് നിങ്ങൾക്ക് തരൂ.” അവൻ പറഞ്ഞു, "ഇല്ല, നിങ്ങൾ എനിക്ക് തന്നില്ലെങ്കിൽ ഞാൻ അത് നിങ്ങൾക്ക് തരില്ല." കൂടാതെ നമ്മൾ ഒരു സ്തംഭനാവസ്ഥയിൽ അവസാനിക്കുന്നു. ഇവൻ ഇത് ചെയ്യില്ല എന്ന് എനിക്ക് ഉറപ്പുണ്ട്, പക്ഷേ നമുക്ക് എന്തെങ്കിലും ലഭിക്കാൻ ആഗ്രഹിക്കുന്ന രണ്ട് പേർ ഉണ്ടെന്നും മറ്റേയാൾ അവർക്ക് ആവശ്യമുള്ളത് നൽകുന്നതുവരെ അവർ അത് നൽകാൻ തയ്യാറല്ലെന്നുമുള്ള അർത്ഥം നിങ്ങൾ മനസ്സിലാക്കുന്നു. പിന്നെ ഒരു പരിഹാരവുമില്ല.

അടിസ്ഥാനപരമായി, നിങ്ങളുടെ ഡാറ്റാബേസിന് ഇത് കണ്ടെത്തേണ്ടതുണ്ട്. തുടർന്ന് നിങ്ങൾ സെഷനുകളിലൊന്ന് ഇല്ലാതാക്കുകയോ അടയ്ക്കുകയോ ചെയ്യേണ്ടതുണ്ട്, അല്ലാത്തപക്ഷം അവ എന്നെന്നേക്കുമായി നിലനിൽക്കും. ഞങ്ങൾ ഇത് ഡാറ്റാബേസുകളിൽ കാണുന്നു, ഞങ്ങൾ അത് ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളിൽ കാണുന്നു. നമുക്ക് സമാന്തര പ്രക്രിയകളുള്ള എല്ലാ സ്ഥലങ്ങളിലും ഇത് സംഭവിക്കാം.

ഇപ്പോൾ ഞങ്ങൾ രണ്ട് ഡെഡ്‌ലോക്കുകൾ ഇൻസ്റ്റാൾ ചെയ്യും. ഞങ്ങൾ 50 ഉം 80 ഉം ഇടും. ആദ്യ വരിയിൽ, ഞാൻ 50 ൽ നിന്ന് 50 ആയി അപ്ഡേറ്റ് ചെയ്യും. എനിക്ക് ഇടപാട് നമ്പർ 710 ലഭിക്കും.

തുടർന്ന് ഞാൻ 80 ലേക്ക് 81 ആയും 50 ലേക്ക് 51 ആയും മാറ്റും.

പിന്നെ ഇത് ഇങ്ങനെയായിരിക്കും. അതിനാൽ 710 ഒരു വരി തടഞ്ഞു, 711 സ്ഥിരീകരണത്തിനായി കാത്തിരിക്കുന്നു. ഞങ്ങൾ ഇത് അപ്ഡേറ്റ് ചെയ്തപ്പോൾ കണ്ടു. 710 ആണ് ഞങ്ങളുടെ പരമ്പരയുടെ ഉടമ. ഇടപാട് പൂർത്തിയാക്കാൻ 711 കാത്തിരിക്കുന്നു.

കൂടാതെ ഏത് വരിയിലാണ് തടസ്സങ്ങൾ സംഭവിക്കുന്നതെന്ന് പോലും പറയുന്നു. ഇവിടെയാണ് ഇത് വിചിത്രമാകാൻ തുടങ്ങുന്നത്.

ഇപ്പോൾ ഞങ്ങൾ 80 മുതൽ 80 വരെ അപ്ഡേറ്റ് ചെയ്യുന്നു.

ഇവിടെയാണ് തടസ്സങ്ങൾ ആരംഭിക്കുന്നത്. 710 ൽ നിന്നുള്ള പ്രതികരണത്തിനായി 711 കാത്തിരിക്കുന്നു, 711 710 നായി കാത്തിരിക്കുന്നു. ഇത് നല്ല രീതിയിൽ അവസാനിക്കില്ല. കൂടാതെ ഇതിൽ നിന്ന് ഒരു പോംവഴിയുമില്ല. അവർ പരസ്പരം പ്രതികരണം പ്രതീക്ഷിക്കുകയും ചെയ്യും.

അത് എല്ലാം വൈകിപ്പിക്കാൻ തുടങ്ങും. പിന്നെ ഞങ്ങൾക്ക് അത് വേണ്ട.

ഇത് സംഭവിക്കുമ്പോൾ ശ്രദ്ധിക്കാനുള്ള വഴികൾ Postgres-നുണ്ട്. ഇത് സംഭവിക്കുമ്പോൾ, നിങ്ങൾക്ക് ഈ പിശക് ലഭിക്കും. അത്തരത്തിലുള്ളതും അത്തരത്തിലുള്ളതുമായ ഒരു പ്രക്രിയ മറ്റൊരു പ്രക്രിയയിൽ നിന്ന് ഒരു ഷെയർ ലോക്കിനായി കാത്തിരിക്കുകയാണെന്ന് ഇതിൽ നിന്ന് വ്യക്തമാണ്, അതായത്, 711 പ്രോസസ്സ് തടഞ്ഞിരിക്കുന്നു. അത്തരം ഒരു ഇടപാട് ഐഡിയിൽ ഒരു ഷെയർ ലോക്ക് ലഭിക്കുന്നതിനായി ആ പ്രക്രിയ കാത്തിരിക്കുകയായിരുന്നു, ഇത്തരമൊരു പ്രക്രിയ തടഞ്ഞു. അതുകൊണ്ട് തന്നെ ഇവിടെ സ്തംഭനാവസ്ഥയിലാണ്.

ത്രീ-വേ ഡെഡ്‌ലോക്കുകൾ ഉണ്ടോ? ഇത് സാധ്യമാണോ? അതെ.

ഞങ്ങൾ ഈ നമ്പറുകൾ ഒരു പട്ടികയിൽ നൽകുന്നു. ഞങ്ങൾ 40 ലേക്ക് 40 മാറ്റുന്നു, ഞങ്ങൾ തടയുന്നു.

ഞങ്ങൾ 60 ലേക്ക് 61 ലേക്ക് മാറ്റുന്നു, 80 മുതൽ 81 വരെ.

തുടർന്ന് ഞങ്ങൾ 80 മാറ്റുകയും തുടർന്ന് ബൂം ചെയ്യുകയും ചെയ്യുന്നു!

714 ഇപ്പോൾ 715-നായി കാത്തിരിക്കുന്നു. 716-ാമത്തേത് 715-നായാണ് കാത്തിരിക്കുന്നത്. പിന്നെ ഒന്നും ചെയ്യാൻ പറ്റില്ല.

ഇവിടെ ഇപ്പോൾ രണ്ടുപേരില്ല, ഇവിടെ ഇതിനകം മൂന്ന് പേരുണ്ട്. എനിക്ക് നിങ്ങളിൽ നിന്ന് എന്തെങ്കിലും വേണം, ഇവൻ മൂന്നാമതൊരാളിൽ നിന്ന് എന്തെങ്കിലും ആഗ്രഹിക്കുന്നു, മൂന്നാമത്തെ വ്യക്തി എന്നിൽ നിന്ന് എന്തെങ്കിലും ആഗ്രഹിക്കുന്നു. ഞങ്ങൾ മൂന്ന് വഴിക്കുള്ള കാത്തിരിപ്പിലാണ് അവസാനിക്കുന്നത്, കാരണം മറ്റൊരാൾ ചെയ്യേണ്ടത് പൂർത്തിയാക്കുന്നതിനായി നാമെല്ലാവരും കാത്തിരിക്കുകയാണ്.

ഏത് നിരയിലാണ് ഇത് സംഭവിക്കുന്നതെന്ന് പോസ്റ്റ്‌ഗ്രെസിന് അറിയാം. അതിനാൽ ഇത് നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന സന്ദേശം നൽകും, ഇത് മൂന്ന് ഇൻപുട്ടുകൾ പരസ്പരം തടയുന്ന ഒരു പ്രശ്നമുണ്ടെന്ന് കാണിക്കുന്നു. കൂടാതെ ഇവിടെ നിയന്ത്രണങ്ങളൊന്നുമില്ല. 20 എൻട്രികൾ പരസ്പരം തടയുന്ന സാഹചര്യമായിരിക്കാം ഇത്.

അടുത്ത പ്രശ്നം സീരിയലൈസ് ചെയ്യാവുന്നതാണ്.

പ്രത്യേക സീരിയൽ ലോക്ക് ആണെങ്കിൽ.

ഞങ്ങൾ 719-ലേക്ക് മടങ്ങുന്നു. അതിന്റെ ഔട്ട്പുട്ട് തികച്ചും സാധാരണമാണ്.

ഇടപാട് സീരിയലൈസ് ചെയ്യാവുന്നതാക്കി മാറ്റാൻ നിങ്ങൾക്ക് ക്ലിക്ക് ചെയ്യാം.

നിങ്ങൾക്ക് ഇപ്പോൾ മറ്റൊരു തരത്തിലുള്ള SA ലോക്ക് ഉണ്ടെന്ന് നിങ്ങൾ മനസ്സിലാക്കുന്നു - അതിനർത്ഥം സീരിയലൈസ് ചെയ്യാവുന്നതാണെന്നാണ്.

അതിനാൽ ഞങ്ങൾക്ക് SARieadLock എന്ന് വിളിക്കപ്പെടുന്ന ഒരു പുതിയ തരം ലോക്ക് ഉണ്ട്, അത് ഒരു സീരിയൽ ലോക്കും സീരിയലുകളിൽ പ്രവേശിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

കൂടാതെ നിങ്ങൾക്ക് അദ്വിതീയ സൂചികകൾ ചേർക്കാനും കഴിയും.

ഈ പട്ടികയിൽ നമുക്ക് അദ്വിതീയ സൂചികകൾ ഉണ്ട്.

ഞാൻ ഇവിടെ നമ്പർ 2 ഇട്ടാൽ, എനിക്ക് 2 ഉണ്ട്. എന്നാൽ ഏറ്റവും മുകളിൽ, ഞാൻ മറ്റൊരു 2 ഇഞ്ച് ഇട്ടു. കൂടാതെ 721 ന് ഒരു എക്സ്ക്ലൂസീവ് ലോക്ക് ഉണ്ടെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും. എന്നാൽ ഇപ്പോൾ 722 അതിന്റെ പ്രവർത്തനം പൂർത്തിയാക്കാൻ 721 കാത്തിരിക്കുകയാണ്, കാരണം 2 ന് എന്ത് സംഭവിക്കുമെന്ന് അറിയുന്നത് വരെ അതിന് 721 ചേർക്കാൻ കഴിയില്ല.

ഞങ്ങൾ ഉപഭോക്തൃ ഇടപാട് നടത്തുകയാണെങ്കിൽ.

ഇവിടെ നമുക്ക് 723 ഉണ്ട്.

ഞങ്ങൾ പോയിന്റ് സേവ് ചെയ്‌ത് അത് അപ്‌ഡേറ്റ് ചെയ്‌താൽ, ഞങ്ങൾക്ക് ഒരു പുതിയ ഇടപാട് ഐഡി ലഭിക്കും. നിങ്ങൾ അറിഞ്ഞിരിക്കേണ്ട മറ്റൊരു സ്വഭാവരീതിയാണിത്. ഞങ്ങൾ ഇത് തിരികെ നൽകിയാൽ, ഇടപാട് ഐഡി ഇല്ലാതാകും. 724 പുറപ്പെടുന്നു. എന്നാൽ ഇപ്പോൾ നമുക്ക് 725 ഉണ്ട്.

അപ്പോൾ ഞാൻ ഇവിടെ എന്താണ് ചെയ്യാൻ ശ്രമിക്കുന്നത്? നിങ്ങൾ കണ്ടെത്തിയേക്കാവുന്ന അസാധാരണമായ ലോക്കുകളുടെ ഉദാഹരണങ്ങൾ കാണിക്കാൻ ഞാൻ ശ്രമിക്കുന്നു: ഇത് സീരിയലൈസ് ചെയ്യാവുന്ന ലോക്കുകളായാലും സേവ്‌പോയിന്റായാലും, ലോക്ക് ടേബിളിൽ ദൃശ്യമാകുന്ന വ്യത്യസ്ത തരം ലോക്കുകളാണ് ഇവ.

pg_advisory_lock ഉള്ള വ്യക്തമായ (വ്യക്തമായ) ലോക്കുകളുടെ സൃഷ്ടിയാണിത്.

തടയൽ തരം ഉപദേശമായി പട്ടികപ്പെടുത്തിയിരിക്കുന്നതായി നിങ്ങൾ കാണുന്നു. ഇവിടെ അത് ചുവപ്പിൽ "ഉപദേശം" എന്ന് പറയുന്നു. pg_advisory_unlock ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഒരേസമയം ഇതുപോലെ ബ്ലോക്ക് ചെയ്യാം.

ഉപസംഹാരമായി, മനസ്സിനെ സ്പർശിക്കുന്ന ഒരു കാര്യം കൂടി നിങ്ങളെ കാണിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. ഞാൻ മറ്റൊരു കാഴ്ച സൃഷ്ടിക്കും. എന്നാൽ ഞാൻ pg_stat_activity ടേബിളിനൊപ്പം pg_locks പട്ടികയിൽ ചേരും. പിന്നെ എന്തിനാണ് ഞാൻ ഇത് ചെയ്യാൻ ആഗ്രഹിക്കുന്നത്? കാരണം നിലവിലെ എല്ലാ സെഷനുകളും നോക്കാനും കാണാനും അവർ ഏത് തരത്തിലുള്ള ലോക്കുകൾക്കായി കാത്തിരിക്കുന്നുവെന്ന് കൃത്യമായി കാണാനും ഇത് എന്നെ അനുവദിക്കും. ലോക്ക് ടേബിളും അന്വേഷണ പട്ടികയും ഒരുമിച്ച് ചേർക്കുമ്പോൾ ഇത് വളരെ രസകരമാണ്.

ഇവിടെ ഞങ്ങൾ pg_stat_view സൃഷ്ടിക്കുന്നു.

ഞങ്ങൾ വരി ഒന്നായി അപ്ഡേറ്റ് ചെയ്യുന്നു. ഇവിടെ നമ്മൾ 724 കാണുന്നു. തുടർന്ന് ഞങ്ങളുടെ വരി മൂന്നായി അപ്ഡേറ്റ് ചെയ്യുന്നു. നിങ്ങൾ ഇപ്പോൾ ഇവിടെ എന്താണ് കാണുന്നത്? ഇവ അഭ്യർത്ഥനകളാണ്, അതായത് ഇടത് കോളത്തിൽ ലിസ്റ്റുചെയ്തിരിക്കുന്ന അഭ്യർത്ഥനകളുടെ മുഴുവൻ ലിസ്റ്റും നിങ്ങൾ കാണുന്നു. തുടർന്ന് വലതുവശത്ത് നിങ്ങൾക്ക് തടസ്സങ്ങളും അവ സൃഷ്ടിക്കുന്നതും കാണാൻ കഴിയും. ഓരോ തവണയും ഓരോ സെഷനിലേക്കും തിരികെ പോകേണ്ടതില്ല, നിങ്ങൾ അതിൽ ചേരണോ വേണ്ടയോ എന്ന് നോക്കുന്നതിന് ഇത് നിങ്ങൾക്ക് കൂടുതൽ വ്യക്തമാകും. അവർ നമുക്കുവേണ്ടി ചെയ്യുന്നു.

വളരെ ഉപയോഗപ്രദമായ മറ്റൊരു സവിശേഷതയാണ് pg_blocking_pids. നിങ്ങൾ അവളെ കുറിച്ച് കേട്ടിട്ടുണ്ടാവില്ല. അവൾ എന്താണ് ചെയ്യുന്നത്? ഈ സെഷൻ 11740 ഏത് നിർദ്ദിഷ്ട പ്രോസസ്സ് ഐഡികൾക്കായി കാത്തിരിക്കുന്നുവെന്ന് പറയാൻ ഇത് ഞങ്ങളെ അനുവദിക്കുന്നു. 11740-ന് 724 കാത്തിരിക്കുന്നതായി നിങ്ങൾക്ക് കാണാം. 724 ഏറ്റവും മുകളിലാണ്. 11306 ആണ് നിങ്ങളുടെ പ്രോസസ്സ് ഐഡി. അടിസ്ഥാനപരമായി, ഈ പ്രവർത്തനം നിങ്ങളുടെ ലോക്ക് ടേബിളിലൂടെ കടന്നുപോകുന്നു. ഇത് കുറച്ച് സങ്കീർണ്ണമാണെന്ന് എനിക്കറിയാം, പക്ഷേ നിങ്ങൾ അത് മനസ്സിലാക്കുന്നു. അടിസ്ഥാനപരമായി ഈ പ്രവർത്തനം ഈ ലോക്ക് ടേബിളിലൂടെ കടന്നുപോകുകയും ഈ പ്രോസസ്സ് ഐഡിക്ക് അത് കാത്തിരിക്കുന്ന ലോക്കുകൾ എവിടെയാണ് നൽകിയിരിക്കുന്നതെന്ന് കണ്ടെത്താൻ ശ്രമിക്കുകയും ചെയ്യുന്നു. ലോക്കിനായി കാത്തിരിക്കുന്ന പ്രോസസ്സിന് ഏത് പ്രോസസ്സ് ഐഡി ഉണ്ടെന്ന് കണ്ടെത്താനും ഇത് ശ്രമിക്കുന്നു. അതിനാൽ നിങ്ങൾക്ക് ഈ ഫംഗ്ഷൻ പ്രവർത്തിപ്പിക്കാൻ കഴിയും pg_blocking_pids.

കൂടാതെ ഇത് വളരെ ഉപയോഗപ്രദമാകും. ഞങ്ങൾ ഇത് 9.6 പതിപ്പിൽ മാത്രമേ ചേർത്തിട്ടുള്ളൂ, അതിനാൽ ഈ സവിശേഷത 5 വർഷം പഴക്കമുള്ളതാണ്, എന്നാൽ ഇത് വളരെ ഉപയോഗപ്രദമാണ്. രണ്ടാമത്തെ അഭ്യർത്ഥനയ്ക്കും ഇത് ബാധകമാണ്. നമ്മൾ കാണേണ്ട കാര്യങ്ങൾ കൃത്യമായി കാണിക്കുന്നു.

ഞാൻ നിങ്ങളോട് സംസാരിക്കാൻ ആഗ്രഹിച്ചത് ഇതാണ്. ഞാൻ പ്രതീക്ഷിച്ചതുപോലെ, ധാരാളം സ്ലൈഡുകൾ ഉള്ളതിനാൽ ഞങ്ങൾ ഞങ്ങളുടെ സമയമെല്ലാം ഉപയോഗിച്ചു. കൂടാതെ സ്ലൈഡുകൾ ഡൗൺലോഡ് ചെയ്യാൻ ലഭ്യമാണ്. ഇവിടെ വന്നതിന് നിങ്ങൾക്ക് നന്ദി പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. കോൺഫറൻസിന്റെ ബാക്കി ഭാഗങ്ങൾ നിങ്ങൾ ആസ്വദിക്കുമെന്ന് എനിക്ക് ഉറപ്പുണ്ട്, വളരെ നന്ദി!

ചോദ്യങ്ങൾ:

ഉദാഹരണത്തിന്, ഞാൻ വരികൾ അപ്ഡേറ്റ് ചെയ്യാൻ ശ്രമിക്കുകയാണെങ്കിൽ, രണ്ടാമത്തെ സെഷൻ മുഴുവൻ പട്ടികയും ഇല്ലാതാക്കാൻ ശ്രമിക്കുകയാണ്. ഞാൻ മനസ്സിലാക്കിയിടത്തോളം, ഒരു ഇന്റന്റ് ലോക്ക് പോലെയുള്ള ഒന്ന് ഉണ്ടായിരിക്കണം. പോസ്റ്റ്‌ഗ്രേസിൽ അങ്ങനെയൊന്നുണ്ടോ?

നമുക്ക് തുടക്കത്തിലേക്ക് മടങ്ങാം. നിങ്ങൾ എന്തെങ്കിലും ചെയ്യുമ്പോൾ, ഉദാഹരണത്തിന് നിങ്ങൾ ഒരു SELECT ചെയ്യുമ്പോൾ, ഞങ്ങൾ ഒരു AccessShareLock ഇഷ്യൂ ചെയ്യുന്നത് നിങ്ങൾ ഓർക്കുന്നുണ്ടാകാം. ഇത് ടേബിൾ വീഴുന്നത് തടയുന്നു. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് ഒരു പട്ടികയിലെ ഒരു വരി അപ്‌ഡേറ്റ് ചെയ്യാനോ ഒരു വരി ഇല്ലാതാക്കാനോ താൽപ്പര്യമുണ്ടെങ്കിൽ, മുഴുവൻ ടേബിളിലും വരിയിലും നിങ്ങൾ ഈ AccessShareLock കൈവശം വച്ചിരിക്കുന്നതിനാൽ ഒരാൾക്ക് മുഴുവൻ പട്ടികയും ഒരേ സമയം ഇല്ലാതാക്കാൻ കഴിയില്ല. നിങ്ങൾ ചെയ്തുകഴിഞ്ഞാൽ, അവർക്ക് അത് ഇല്ലാതാക്കാനാകും. എന്നാൽ നിങ്ങൾ അവിടെ എന്തെങ്കിലും നേരിട്ട് മാറ്റുമ്പോൾ, അവർക്ക് അത് ചെയ്യാൻ കഴിയില്ല.

നമുക്ക് വീണ്ടും ചെയ്യാം. നമുക്ക് ഡിലീറ്റ് ഉദാഹരണത്തിലേക്ക് പോകാം. മുഴുവൻ പട്ടികയ്ക്കും മുകളിലുള്ള വരിയിൽ ഒരു എക്സ്ക്ലൂസീവ് ലോക്ക് എങ്ങനെ ഉണ്ടെന്ന് നിങ്ങൾ കാണുന്നു.

ഇത് ലോക്ക് എക്‌സ്‌ക്ലൂസീവ് ആയി കാണപ്പെടും, അല്ലേ?

അതെ, അത് പോലെ തോന്നുന്നു. നിങ്ങൾ എന്താണ് സംസാരിക്കുന്നതെന്ന് എനിക്ക് മനസ്സിലായി. ഞാൻ ഒരു സെലക്ട് ചെയ്യുകയാണെങ്കിൽ, എനിക്ക് ഒരു ഷെയർ എക്‌സ്‌ക്ലൂസീവ് ഉണ്ടെന്നും തുടർന്ന് അത് റോ എക്‌സ്‌ക്ലൂസീവ് ആക്കുമെന്നും നിങ്ങൾ പറയുന്നു, അതൊരു പ്രശ്‌നമാകുമോ? എന്നാൽ അതിശയകരമെന്നു പറയട്ടെ, ഇത് ഒരു പ്രശ്നമല്ല. ഇത് ലോക്ക് ഡിഗ്രി വർദ്ധിപ്പിക്കുന്നതായി തോന്നുന്നു, പക്ഷേ പ്രധാനമായും എനിക്ക് ഇല്ലാതാക്കുന്നത് തടയുന്ന ഒരു ലോക്ക് ഉണ്ട്. ഇപ്പോൾ, ഞാൻ ഈ ലോക്ക് കൂടുതൽ ശക്തമാക്കുമ്പോൾ, അത് ഇപ്പോഴും ഇല്ലാതാക്കുന്നത് തടയുന്നു. അതുകൊണ്ട് ഞാൻ കയറുന്നത് പോലെയല്ല. അതായത്, താഴ്ന്ന നിലയിലായിരിക്കുമ്പോൾ ഇത് സംഭവിക്കുന്നത് തടയുന്നു, അതിനാൽ ഞാൻ അതിന്റെ ലെവൽ വർദ്ധിപ്പിക്കുമ്പോൾ അത് ഇപ്പോഴും പട്ടിക ഇല്ലാതാക്കുന്നതിൽ നിന്ന് തടയുന്നു.

നിങ്ങൾ എന്താണ് സംസാരിക്കുന്നതെന്ന് എനിക്ക് മനസ്സിലായി. ഇവിടെ ലോക്ക് എസ്‌കലേഷൻ കേസ് ഒന്നുമില്ല, ഇവിടെ നിങ്ങൾ ഒരു ലോക്ക് ഉപേക്ഷിക്കാൻ ശ്രമിക്കുന്നു. ഇവിടെ ഇത് ബോർഡിലുടനീളം ഈ പ്രതിരോധം വർദ്ധിപ്പിക്കുന്നു, അതിനാൽ ഇത് ഒരു സംഘട്ടനത്തിനും കാരണമാകില്ല. പക്ഷേ നല്ല ചോദ്യമാണ്. ഇത് ചോദിച്ചതിന് വളരെ നന്ദി!

ഞങ്ങൾക്ക് നിരവധി സെഷനുകളും ധാരാളം ഉപയോക്താക്കളും ഉള്ളപ്പോൾ ഒരു തടസ്സം ഒഴിവാക്കാൻ ഞങ്ങൾ എന്താണ് ചെയ്യേണ്ടത്?

പോസ്റ്റ്‌ഗ്രേസ് യാന്ത്രികമായി തടസ്സപ്പെട്ട സാഹചര്യങ്ങൾ ശ്രദ്ധിക്കുന്നു. കൂടാതെ ഇത് സെഷനുകളിലൊന്ന് സ്വയമേവ ഇല്ലാതാക്കും. ഒരേ ക്രമത്തിൽ ആളുകളെ തടയുക എന്നതാണ് ഡെഡ് ബ്ലോക്കിംഗ് ഒഴിവാക്കാനുള്ള ഏക മാർഗം. അതിനാൽ, നിങ്ങളുടെ ആപ്ലിക്കേഷൻ നോക്കുമ്പോൾ, പലപ്പോഴും ഡെഡ്‌ലോക്കുകളുടെ കാരണം... എനിക്ക് രണ്ട് വ്യത്യസ്ത കാര്യങ്ങൾ തടയാൻ താൽപ്പര്യമുണ്ടെന്ന് സങ്കൽപ്പിക്കുക. ഒരു ആപ്ലിക്കേഷൻ ടേബിൾ 1 ലോക്ക് ചെയ്യുന്നു, മറ്റൊരു ആപ്ലിക്കേഷൻ 2 ലോക്ക് ചെയ്യുന്നു, തുടർന്ന് ടേബിൾ 1. കൂടാതെ ഡെഡ്‌ലോക്കുകൾ ഒഴിവാക്കാനുള്ള ഏറ്റവും എളുപ്പ മാർഗം നിങ്ങളുടെ ആപ്ലിക്കേഷൻ നോക്കുകയും എല്ലാ ആപ്ലിക്കേഷനുകളിലും ഒരേ ക്രമത്തിലാണ് ലോക്കിംഗ് സംഭവിക്കുന്നതെന്ന് ഉറപ്പാക്കാൻ ശ്രമിക്കുക എന്നതാണ്. ഇത് സാധാരണയായി 80% പ്രശ്നങ്ങളും ഇല്ലാതാക്കുന്നു, കാരണം എല്ലാത്തരം ആളുകളും ഈ ആപ്ലിക്കേഷനുകൾ എഴുതുന്നു. അതേ ക്രമത്തിൽ നിങ്ങൾ അവരെ തടയുകയാണെങ്കിൽ, നിങ്ങൾക്ക് ഒരു സ്തംഭനാവസ്ഥ നേരിടേണ്ടിവരില്ല.

നിങ്ങളുടെ പ്രകടനത്തിന് വളരെ നന്ദി! നിങ്ങൾ വാക്വം ഫുൾ എന്നതിനെ കുറിച്ച് സംസാരിച്ചു, ഞാൻ ശരിയായി മനസ്സിലാക്കിയാൽ, വാക്വം ഫുൾ പ്രത്യേക സ്റ്റോറേജിലെ റെക്കോർഡുകളുടെ ക്രമത്തെ വളച്ചൊടിക്കുന്നു, അതിനാൽ അവ നിലവിലെ റെക്കോർഡുകൾ മാറ്റമില്ലാതെ സൂക്ഷിക്കുന്നു. എന്തുകൊണ്ടാണ് വാക്വം ഫുൾ എക്‌സ്‌ക്ലൂസീവ് ലോക്ക് ആക്‌സസ് എടുക്കുന്നത്, അത് റൈറ്റ് ഓപ്പറേഷനുകളുമായി വൈരുദ്ധ്യമുള്ളത് എന്തുകൊണ്ട്?

അതൊരു നല്ല ചോദ്യമാണ്. കാരണം, വാക്വം ഫുൾ ടേബിളിനെ എടുക്കുന്നു. ഞങ്ങൾ അടിസ്ഥാനപരമായി പട്ടികയുടെ ഒരു പുതിയ പതിപ്പ് സൃഷ്ടിക്കുകയാണ്. ഒപ്പം മേശയും പുതിയതായിരിക്കും. ഇത് പട്ടികയുടെ പൂർണ്ണമായും പുതിയ പതിപ്പായിരിക്കുമെന്ന് ഇത് മാറുന്നു. ഞങ്ങൾ ഇത് ചെയ്യുമ്പോൾ, ആളുകൾ അത് വായിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നില്ല, കാരണം അവർക്ക് പുതിയ ടേബിൾ കാണേണ്ടതുണ്ട്. അതിനാൽ ഇത് മുമ്പത്തെ ചോദ്യവുമായി ബന്ധിപ്പിക്കുന്നു. ഒരേ സമയം വായിക്കാൻ കഴിയുമെങ്കിൽ, അത് നീക്കാനും ആളുകളെ പുതിയ മേശയിലേക്ക് നയിക്കാനും ഞങ്ങൾക്ക് കഴിയില്ല. എല്ലാവരും ഈ ടേബിൾ വായിച്ചുതീരുന്നതുവരെ ഞങ്ങൾ കാത്തിരിക്കേണ്ടതുണ്ട്, അതിനാൽ ഇത് ഒരു ലോക്ക് എക്സ്ക്ലൂസീവ് സാഹചര്യമാണ്.
എല്ലാവരേയും പുതിയ പകർപ്പിലേക്ക് മാറ്റുന്നതിന് അവസാനം ഞങ്ങൾക്ക് ഒരു എക്സ്ക്ലൂസീവ് ലോക്ക് ആവശ്യമാണെന്ന് ഞങ്ങൾക്കറിയാം എന്നതിനാൽ ഞങ്ങൾ ആദ്യം മുതൽ ലോക്ക് ചെയ്യുന്നുവെന്ന് ഞങ്ങൾ പറയുന്നു. അതിനാൽ നമുക്ക് ഇത് പരിഹരിക്കാൻ കഴിയും. ഒരേസമയം ഇൻഡക്‌സിംഗ് ഉപയോഗിച്ച് ഞങ്ങൾ ഇത് ചെയ്യുന്നു. എന്നാൽ ഇത് ചെയ്യാൻ കൂടുതൽ ബുദ്ധിമുട്ടാണ്. ലോക്ക് എക്സ്ക്ലൂസീവ് സംബന്ധിച്ച നിങ്ങളുടെ മുമ്പത്തെ ചോദ്യവുമായി ഇത് വളരെ ബന്ധപ്പെട്ടിരിക്കുന്നു.

Postgres-ലേക്ക് ലോക്കിംഗ് ടൈംഔട്ട് ചേർക്കാൻ കഴിയുമോ? Oracle-ൽ, എനിക്ക്, ഉദാഹരണത്തിന്, "അപ്ഡേറ്റ് ചെയ്യാൻ തിരഞ്ഞെടുക്കുക" എന്ന് എഴുതാനും അപ്ഡേറ്റ് ചെയ്യുന്നതിന് മുമ്പ് 50 സെക്കൻഡ് കാത്തിരിക്കാനും കഴിയും. ഇത് അപേക്ഷയ്ക്ക് നല്ലതായിരുന്നു. എന്നാൽ പോസ്റ്റ്‌ഗ്രേസിൽ, ഒന്നുകിൽ ഞാൻ അത് ഉടനടി ചെയ്യണം, കാത്തിരിക്കരുത്, അല്ലെങ്കിൽ കുറച്ച് സമയം വരെ കാത്തിരിക്കുക.

അതെ, നിങ്ങളുടെ ലോക്കുകളിൽ, നിങ്ങളുടെ ലോക്കുകളിൽ സമയപരിധി തിരഞ്ഞെടുക്കാം. നിങ്ങൾക്ക് ഒരു നോ വേ കമാൻഡ് നൽകാനും കഴിയും, അത് നിങ്ങൾക്ക് ഉടനടി ലോക്ക് നേടാൻ കഴിയുന്നില്ലെങ്കിൽ. അതിനാൽ, ഒന്നുകിൽ ലോക്ക് ടൈംഔട്ട് അല്ലെങ്കിൽ ഇത് ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്ന മറ്റെന്തെങ്കിലും. ഇത് വാക്യഘടന തലത്തിലല്ല ചെയ്യുന്നത്. ഇത് സെർവറിൽ ഒരു വേരിയബിൾ ആയിട്ടാണ് ചെയ്യുന്നത്. ചിലപ്പോൾ ഇത് ഉപയോഗിക്കാൻ കഴിയില്ല.

നിങ്ങൾക്ക് സ്ലൈഡ് 75 തുറക്കാമോ?

അതെ.

പിന്നെ എന്റെ ചോദ്യം ഇനിപ്പറയുന്നതാണ്. എന്തുകൊണ്ടാണ് രണ്ട് അപ്‌ഡേറ്റ് പ്രക്രിയകളും 703 പ്രതീക്ഷിക്കുന്നത്?

പിന്നെ ഇതൊരു വലിയ ചോദ്യമാണ്. പോസ്റ്റ്‌ഗ്രേസ് എന്തിനാണ് ഇത് ചെയ്യുന്നത് എന്ന് എനിക്ക് മനസ്സിലാകുന്നില്ല. എന്നാൽ 703 സൃഷ്‌ടിച്ചപ്പോൾ, അത് 702 പ്രതീക്ഷിച്ചിരുന്നു. 704 ഉം 705 ഉം കാണിക്കുമ്പോൾ, അവർ എന്താണ് പ്രതീക്ഷിക്കുന്നതെന്ന് അവർക്കറിയില്ല എന്ന് തോന്നുന്നു, കാരണം അവിടെ ഇതുവരെ ഒന്നുമില്ല. പോസ്റ്റ്‌ഗ്രേസ് ഇത് ഈ രീതിയിൽ ചെയ്യുന്നു: നിങ്ങൾക്ക് ഒരു ലോക്ക് ലഭിക്കാതെ വരുമ്പോൾ, "നിങ്ങളെ പ്രോസസ്സ് ചെയ്യുന്നതിന്റെ പ്രയോജനം എന്താണ്?", കാരണം നിങ്ങൾ ഇതിനകം ആരെയെങ്കിലും കാത്തിരിക്കുകയാണ്. അതിനാൽ ഞങ്ങൾ അതിനെ വായുവിൽ തൂങ്ങാൻ അനുവദിക്കും, അത് അപ്‌ഡേറ്റ് ചെയ്യില്ല. എന്നാൽ ഇവിടെ എന്താണ് സംഭവിച്ചത്? 702 പ്രക്രിയ പൂർത്തിയാക്കി 703-ന് അതിന്റെ ലോക്ക് ലഭിച്ചയുടൻ, സിസ്റ്റം തിരികെ വന്നു. അവൾ പറഞ്ഞു, ഇപ്പോൾ ഞങ്ങൾക്ക് രണ്ട് പേർ കാത്തിരിക്കുന്നു. എന്നിട്ട് നമുക്ക് അവ ഒരുമിച്ച് അപ്ഡേറ്റ് ചെയ്യാം. ഇരുവരും പ്രതീക്ഷിക്കുന്നുണ്ടെന്ന് സൂചിപ്പിക്കാം.

എന്തുകൊണ്ടാണ് പോസ്റ്റ്‌ഗ്രേസ് ഇത് ചെയ്യുന്നത് എന്ന് എനിക്കറിയില്ല. എന്നാൽ f എന്നൊരു പ്രശ്നമുണ്ട്.... ഇത് റഷ്യൻ ഭാഷയിൽ ഒരു പദമല്ലെന്ന് എനിക്ക് തോന്നുന്നു. 20 അധികാരികൾ കൊട്ടാരത്തിനായി കാത്തിരിക്കുന്നുണ്ടെങ്കിലും എല്ലാവരും ഒരു കോട്ടയ്ക്കായി കാത്തിരിക്കുമ്പോൾ ഇതാണ്. പെട്ടെന്ന് എല്ലാവരും ഒരേ സമയം ഉണരുന്നു. എല്ലാവരും പ്രതികരിക്കാൻ ശ്രമിക്കുകയും ചെയ്യുന്നു. എന്നാൽ എല്ലാവരും 703-ന് വേണ്ടി കാത്തിരിക്കുന്ന തരത്തിൽ സിസ്റ്റം അത് ഉണ്ടാക്കുന്നു. കാരണം അവരെല്ലാം കാത്തിരിക്കുകയാണ്, ഞങ്ങൾ അവരെയെല്ലാം ഉടൻ അണിനിരത്തും. ഇതിനുശേഷം ജനറേറ്റുചെയ്‌ത മറ്റേതെങ്കിലും പുതിയ അഭ്യർത്ഥന ദൃശ്യമാകുകയാണെങ്കിൽ, ഉദാഹരണത്തിന്, 707, വീണ്ടും ശൂന്യതയുണ്ടാകും.

ഈ ഘട്ടത്തിൽ 702 കാത്തിരിക്കുന്നത് 703 ആണെന്നും അതിനു ശേഷം വരുന്നവർക്കെല്ലാം ഈ ഫീൽഡിൽ പ്രവേശനം ഇല്ലെന്നും പറയാൻ വേണ്ടിയാണ് ഇത് ചെയ്തതെന്ന് എനിക്ക് തോന്നുന്നു. എന്നാൽ ആദ്യത്തെ വെയിറ്റർ പോയാലുടൻ, അപ്‌ഡേറ്റിന് മുമ്പ് ആ നിമിഷം കാത്തിരുന്ന എല്ലാവർക്കും ഒരേ ടോക്കൺ ലഭിക്കും. അതിനാൽ, ഇത് ശരിയായി ക്രമീകരിച്ചിരിക്കുന്നതിനാൽ നമുക്ക് ക്രമത്തിൽ പ്രോസസ്സ് ചെയ്യാൻ കഴിയുമെന്ന് ഞാൻ കരുതുന്നു.

ഞാൻ എപ്പോഴും ഇതിനെ ഒരു വിചിത്രമായ പ്രതിഭാസമായാണ് വീക്ഷിച്ചിരുന്നത്. കാരണം ഇവിടെ, ഉദാഹരണത്തിന്, ഞങ്ങൾ അവയെ പട്ടികപ്പെടുത്തുന്നില്ല. പക്ഷേ, ഓരോ തവണ പുതിയ പൂട്ട് നൽകുമ്പോഴും കാത്തിരിപ്പിൽ കഴിയുന്നവരെയെല്ലാം നോക്കുന്നതായി എനിക്ക് തോന്നുന്നു. എന്നിട്ട് ഞങ്ങൾ അവരെയെല്ലാം നിരത്തുന്നു. പുതിയതായി വരുന്ന ഏതൊരു വ്യക്തിയും അടുത്ത ആളെ പ്രോസസ് ചെയ്തു കഴിയുമ്പോൾ മാത്രമേ ക്യൂവിൽ കയറുകയുള്ളൂ. വളരെ നല്ല ചോദ്യം. നിങ്ങളുടെ ചോദ്യത്തിന് വളരെ നന്ദി!

705 704 പ്രതീക്ഷിക്കുമ്പോൾ അത് കൂടുതൽ യുക്തിസഹമാണെന്ന് എനിക്ക് തോന്നുന്നു.

എന്നാൽ ഇവിടെ പ്രശ്നം താഴെ പറയുന്നതാണ്. സാങ്കേതികമായി, നിങ്ങൾക്ക് ഒന്നോ അല്ലെങ്കിൽ മറ്റൊന്നോ ഉണർത്താൻ കഴിയും. അങ്ങനെ നമ്മൾ ഒന്നല്ലെങ്കിൽ മറ്റൊന്ന് ഉണരും. എന്നാൽ സിസ്റ്റത്തിൽ എന്താണ് സംഭവിക്കുന്നത്? ഏറ്റവും മുകളിലുള്ള 703 എങ്ങനെയാണ് സ്വന്തം ഇടപാട് ഐഡി ബ്ലോക്ക് ചെയ്തതെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും. പോസ്റ്റ്ഗ്രെസ് പ്രവർത്തിക്കുന്നത് ഇങ്ങനെയാണ്. കൂടാതെ, 703 അതിന്റെ സ്വന്തം ഇടപാട് ഐഡി വഴി ബ്ലോക്ക് ചെയ്‌തിരിക്കുന്നു, അതിനാൽ ആരെങ്കിലും കാത്തിരിക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, അവർ 703-നായി കാത്തിരിക്കും. ചുരുക്കത്തിൽ, 703 പൂർത്തിയാകും. അതിന്റെ പൂർത്തീകരണത്തിനു ശേഷം മാത്രമേ ഒരു പ്രക്രിയ ഉണർത്തുകയുള്ളൂ. ഈ പ്രക്രിയ കൃത്യമായി എന്തായിരിക്കുമെന്ന് ഞങ്ങൾക്ക് അറിയില്ല. പിന്നെ ഞങ്ങൾ എല്ലാം ക്രമേണ പ്രോസസ്സ് ചെയ്യുന്നു. എന്നാൽ ഏത് പ്രക്രിയയാണ് ആദ്യം ഉണർന്നതെന്ന് വ്യക്തമല്ല, കാരണം ഇത് ഈ പ്രക്രിയകളിൽ ഏതെങ്കിലും ആകാം. അടിസ്ഥാനപരമായി, ഞങ്ങൾക്ക് ഇപ്പോൾ ഈ പ്രക്രിയകളിൽ ഏതെങ്കിലും ഉണർത്താൻ കഴിയുമെന്ന് പറയുന്ന ഒരു ഷെഡ്യൂളർ ഉണ്ടായിരുന്നു. ഞങ്ങൾ ക്രമരഹിതമായി ഒരെണ്ണം തിരഞ്ഞെടുക്കുന്നു. അതിനാൽ അവ രണ്ടും ശ്രദ്ധിക്കേണ്ടതുണ്ട്, കാരണം അവയിലൊന്നിനെ ഉണർത്താൻ നമുക്ക് കഴിയും.

പിന്നെ പ്രശ്നം നമുക്ക് CP-infinity ഉണ്ട് എന്നതാണ്. അതിനാൽ, പിന്നീടുള്ളതിനെ നമുക്ക് ഉണർത്താൻ സാധ്യതയുണ്ട്. ഉദാഹരണത്തിന്, ഞങ്ങൾ പിന്നീടുള്ളവരെ ഉണർത്തുകയാണെങ്കിൽ, ഇപ്പോൾ ബ്ലോക്ക് ലഭിച്ചയാൾക്കായി ഞങ്ങൾ കാത്തിരിക്കും, അതിനാൽ ആരാണ് ആദ്യം ഉണർന്നതെന്ന് ഞങ്ങൾ നിർണ്ണയിക്കുന്നില്ല. ഞങ്ങൾ അത്തരമൊരു സാഹചര്യം സൃഷ്ടിക്കുന്നു, സിസ്റ്റം അവരെ ക്രമരഹിതമായ ക്രമത്തിൽ ഉണർത്തും.

ഉണ്ട് എഗോർ റോഗോവിന്റെ ലോക്കുകളെക്കുറിച്ചുള്ള ലേഖനങ്ങൾ. നോക്കൂ, അവ രസകരവും ഉപയോഗപ്രദവുമാണ്. തീർച്ചയായും, വിഷയം വളരെ സങ്കീർണ്ണമാണ്. വളരെ നന്ദി, ബ്രൂസ്!

അവലംബം: www.habr.com