लेखों की पिछली दो श्रृंखलाओं ने अलगाव और बहुसंस्कृतिवाद और जर्नलिंग पर ध्यान केंद्रित किया है।

इस श्रृंखला में हम ताले के बारे में बात करेंगे। मैं इस शब्द का पालन करूंगा, लेकिन साहित्य में एक और भी हो सकता है: महल ।

चक्र में चार भाग होंगे:

रिश्ते के ताले (यह लेख);
पंक्ति ताले ;
अन्य वस्तुओं के ताले और विधेय ताले;
रैम में ताले ।

सभी लेखों की सामग्री प्रशासनिक प्रशिक्षण पाठ्यक्रमों पर आधारित है जो पावेल प्लूज़नोव और मैं करते हैं , लेकिन उन्हें शब्दशः दोहराते नहीं हैं और विचारशील पढ़ने और स्वतंत्र प्रयोग के लिए अभिप्रेत हैं।

ताले के बारे में सामान्य जानकारी

PostgreSQL कई अलग-अलग तंत्रों का उपयोग करता है जो कुछ को ब्लॉक करने के लिए उपयोग किया जाता है (या कम से कम इसे कहा जाता है)। इसलिए, मैं सबसे सामान्य शब्दों के साथ शुरू करूंगा कि ताले की आवश्यकता क्यों है, वे क्या हैं और वे एक दूसरे से कैसे भिन्न हैं। फिर हम देखेंगे कि PostgreSQL में यह किस्म क्या पाई जाती है और उसके बाद ही हम विभिन्न प्रकार के तालों के बारे में विस्तार से सौदा करना शुरू करेंगे।

साझा संसाधनों तक समवर्ती पहुंच को सुव्यवस्थित करने के लिए ताले का उपयोग किया जाता है।

प्रतिस्पर्धी पहुंच से तात्पर्य कई प्रक्रियाओं के एक साथ उपयोग से है। प्रक्रियाओं को स्वयं समानांतर (यदि उपकरण अनुमति देता है) और समय-साझाकरण मोड में क्रमिक रूप से दोनों किया जा सकता है - यह महत्वपूर्ण नहीं है।

यदि कोई प्रतिस्पर्धा नहीं है, तो ताले की आवश्यकता नहीं है (उदाहरण के लिए, एक साझा बफर कैश में ताले की आवश्यकता होती है, लेकिन एक स्थानीय व्यक्ति नहीं करता है)।

किसी संसाधन तक पहुँचने से पहले, एक प्रक्रिया को उस संसाधन से जुड़े लॉक का अधिग्रहण करना होगा। यही है, हम एक निश्चित अनुशासन के बारे में बात कर रहे हैं: जब तक सभी प्रक्रियाएं साझा संसाधन तक पहुंचने के लिए स्थापित नियमों का पालन करती हैं, तब तक सब कुछ काम करता है। यदि डीबीएमएस ताले का प्रबंधन करता है, तो यह स्वयं आदेश की निगरानी करता है; यदि आवेदन द्वारा अवरुद्ध किया जाता है, तो यह दायित्व उस पर पड़ता है।

निम्न स्तर पर, एक लॉक को साझा मेमोरी के एक खंड द्वारा दर्शाया जाता है, जिसमें यह किसी तरह से नोट किया जाता है कि क्या लॉक मुफ्त है या कब्जा कर लिया गया है (और, संभवतः, अतिरिक्त जानकारी दर्ज की गई है: प्रक्रिया संख्या, कैप्चर समय, आदि)।

आप देख सकते हैं कि इस तरह की साझा की गई मेमोरी अपने आप में एक संसाधन है, जिसके लिए प्रतिस्पर्धात्मक पहुंच संभव है। यदि हम नीचे एक स्तर नीचे जाते हैं, तो हम देखेंगे कि ओएस द्वारा प्रदान किए गए विशेष सहायक प्राइमेटिव (जैसे कि सेमीफोर्स या म्यूटेक्स) का उपयोग एक्सेस को व्यवस्थित करने के लिए किया जाता है। उनका अर्थ यह है कि साझा संसाधन तक पहुंचने वाले कोड को एक समय में केवल एक प्रक्रिया में निष्पादित किया जाना चाहिए। निम्नतम स्तर पर, ये प्राइमिटिव परमाणु प्रोसेसर निर्देशों (जैसे कि परीक्षण-और-सेट या तुलना-और-स्वैप) के आधार पर कार्यान्वित किए जाते हैं।

