पोस्टग्रेस लॉक व्यवस्थापक अनलॉक करत आहे. ब्रूस मोमजियन

ब्रूस मोमजियन यांच्या 2020 च्या चर्चेचा उतारा "अनलॉकिंग द पोस्टग्रेस लॉक मॅनेजर".

(टीप: स्लाइड्सवरील सर्व SQL क्वेरी या लिंकवरून मिळू शकतात: http://momjian.us/main/writings/pgsql/locking.sql)

नमस्कार! येथे पुन्हा रशियामध्ये येणे खूप छान आहे. मला माफ करा की मी गेल्या वर्षी येऊ शकलो नाही, पण या वर्षी इव्हान आणि माझ्याकडे मोठ्या योजना आहेत. मला येथे अधिक वेळा येण्याची आशा आहे. मला रशियाला यायला आवडते. मी Tyumen, Tver ला भेट देईन. मला खूप आनंद झाला की मी या शहरांना भेट देऊ शकेन.

माझे नाव ब्रूस मोमजियान आहे. मी एंटरप्राइजडीबी येथे काम करतो आणि 23 वर्षांपासून पोस्टग्रेसमध्ये काम करत आहे. मी फिलाडेल्फिया, यूएसए येथे राहतो. मी वर्षातून ९० दिवस प्रवास करतो. आणि मी सुमारे 90 परिषदांमध्ये भाग घेतो. माझे संकेतस्थळ, ज्यात स्लाइड्स आहेत ज्या मी आता तुम्हाला दाखवणार आहे. म्हणून, कॉन्फरन्स नंतर आपण ते माझ्या वैयक्तिक वेबसाइटवरून डाउनलोड करू शकता. यात सुमारे 30 सादरीकरणे देखील आहेत. व्हिडिओ आणि मोठ्या संख्येने ब्लॉग नोंदी देखील आहेत, 500 पेक्षा जास्त. हे एक बऱ्यापैकी माहितीपूर्ण संसाधन आहे. आणि जर तुम्हाला या सामग्रीमध्ये स्वारस्य असेल तर मी तुम्हाला ते वापरण्यासाठी आमंत्रित करतो.

पोस्टग्रेसमध्ये काम सुरू करण्यापूर्वी मी एक शिक्षक, प्राध्यापक होतो. आणि मला खूप आनंद झाला आहे की मी तुम्हाला जे सांगणार आहे ते आता मी तुम्हाला सांगू शकेन. हे माझ्या सर्वात मनोरंजक सादरीकरणांपैकी एक आहे. आणि या सादरीकरणात 110 स्लाइड्स आहेत. आपण साध्या गोष्टींसह बोलण्यास सुरुवात करू, आणि शेवटी अहवाल अधिकाधिक गुंतागुंतीचा होत जाईल, आणि खूप गुंतागुंतीचा होईल.

हे एक ऐवजी अप्रिय संभाषण आहे. अवरोधित करणे हा सर्वात लोकप्रिय विषय नाही. हे कुठेतरी नाहीसे व्हावे अशी आमची इच्छा आहे. हे दंतवैद्याकडे जाण्यासारखे आहे.

1. डेटाबेसमध्ये काम करणार्‍या आणि एकाच वेळी अनेक प्रक्रिया चालू असलेल्या बर्‍याच लोकांसाठी लॉकिंग ही समस्या आहे. त्यांना ब्लॉक करणे आवश्यक आहे. म्हणजेच, आज मी तुम्हाला ब्लॉकिंगवर मूलभूत ज्ञान देईन.
2. व्यवहार आयडी. सादरीकरणाचा हा एक कंटाळवाणा भाग आहे, परंतु ते समजून घेणे आवश्यक आहे.
3. पुढे आपण ब्लॉकिंगच्या प्रकारांबद्दल बोलू. हा बऱ्यापैकी यांत्रिक भाग आहे.
4. आणि खाली आम्ही ब्लॉकिंगची काही उदाहरणे देऊ. आणि ते समजून घेणे खूप कठीण होईल.

चला ब्लॉक करण्याबद्दल बोलूया.

आमची शब्दावली खूपच गुंतागुंतीची आहे. हा उतारा कुठून आला हे तुमच्यापैकी किती जणांना माहीत आहे? दोन व्यक्ती. हे Colossal Cave Adventure नावाच्या खेळातील आहे. मला वाटतं 80 च्या दशकात हा मजकूर-आधारित संगणक गेम होता. तेथे तुम्हाला गुहेत, चक्रव्यूहात जावे लागले आणि मजकूर बदलला, परंतु सामग्री प्रत्येक वेळी अंदाजे सारखीच होती. तसा हा खेळ आठवतो.

आणि येथे आम्ही ओरॅकलकडून आमच्याकडे आलेल्या लॉकचे नाव पाहतो. आम्ही त्यांचा वापर करतो.

येथे आपण मला गोंधळात टाकणाऱ्या अटी पाहतो. उदाहरणार्थ, ECXLUSIVE अपडेट शेअर करा. पुढील RAW ECXLUSIVE शेअर करा. खरे सांगायचे तर ही नावे फारशी स्पष्ट नाहीत. आम्ही त्यांचा अधिक तपशीलवार विचार करण्याचा प्रयत्न करू. काहींमध्ये “शेअर” हा शब्द आहे, ज्याचा अर्थ वेगळे करणे. काहींमध्ये "अनन्य" हा शब्द असतो. काहींमध्ये हे दोन्ही शब्द असतात. हे कुलूप कसे कार्य करतात यापासून मला सुरुवात करायची आहे.

आणि "प्रवेश" हा शब्द देखील खूप महत्वाचा आहे. आणि "पंक्ती" हे शब्द एक स्ट्रिंग आहेत. म्हणजेच, प्रवेश वितरण, पंक्ती वितरण.

आणखी एक मुद्दा जो पोस्टग्रेसमध्ये समजून घेणे आवश्यक आहे, जो मी दुर्दैवाने माझ्या भाषणात कव्हर करू शकणार नाही, तो म्हणजे 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, इ.

लक्षात ठेवा की येथे दोन स्तंभ आहेत. डावीकडे व्हर्च्युअल ट्रान्झॅक्शन आयडी – २/१२ दिसतो. आणि उजवीकडे आमच्याकडे कायमस्वरूपी व्यवहार आयडी आहे. आणि हे मैदान रिकामे आहे. आणि हा व्यवहार डेटाबेसमध्ये बदल करत नाही. त्यामुळे मी त्याला कायमस्वरूपी व्यवहार आयडी देत ​​नाही.

मी विश्लेषण कमांड (ANALYZE) चालवताच, तीच क्वेरी मला कायमस्वरूपी व्यवहार आयडी देते. आमच्यासाठी हे कसे बदलले आहे ते पहा. माझ्याकडे हा आयडी आधी नव्हता, पण आता माझ्याकडे आहे.

तर इथे दुसरी विनंती आहे, दुसरा व्यवहार. आभासी व्यवहार क्रमांक 2/13 आहे. आणि जर मी पर्सिस्टंट ट्रान्झॅक्शन आयडी मागितला, तर मी क्वेरी रन केल्यावर मला तो मिळेल.

तर, आणखी एकदा. आमच्याकडे व्हर्च्युअल ट्रान्झॅक्शन आयडी आणि पर्सिस्टंट ट्रान्झॅक्शन आयडी आहे. पोस्टग्रेस वर्तन समजून घेण्यासाठी फक्त हा मुद्दा समजून घ्या.

आम्ही तिसऱ्या विभागाकडे जाऊ. येथे आपण पोस्टग्रेसमधील विविध प्रकारच्या लॉक्समधून सहजतेने फिरू. हे फार मनोरंजक नाही. शेवटचा भाग अधिक मनोरंजक असेल. परंतु आपण मूलभूत गोष्टींचा विचार केला पाहिजे, कारण अन्यथा पुढे काय होईल हे आपल्याला समजणार नाही.

आम्ही या विभागात जाऊ, आम्ही प्रत्येक प्रकारचे लॉक पाहू. आणि ते कसे स्थापित केले जातात, ते कसे कार्य करतात याची उदाहरणे मी तुम्हाला दाखवतो, मी तुम्हाला काही क्वेरी दाखवतो ज्याचा वापर पोस्टग्रेसमध्ये लॉकिंग कसे कार्य करते हे पाहण्यासाठी तुम्ही करू शकता.

क्वेरी तयार करण्यासाठी आणि पोस्टग्रेसमध्ये काय चालले आहे हे पाहण्यासाठी, आम्हाला सिस्टम व्ह्यूमध्ये क्वेरी जारी करणे आवश्यक आहे. या प्रकरणात, pg_lock लाल रंगात हायलाइट केले आहे. Pg_lock हे सिस्टम टेबल आहे जे पोस्टग्रेसमध्ये सध्या कोणते लॉक वापरात आहेत हे सांगते.

तथापि, तुम्हाला pg_lock स्वतःच दाखवणे माझ्यासाठी खूप अवघड आहे कारण ते खूपच गुंतागुंतीचे आहे. म्हणून मी एक दृश्य तयार केले जे pg_locks दर्शवते. आणि हे माझ्यासाठी काही कार्य करते जे मला अधिक चांगल्या प्रकारे समजून घेण्यास अनुमती देते. म्हणजेच, ते माझे कुलूप, माझे स्वतःचे सत्र इ. वगळते. हे फक्त मानक SQL आहे आणि ते तुम्हाला काय चालले आहे ते अधिक चांगल्या प्रकारे दाखवू देते.

दुसरी समस्या अशी आहे की हे दृश्य खूप विस्तृत आहे, म्हणून मला दुसरा एक तयार करावा लागेल - lockview2.

आणि ते मला टेबलमधील आणखी स्तंभ दाखवते. आणि दुसरा एक जो मला बाकीचे कॉलम दाखवतो. हे खूपच क्लिष्ट आहे, म्हणून मी ते शक्य तितक्या सोप्या पद्धतीने मांडण्याचा प्रयत्न केला.

म्हणून आम्ही लॉकडेमो नावाचे टेबल तयार केले. आणि आम्ही तिथे एक ओळ तयार केली. हे आमचे नमुना सारणी आहे. आणि आम्ही तुम्हाला फक्त लॉकची उदाहरणे दाखवण्यासाठी विभाग तयार करू.

तर, एक पंक्ती, एक स्तंभ. पहिल्या प्रकारच्या लॉकला ACCESS SHARE म्हणतात. हे सर्वात कमी प्रतिबंधात्मक ब्लॉकिंग आहे. याचा अर्थ असा आहे की ते इतर लॉकसह व्यावहारिकरित्या विरोधाभास करत नाही.

आणि जर आपल्याला लॉक स्पष्टपणे परिभाषित करायचे असेल तर आपण “लॉक टेबल” कमांड चालवू. आणि हे स्पष्टपणे अवरोधित होईल, म्हणजे ACCESS SHARE मोडमध्ये आम्ही लॉक टेबल लॉन्च करतो. आणि जर मी बॅकग्राउंडमध्ये PSQL चालवले, तर मी माझ्या पहिल्या सत्रापासून दुसरे सत्र अशा प्रकारे सुरू करतो. म्हणजे मी इथे काय करू? मी दुसर्‍या सत्रात जातो आणि त्याला "या विनंतीसाठी मला लॉक व्ह्यू दाखवा" असे सांगतो. आणि इथे माझ्याकडे या टेबलमध्ये AccessShareLock आहे. मी नेमकी हीच विनंती केली होती. आणि तो म्हणतो की ब्लॉक नियुक्त केला आहे. अगदी साधे.

पुढे, जर आपण दुसरा स्तंभ पाहिला तर तेथे काहीही नाही. ते रिकामे आहेत.

आणि जर मी "SELECT" कमांड चालवली, तर AccessShareLock ची विनंती करण्याचा हा अंतर्निहित (स्पष्ट) मार्ग आहे. म्हणून मी माझे टेबल सोडते आणि क्वेरी चालवते आणि क्वेरी अनेक पंक्ती परत करते. आणि एका ओळीत आपण AccessShareLock पाहतो. अशा प्रकारे, SELECT टेबलवर AccessShareLock ला कॉल करते. आणि हे अक्षरशः कोणत्याही गोष्टीशी विरोधाभास करत नाही कारण ते निम्न-स्तरीय लॉक आहे.

मी SELECT चालवल्यास आणि तीन भिन्न टेबल्स असल्यास? पूर्वी मी फक्त एक टेबल चालवत होतो, आता मी तीन चालवत आहे: pg_class, pg_namespace आणि pg_attribute.

आणि आता जेव्हा मी क्वेरी पाहतो तेव्हा मला तीन टेबलमध्ये 9 AccessShareLocks दिसतात. का? तीन सारण्या निळ्या रंगात हायलाइट केल्या आहेत: pg_attribute, pg_class, pg_namespace. परंतु आपण हे देखील पाहू शकता की या सारण्यांद्वारे परिभाषित केलेल्या सर्व निर्देशांकांमध्ये AccessShareLock देखील आहे.

आणि हे एक लॉक आहे जे व्यावहारिकपणे इतरांशी संघर्ष करत नाही. आणि हे सर्व फक्त आम्ही टेबल निवडत असताना आम्हाला ते रीसेट करण्यापासून प्रतिबंधित करतो. तो अर्थ प्राप्त होतो. म्हणजेच, जर आपण टेबल निवडले तर ते त्या क्षणी अदृश्य होते, तर हे चुकीचे आहे, म्हणून AccessShare हे निम्न स्तरावरील लॉक आहे जे आम्हाला सांगते "मी काम करत असताना हे टेबल टाकू नका". मूलत:, ती फक्त एवढेच करते.

ROW SHARE - हे लॉक थोडे वेगळे आहे.

एक उदाहरण घेऊ. प्रत्येक पंक्ती स्वतंत्रपणे लॉक करण्यासाठी ROW SHARE पद्धत निवडा. अशा प्रकारे आम्ही त्यांना पाहत असताना कोणीही त्यांना हटवू किंवा बदलू शकत नाही.

तर SHARE LOCK काय करते? आम्ही पाहतो की SELECT साठी व्यवहार आयडी 681 आहे. आणि हे मनोरंजक आहे. येथे काय घडले? आपण प्रथमच संख्या पाहतो तेव्हा “लॉक” फील्डमध्ये आहे. आम्ही ट्रान्झॅक्शन आयडी घेतो आणि तो अनन्य मोडमध्ये ब्लॉक करत आहे. ते इतकेच करते की माझ्याकडे एक पंक्ती आहे जी तांत्रिकदृष्ट्या टेबलमध्ये कुठेतरी लॉक केलेली आहे. पण नेमके कुठे ते सांगत नाही. आम्ही थोड्या वेळाने हे अधिक तपशीलवार पाहू.

येथे आम्ही म्हणतो की कुलूप आमच्याद्वारे वापरले जाते.

तर, एक अनन्य लॉक स्पष्टपणे सांगते की ते अनन्य आहे. आणि जर तुम्ही या सारणीतील एक पंक्ती हटवली तर हेच होईल, जसे तुम्ही पाहू शकता.

SHARE EXCLUSIVE हा मोठा लॉक आहे.

ही (ANALYZE) विश्लेषक कमांड वापरली जाईल.

शेअर लॉक - तुम्ही शेअर मोडमध्ये स्पष्टपणे लॉक करू शकता.

आपण एक अद्वितीय अनुक्रमणिका देखील तयार करू शकता. आणि तिथे तुम्ही SHARE LOCK पाहू शकता, जो त्यांचा एक भाग आहे. आणि ते टेबल लॉक करते आणि त्यावर SHARE LOCK ठेवते.

डीफॉल्टनुसार, टेबलवर SHARE LOCK म्हणजे इतर लोक टेबल वाचू शकतात, परंतु कोणीही त्यात बदल करू शकत नाही. आणि जेव्हा तुम्ही एक अद्वितीय अनुक्रमणिका तयार करता तेव्हा हेच घडते.

जर मी एक अनन्य समवर्ती अनुक्रमणिका तयार केली, तर माझ्याकडे वेगळ्या प्रकारचे लॉकिंग असेल कारण, जसे तुम्हाला आठवते, समवर्ती निर्देशांक वापरल्याने लॉकिंगची आवश्यकता कमी होते. आणि जर मी एक सामान्य लॉक, एक सामान्य अनुक्रमणिका वापरत असेल, तर मी अशा प्रकारे टेबल इंडेक्स तयार होत असताना त्यावर लिहिण्यास प्रतिबंध करेन. मी समवर्ती निर्देशांक वापरत असल्यास, मला वेगळ्या प्रकारचे लॉकिंग वापरावे लागेल.

ROW EXCLUSIVE सामायिक करा - पुन्हा ते स्पष्टपणे (स्पष्टपणे) सेट केले जाऊ शकते.

किंवा आम्ही एक नियम तयार करू शकतो, म्हणजे, एक विशिष्ट केस घ्या ज्यामध्ये तो वापरला जाईल.

अनन्य लॉकिंगचा अर्थ असा आहे की इतर कोणीही टेबल बदलू शकत नाही.

येथे आपण विविध प्रकारचे कुलूप पाहतो.

EXCESS EXCLUSIVE, उदाहरणार्थ, ब्लॉकिंग कमांड आहे. उदाहरणार्थ, आपण केले तर CLUSTER table, तर याचा अर्थ असा होईल की तेथे कोणीही लिहू शकणार नाही. आणि हे केवळ टेबलच नाही तर इंडेक्स देखील लॉक करते.

हे EXCESS EXCLUSIVE ब्लॉकिंगचे दुसरे पान आहे, जिथे ते टेबलमध्ये नक्की काय ब्लॉक करते ते आपण पाहतो. हे वैयक्तिक सारणी पंक्ती लॉक करते, जे खूप मनोरंजक आहे.

एवढीच प्राथमिक माहिती मला द्यायची होती. आम्ही लॉक बद्दल बोललो, ट्रान्झॅक्शन आयडी बद्दल बोललो, आम्ही व्हर्च्युअल ट्रान्झॅक्शन आयडी बद्दल बोललो, कायम ट्रान्झॅक्शन आयडी बद्दल बोललो.

आणि आता आपण काही ब्लॉकिंग उदाहरणे पाहू. हा सर्वात मनोरंजक भाग आहे. आम्ही अतिशय मनोरंजक प्रकरणे पाहू. आणि या सादरीकरणातील माझे ध्येय आहे की पोस्टग्रेस जेव्हा काही गोष्टी अवरोधित करण्याचा प्रयत्न करतो तेव्हा प्रत्यक्षात काय करत आहे याची आपल्याला अधिक चांगली समज देणे आहे. मला वाटते की तो भाग रोखण्यात खूप चांगला आहे.

चला काही विशिष्ट उदाहरणे पाहू.

आम्ही टेबल आणि टेबलमधील एका पंक्तीसह प्रारंभ करू. जेव्हा मी काहीतरी घालतो तेव्हा माझ्याकडे टेबलवर ExclusiveLock, Transaction ID आणि ExclusiveLock प्रदर्शित होतो.

मी आणखी दोन पंक्ती टाकल्यास काय होईल? आणि आता आमच्या टेबलमध्ये तीन पंक्ती आहेत. आणि मी एक पंक्ती घातली आणि हे आउटपुट म्हणून मिळाले. आणि जर मी आणखी दोन पंक्ती टाकल्या तर त्यात काय विचित्र आहे? येथे एक विचित्र गोष्ट आहे कारण मी या टेबलमध्ये तीन ओळी जोडल्या आहेत, परंतु लॉक टेबलमध्ये माझ्याकडे अजूनही दोन पंक्ती आहेत. आणि हे मूलत: पोस्टग्रेसचे मूलभूत वर्तन आहे.

बर्‍याच लोकांना वाटते की जर तुम्ही डेटाबेसमध्ये 100 पंक्ती लॉक केल्या तर तुम्हाला 100 लॉक नोंदी तयार कराव्या लागतील. मी एकाच वेळी 1 पंक्ती अवरोधित केल्यास, मला अशा 000 प्रश्नांची आवश्यकता असेल. आणि जर मला ब्लॉक करण्यासाठी दशलक्ष किंवा एक अब्ज हवे असतील. पण जर आपण असे केले तर ते फारसे चालणार नाही. जर तुम्ही अशी प्रणाली वापरली असेल जी प्रत्येक स्वतंत्र पंक्तीसाठी अवरोधित नोंदी तयार करते, तर तुम्ही पाहू शकता की हे गुंतागुंतीचे आहे. कारण तुम्हाला ताबडतोब एक लॉक टेबल परिभाषित करणे आवश्यक आहे जे ओव्हरफ्लो होऊ शकते, परंतु पोस्टग्रेस तसे करत नाही.

आणि या स्‍लाइडबद्दल खरोखर महत्‍त्‍वाचे आहे की ते स्‍पष्‍टपणे दाखवते की MVCC आत चालणारी दुसरी प्रणाली आहे जी वैयक्तिक पंक्ती लॉक करते. म्हणून जेव्हा तुम्ही अब्जावधी पंक्ती लॉक करता तेव्हा पोस्टग्रेस एक अब्ज स्वतंत्र लॉकिंग कमांड तयार करत नाही. आणि याचा उत्पादकतेवर खूप चांगला परिणाम होतो.

अपडेटबद्दल काय? मी आता पंक्ती अद्यतनित करत आहे, आणि तुम्ही पाहू शकता की तिने एकाच वेळी दोन भिन्न ऑपरेशन केले आहेत. त्याने त्याच वेळी टेबल लॉक केले, परंतु निर्देशांक देखील लॉक केला. आणि त्याला इंडेक्स लॉक करणे आवश्यक होते कारण या टेबलवर अद्वितीय मर्यादा आहेत. आणि आम्ही हे सुनिश्चित करू इच्छितो की कोणीही ते बदलत नाही, म्हणून आम्ही ते अवरोधित करतो.

मला दोन पंक्ती अपडेट करायच्या असतील तर काय होईल? आणि तो तसाच वागतो हे आपण पाहतो. आम्ही दुप्पट अद्यतने करतो, परंतु लॉक लाईन्सची समान संख्या.

पोस्टग्रेस हे कसे करते याबद्दल तुम्हाला आश्चर्य वाटत असल्यास, पोस्टग्रेस या बदललेल्या ओळींना आंतरिकरित्या कसे चिन्हांकित करते हे जाणून घेण्यासाठी तुम्हाला MVCC वरील माझे बोलणे ऐकावे लागेल. आणि पोस्टग्रेसकडे एक मार्ग आहे ज्यामध्ये ते हे करते, परंतु ते टेबल लॉकिंग स्तरावर करत नाही, ते कमी आणि अधिक कार्यक्षम स्तरावर करते.

मला काहीतरी हटवायचे असेल तर? मी हटवल्यास, उदाहरणार्थ, एक पंक्ती आणि माझ्याकडे अजूनही माझे दोन ब्लॉकिंग इनपुट आहेत, आणि जरी मला ते सर्व हटवायचे असतील, तरीही ते आहेत.

आणि, उदाहरणार्थ, मला 1 ओळी घालायच्या आहेत, आणि नंतर 000 ओळी हटवायच्या किंवा जोडायच्या आहेत, नंतर त्या वैयक्तिक ओळी ज्या मी जोडतो किंवा बदलतो, त्या येथे रेकॉर्ड केल्या जात नाहीत. ते मालिकेतच खालच्या पातळीवर लिहिलेले आहेत. आणि MVCC च्या भाषणादरम्यान मी याबद्दल तपशीलवार बोललो. परंतु तुम्ही टेबल स्तरावर लॉक करत आहात आणि येथे वैयक्तिक पंक्ती कशा रेकॉर्ड केल्या जात आहेत हे तुम्ही पाहत नाही आहात याची खात्री करण्यासाठी तुम्ही लॉकचे विश्लेषण करत असताना हे खूप महत्वाचे आहे.

स्पष्ट ब्लॉकिंगबद्दल काय?

मी रिफ्रेश क्लिक केल्यास, माझ्याकडे दोन पंक्ती लॉक आहेत. आणि जर मी ते सर्व निवडले आणि "सर्वत्र अद्यतनित करा" वर क्लिक केले तर माझ्याकडे अजूनही दोन ब्लॉकिंग रेकॉर्ड आहेत.

आम्ही प्रत्येक वैयक्तिक पंक्तीसाठी स्वतंत्र रेकॉर्ड तयार करत नाही. कारण नंतर उत्पादकता कमी होते, त्यात बरेच काही असू शकते. आणि आपण स्वतःला एक अप्रिय परिस्थितीत सापडू शकतो.

आणि तीच गोष्ट, जर आपण सामायिक केले तर आपण ते सर्व 30 वेळा करू शकतो.

आम्ही आमचे टेबल पुनर्संचयित करतो, सर्वकाही हटवतो, नंतर पुन्हा एक पंक्ती घाला.

आणखी एक वर्तन जे तुम्ही Postgres मध्ये पाहता ते अतिशय सुप्रसिद्ध आणि इच्छित वर्तन आहे ते म्हणजे तुम्ही अपडेट किंवा सिलेक्ट करू शकता. आणि आपण हे एकाच वेळी करू शकता. आणि निवडा अपडेट ब्लॉक करत नाही आणि तीच गोष्ट उलट दिशेने. आम्ही वाचकाला सांगतो की लेखकाला ब्लॉक करू नका आणि लेखकाने वाचकाला ब्लॉक केले नाही.

मी तुम्हाला याचे एक उदाहरण दाखवतो. मी आता निवड करेन. त्यानंतर आम्ही INSERT करू. आणि मग तुम्ही पाहू शकता - 694. तुम्ही हा इन्सर्शन केलेल्या व्यवहाराचा आयडी पाहू शकता. आणि ते कसे कार्य करते.

आणि मी आता माझा बॅकएंड आयडी पाहिला तर तो आता ६९५ आहे.

आणि मी माझ्या टेबलमध्ये 695 दिसत आहे.

आणि जर मी इथे असे अपडेट केले तर मला एक वेगळे प्रकरण मिळेल. या प्रकरणात, 695 एक अनन्य लॉक आहे, आणि अपडेटमध्ये समान वर्तन आहे, परंतु त्यांच्यामध्ये कोणताही विरोध नाही, जो अगदी असामान्य आहे.

आणि तुम्ही पाहू शकता की शीर्षस्थानी ते ShareLock आहे आणि तळाशी ते ExclusiveLock आहे. आणि दोन्ही व्यवहार पार पडले.

आणि हे कसे घडते हे समजून घेण्यासाठी तुम्हाला MVCC मधील माझे बोलणे ऐकावे लागेल. परंतु हे एक उदाहरण आहे की तुम्ही ते एकाच वेळी करू शकता, म्हणजे एकाच वेळी SELECT आणि अपडेट करा.

चला रीसेट करू आणि आणखी एक ऑपरेशन करू.

तुम्ही एकाच पंक्तीवर एकाच वेळी दोन अपडेट्स चालवण्याचा प्रयत्न केल्यास, ते ब्लॉक केले जाईल. आणि लक्षात ठेवा, मी म्हटलं की वाचक लेखकाला ब्लॉक करत नाही आणि लेखक वाचकाला ब्लॉक करत नाही, पण एक लेखक दुसऱ्या लेखकाला ब्लॉक करतो. म्हणजेच, एकाच वेळी दोन लोक एकाच पंक्तीला अपडेट करू शकत नाहीत. त्यापैकी एक पूर्ण होईपर्यंत आपल्याला प्रतीक्षा करावी लागेल.

आणि हे स्पष्ट करण्यासाठी, मी लॉकडेमो टेबल बघेन. आणि आम्ही एक पंक्ती पाहू. प्रति व्यवहार ६९८.

आम्ही हे 2 वर अपडेट केले आहे. 699 हे पहिले अपडेट आहे. आणि तो यशस्वी झाला किंवा तो प्रलंबित व्यवहारात आहे आणि आमच्या पुष्टी किंवा रद्द होण्याची वाट पाहत आहे.

पण काहीतरी वेगळे पहा - 2/51 हा आमचा पहिला व्यवहार आहे, आमचे पहिले सत्र आहे. 3/112 ही वरून आलेली दुसरी विनंती आहे ज्याने ते मूल्य 3 वर बदलले आहे. आणि जर तुमच्या लक्षात आले, तर शीर्षाने स्वतःला लॉक केले, जे 699 आहे. परंतु 3/112 ने लॉक मंजूर केले नाही. लॉक_मोड कॉलम ते कशाची वाट पाहत आहे ते सांगते. ते 699 ची अपेक्षा करते. आणि जर तुम्ही 699 कुठे आहे ते पाहिले तर ते जास्त आहे. आणि पहिल्या सत्रात काय केले? तिने स्वतःच्या ट्रान्झॅक्शन आयडीवर एक खास लॉक तयार केला. पोस्टग्रेस हे असेच करतात. तो स्वतःचा व्यवहार आयडी ब्लॉक करतो. आणि जर तुम्हाला कोणीतरी पुष्टी किंवा रद्द करण्याची प्रतीक्षा करायची असेल, तर तुम्हाला प्रलंबित व्यवहार होईपर्यंत प्रतीक्षा करावी लागेल. आणि म्हणूनच आपण एक विचित्र ओळ पाहू शकतो.

पुन्हा बघूया. डावीकडे आमचा प्रोसेसिंग आयडी दिसतो. दुस-या रकान्यात आपल्याला आपला आभासी व्यवहार आयडी दिसतो आणि तिसर्‍या स्तंभात आपल्याला lock_type दिसतो. याचा अर्थ काय? मूलत: ते काय म्हणते की ते व्यवहार आयडी ब्लॉक करत आहे. पण लक्षात घ्या की तळाशी असलेल्या सर्व पंक्ती रिलेशन सांगतात. आणि म्हणून आपल्याकडे टेबलवर दोन प्रकारचे लॉक आहेत. रिलेशन लॉक आहे. आणि नंतर ट्रान्झॅक्शनिड ब्लॉकिंग आहे, जिथे तुम्ही स्वतः ब्लॉक करता, जे पहिल्या ओळीत किंवा अगदी तळाशी होते, जिथे ट्रान्झॅक्शनिड आहे, जिथे आम्ही त्याचे ऑपरेशन पूर्ण करण्यासाठी 699 ची प्रतीक्षा करतो.

इथे काय होते ते मी बघेन. आणि इथे दोन गोष्टी एकाच वेळी घडतात. तुम्ही पहिल्या रांगेत एक व्यवहार आयडी लॉक पहात आहात जो स्वतःच लॉक होतो. आणि लोकांना वाट दाखवण्यासाठी ती स्वतःला ब्लॉक करते.

आपण 6 व्या ओळीकडे पाहिल्यास, ती पहिल्यासारखीच नोंद आहे. आणि म्हणून व्यवहार 699 अवरोधित केला आहे. 700 हे सेल्फ लॉकिंग देखील आहे. आणि मग खालच्या ओळीत तुम्हाला दिसेल की आम्ही 699 चे ऑपरेशन पूर्ण होण्याची वाट पाहत आहोत.

आणि lock_type मध्ये, तुम्हाला संख्या दिसेल.

तुम्ही पाहू शकता की ते 0/10 आहे. आणि हा पृष्ठ क्रमांक आहे आणि या विशिष्ट पंक्तीचा ऑफसेट देखील आहे.

आणि जेव्हा आम्ही अपडेट करतो तेव्हा ते 0/11 होते हे तुम्हाला दिसेल.

परंतु प्रत्यक्षात ते 0/10 आहे, कारण या ऑपरेशनची प्रतीक्षा आहे. आम्हाला हे पाहण्याची संधी आहे की ही ती मालिका आहे ज्याची पुष्टी करण्यासाठी मी वाट पाहत आहे.

एकदा आम्ही याची पुष्टी केली आणि कमिट दाबले आणि अपडेट पूर्ण झाल्यावर, हेच आम्हाला पुन्हा मिळते. व्यवहार 700 हा एकमेव लॉक आहे, तो इतर कोणाचीही वाट पाहत नाही कारण तो वचनबद्ध होता. तो फक्त व्यवहार पूर्ण होण्याची वाट पाहतो. एकदा 699 धावा झाल्या की, आता आम्ही कशाचीही वाट पाहत नाही. आणि आता ट्रान्झॅक्शन 700 म्हणते की सर्व काही ठीक आहे, सर्व परवानगी असलेल्या टेबल्सवर त्याला आवश्यक असलेले सर्व लॉक आहेत.

आणि ही संपूर्ण गोष्ट आणखी क्लिष्ट करण्यासाठी, आम्ही आणखी एक दृश्य तयार करतो, जे या वेळी आम्हाला पदानुक्रम प्रदान करेल. ही विनंती तुम्ही समजून घ्यावी अशी माझी अपेक्षा नाही. परंतु हे आपल्याला काय चालले आहे याचे स्पष्ट दृश्य देईल.

हे एक पुनरावर्ती दृश्य आहे ज्यामध्ये आणखी एक विभाग आहे. आणि मग ते सर्वकाही पुन्हा एकत्र आणते. चला याचा वापर करूया.

जर आपण एकाच वेळी तीन अपडेट केले आणि पंक्ती आता तीन झाली आहे असे म्हटले तर काय होईल. आणि आम्ही 3 ते 4 बदलू.

आणि येथे आपण 4. आणि व्यवहार आयडी 702 पाहतो.

आणि मग मी 4 ते 5 बदलेन. आणि 5 ते 6, आणि 6 ते 7. आणि मी अनेक लोकांची लाइन तयार करेन जे हा एक व्यवहार संपण्याची वाट पाहत असतील.

आणि सर्व काही स्पष्ट होते. पहिली पंक्ती कोणती? हे 702 आहे. हा व्यवहार आयडी आहे ज्याने मूळत: हे मूल्य सेट केले आहे. माझ्या ग्रँटेड कॉलममध्ये काय लिहिले आहे? मला मार्क्स आहेत f. हे माझे अपडेट्स आहेत जे (5, 6, 7) मंजूर केले जाऊ शकत नाहीत कारण आम्ही व्यवहार ID 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 व्यवहार पूर्ण करण्यासाठी 710 ची वाट पाहत आहे.

आणि हे देखील सांगते की कोणत्या पंक्तीवर डेडलॉक होतात. आणि इथेच ते विचित्र होऊ लागते.

आता आम्ही 80 ते 80 अपडेट करत आहोत.

आणि येथूनच गतिरोध सुरू होतो. 710 711 च्या प्रतिसादाची वाट पाहत आहे आणि 711 710 ची वाट पाहत आहे. आणि हे चांगले संपणार नाही. आणि यातून बाहेर पडण्याचा कोणताही मार्ग नाही. आणि ते एकमेकांकडून प्रतिसादाची अपेक्षा करतील.

आणि तो फक्त सर्वकाही विलंब सुरू होईल. आणि आम्हाला ते नको आहे.

आणि जेव्हा हे घडते तेव्हा पोस्टग्रेसकडे लक्षात घेण्याचे मार्ग आहेत. आणि जेव्हा हे घडते, तेव्हा तुम्हाला ही त्रुटी येते. आणि यावरून हे स्पष्ट होते की अशी आणि अशी प्रक्रिया दुसर्‍या प्रक्रियेतून SHARE LOCK ची वाट पाहत आहे, म्हणजेच 711 प्रक्रियेद्वारे अवरोधित आहे. आणि ती प्रक्रिया अशा आणि अशा ट्रान्झॅक्शन आयडीवर SHARE LOCK देण्याची वाट पाहत होती आणि अशा आणि अशा प्रक्रियेद्वारे ब्लॉक केली गेली होती. त्यामुळे येथे कोंडीची स्थिती आहे.

त्रि-मार्गी गतिरोध आहेत का? ते शक्य आहे का? होय.

आम्ही हे आकडे टेबलमध्ये टाकतो. आम्ही 40 ते 40 बदलतो, आम्ही ब्लॉकिंग करतो.

आम्ही 60 ते 61, 80 ते 81 बदलतो.

आणि मग आम्ही 80 बदलतो आणि मग बूम!

आणि 714 आता 715 ची वाट पाहत आहे. 716वा 715 ची वाट पाहत आहे. आणि त्याबद्दल काहीही करता येत नाही.

येथे आता दोन लोक नाहीत, येथे आधीच तीन लोक आहेत. मला तुमच्याकडून काहीतरी हवे आहे, याला तिसऱ्या व्यक्तीकडून काहीतरी हवे आहे आणि तिसऱ्या व्यक्तीला माझ्याकडून काहीतरी हवे आहे. आणि आपण तीन-मार्गी वाट पाहत असतो कारण आपण सर्वजण दुसर्‍या व्यक्तीला काय करावे लागेल याची वाट पाहत आहोत.

आणि पोस्टग्रेसला माहित आहे की हे कोणत्या पंक्तीवर होते. आणि म्हणून ते तुम्हाला खालील संदेश देईल, जे दर्शवेल की तुम्हाला एक समस्या आहे जिथे तीन इनपुट एकमेकांना ब्लॉक करत आहेत. आणि येथे कोणतेही निर्बंध नाहीत. 20 नोंदी एकमेकांना अवरोधित करतात अशी ही परिस्थिती असू शकते.

पुढील समस्या अनुक्रमे करण्यायोग्य आहे.

विशेष क्रमवारी लावता येण्याजोगे लॉक असल्यास.

आणि आपण ७१९ वर परत येऊ. त्याचे आउटपुट अगदी सामान्य आहे.

आणि तुम्ही सीरिअलायझेशन वरून व्यवहार करण्यासाठी क्लिक करू शकता.

आणि तुम्हाला हे समजले आहे की तुमच्याकडे आता वेगळ्या प्रकारचा SA लॉक आहे - याचा अर्थ अनुक्रमे करण्यायोग्य आहे.

आणि म्हणून आमच्याकडे SARieadLock नावाचा एक नवीन प्रकारचा लॉक आहे, जो एक सिरीयल लॉक आहे आणि तुम्हाला मालिकांमध्ये प्रवेश करण्याची परवानगी देतो.

आणि आपण अद्वितीय अनुक्रमणिका देखील घालू शकता.

या सारणीमध्ये आमच्याकडे अद्वितीय अनुक्रमणिका आहेत.

म्हणून जर मी येथे क्रमांक 2 टाकला, तर माझ्याकडे 2 आहे. पण अगदी वर, मी आणखी 2 टाकतो. आणि तुम्ही पाहू शकता की 721 ला एक विशेष लॉक आहे. परंतु आता 722 त्याचे ऑपरेशन पूर्ण करण्यासाठी 721 ची वाट पाहत आहे कारण 2 चे काय होईल हे कळेपर्यंत ते 721 घालू शकत नाही.

आणि जर आपण उपव्यवहार करतो.

येथे आमच्याकडे 723 आहेत.

आणि जर आपण पॉइंट सेव्ह करून तो अपडेट केला तर आपल्याला नवीन ट्रान्झॅक्शन आयडी मिळेल. वर्तनाचा हा आणखी एक नमुना आहे ज्याची तुम्हाला जाणीव असणे आवश्यक आहे. जर आपण हे परत केले तर व्यवहार आयडी निघून जाईल. 724 निघत आहे. पण आता आमच्याकडे ७२५ आहेत.

मग मी इथे काय करण्याचा प्रयत्न करत आहे? मी तुम्हाला असामान्य लॉकची उदाहरणे दाखविण्याचा प्रयत्न करत आहे जे तुम्हाला सापडतील: ते क्रमिक लॉक किंवा सेव्हपॉइंट असोत, हे लॉकचे विविध प्रकार आहेत जे लॉक टेबलमध्ये दिसतील.

हे स्पष्ट (स्पष्ट) लॉकची निर्मिती आहे, ज्यात pg_advisory_lock आहे.

आणि तुम्हाला दिसेल की ब्लॉकिंग प्रकार सल्लागार म्हणून सूचीबद्ध आहे. आणि येथे लाल रंगात "सल्लागार" असे म्हटले आहे. आणि तुम्ही pg_advisory_unlock सह अशा प्रकारे एकाच वेळी ब्लॉक करू शकता.

आणि शेवटी, मी तुम्हाला आणखी एक गोष्ट दाखवू इच्छितो. मी दुसरे दृश्य तयार करेन. पण मी pg_stat_activity टेबलसह pg_locks टेबलमध्ये सामील होईन. आणि मला हे का करायचे आहे? कारण यामुळे मला सध्याची सर्व सत्रे बघता येतील आणि ते नेमके कोणत्या प्रकारच्या लॉकची वाट पाहत आहेत ते पाहू शकतील. आणि जेव्हा आपण लॉक टेबल आणि क्वेरी टेबल एकत्र ठेवतो तेव्हा हे खूप मनोरंजक आहे.

आणि इथे आपण pg_stat_view तयार करतो.

आणि आम्ही पंक्ती एक एक करून अद्यतनित करतो. आणि इथे आपण ७२४ पाहतो. आणि मग आपण आपली पंक्ती तीन वर अपडेट करू. आणि आता तुम्हाला इथे काय दिसते? या विनंत्या आहेत, म्हणजे तुम्हाला डाव्या स्तंभात सूचीबद्ध केलेल्या विनंत्यांची संपूर्ण यादी दिसते. आणि मग उजव्या बाजूला तुम्ही अडथळे आणि ते काय तयार करतात ते पाहू शकता. आणि हे तुमच्यासाठी अधिक स्पष्ट होऊ शकते जेणेकरून तुम्हाला प्रत्येक सत्रात परत जावे लागणार नाही आणि तुम्हाला त्यात सामील होण्याची आवश्यकता आहे की नाही ते पहा. ते आमच्यासाठी करतात.

आणखी एक वैशिष्ट्य जे खूप उपयुक्त आहे pg_blocking_pids. तुम्ही कदाचित तिच्याबद्दल कधीच ऐकले नसेल. ती काय करत आहे? हे आम्हाला सांगण्याची परवानगी देते की या सत्रासाठी 11740 कोणत्या विशिष्ट प्रक्रिया आयडीची वाट पाहत आहे. आणि तुम्ही पाहू शकता की 11740 724 ची वाट पाहत आहे. आणि 724 सर्वात वर आहे. आणि 11306 हा तुमचा प्रोसेस आयडी आहे. मूलत:, हे कार्य तुमच्या लॉक टेबलमधून जाते. आणि मला माहित आहे की हे थोडे क्लिष्ट आहे, परंतु आपण ते समजून घेण्यात व्यवस्थापित करता. मूलत: हे फंक्शन या लॉक टेबलमधून जाते आणि हे शोधण्याचा प्रयत्न करते की या प्रोसेस आयडीला ते थांबलेले लॉक कुठे दिले जातात. आणि लॉकची वाट पाहत असलेल्या प्रक्रियेमध्ये कोणता प्रोसेस आयडी आहे हे शोधण्याचा प्रयत्न केला जातो. त्यामुळे तुम्ही हे फंक्शन चालवू शकता pg_blocking_pids.

आणि हे खूप उपयुक्त असू शकते. आम्ही हे फक्त आवृत्ती 9.6 मध्ये जोडले आहे, त्यामुळे हे वैशिष्ट्य फक्त 5 वर्षे जुने आहे, परंतु ते अतिशय उपयुक्त आहे. आणि तेच दुसऱ्या विनंतीला लागू होते. हे आपल्याला नक्की काय पाहण्याची गरज आहे ते दर्शवते.

हेच मला तुमच्याशी बोलायचे होते. आणि माझ्या अपेक्षेप्रमाणे, आम्ही आमचा सर्व वेळ वापरला कारण तेथे बर्‍याच स्लाइड्स होत्या. आणि स्लाइड्स डाउनलोड करण्यासाठी उपलब्ध आहेत. येथे आल्याबद्दल मी तुमचे आभार मानू इच्छितो. मला खात्री आहे की तुम्ही उर्वरित कॉन्फरन्सचा आनंद घ्याल, खूप खूप धन्यवाद!

प्रश्नः

उदाहरणार्थ, मी पंक्ती अपडेट करण्याचा प्रयत्न करत असल्यास आणि दुसरे सत्र संपूर्ण टेबल हटवण्याचा प्रयत्न करत असल्यास. माझ्या समजल्याप्रमाणे, इंटेंट लॉक सारखे काहीतरी असावे. पोस्टग्रेसमध्ये असे काही आहे का?

चला अगदी सुरुवातीस परत जाऊया. तुम्हाला आठवत असेल की जेव्हा तुम्ही काहीही करता, उदाहरणार्थ तुम्ही SELECT करता तेव्हा, आम्ही AccessShareLock जारी करतो. आणि हे टेबल टाकण्यापासून प्रतिबंधित करते. म्हणून, उदाहरणार्थ, जर तुम्हाला टेबलमधील पंक्ती अपडेट करायची असेल किंवा एखादी पंक्ती हटवायची असेल, तर कोणीतरी संपूर्ण टेबल एकाच वेळी हटवू शकत नाही कारण तुम्ही संपूर्ण टेबलवर आणि पंक्तीवर हे AccessShareLock धरून ठेवले आहे. आणि तुम्ही पूर्ण केल्यावर ते ते हटवू शकतात. परंतु तुम्ही तेथे थेट काहीतरी बदलत असताना, ते ते करू शकणार नाहीत.

चला ते पुन्हा करूया. हटवण्याच्या उदाहरणाकडे वळू. आणि संपूर्ण टेबलच्या वरच्या पंक्तीवर एक अनन्य लॉक कसे आहे ते तुम्ही पहा.

हे लॉक अनन्य दिसेल, बरोबर?

होय, असे दिसते. तुम्ही कशाबद्दल बोलत आहात ते मला समजले आहे. तुम्ही म्हणत आहात की मी SELECT केले तर माझ्याकडे ShareExclusive आहे आणि मग मी Row Exclusive बनवतो, त्यामुळे समस्या निर्माण होते का? परंतु आश्चर्याची गोष्ट म्हणजे यामुळे कोणतीही समस्या उद्भवत नाही. हे लॉकची डिग्री वाढवण्यासारखे दिसते, परंतु मूलत: माझ्याकडे एक लॉक आहे जो हटवण्यापासून प्रतिबंधित करतो. आणि आता, जेव्हा मी हे लॉक अधिक शक्तिशाली बनवतो, तरीही ते हटवण्यापासून प्रतिबंधित करते. त्यामुळे मी वर जात आहे असे नाही. म्हणजेच, जेव्हा ते अगदी खालच्या पातळीवर होते तेव्हा ते होण्यापासून प्रतिबंधित करते, म्हणून जेव्हा मी त्याचा स्तर वाढवतो तेव्हा ते टेबल हटवण्यापासून प्रतिबंधित करते.

तुम्ही कशाबद्दल बोलत आहात ते मला समजले आहे. येथे कोणतेही लॉक एस्केलेशन केस नाही, जिथे तुम्ही एक मजबूत ओळखण्यासाठी एक लॉक सोडण्याचा प्रयत्न करत आहात. येथे ते संपूर्ण बोर्डवर हे प्रतिबंध वाढवते, त्यामुळे कोणत्याही संघर्षास कारणीभूत नाही. पण चांगला प्रश्न आहे. हे विचारल्याबद्दल खूप खूप धन्यवाद!

जेव्हा आमच्याकडे अनेक सत्रे असतात, मोठ्या संख्येने वापरकर्ते असतात तेव्हा डेडलॉक परिस्थिती टाळण्यासाठी आम्हाला काय करण्याची आवश्यकता आहे?

पोस्टग्रेस आपोआप डेडलॉक परिस्थिती लक्षात घेते. आणि ते सत्रांपैकी एक स्वयंचलितपणे हटवेल. डेड ब्लॉकिंग टाळण्याचा एकमेव मार्ग म्हणजे त्याच क्रमाने लोकांना ब्लॉक करणे. त्यामुळे जेव्हा तुम्ही तुमचा अर्ज पाहता, तेव्हा अनेकदा अडथळे येण्याचे कारण... चला कल्पना करूया की मला दोन वेगवेगळ्या गोष्टी ब्लॉक करायच्या आहेत. एक ऍप्लिकेशन टेबल 1 लॉक करतो, आणि दुसरा ऍप्लिकेशन 2 लॉक करतो आणि नंतर टेबल 1. आणि डेडलॉक टाळण्याचा सर्वात सोपा मार्ग म्हणजे तुमचा ऍप्लिकेशन पाहणे आणि लॉकिंग सर्व ऍप्लिकेशन्समध्ये समान क्रमाने होत असल्याचे सुनिश्चित करण्याचा प्रयत्न करणे. आणि हे सहसा 80% समस्या दूर करते, कारण सर्व प्रकारचे लोक हे अनुप्रयोग लिहितात. आणि जर तुम्ही त्यांना त्याच क्रमाने अवरोधित केले तर तुम्हाला डेडलॉक परिस्थितीचा सामना करावा लागणार नाही.

आपल्या कामगिरीबद्दल खूप खूप धन्यवाद! तुम्ही व्हॅक्यूम फुल बद्दल बोललात आणि, जर मला बरोबर समजले असेल तर, व्हॅक्यूम फुल वेगळ्या स्टोरेजमधील रेकॉर्डचा क्रम विकृत करते, त्यामुळे ते सध्याचे रेकॉर्ड अपरिवर्तित ठेवतात. व्हॅक्यूम फुल अनन्य लॉक ऍक्सेस का घेते आणि ते लेखन ऑपरेशन्सशी विरोध का करते?

तो एक चांगला प्रश्न आहे. कारण व्हॅक्यूम फुल टेबल घेते. आणि आम्ही मूलत: टेबलची नवीन आवृत्ती तयार करत आहोत. आणि टेबल नवीन असेल. हे सारणीची पूर्णपणे नवीन आवृत्ती असेल. आणि अडचण अशी आहे की जेव्हा आपण हे करतो तेव्हा लोकांनी ते वाचावे असे आम्हाला वाटत नाही कारण आम्हाला नवीन टेबल पाहण्याची गरज आहे. आणि म्हणून हे मागील प्रश्नाशी जोडते. आम्ही एकाच वेळी वाचू शकलो तर, आम्ही ते हलवू शकणार नाही आणि लोकांना नवीन टेबलवर निर्देशित करू शकणार नाही. प्रत्येकाने हे सारणी वाचून पूर्ण होईपर्यंत आम्हाला प्रतीक्षा करावी लागेल आणि त्यामुळे ही मूलत: लॉक अनन्य परिस्थिती आहे.
आम्ही फक्त असे म्हणतो की आम्ही सुरुवातीपासून लॉक करतो कारण आम्हाला माहित आहे की प्रत्येकजण नवीन कॉपीवर हलविण्यासाठी आम्हाला एका विशिष्ट लॉकची आवश्यकता असेल. त्यामुळे आम्ही संभाव्यपणे याचे निराकरण करू शकतो. आणि आम्ही हे एकाच वेळी अनुक्रमणिकेसह करतो. परंतु हे करणे अधिक कठीण आहे. आणि हे लॉक अनन्य बद्दलच्या तुमच्या मागील प्रश्नाशी खूप संबंधित आहे.

पोस्टग्रेसमध्ये लॉकिंग टाइमआउट जोडणे शक्य आहे का? Oracle मध्ये, मी, उदाहरणार्थ, "अद्यतनासाठी निवडा" लिहू शकतो आणि अपडेट करण्यापूर्वी 50 सेकंद प्रतीक्षा करू शकतो. ते अर्जासाठी चांगले होते. परंतु पोस्टग्रेसमध्ये, मला एकतर ते लगेच करावे लागेल आणि अजिबात वाट पाहू नये किंवा काही काळ प्रतीक्षा करावी लागेल.

होय, तुम्ही तुमच्या लॉकवर, तुमच्या लॉकवर कालबाह्य निवडू शकता. तुम्ही नो वे आदेश देखील जारी करू शकता, जे तुम्हाला ताबडतोब लॉक मिळवू शकत नसल्यास... म्हणून, एकतर लॉक टाइमआउट किंवा दुसरे काहीतरी जे आपल्याला हे करण्यास अनुमती देईल. हे वाक्यरचना स्तरावर केले जात नाही. हे सर्व्हरवर व्हेरिएबल म्हणून केले जाते. कधीकधी हे वापरले जाऊ शकत नाही.

तुम्ही स्लाइड 75 उघडू शकता का?

होय

आणि माझा प्रश्न खालीलप्रमाणे आहे. दोन्ही अद्यतन प्रक्रिया 703 ची अपेक्षा का करत आहेत?

आणि हा एक मोठा प्रश्न आहे. मला समजत नाही, तसे, पोस्टग्रेस असे का करतात. परंतु जेव्हा 703 तयार केले गेले तेव्हा ते 702 ची अपेक्षा करत होते. आणि जेव्हा 704 आणि 705 दिसले, तेव्हा असे दिसते की त्यांना काय अपेक्षित आहे हे माहित नाही कारण तेथे अद्याप काहीही नाही. आणि पोस्टग्रेस हे अशा प्रकारे करतो: जेव्हा तुम्हाला लॉक मिळू शकत नाही, तेव्हा ते लिहिते "तुमच्यावर प्रक्रिया करण्यात काय अर्थ आहे?", कारण तुम्ही आधीच कोणाची तरी वाट पाहत आहात. म्हणून आम्ही ते हवेत लटकू देऊ, ते अजिबात अद्यतनित करणार नाही. पण इथे काय झालं? 702 ने प्रक्रिया पूर्ण करताच आणि 703 ला लॉक प्राप्त होताच, सिस्टम परत आली. आणि ती म्हणाली कि आता आमच्याकडे दोन लोक वाट पाहत आहेत. आणि मग त्यांना एकत्र अपडेट करूया. आणि दोघेही अपेक्षा करत असल्याचे सूचित करूया.

पोस्टग्रेस असे का करतात हे मला माहित नाही. पण च नावाची समस्या आहे…. मला असे वाटते की ही रशियन भाषेतील संज्ञा नाही. हे असे आहे जेव्हा प्रत्येकजण एका वाड्याची वाट पाहत असतो, जरी 20 अधिकारी वाड्याची वाट पाहत असले तरीही. आणि अचानक ते सर्व एकाच वेळी जागे होतात. आणि प्रत्येकजण प्रतिक्रिया देण्याचा प्रयत्न करू लागतो. पण सिस्टीम असे बनवते की प्रत्येकजण 703 ची वाट पाहत आहे. कारण ते सर्व वाट पाहत आहेत, आणि आम्ही त्यांना ताबडतोब रांगेत आणू. आणि यानंतर व्युत्पन्न केलेली इतर कोणतीही नवीन विनंती दिसल्यास, उदाहरणार्थ, 707, नंतर पुन्हा रिक्तता येईल.

आणि मला असे वाटते की हे असे केले आहे की आपण असे म्हणू शकतो की या टप्प्यावर 702 703 ची वाट पाहत आहे आणि त्यानंतर येणार्‍या सर्वांना या क्षेत्रात प्रवेश मिळणार नाही. पण पहिला वेटर निघून गेल्यावर, अपडेटच्या आधी त्या क्षणी वाट पाहणाऱ्या सर्वांना समान टोकन मिळेल. आणि म्हणून मला वाटते की हे केले गेले आहे जेणेकरून आम्ही क्रमाने प्रक्रिया करू शकू जेणेकरून ते योग्यरित्या ऑर्डर केले जातील.

मी याकडे नेहमीच एक विचित्र घटना म्हणून पाहिले. कारण येथे, उदाहरणार्थ, आम्ही त्यांची अजिबात यादी करत नाही. पण मला असे वाटते की प्रत्येक वेळी जेव्हा आपण नवीन कुलूप देतो तेव्हा आपण प्रतीक्षा करण्याच्या प्रक्रियेत असलेल्या सर्वांकडे पाहतो. मग आम्ही त्या सर्वांची रांग लावतो. आणि त्यानंतर येणारा कोणताही नवा फक्त रांगेत येतो जेव्हा पुढील व्यक्तीने प्रक्रिया पूर्ण केली. खूप चांगला प्रश्न. तुमच्या प्रश्नासाठी खूप खूप धन्यवाद!

मला असे वाटते की 705 ला 704 ची अपेक्षा असते तेव्हा ते अधिक तार्किक असते.

परंतु येथे समस्या खालीलप्रमाणे आहे. तांत्रिकदृष्ट्या, आपण एक किंवा दुसर्या जागे करू शकता. आणि म्हणून आपण एक किंवा दुसर्या जागे करू. पण व्यवस्थेत काय होते? अगदी वरच्या ७०३ ने त्याचा स्वतःचा व्यवहार आयडी कसा ब्लॉक केला आहे ते तुम्ही पाहू शकता. पोस्टग्रेस अशा प्रकारे कार्य करते. आणि 703 त्याच्या स्वतःच्या ट्रान्झॅक्शन आयडीने ब्लॉक केला आहे, त्यामुळे जर एखाद्याला वाट पाहायची असेल तर ते 703 ची वाट पाहतील. आणि थोडक्यात, 703 पूर्ण होते. आणि ती पूर्ण झाल्यानंतरच एक प्रक्रिया जागृत होते. आणि ही प्रक्रिया नक्की काय असेल हे आम्हाला माहित नाही. मग आम्ही हळूहळू सर्वकाही प्रक्रिया करतो. परंतु कोणती प्रक्रिया प्रथम जागृत होते हे स्पष्ट नाही, कारण ती यापैकी कोणतीही प्रक्रिया असू शकते. मूलत:, आमच्याकडे एक शेड्यूलर होता ज्याने सांगितले की आम्ही आता यापैकी कोणतीही प्रक्रिया जागृत करू शकतो. आम्ही फक्त एक यादृच्छिकपणे निवडतो. त्यामुळे या दोघांचीही नोंद घेणे आवश्यक आहे कारण आपण त्यापैकी एकाला जागृत करू शकतो.

आणि समस्या अशी आहे की आमच्याकडे सीपी-अनंत आहे. आणि म्हणूनच, आपण नंतरच्याला जागे करू शकू अशी शक्यता आहे. आणि जर, उदाहरणार्थ, आम्ही नंतरच्याला जागृत केले, तर ज्याला नुकताच ब्लॉक मिळाला आहे त्याची आम्ही वाट पाहू, म्हणून आधी नक्की कोण जागृत होईल हे आम्ही ठरवत नाही. आम्ही फक्त अशी परिस्थिती निर्माण करतो आणि प्रणाली त्यांना यादृच्छिक क्रमाने जागृत करेल.

आहेत एगोर रोगोव्हचे लॉक बद्दल लेख. पहा, ते देखील मनोरंजक आणि उपयुक्त आहेत. विषय अर्थातच खूप गुंतागुंतीचा आहे. खूप खूप धन्यवाद, ब्रुस!

स्त्रोत: www.habr.com