ലേഖനത്തിന്റെ വിവർത്തനം കോഴ്‌സിലെ വിദ്യാർത്ഥികൾക്കായി പ്രത്യേകം തയ്യാറാക്കിയതാണ് "ഡാറ്റാബേസ്". ഈ ദിശയിൽ വികസിപ്പിക്കാൻ താൽപ്പര്യമുണ്ടോ? ഞങ്ങൾ നിങ്ങളെ ക്ഷണിക്കുന്നു തുറന്ന ദിവസം, അവിടെ ഞങ്ങൾ പ്രോഗ്രാമിനെ കുറിച്ച് വിശദമായി സംസാരിക്കുന്നു, ഓൺലൈൻ ഫോർമാറ്റിന്റെ സവിശേഷതകൾ, പരിശീലനത്തിന് ശേഷം ബിരുദധാരികളെ കാത്തിരിക്കുന്ന കഴിവുകൾ, തൊഴിൽ സാധ്യതകൾ.

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

എനിക്ക് എന്തിനാണ് ഇത് വേണ്ടത്?

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

ഒത്തുതീർപ്പിനെ നേരിടുക

ഡാറ്റ സ്ഥിരതയും പ്രകടനവും തമ്മിൽ നിങ്ങൾ ഇടപാടുകൾ നടത്തേണ്ടതുണ്ട്. PostgreSQL സ്ഥിരതയിൽ നിന്ന് അകന്നുപോകുന്നു, കാരണം സ്ഥിരസ്ഥിതി കോൺഫിഗറേഷൻ പ്രവചിക്കാവുന്നതും അപ്രതീക്ഷിതമായ ആശ്ചര്യങ്ങളില്ലാതെയുമാണ്. ഇനി വിട്ടുവീഴ്ചകൾ നോക്കാം.

വ്യാപാരം 1: പ്രകടനം

PostgreSQL ക്ലസ്റ്ററിന് സ്ഥിരത ആവശ്യമില്ലെങ്കിൽ, അത് അസമന്വിതമായി പ്രവർത്തിക്കാൻ കഴിയും. ക്ലസ്റ്റർ ലീഡർക്കാണ് എഴുത്ത് നൽകിയത്, ഏതാനും മില്ലിസെക്കൻഡുകൾക്ക് ശേഷം അപ്‌ഡേറ്റുകൾ അതിന്റെ പകർപ്പുകളിലേക്ക് അയയ്‌ക്കും. ഒരു PostgreSQL ക്ലസ്റ്ററിന് സ്ഥിരത ആവശ്യമുള്ളപ്പോൾ, അത് സമന്വയത്തോടെ പ്രവർത്തിക്കണം. ക്ലസ്റ്റർ ലീഡർക്കാണ് ഈ എഴുത്ത് നൽകുന്നത്, അത് പകർപ്പുകളിലേക്ക് ഒരു അപ്‌ഡേറ്റ് അയയ്‌ക്കുകയും അത് വിജയകരമാണെന്ന് എഴുതാൻ ആരംഭിച്ച ക്ലയന്റിന് സ്ഥിരീകരണം അയയ്‌ക്കുന്നതിന് മുമ്പ് ഓരോരുത്തരും എഴുതിയിട്ടുണ്ടെന്ന് സ്ഥിരീകരണത്തിനായി കാത്തിരിക്കുകയും ചെയ്യും. ഈ സമീപനങ്ങൾ തമ്മിലുള്ള പ്രായോഗിക വ്യത്യാസം, അസിൻക്രണസ് രീതിക്ക് രണ്ട് നെറ്റ്‌വർക്ക് ഹോപ്പുകൾ ആവശ്യമാണ്, അതേസമയം സിൻക്രണസ് രീതിക്ക് നാല് ആവശ്യമാണ്.

വ്യാപാരം 2: സ്ഥിരത

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

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

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

ട്രേഡ് ഓഫ് 3: ക്രാഷുകൾ

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

ഒരു ഇടപാടിന് ഒരു കണക്ഷൻ?

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

ഈ തീരുമാനങ്ങളെല്ലാം, തീർച്ചയായും, ആപ്ലിക്കേഷൻ ഡെവലപ്പറാണ് എടുക്കുന്നത്. ഓരോ സമീപനവും എപ്പോൾ ഉപയോഗിക്കണം എന്നതിനെക്കുറിച്ച് ശരിയായ തീരുമാനങ്ങൾ എടുക്കുന്നത് നിങ്ങളുടെ ക്ലസ്റ്ററിൽ നിന്ന് പരമാവധി പ്രയോജനപ്പെടുത്താൻ നിങ്ങളെ സഹായിക്കും. കണക്ഷനുകൾക്കും ഇടപാടുകൾക്കുമായി ഡെവലപ്പർക്ക് SQL തലത്തിൽ അവയ്ക്കിടയിൽ മാറാൻ കഴിയുന്നത് പ്രധാനമാണ്.