प्रक्रिया द्वारा संसाधन की आवश्यकता नहीं होने के बाद, यह लॉक को रिलीज़ करता है ताकि अन्य संसाधन का उपयोग कर सकें।

बेशक, ताला बंद करना हमेशा संभव नहीं होता है: संसाधन पहले से ही किसी और द्वारा लिया जा सकता है। फिर प्रक्रिया या तो प्रतीक्षा कतार में प्रवेश करती है (यदि लॉकिंग तंत्र यह अवसर देता है), या एक निश्चित समय के बाद लॉक को पकड़ने के लिए पुन: प्रयास करता है। एक तरह से या किसी अन्य, यह इस तथ्य की ओर जाता है कि संसाधन की रिहाई की प्रत्याशा में प्रक्रिया को निष्क्रिय खड़े होने के लिए मजबूर किया जाता है।

कभी-कभी अन्य गैर-अवरुद्ध रणनीतियों को लागू करना संभव है। उदाहरण के लिए, बहु- संस्करण तंत्र कुछ मामलों में कई प्रक्रियाओं को एक-दूसरे को अवरुद्ध किए बिना डेटा के विभिन्न संस्करणों के साथ एक साथ काम करने की अनुमति देता है।

सिद्धांत रूप में, एक संरक्षित संसाधन कुछ भी हो सकता है, यदि केवल इस संसाधन को अवरुद्ध पते के साथ स्पष्ट रूप से पहचाना और मिलान किया जा सकता है।

उदाहरण के लिए, संसाधन वह ऑब्जेक्ट हो सकता है जो DBMS के साथ काम कर रहा है, जैसे कि एक डेटा पेज (फ़ाइल के अंदर फ़ाइल नाम और स्थिति द्वारा पहचाना गया), एक टेबल (सिस्टम डायरेक्टरी में ओड), एक टेबल रो (पेज और पेज के अंदर ऑफसेट)। एक संसाधन मेमोरी में एक संरचना हो सकती है, जैसे कि हैश टेबल, बफर, आदि (पूर्व-निर्धारित संख्या द्वारा पहचानी गई)। कभी-कभी यह अमूर्त संसाधनों का उपयोग करने के लिए भी सुविधाजनक होता है, जिसका कोई भौतिक अर्थ नहीं होता है (वे केवल एक अद्वितीय संख्या से पहचाने जाते हैं)।

तालों की प्रभावशीलता कई कारकों से प्रभावित होती है, जिनमें से हम दो को अलग करते हैं।

यदि संसाधन एक पदानुक्रम बनाते हैं, तो ग्रैन्युलैरिटी (ग्रैन्युलैरिटी) महत्वपूर्ण है।

उदाहरण के लिए, एक तालिका में पृष्ठ होते हैं जिनमें तालिका पंक्तियाँ होती हैं। ये सभी ऑब्जेक्ट संसाधन के रूप में कार्य कर सकते हैं। यदि प्रक्रियाओं को आमतौर पर बस कुछ पंक्तियों में रुचि होती है, और तालिका स्तर पर लॉक सेट किया जाता है, तो अन्य प्रक्रियाएं एक ही समय में विभिन्न पंक्तियों के साथ काम करने में सक्षम नहीं होंगी। इसलिए, दानेदारता जितनी अधिक होगी, समानांतरकरण की संभावना के लिए बेहतर होगा।

लेकिन इससे तालों की संख्या में वृद्धि होती है (जानकारी जिसके बारे में स्मृति में संग्रहीत किया जाना चाहिए)। इस मामले में, ताले के स्तर (वृद्धि) में वृद्धि लागू की जा सकती है: जब निम्न-स्तर की संख्या, दानेदार ताले एक निश्चित सीमा से अधिक हो जाते हैं, तो उन्हें उच्च स्तर के एक लॉक के साथ बदल दिया जाता है।
ताले को अलग-अलग मोड में कैप्चर किया जा सकता है ।

मोड के नाम बिल्कुल मनमाने हो सकते हैं, केवल एक दूसरे के साथ उनकी संगतता का मैट्रिक्स महत्वपूर्ण है। किसी भी मोड के साथ असंगत एक मोड (स्वयं के साथ) को आमतौर पर अनन्य या अनन्य कहा जाता है। यदि मोड संगत हैं, तो एक साथ कई प्रक्रियाओं द्वारा लॉक को कैप्चर किया जा सकता है; ऐसे मोड को साझा कहा जाता है। सामान्य तौर पर, एक-दूसरे के साथ संगत अधिक भिन्न तरीकों को प्रतिष्ठित किया जा सकता है, अधिक अवसर समानता के लिए बनाए जाते हैं।

उपयोग के समय के अनुसार, ताले को लंबे और छोटे में विभाजित किया जा सकता है।

लंबे समय तक ताले संभावित रूप से लंबे समय तक (आमतौर पर लेनदेन के अंत तक) पर कब्जा कर लिया जाता है और अक्सर तालिकाओं (रिश्तों) और पंक्तियों जैसे संसाधनों से संबंधित होता है। PostgreSQL आमतौर पर इन तालों को स्वचालित रूप से प्रबंधित करता है, लेकिन उपयोगकर्ता का इस प्रक्रिया पर कुछ नियंत्रण होता है।

लंबे तालों को बड़ी संख्या में मोड की विशेषता होती है ताकि डेटा पर अधिक से अधिक एक साथ क्रियाओं को संभव हो सके। आमतौर पर, ऐसे ताले के लिए, एक विकसित बुनियादी ढांचा होता है (उदाहरण के लिए, प्रतीक्षा कतारों का समर्थन और गतिरोधों का पता लगाना) और निगरानी उपकरण, क्योंकि संरक्षित डेटा पर संचालन की लागत की तुलना में इन सभी सुविधाओं को बनाए रखने की लागत अभी भी अतुलनीय रूप से कम है।
अल्पकालिक तालों को थोड़े समय के लिए (कुछ प्रोसेसर निर्देशों से एक सेकंड के अंशों में) पकड़ा जाता है और आमतौर पर साझा मेमोरी में डेटा संरचनाओं को संदर्भित करता है। PostgreSQL ऐसे ताले को पूरी तरह से स्वचालित रूप से प्रबंधित करता है - आपको बस उनके अस्तित्व के बारे में जानने की आवश्यकता है।

लघु तालों की विशेषता न्यूनतम मोड (अनन्य और साझा) और एक साधारण बुनियादी ढांचे से होती है। कुछ मामलों में, निगरानी उपकरण भी उपलब्ध नहीं हो सकते हैं।

PostgreSQL विभिन्न प्रकार के ताले का उपयोग करता है।

ऑब्जेक्ट स्तर पर ताले दीर्घकालिक हैं, "हैवीवेट" ताले । यहां के संसाधन संबंध और अन्य वस्तुएं हैं। यदि पाठ में बिना किसी स्पष्टीकरण के अवरुद्ध शब्द दिखाई देता है, तो यह ऐसे "सामान्य" अवरोध को दर्शाता है।

लंबे समय तक ताले के बीच, पंक्ति-स्तरीय ताले अलग-अलग खड़े होते हैं। उनका कार्यान्वयन उनके संभावित विशाल संख्या (एक लेनदेन में एक लाख पंक्तियों को अपडेट करने की कल्पना) के कारण अन्य दीर्घकालिक तालों से भिन्न होता है। इस तरह के ताले पर अगले लेख में चर्चा की जाएगी।

श्रृंखला का तीसरा लेख ऑब्जेक्ट स्तर पर शेष ताले के लिए समर्पित होगा, साथ ही साथ विधेय ताले (चूंकि इन सभी ताले के बारे में जानकारी उसी तरह रैम में संग्रहीत होती है)।

लघु तालों में रैम संरचनाओं के विभिन्न ताले शामिल हैं। हम उन्हें चक्र के अंतिम लेख में विचार करेंगे।

वस्तु ताले

तो, हम ऑब्जेक्ट स्तर के ताले से शुरू करते हैं। यहां, किसी वस्तु को पहले स्थान पर संबंधों के रूप में समझा जाता है, अर्थात् टेबल, इंडेक्स, अनुक्रम, भौतिक प्रतिनिधित्व, लेकिन कुछ अन्य संस्थाएं भी। ये ताले आमतौर पर वस्तुओं को एक ही समय में बदलने से या वस्तु को बदलने के दौरान उपयोग किए जाने से बचाते हैं, लेकिन अन्य जरूरतों के लिए भी।

धुँधली कीड़ा? यह है, क्योंकि इस समूह के ताले विभिन्न प्रयोजनों के लिए उपयोग किए जाते हैं। उन्हें क्या एकजुट करता है, कैसे उनकी व्यवस्था की जाती है।