പ്രായോഗികമായി നിയന്ത്രണം ഉറപ്പാക്കുന്നു

സ്ഥിരസ്ഥിതിയായി, PostgreSQL സ്ഥിരത നൽകുന്നു. ഇത് സെർവർ പാരാമീറ്ററാണ് നിയന്ത്രിക്കുന്നത് synchronous_commit. സ്ഥിരസ്ഥിതിയായി അത് സ്ഥാനത്താണ് on, എന്നാൽ ഇതിന് മറ്റ് മൂന്ന് ഓപ്ഷനുകൾ ഉണ്ട്: local, remote_write അഥവാ off.

പരാമീറ്റർ സജ്ജമാക്കുമ്പോൾ off ലോക്കൽ സിസ്റ്റത്തിൽ പോലും എല്ലാ സിൻക്രണസ് കമ്മിറ്റുകളും നിർത്തി. ലോക്കൽ പാരാമീറ്റർ ലോക്കൽ സിസ്റ്റത്തിനായുള്ള സിൻക്രണസ് മോഡ് വ്യക്തമാക്കുന്നു, എന്നാൽ പകർപ്പുകളിലേക്കുള്ള റൈറ്റുകൾ അസമന്വിതമായി നടപ്പിലാക്കുന്നു. Remote_write ഇനിയും മുന്നോട്ട് പോകുന്നു: പകർപ്പുകളിലേക്കുള്ള എഴുത്തുകൾ അസമന്വിതമായാണ് നിർമ്മിച്ചിരിക്കുന്നത്, എന്നാൽ പകർപ്പ് എഴുതുന്നത് സ്വീകരിച്ചു, പക്ഷേ അത് ഡിസ്കിലേക്ക് എഴുതാത്തപ്പോൾ തിരികെ നൽകും.

ലഭ്യമായ ഓപ്ഷനുകളുടെ ശ്രേണി പരിഗണിക്കുന്നതിലൂടെ, ഞങ്ങൾ ഒരു പെരുമാറ്റം തിരഞ്ഞെടുക്കുകയും അത് മനസ്സിൽ വയ്ക്കുകയും ചെയ്യുന്നു on - ഇവ സിൻക്രണസ് റെക്കോർഡിംഗുകളാണ്, ഞങ്ങൾ തിരഞ്ഞെടുക്കും local നെറ്റ്‌വർക്കിലൂടെയുള്ള അസിൻക്രണസ് കമ്മിറ്റുകൾക്കായി, ലോക്കൽ കമ്മിറ്റുകളെ സമന്വയിപ്പിക്കുന്നു.

ഇപ്പോൾ, ഇത് എങ്ങനെ സജ്ജീകരിക്കാമെന്ന് ഞങ്ങൾ നിങ്ങളോട് പറയും, എന്നാൽ ഞങ്ങൾ സജ്ജീകരിച്ചതായി സങ്കൽപ്പിക്കുക synchronous_commit в local സെർവറിനായി. പരാമീറ്റർ മാറ്റാൻ കഴിയുമോ എന്ന് ഞങ്ങൾ ചിന്തിച്ചു synchronous_commit ഈച്ചയിൽ, ഇത് സാധ്യമല്ലെന്ന് മാത്രമല്ല, ഇത് ചെയ്യാൻ രണ്ട് വഴികളുണ്ട്. നിങ്ങളുടെ കണക്ഷന്റെ സെഷൻ ഇനിപ്പറയുന്ന രീതിയിൽ സജ്ജമാക്കുക എന്നതാണ് ആദ്യത്തേത്:

SET SESSION synchronous_commit TO ON;  
// Your writes go here

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

ഒരൊറ്റ ഇടപാടിന് നിങ്ങൾക്ക് സിൻക്രണസ് റെപ്ലിക്കേഷൻ ലഭിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ രണ്ടാമത്തെ രീതി നല്ലതാണ്. പല NoSQL ജനറേഷൻ ഡാറ്റാബേസുകളിലും ഇടപാടുകൾ എന്ന ആശയം നിലവിലില്ല, പക്ഷേ അത് PostgreSQL-ൽ ഉണ്ട്. ഈ സാഹചര്യത്തിൽ നിങ്ങൾ ഒരു ഇടപാട് ആരംഭിക്കുകയും തുടർന്ന് സജ്ജമാക്കുകയും ചെയ്യുക synchronous_commit в on ഇടപാടിനുള്ള എൻട്രി നടപ്പിലാക്കുന്നതിന് മുമ്പ്. COMMIT ഏതെങ്കിലും പാരാമീറ്റർ മൂല്യം ഉപയോഗിച്ച് ഇടപാട് നടത്തും synchronous_commit, ആ സമയത്ത് സജ്ജീകരിച്ചത്, മറ്റ് ഡെവലപ്പർമാർ എഴുതുന്നത് അസമന്വിതമല്ലെന്ന് ഉറപ്പാക്കാൻ വേരിയബിൾ മുൻ‌കൂട്ടി സജ്ജീകരിക്കുന്നതാണ് നല്ലത്.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