युक्ति

ऑब्जेक्ट लॉक सर्वर की साझा मेमोरी में स्थित हैं। उनकी संख्या दो मापदंडों के उत्पाद द्वारा सीमित है: max_locks_per_transaction × max_connections ।

लॉक लेन-देन सभी लेन-देन के लिए सामान्य है, अर्थात, एक लेन-देन max_locks_per_transaction से अधिक तालों को पकड़ सकता है: यह केवल महत्वपूर्ण है कि सिस्टम में कुल तालों की संख्या निर्धारित सीमा से अधिक न हो। पूल स्टार्टअप पर बनाया गया है, इसलिए दोनों विकल्पों में से किसी एक को बदलने के लिए सर्वर रिबूट की आवश्यकता होती है।

सभी ताले pg_locks दृश्य में देखे जा सकते हैं।

यदि संसाधन पहले से ही असंगत मोड में बंद है, तो इस संसाधन को कैप्चर करने का प्रयास करने वाला लेन-देन कतारबद्ध है और लॉक जारी होने का इंतजार करता है। लंबित लेनदेन प्रोसेसर संसाधनों का उपभोग नहीं करते हैं: संबंधित सेवा प्रक्रिया "सो जाते हैं" और संसाधन जारी होने पर ऑपरेटिंग सिस्टम द्वारा उठता है।

एक गतिरोध की स्थिति संभव है जिसमें एक लेन-देन को जारी रखने के लिए दूसरे लेनदेन के कब्जे वाले संसाधन की आवश्यकता होती है, और दूसरे को पहले (सामान्य स्थिति में, एक गतिरोध और दो से अधिक लेनदेन हो सकते हैं) द्वारा कब्जा किए गए संसाधन की आवश्यकता होती है। इस मामले में, प्रतीक्षा अनिश्चित काल तक जारी रहेगी, इसलिए PostgreSQL स्वचालित रूप से ऐसी स्थितियों का पता लगाता है और लेनदेन में से एक को निरस्त कर देता है ताकि अन्य लोग काम करना जारी रख सकें। (हम अगले लेख में गतिरोधों के बारे में अधिक बात करेंगे।)

वस्तु प्रकार

यहां तालों के प्रकारों की एक सूची दी गई है (या, यदि आप चाहें, तो वस्तुओं के प्रकार) जिन्हें हम इस और अगले लेख में देखेंगे। नाम pg_locks दृश्य के लॉकटाइप कॉलम के अनुसार दिए गए हैं।

संबंध

रिश्ते को ताले।
लेन-देन और virtualxid

एक लेनदेन संख्या (वास्तविक या आभासी) को अवरुद्ध करना। प्रत्येक लेनदेन में स्वयं अपने नंबर का एक विशिष्ट लॉक होता है, इसलिए ऐसे लॉक का उपयोग करना सुविधाजनक होता है जब आपको किसी अन्य लेनदेन के अंत तक प्रतीक्षा करने की आवश्यकता होती है।
टपल

स्ट्रिंग संस्करण लॉक। इसका उपयोग कुछ मामलों में एक ही पंक्ति को लॉक करने की अपेक्षा करने वाले कई लेनदेन के बीच प्राथमिकता निर्धारित करने के लिए किया जाता है।

हम चक्र में तीसरे लेख तक अन्य प्रकार के ताले की चर्चा को स्थगित कर देंगे। उन सभी को या तो केवल असाधारण मोड में, या अनन्य और साझा में कैप्चर किया जाता है।

विस्तार

किसी भी रिश्ते की फाइल में पेज जोड़ते समय इसका इस्तेमाल किया जाता है।
वस्तु

उन वस्तुओं को लॉक करना जो रिश्ते नहीं हैं (डेटाबेस, स्कीमा, सदस्यता, आदि)।
पेज

पृष्ठ लॉक का उपयोग बार-बार और केवल कुछ प्रकार के अनुक्रमित द्वारा किया जाता है।
सलाहकार

अनुशंसित अवरुद्ध, मैन्युअल रूप से उपयोगकर्ता द्वारा निर्धारित।

रिश्ते को ताले

संदर्भ न खोने के लिए, मैं इस तरह के एक चित्र को उन प्रकार के तालों पर चिह्नित करूंगा, जिनकी चर्चा बाद में की जाएगी।

मोड