കണക്റ്റുചെയ്‌ത ക്ലയന്റിലേക്ക് ഡാറ്റാബേസ് ഒരു നല്ല പ്രതികരണം നൽകുന്നതിന് മുമ്പ് എല്ലാ ഇടപാട് കമ്മിറ്റുകളും ഇപ്പോൾ പകർപ്പുകളിൽ എഴുതിയതായി സ്ഥിരീകരിക്കും.

PostgreSQL സജ്ജീകരിക്കുന്നു

ഇതിന് മുമ്പ്, ഞങ്ങൾ ഒരു PostgreSQL സിസ്റ്റം സങ്കൽപ്പിച്ചു synchronous_commit, ഇൻസ്റ്റാൾ ചെയ്തു local. സെർവർ വശത്ത് ഇത് യാഥാർത്ഥ്യമാക്കുന്നതിന്, നിങ്ങൾ രണ്ട് സെർവർ കോൺഫിഗറേഷൻ ഓപ്ഷനുകൾ സജ്ജമാക്കേണ്ടതുണ്ട്. ഒരു പരാമീറ്റർ കൂടി synchronous_standby_names എപ്പോൾ സ്വന്തമായി വരും synchronous_commit ഉള്ളിൽ ആയിരിക്കും on. ഏത് പകർപ്പുകളാണ് സിൻക്രണസ് കമ്മിറ്റുകൾക്ക് യോഗ്യമെന്ന് ഇത് നിർണ്ണയിക്കുന്നു, ഞങ്ങൾ അത് സജ്ജമാക്കും *, എല്ലാ പകർപ്പുകളും ഉൾപ്പെട്ടിരിക്കുന്നു എന്നാണ് ഇതിനർത്ഥം. ഈ മൂല്യങ്ങൾ സാധാരണയായി കോൺഫിഗർ ചെയ്യപ്പെടുന്നു കോൺഫിഗറേഷൻ ഫയൽ ചേർത്തുകൊണ്ട്:

synchronous_commit = local  
synchronous_standby_names='*'

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

നിങ്ങൾ വികസനം പിന്തുടരുകയാണെങ്കിൽ ഗവർണർ പദ്ധതി, സമീപകാലത്തെ ചില മാറ്റങ്ങൾ നിങ്ങൾ ശ്രദ്ധിച്ചിരിക്കാം (1, 2), ഈ പാരാമീറ്ററുകൾ പരിശോധിക്കാനും അവയുടെ സ്ഥിരത നിരീക്ഷിക്കാനും ഗവർണർ ഉപയോക്താക്കളെ അനുവദിച്ചു.

കുറച്ച് വാക്കുകൾ കൂടി...

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

ഈ ക്രമീകരണം എപ്പോൾ വേണമെങ്കിലും മാറ്റാവുന്നതാണ്. ഏതൊരു ഇടപാടിന്റെയും പെരുമാറ്റം നിർണ്ണയിക്കുന്നത് പ്രതിജ്ഞാബദ്ധസമയത്ത് പ്രാബല്യത്തിലുള്ള ക്രമീകരണമാണ്. അതിനാൽ, ചില ഇടപാടുകൾ സമന്വയത്തോടെയും മറ്റുള്ളവയ്ക്ക് അസമന്വിതമായും നടത്താനുള്ള സാധ്യതയും ഉപയോഗപ്രദവുമാണ്. ഉദാഹരണത്തിന്, ഒന്ന് നിർബന്ധിക്കാൻ multistatement പരാമീറ്ററിന്റെ ഡിഫോൾട്ട് മൂല്യം വിപരീതമായിരിക്കുമ്പോൾ, സെറ്റ് ചെയ്യാനുള്ള ഇടപാട് അസമന്വിതമായി നടത്തുന്നു SET LOCAL synchronous_commit TO OFF ഒരു ഇടപാടിൽ.

കോൺഫിഗറേഷൻ ഫയലിലെ ഈ ചെറിയ പരിഷ്ക്കരണത്തിലൂടെ, ഞങ്ങൾ ഉപയോക്താക്കൾക്ക് അവരുടെ സ്ഥിരതയിലും പ്രകടനത്തിലും നിയന്ത്രണം നൽകി.

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