यदि सबसे महत्वपूर्ण नहीं है, तो निश्चित रूप से सबसे "शाखा" अवरुद्ध - अवरुद्ध संबंध है। उसके लिए, 8 विभिन्न मोड परिभाषित किए गए हैं। इतनी मात्रा आवश्यक है ताकि एक तालिका से संबंधित निर्देशों की सबसे बड़ी संभव संख्या को एक साथ निष्पादित किया जा सके।

इन तरीकों को दिल से सीखने या उनके नामों के अर्थ को समझने की कोशिश करने का कोई मतलब नहीं है; मुख्य बात यह है कि सही समय पर आपकी आंखों के सामने एक मैट्रिक्स होना चाहिए, जो दर्शाता है कि एक-दूसरे के साथ टकराव को कौन रोकता है। सुविधा के लिए, यह उपयुक्त लॉकिंग स्तर की आवश्यकता वाले कमांड के उदाहरणों के साथ यहां पुन: प्रस्तुत किया गया है:

लॉक मोड	के रूप में	रुपये	आरई	स्यू	एस	एसआरई	ए	एई	नमूना SQL आदेश
पहुंच साझा करें								एक्स	का चयन करें
पंक्ति साझा करें							एक्स	एक्स	अद्यतन / शेयर के लिए चयन करें
पंक्ति विशेष					एक्स	एक्स	एक्स	एक्स	INSERT, UPDATE, DELETE
शेयर अपडेट एक्सक्लूसिव				एक्स	एक्स	एक्स	एक्स	एक्स	वैकुम, अन्य तालिका ^* , भारत के संदर्भ में बनाएँ
शेयर			एक्स	एक्स		एक्स	एक्स	एक्स	पैदा करना
शेयर एक्सक्लूसिव			एक्स	एक्स	एक्स	एक्स	एक्स	एक्स	बनाने का काम, बेहतर टेबल ^*
अनन्य		एक्स	एक्स	एक्स	एक्स	एक्स	एक्स	एक्स	रेफरी मेट। नियमित रूप से देखें
अनन्य पहुँच	एक्स	एक्स	एक्स	एक्स	एक्स	एक्स	एक्स	एक्स	DROP, TRUNCATE, VACUUM FULL, LOCK TABLE, ALTER TABLE ^* , REFRESH MAT। देखें

कुछ टिप्पणियाँ:

पहले 4 मोड तालिका में एक साथ डेटा परिवर्तन की अनुमति देते हैं, और अगले 4 नहीं करते हैं।
पहला मोड (एक्सेस शेयर) सबसे कमजोर है, यह पिछले (एक्सेस एक्सक्लूसिव) के अलावा किसी भी अन्य के साथ संगत है। यह अंतिम मोड अनन्य है, यह किसी भी मोड के साथ संगत नहीं है।
ALTER TABLE कमांड में कई विकल्प होते हैं, जिनमें से विभिन्न को लॉक करने के विभिन्न स्तरों की आवश्यकता होती है। इसलिए, मैट्रिक्स में, यह कमांड विभिन्न लाइनों पर दिखाई देता है और तारांकन चिह्न के साथ चिह्नित होता है।

उदाहरण के लिए, उदाहरण के लिए

एक उदाहरण दें। अगर मैं CREATE INDEX कमांड चलाता हूं तो क्या होगा?

हम दस्तावेज़ में यह कमांड शेयर मोड में लॉक सेट करते हैं। मैट्रिक्स के अनुसार, हम यह निर्धारित करते हैं कि कमांड स्वयं के साथ संगत है (अर्थात, आप एक साथ कई इंडेक्स बना सकते हैं) और रीडिंग कमांड के साथ। इस प्रकार, SELECT कमांड काम करना जारी रखेगा, लेकिन UPDATE, DELETE, INSERT कमांड ब्लॉक हो जाएंगे।

और इसके विपरीत - तालिका में डेटा को संशोधित करने वाले अपूर्ण लेनदेन क्रिएट इंडेक्स कमांड के संचालन को रोक देंगे। इसलिए, कमांड का एक प्रकार है - क्रेट इंडेक्स सहमति। यह लंबे समय तक काम करता है (और एक त्रुटि के साथ भी गिर सकता है), लेकिन एक साथ डेटा परिवर्तन की अनुमति देता है।

इसे व्यवहार में देखा जा सकता है। प्रयोगों के लिए, हम पहले चक्र से परिचित "बैंक" खातों की तालिका का उपयोग करेंगे, जिसमें हम खाता संख्या और राशि संग्रहीत करेंगे।

=> CREATE TABLE accounts( acc_no integer PRIMARY KEY, amount numeric ); => INSERT INTO accounts VALUES (1,1000.00), (2,2000.00), (3,3000.00);

दूसरे सत्र में, लेनदेन शुरू करें। हमें एक सेवा प्रक्रिया संख्या चाहिए।

 | => SELECT pg_backend_pid();

 | pg_backend_pid | ---------------- | 4746 | (1 row)

नए शुरू किए गए लेन-देन में क्या ताले हैं? हम pg_locks में दिखते हैं:

 => SELECT locktype, relation::REGCLASS, virtualxid AS virtxid, transactionid AS xid, mode, granted FROM pg_locks WHERE pid = 4746;

  locktype | relation | virtxid | xid | mode | granted ------------+----------+---------+-----+---------------+--------- virtualxid | | 5/15 | | ExclusiveLock | t (1 row)

जैसा कि मैंने पहले ही कहा था, एक लेनदेन हमेशा अपने नंबर का एक अनन्य (एक्सक्लूसिवलॉक) लॉक रखता है, इस मामले में, एक आभासी। इस प्रक्रिया पर अन्य ताले नहीं हैं।

अब टेबल रो को अपडेट करें। कैसे बदलेगी स्थिति?

 | => UPDATE accounts SET amount = amount + 100 WHERE acc_no = 1;

 => \g

  locktype | relation | virtxid | xid | mode | granted ---------------+---------------+---------+--------+------------------+--------- relation | accounts_pkey | | | RowExclusiveLock | t relation | accounts | | | RowExclusiveLock | t virtualxid | | 5/15 | | ExclusiveLock | t transactionid | | | 529404 | ExclusiveLock | t (4 rows)

अब उत्परिवर्तित तालिका और सूचकांक (प्राथमिक कुंजी के लिए बनाई गई) पर ताले हैं, जिसका उपयोग UPDATE कमांड द्वारा किया जाता है। दोनों ताले RowExclusiveLock मोड में लिए गए हैं। इसके अलावा, वास्तविक लेनदेन संख्या का एक विशेष अवरोध जोड़ा गया (जो कि जैसे ही लेनदेन डेटा को बदलना शुरू हुआ) दिखाई दिया।

अब दूसरे सत्र में हम एक तालिका पर एक सूचकांक बनाने की कोशिश करेंगे।

 || => SELECT pg_backend_pid();

 || pg_backend_pid || ---------------- || 4782 || (1 row)

 || => CREATE INDEX ON accounts(acc_no);

आदेश संसाधन जारी करने की प्रत्याशा में जमा देता है। वह किस तरह का ताला पकड़ने की कोशिश कर रहा है? की जाँच करें:

 => SELECT locktype, relation::REGCLASS, virtualxid AS virtxid, transactionid AS xid, mode, granted FROM pg_locks WHERE pid = 4782;

  locktype | relation | virtxid | xid | mode | granted ------------+----------+---------+-----+---------------+--------- virtualxid | | 6/15 | | ExclusiveLock | t relation | accounts | | | ShareLock | f (2 rows)

हम देखते हैं कि लेनदेन ShareLock मोड में टेबल लॉक प्राप्त करने की कोशिश कर रहा है, लेकिन (= f) प्रदान नहीं किया जा सकता है।

अवरोधक प्रक्रिया की संख्या और सामान्य रूप से कई संख्याओं में, 9.6 संस्करण में दिखाई देने वाले फ़ंक्शन का उपयोग करना सुविधाजनक है (इससे पहले मुझे pg_locks की सभी सामग्रियों को ध्यान से देखकर निष्कर्ष निकालना था):

 => SELECT pg_blocking_pids(4782);

  pg_blocking_pids ------------------ {4746} (1 row)

और फिर, स्थिति को समझने के लिए, आप सत्रों के बारे में जानकारी प्राप्त कर सकते हैं, जिसमें पाए गए नंबर शामिल हैं:

 => SELECT * FROM pg_stat_activity WHERE pid = ANY(pg_blocking_pids(4782)) \gx

 -[ RECORD 1 ]----+------------------------------------------------------------ datid | 16386 datname | test pid | 4746 usesysid | 16384 usename | student application_name | psql client_addr | client_hostname | client_port | -1 backend_start | 2019-08-07 15:02:53.811842+03 xact_start | 2019-08-07 15:02:54.090672+03 query_start | 2019-08-07 15:02:54.10621+03 state_change | 2019-08-07 15:02:54.106965+03 wait_event_type | Client wait_event | ClientRead state | idle in transaction backend_xid | 529404 backend_xmin | query | UPDATE accounts SET amount = amount + 100 WHERE acc_no = 1; backend_type | client backend

लेनदेन पूरा होने के बाद, ताले जारी किए जाते हैं और सूचकांक बनाया जाता है।

 | => COMMIT;

 | COMMIT

 || CREATE INDEX

कतार में! ..

एक असंगत लॉक की उपस्थिति क्या होती है, इसकी बेहतर कल्पना करने के लिए, हम देखेंगे कि सिस्टम के संचालन के दौरान VACUUM FULL कमांड को निष्पादित करने पर क्या होता है।

का चयन करें कमान पहले हमारी मेज पर निष्पादित किया जाता है। उसे एक्सेस शेयर के सबसे कमजोर स्तर पर ताला मिलता है। लॉक रिलीज के समय को नियंत्रित करने के लिए, हम लेन-देन के अंदर इस कमांड को निष्पादित करते हैं - जब तक लेनदेन समाप्त नहीं हो जाता, तब तक लॉक जारी नहीं किया जाएगा। वास्तव में, कई कमांड टेबल को पढ़ (और संशोधित) कर सकते हैं, और कुछ प्रश्नों में काफी समय लग सकता है।

 => BEGIN; => SELECT * FROM accounts;

  acc_no | amount --------+--------- 2 | 2000.00 3 | 3000.00 1 | 1100.00 (3 rows)

 => SELECT locktype, mode, granted, pid, pg_blocking_pids(pid) AS wait_for FROM pg_locks WHERE relation = 'accounts'::regclass;

  locktype | mode | granted | pid | wait_for ----------+-----------------+---------+------+---------- relation | AccessShareLock | t | 4710 | {} (1 row)

तब व्यवस्थापक VACUUM FULL कमांड निष्पादित करता है, जिसके लिए एक्सेस एक्सक्लूसिव स्तर लॉक की आवश्यकता होती है, एक्सेस शेयर के साथ भी कुछ भी असंगत। (लॉक टेबल कमांड को भी उसी लॉक की आवश्यकता होती है।) लेन-देन की कतारें।

 | => BEGIN; | => LOCK TABLE accounts; --  VACUUM FULL

 => SELECT locktype, mode, granted, pid, pg_blocking_pids(pid) AS wait_for FROM pg_locks WHERE relation = 'accounts'::regclass;

  locktype | mode | granted | pid | wait_for ----------+---------------------+---------+------+---------- relation | AccessShareLock | t | 4710 | {} relation | AccessExclusiveLock | f | 4746 | {4710} (2 rows)

लेकिन एप्लिकेशन अनुरोध जारी करना जारी रखता है, और अब सिस्टम में SELECT कमांड दिखाई देता है। विशुद्ध रूप से सैद्धांतिक रूप से, वह "फिसल" सकती थी, जबकि VACUUM FULL का इंतजार किया जा रहा है, लेकिन नहीं - वह ईमानदारी से VACUUM FULL के लिए कतार में जगह लेती है।

 || => SELECT * FROM accounts;

 => SELECT locktype, mode, granted, pid, pg_blocking_pids(pid) AS wait_for FROM pg_locks WHERE relation = 'accounts'::regclass;

  locktype | mode | granted | pid | wait_for ----------+---------------------+---------+------+---------- relation | AccessShareLock | t | 4710 | {} relation | AccessExclusiveLock | f | 4746 | {4710} relation | AccessShareLock | f | 4782 | {4746} (3 rows)

सेलेक्ट कमांड के साथ पहला ट्रांजेक्शन पूरा होने और लॉक जारी करने के बाद, VACUUM FULL कमांड शुरू होता है (जिसे हमने LOCK TABLE कमांड के साथ सिम्युलेटेड किया है)।

 => COMMIT;

 COMMIT

 | LOCK TABLE

 => SELECT locktype, mode, granted, pid, pg_blocking_pids(pid) AS wait_for FROM pg_locks WHERE relation = 'accounts'::regclass;

  locktype | mode | granted | pid | wait_for ----------+---------------------+---------+------+---------- relation | AccessExclusiveLock | t | 4746 | {} relation | AccessShareLock | f | 4782 | {4746} (2 rows)

और केवल VACUUM FULL अपना काम पूरा करने और लॉक को हटाने के बाद, कतार में संचित सभी कमांड (हमारे उदाहरण में सेलेक्ट) संबंधित ताले (एक्सेस शेयर) को कैप्चर करने और निष्पादित करने में सक्षम होंगे।

 | => COMMIT;

 | COMMIT

 || acc_no | amount || --------+--------- || 2 | 2000.00 || 3 | 3000.00 || 1 | 1100.00 || (3 rows)

इस प्रकार, एक गलत कमांड कमांड के निष्पादन समय की तुलना में काफी समय तक सिस्टम के संचालन को पंगु बना सकता है।

निगरानी उपकरण

बेशक, ताले सही संचालन के लिए आवश्यक हैं, लेकिन अवांछनीय उम्मीदों को जन्म दे सकते हैं। इस तरह की अपेक्षाओं को उनके कारण को समझने के लिए निगरानी की जा सकती है और यदि संभव हो तो, उन्हें समाप्त करें (उदाहरण के लिए, एप्लिकेशन एल्गोरिथ्म को बदलकर)।

हम पहले से ही एक विधि से परिचित हो गए हैं: एक लंबे लॉक के क्षण में, हम pg_locks देखने के अनुरोध को निष्पादित कर सकते हैं, लॉक करने योग्य और अवरुद्ध लेनदेन (pg_blocking_pids फ़ंक्शन) को देख सकते हैं और उन्हें pg_stat_activity के साथ डिक्रिप्ट कर सकते हैं।

दूसरा तरीका log_lock_waits पैरामीटर को सक्षम करना है। इस स्थिति में, सर्वर के संदेश लॉग में जानकारी दिखाई देगी यदि लेनदेन डेडलॉक_टाइमआउट से अधिक समय से प्रतीक्षा कर रहा है (इस तथ्य के बावजूद कि डेडलॉक के पैरामीटर का उपयोग किया जाता है, हम सामान्य अपेक्षाओं के बारे में बात कर रहे हैं)।

चलो इसे आजमाएँ।

 => ALTER SYSTEM SET log_lock_waits = on; => SELECT pg_reload_conf();

डिफ़ॉल्ट गति-समय पैरामीटर मान एक सेकंड है:

 => SHOW deadlock_timeout;

  deadlock_timeout ------------------ 1s (1 row)

ताला बजाओ।

 => BEGIN; => UPDATE accounts SET amount = amount - 100.00 WHERE acc_no = 1;

 UPDATE 1

 | => BEGIN; | => UPDATE accounts SET amount = amount + 100.00 WHERE acc_no = 1;

दूसरा UPDATE कमांड लॉक की उम्मीद करता है। एक दूसरे की प्रतीक्षा करें और पहले लेनदेन को पूरा करें।

 => SELECT pg_sleep(1); => COMMIT;

 COMMIT

अब दूसरा लेन-देन पूरा हो सकता है।

 | UPDATE 1

 | => COMMIT;

 | COMMIT

और सभी महत्वपूर्ण जानकारी पत्रिका में मिली:

 postgres$ tail -n 7 /var/log/postgresql/postgresql-11-main.log

 2019-08-07 15:26:30.827 MSK [5898] student@test LOG: process 5898 still waiting for ShareLock on transaction 529427 after 1000.186 ms 2019-08-07 15:26:30.827 MSK [5898] student@test DETAIL: Process holding the lock: 5862. Wait queue: 5898. 2019-08-07 15:26:30.827 MSK [5898] student@test CONTEXT: while updating tuple (0,4) in relation "accounts" 2019-08-07 15:26:30.827 MSK [5898] student@test STATEMENT: UPDATE accounts SET amount = amount + 100.00 WHERE acc_no = 1;

 2019-08-07 15:26:30.836 MSK [5898] student@test LOG: process 5898 acquired ShareLock on transaction 529427 after 1009.536 ms 2019-08-07 15:26:30.836 MSK [5898] student@test CONTEXT: while updating tuple (0,4) in relation "accounts" 2019-08-07 15:26:30.836 MSK [5898] student@test STATEMENT: UPDATE accounts SET amount = amount + 100.00 WHERE acc_no = 1;

जारी रखा जाए ।

PostgreSQL में ताले: 1. संबंध ताले