पिछली बार, हमने ऑब्जेक्ट-स्तर के ताले के बारे में बात की थी, विशेष रूप से, रिश्तों पर ताले के बारे में। आज हम देखेंगे कि PostgreSQL में पंक्ति लॉक की व्यवस्था कैसे की जाती है और ऑब्जेक्ट लॉक के साथ उनका उपयोग कैसे किया जाता है, आइए प्रतीक्षा कतारों और बारी से बाहर निकलने वालों के बारे में बात करते हैं।

रो ताले

युक्ति

मुझे पिछले लेख से कई महत्वपूर्ण निष्कर्षों की याद दिलाते हैं।

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

हम निश्चित रूप से एक पंक्ति के परिवर्तन को उसी तालिका की अन्य पंक्तियों को अवरुद्ध नहीं करना चाहते हैं। लेकिन हम अपने स्वयं के लॉक के साथ प्रत्येक लाइन शुरू करने का जोखिम नहीं उठा सकते।

इस समस्या को हल करने के लिए अलग-अलग तरीके हैं। कुछ DBMS में, तालों के स्तर में वृद्धि होती है: यदि बहुत अधिक पंक्ति स्तर के ताले हैं, तो उन्हें एक और सामान्य लॉक (उदाहरण के लिए, पृष्ठ स्तर या संपूर्ण तालिका) से बदल दिया जाता है।

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

PostgreSQL में, एक पंक्ति को लॉक करने वाली जानकारी को डेटा पेज के अंदर पंक्ति के संस्करण में और केवल विशेष रूप से संग्रहीत किया जाता है (और रैम में नहीं)। यही है, यह सामान्य अर्थों में बिल्कुल भी ब्लॉक नहीं है, बल्कि सिर्फ एक संकेत है। यह संकेत वास्तव में अतिरिक्त जानकारी बिट्स के साथ संयोजन में xmax लेनदेन संख्या है; थोड़ी देर बाद हम विस्तार से देखेंगे कि यह कैसे काम करता है।

प्लस यह है कि हम बिना किसी संसाधन का उपभोग किए जितनी चाहें उतने लाइनों को ब्लॉक कर सकते हैं।

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

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

असाधारण मोड

कुल में 4 मोड हैं जिसमें आप लाइन को लॉक कर सकते हैं। इनमें से, दो मोड अनन्य ताले का प्रतिनिधित्व करते हैं जो एक समय में केवल एक लेनदेन पकड़ सकते हैं।

अद्यतन मोड के लिए एक पंक्ति का पूर्ण परिवर्तन (या विलोपन) का अर्थ है।
NO KEY UPDATE मोड के लिए - केवल उन फ़ील्ड्स को बदलना जो अद्वितीय अनुक्रमित में शामिल नहीं हैं (दूसरे शब्दों में, इस तरह के बदलाव के साथ, सभी विदेशी कुंजी अपरिवर्तित रहते हैं)।

UPDATE कमांड न्यूनतम उपयुक्त लॉक मोड का चयन करता है; आमतौर पर पंक्तियाँ NO KEY UPDATE मोड में लॉक की जाती हैं।

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

आइए देखते हैं। पिछले लेख के समान खातों की एक तालिका बनाएँ।

=> CREATE TABLE accounts( acc_no integer PRIMARY KEY, amount numeric ); => INSERT INTO accounts VALUES (1, 100.00), (2, 200.00), (3, 300.00);

पृष्ठों को देखने के लिए, निश्चित रूप से, हमें पहले से ही परिचित पेजिन्सपेक्ट एक्सटेंशन की आवश्यकता है।

 => CREATE EXTENSION pageinspect;

सुविधा के लिए, केवल वही जानकारी दिखाएं जो हम में रुचि रखते हैं: xmax और कुछ जानकारी बिट्स।

 => CREATE VIEW accounts_v AS SELECT '(0,'||lp||')' AS ctid, t_xmax as xmax, CASE WHEN (t_infomask & 128) > 0 THEN 't' END AS lock_only, CASE WHEN (t_infomask & 4096) > 0 THEN 't' END AS is_multi, CASE WHEN (t_infomask2 & 8192) > 0 THEN 't' END AS keys_upd, CASE WHEN (t_infomask & 16) > 0 THEN 't' END AS keyshr_lock, CASE WHEN (t_infomask & 16+64) = 16+64 THEN 't' END AS shr_lock FROM heap_page_items(get_raw_page('accounts',0)) ORDER BY lp;

इसलिए, हम लेन-देन शुरू करते हैं और पहले खाते की राशि को अपडेट करते हैं (कुंजी नहीं बदलती है) और दूसरे खाते की संख्या (मुख्य परिवर्तन):

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

हम दृश्य में देखते हैं:

 => SELECT * FROM accounts_v LIMIT 2;

  ctid | xmax | lock_only | is_multi | keys_upd | keyshr_lock | shr_lock -------+--------+-----------+----------+----------+-------------+---------- (0,1) | 530492 | | | | | (0,2) | 530492 | | | t | | (2 rows)

लॉक मोड की_सुधारित सूचना बिट द्वारा निर्धारित किया जाता है।

उसी xmax फ़ील्ड का उपयोग सिलेक्ट फॉर UPDATE कमांड के साथ एक पंक्ति लॉक करते समय भी किया जाता है, लेकिन इस मामले में एक अतिरिक्त सूचना बिट (xmax_lock_only) डाल दी जाती है, जो इंगित करता है कि पंक्ति का संस्करण केवल लॉक है, लेकिन हटाया नहीं गया है और अभी भी प्रासंगिक है।

 => ROLLBACK; => BEGIN; => SELECT * FROM accounts WHERE acc_no = 1 FOR NO KEY UPDATE; => SELECT * FROM accounts WHERE acc_no = 2 FOR UPDATE;

 => SELECT * FROM accounts_v LIMIT 2;

  ctid | xmax | lock_only | is_multi | keys_upd | keyshr_lock | shr_lock -------+--------+-----------+----------+----------+-------------+---------- (0,1) | 530493 | t | | | | (0,2) | 530493 | t | | t | | (2 rows)

 => ROLLBACK;

साझा किए गए मोड

दो और मोड साझा ताले का प्रतिनिधित्व करते हैं जिन्हें कई लेनदेन द्वारा आयोजित किया जा सकता है।

जब आप एक स्ट्रिंग को पढ़ने की आवश्यकता होती है, तो SHARE मोड का उपयोग किया जाता है, लेकिन आपको इसे किसी अन्य लेन-देन द्वारा किसी भी तरह से बदलने की अनुमति नहीं देनी चाहिए।
कुंजी साझा मोड के लिए स्ट्रिंग को बदलने की अनुमति देता है, लेकिन केवल गैर-कुंजी फ़ील्ड। यह मोड, विशेष रूप से, विदेशी कुंजियों की जांच करते समय PostgreSQL द्वारा स्वचालित रूप से उपयोग किया जाता है।

आइए देखते हैं।

 => BEGIN; => SELECT * FROM accounts WHERE acc_no = 1 FOR KEY SHARE; => SELECT * FROM accounts WHERE acc_no = 2 FOR SHARE;

पंक्ति संस्करणों में हम देखते हैं:

 => SELECT * FROM accounts_v LIMIT 2;

  ctid | xmax | lock_only | is_multi | keys_upd | keyshr_lock | shr_lock -------+--------+-----------+----------+----------+-------------+---------- (0,1) | 530494 | t | | | t | (0,2) | 530494 | t | | | t | t (2 rows)

दोनों ही मामलों में, keyshr_lock बिट सेट है, और SHARE मोड को एक और सूचना बिट को देखकर पहचाना जा सकता है।

यहां सामान्य मोड संगतता मैट्रिक्स जैसा दिखता है।

शासन	प्रमुख शेयर के लिए	शेयर के लिए	कोई प्रमुख अद्यतन के लिए	अद्यतन के लिए
प्रमुख शेयर के लिए				एक्स
शेयर के लिए			एक्स	एक्स
कोई प्रमुख अद्यतन के लिए		एक्स	एक्स	एक्स
अद्यतन के लिए	एक्स	एक्स	एक्स	एक्स

यह दर्शाता है कि:

एक दूसरे के साथ असाधारण मोड संघर्ष;
साझा मोड एक दूसरे के साथ संगत हैं;
साझा किया गया कुंजी साझा करें मोड NO KEY UPDATE मोड के लिए अनन्य के साथ संगत है (अर्थात, आप एक ही समय में गैर-कुंजी फ़ील्ड को अपडेट कर सकते हैं और सुनिश्चित कर सकते हैं कि कुंजी परिवर्तित नहीं होती है)।

Multitranzaktsii

अब तक, हमने सोचा था कि लॉक को xmax फ़ील्ड में अवरुद्ध लेनदेन की संख्या द्वारा दर्शाया गया है। लेकिन साझा किए गए ताले को कई लेनदेन द्वारा आयोजित किया जा सकता है, और कई संख्याओं को एक ही xmax फ़ील्ड में नहीं लिखा जा सकता है। कैसे हो?

साझा ताले के लिए, तथाकथित बहु -लेनदेन (मल्टीएक्सएक्ट) का उपयोग किया जाता है। यह एक लेनदेन समूह है जिसे एक अलग संख्या सौंपी जाती है। इस संख्या में एक नियमित लेनदेन संख्या के समान आयाम है, लेकिन संख्याओं को स्वतंत्र रूप से आवंटित किया जाता है (अर्थात, सिस्टम में समान लेनदेन और बहु-लेनदेन संख्या हो सकती है)। एक को दूसरे से अलग करने के लिए, एक और सूचना बिट (xmax_is_multi) का उपयोग किया जाता है, और इस तरह के एक समूह के सदस्यों और लॉक मोड के बारे में विस्तृत जानकारी $ PGDATA / pg_multi / निर्देशिका में फ़ाइलों में स्थित है। स्वाभाविक रूप से, अंतिम उपयोग किया गया डेटा बफ़र्स में तेजी से एक्सेस के लिए सर्वर की साझा मेमोरी में संग्रहीत किया जाता है।

मौजूदा ताले में किसी अन्य लेनदेन द्वारा निष्पादित एक और असाधारण एक को जोड़ें (हम ऐसा कर सकते हैं, क्योंकि प्रमुख शेयर और कोई प्रमुख अद्यतन मोड एक दूसरे के साथ संगत हैं):

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

 => SELECT * FROM accounts_v LIMIT 2;

  ctid | xmax | lock_only | is_multi | keys_upd | keyshr_lock | shr_lock -------+--------+-----------+----------+----------+-------------+---------- (0,1) | 61 | | t | | | (0,2) | 530494 | t | | | t | t (2 rows)

पहली पंक्ति में, हम देखते हैं कि सामान्य संख्या को एक बहुपरिवर्तन संख्या से बदल दिया गया है - यह xmax_is_multi बिट द्वारा दर्शाया गया है।

मल्टीट्रांसनीकरण कार्यान्वयन के आंतरिक मामलों में तल्लीन नहीं करने के लिए, आप एक और विस्तार का उपयोग कर सकते हैं जो आपको सभी प्रकार के पंक्ति ताले के बारे में सभी जानकारी को सुविधाजनक तरीके से देखने की अनुमति देता है।

 => CREATE EXTENSION pgrowlocks; => SELECT * FROM pgrowlocks('accounts') \gx

 -[ RECORD 1 ]----------------------------- locked_row | (0,1) locker | 61 multi | t xids | {530494,530495} modes | {"Key Share","No Key Update"} pids | {5892,5928} -[ RECORD 2 ]----------------------------- locked_row | (0,2) locker | 530494 multi | f xids | {530494} modes | {"For Share"} pids | {5892}

 => COMMIT;

 | => ROLLBACK;

जमने की सेटिंग

चूंकि मल्टीट्रांसपोर्ट्स के लिए अलग-अलग नंबर आवंटित किए जाते हैं, जो पंक्ति संस्करणों के xmax क्षेत्र में लिखे जाते हैं, काउंटर की बिट क्षमता की सीमा के कारण, वे एक ही xid रैपराउंड समस्या का अनुभव करते हैं जैसे कि एक नियमित संख्या।

इसलिए, बहु-लेनदेन संख्याओं के लिए, ठंड का एक एनालॉग प्रदर्शन करना भी आवश्यक है - पुराने संख्याओं को नए के साथ बदलें (या एक नियमित लेनदेन संख्या के साथ, यदि ठंड के समय ताला केवल एक लेनदेन द्वारा आयोजित किया जाता है)।

ध्यान दें कि साधारण लेनदेन संख्याओं का जमाव केवल xmin फ़ील्ड के लिए किया जाता है (क्योंकि यदि लाइन के संस्करण में एक गैर-खाली xmax फ़ील्ड है, तो यह या तो एक अप्रासंगिक संस्करण है और इसे साफ़ कर दिया जाएगा, या xmax लेनदेन रद्द कर दिया जाता है और इसकी संख्या हमारे लिए रुचि नहीं रखती है)। लेकिन बहु-लेन-देन के लिए, हम लाइन के वर्तमान संस्करण के xmax क्षेत्र के बारे में बात कर रहे हैं, जो प्रासंगिक रह सकता है, लेकिन एक साझा मोड में विभिन्न लेनदेन द्वारा इसे लगातार अवरुद्ध किया जाता है।

बहु -लेन-देन के ठंड के लिए, सामान्य ठंड के मापदंडों के समान पैरामीटर जिम्मेदार हैं : वैक्यूम_मूल्टिक्ट_फ्रीज_मिन_एज , वैक्यूम_मल्टिक्ट_फ्रीज_टेबल_एज , ऑटोवैक्यूम_माइलेटिक्स_फ्रीज_मैक्स_माज ।

अति कौन है?

धीरे-धीरे मिठाई के पास पहुंचें। आइए देखें कि ताले की तस्वीर क्या है जब कई लेनदेन एक ही पंक्ति को अपडेट करने जा रहे हैं।

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

 => CREATE VIEW locks_v AS SELECT pid, locktype, CASE locktype WHEN 'relation' THEN relation::regclass::text WHEN 'transactionid' THEN transactionid::text WHEN 'tuple' THEN relation::regclass::text||':'||tuple::text END AS lockid, mode, granted FROM pg_locks WHERE locktype in ('relation','transactionid','tuple') AND (locktype != 'relation' OR relation = 'accounts'::regclass);

अब पहला लेनदेन शुरू करें और पंक्ति को अपडेट करें।

 => BEGIN; => SELECT txid_current(), pg_backend_pid();

  txid_current | pg_backend_pid --------------+---------------- 530497 | 5892 (1 row)

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

 UPDATE 1

ताले के बारे में क्या?

 => SELECT * FROM locks_v WHERE pid = 5892;

  pid | locktype | lockid | mode | granted ------+---------------+----------+------------------+--------- 5892 | relation | accounts | RowExclusiveLock | t 5892 | transactionid | 530497 | ExclusiveLock | t (2 rows)

लेन-देन तालिका और स्वयं की संख्या लॉक रखता है। अब तक, सब कुछ अपेक्षित है।

हम दूसरा लेनदेन शुरू करते हैं और उसी लाइन को अपडेट करने का प्रयास करते हैं।

 | => BEGIN; | => SELECT txid_current(), pg_backend_pid();

 | txid_current | pg_backend_pid | --------------+---------------- | 530498 | 5928 | (1 row)

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

दूसरे लेन-देन के ताले के बारे में क्या?

 => SELECT * FROM locks_v WHERE pid = 5928;

  pid | locktype | lockid | mode | granted ------+---------------+------------+------------------+--------- 5928 | relation | accounts | RowExclusiveLock | t 5928 | transactionid | 530498 | ExclusiveLock | t 5928 | transactionid | 530497 | ShareLock | f 5928 | tuple | accounts:1 | ExclusiveLock | t (4 rows)

और यहां यह अधिक दिलचस्प है। तालिका और स्वयं की संख्या लॉक करने के अलावा, हम दो और ताले देखते हैं। दूसरे लेन-देन में पाया गया कि पंक्ति को पहले बंद कर दिया गया था और इसके नंबर (दी गई = f) की प्रतीक्षा में "लटका हुआ" था। लेकिन लाइन संस्करण लॉक (लॉकटाइप = ट्यूपल) कहां और क्यों आया?

पंक्ति संस्करण लॉक (टुपल लॉक) और पंक्ति लॉक (पंक्ति लॉक) को भ्रमित न करें। पहला एक नियमित टपल टाइप लॉक है, जो pg_locks में दिखाई देता है। दूसरा डेटा पृष्ठ में एक चिह्न है: xmax और सूचना बिट्स।

जब कोई लेन-देन किसी पंक्ति को बदलने वाला होता है, तो यह क्रियाओं का निम्नलिखित क्रम करता है:

एक स्ट्रिंग (टुपल) के एक परिवर्तनशील संस्करण पर एक विशेष लॉक कैप्चर करता है।
यदि xmax और सूचना बिट्स इंगित करते हैं कि रेखा लॉक है, तो यह xmax लेनदेन संख्या को लॉक करने के लिए कहता है।
इसके xmax और आवश्यक सूचना बिट्स को निर्धारित करता है।
पंक्ति संस्करण लॉक जारी करता है।

जब पहली लेन-देन द्वारा पंक्ति को अद्यतन किया गया था, तो उसने पंक्ति संस्करण लॉक (चरण 1) को भी पकड़ लिया, लेकिन तुरंत इसे (चरण 4) जारी कर दिया।

जब दूसरा लेन-देन आया, तो उसने पंक्ति संस्करण लॉक (आइटम 1) पर कब्जा कर लिया, लेकिन पहले लेनदेन नंबर (आइटम 2) के लॉक का अनुरोध करने के लिए मजबूर किया गया और इस पर लटका दिया गया।

यदि तीसरा समान लेनदेन दिखाई देता है तो क्या होता है? वह लाइन के संस्करण (आइटम 1) के लॉक को पकड़ने की कोशिश करेगी और इस कदम पर पहले से ही लटकाएगी। इसे देखें।

 || => BEGIN; || => SELECT txid_current(), pg_backend_pid();

 || txid_current | pg_backend_pid || --------------+---------------- || 530499 | 5964 || (1 row)

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

 => SELECT * FROM locks_v WHERE pid = 5964;

  pid | locktype | lockid | mode | granted ------+---------------+------------+------------------+--------- 5964 | relation | accounts | RowExclusiveLock | t 5964 | tuple | accounts:1 | ExclusiveLock | f 5964 | transactionid | 530499 | ExclusiveLock | t (3 rows)

चौथा, पाँचवाँ इत्यादि लेन-देन जो एक ही पंक्ति को अपडेट करना चाहते हैं, वह लेन-देन 3 से अलग नहीं होगा - वे सभी एक ही पंक्ति संस्करण लॉक पर "हैंग" करेंगे।

ढेर में एक और लेनदेन जोड़ें।

 ||| => BEGIN; ||| => SELECT txid_current(), pg_backend_pid();

 ||| txid_current | pg_backend_pid ||| --------------+---------------- ||| 530500 | 6000 ||| (1 row)

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

 => SELECT * FROM locks_v WHERE pid = 6000;

  pid | locktype | lockid | mode | granted ------+---------------+------------+------------------+--------- 6000 | relation | accounts | RowExclusiveLock | t 6000 | transactionid | 530500 | ExclusiveLock | t 6000 | tuple | accounts:1 | ExclusiveLock | f (3 rows)

वर्तमान अपेक्षाओं की एक सामान्य तस्वीर को अवरुद्ध प्रक्रियाओं के बारे में जानकारी जोड़ते हुए pg_stat_activity दृश्य में देखा जा सकता है:

 => SELECT pid, wait_event_type, wait_event, pg_blocking_pids(pid) FROM pg_stat_activity WHERE backend_type = 'client backend';

  pid | wait_event_type | wait_event | pg_blocking_pids ------+-----------------+---------------+------------------ 5892 | | | {} 5928 | Lock | transactionid | {5892} 5964 | Lock | tuple | {5928} 6000 | Lock | tuple | {5928,5964} (4 rows)

यह एक तरह का "कतार" निकला, जिसमें पहला (स्ट्रिंग के लॉक संस्करण को रखने वाला) है और अन्य सभी जो पहले के पीछे लाइन करते हैं।

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

यह इस तथ्य से भरा है कि कुछ लेन-देन अनिश्चित काल तक अपनी बारी का इंतजार कर सकते हैं, यदि परिस्थितियों के दुर्भाग्यपूर्ण संयोजन के कारण, यह हमेशा अन्य लेनदेन के आसपास चलेगा। अंग्रेजी में, इस स्थिति को लॉक भुखमरी कहा जाता है।

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

यदि पहला लेन-देन रोलबैक के साथ समाप्त होता है, तो सब कुछ ठीक हो जाएगा: आने वाले लेनदेन उसी क्रम में जाएंगे, जिस क्रम में वे पंक्तिबद्ध थे।

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

पहले लेनदेन को कमिटमेंट के साथ पूरा होने दें।

 => COMMIT;

दूसरा लेन-देन जाग जाएगा और पैराग्राफ को निष्पादित करेगा। 3 और 4।

 | UPDATE 1

 => SELECT * FROM locks_v WHERE pid = 5928;

  pid | locktype | lockid | mode | granted ------+---------------+----------+------------------+--------- 5928 | relation | accounts | RowExclusiveLock | t 5928 | transactionid | 530498 | ExclusiveLock | t (2 rows)

तीसरे लेन-देन के बारे में क्या? वह चरण 1 को छोड़ देती है (क्योंकि संसाधन गायब हो गया है) और चरण 2 पर अटक जाता है:

 => SELECT * FROM locks_v WHERE pid = 5964;

  pid | locktype | lockid | mode | granted ------+---------------+----------+------------------+--------- 5964 | relation | accounts | RowExclusiveLock | t 5964 | transactionid | 530498 | ShareLock | f 5964 | transactionid | 530499 | ExclusiveLock | t (3 rows)

और चौथे लेनदेन के साथ भी यही होता है:

 => SELECT * FROM locks_v WHERE pid = 6000;

  pid | locktype | lockid | mode | granted ------+---------------+----------+------------------+--------- 6000 | relation | accounts | RowExclusiveLock | t 6000 | transactionid | 530498 | ShareLock | f 6000 | transactionid | 530500 | ExclusiveLock | t (3 rows)

यही है, तीसरे और चौथे दोनों लेनदेन दूसरे के पूरा होने का इंतजार कर रहे हैं। लाइन ~~कद्दू~~ भीड़ में बदल गई।

हम सभी शुरू किए गए लेनदेन को पूरा करते हैं।

 | => COMMIT;

 || UPDATE 1

 || => COMMIT;

 ||| UPDATE 1

 ||| => COMMIT;

अवरुद्ध तार के बारे में अधिक विवरण README.tuplock में पाया जा सकता है।

आप यहां खड़े नहीं थे

तो, दो-स्तरीय अवरोधन योजना का विचार "खराब भाग्य" लेनदेन के लिए अनन्त प्रतीक्षा की संभावना को कम करना है। फिर भी, जैसा कि हमने पहले ही देखा है, ऐसी स्थिति काफी संभव है। और अगर एप्लिकेशन साझा किए गए ताले का उपयोग करता है, तो सब कुछ दुखी भी हो सकता है।

पहले लेनदेन को साझा मोड में पंक्ति को लॉक करने दें।

 => BEGIN; => SELECT txid_current(), pg_backend_pid();

  txid_current | pg_backend_pid --------------+---------------- 530501 | 5892 (1 row)

 => SELECT * FROM accounts WHERE acc_no = 1 FOR SHARE;

  acc_no | amount --------+-------- 1 | 100.00 (1 row)

दूसरा लेन-देन एक ही पंक्ति को अपडेट करने का प्रयास करता है, लेकिन - शेयर और कोई प्रमुख अद्यतन मोड असंगत नहीं हैं।

 | => BEGIN; | => SELECT txid_current(), pg_backend_pid();

 | txid_current | pg_backend_pid | --------------+---------------- | 530502 | 5928 | (1 row)

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

दूसरा लेनदेन पहले पूरा होने की प्रतीक्षा करता है और पंक्ति संस्करण लॉक रखता है - अभी के लिए, सब कुछ पिछली बार की तरह है।

 => SELECT * FROM locks_v WHERE pid = 5928;

  pid | locktype | lockid | mode | granted ------+---------------+-------------+------------------+--------- 5928 | relation | accounts | RowExclusiveLock | t 5928 | tuple | accounts:10 | ExclusiveLock | t 5928 | transactionid | 530501 | ShareLock | f 5928 | transactionid | 530502 | ExclusiveLock | t (4 rows)

और फिर एक तीसरा लेनदेन दिखाई देता है जो एक साझा लॉक चाहता है। परेशानी यह है कि यह लाइन के संस्करण पर लॉक को पकड़ने की कोशिश नहीं करता है (क्योंकि यह लाइन को बदलने नहीं जा रहा है), लेकिन बस बारी-बारी से क्रॉल करता है - यह पहले लेनदेन के साथ संगत है।

 || BEGIN || => SELECT txid_current(), pg_backend_pid();

 || txid_current | pg_backend_pid || --------------+---------------- || 530503 | 5964 || (1 row)

 || => SELECT * FROM accounts WHERE acc_no = 1 FOR SHARE;

 || acc_no | amount || --------+-------- || 1 | 100.00 || (1 row)

और अब दो लेनदेन पंक्ति को रोक रहे हैं:

 => SELECT * FROM pgrowlocks('accounts') \gx

 -[ RECORD 1 ]--------------- locked_row | (0,10) locker | 62 multi | t xids | {530501,530503} modes | {Share,Share} pids | {5892,5964}

पहला लेन-देन पूरा होने पर अब क्या होता है? दूसरा लेन-देन जाग जाएगा, लेकिन देखेंगे कि पंक्ति लॉक कहीं भी गायब नहीं हुआ है, और फिर से "कतार" में खड़ा होगा - इस बार तीसरे लेनदेन के लिए:

 => COMMIT; => SELECT * FROM locks_v WHERE pid = 5928;

  pid | locktype | lockid | mode | granted ------+---------------+-------------+------------------+--------- 5928 | relation | accounts | RowExclusiveLock | t 5928 | tuple | accounts:10 | ExclusiveLock | t 5928 | transactionid | 530503 | ShareLock | f 5928 | transactionid | 530502 | ExclusiveLock | t (4 rows)

और केवल जब तीसरा लेनदेन पूरा हो जाता है (और यदि इस दौरान कोई अन्य साझा किए गए ताले दिखाई नहीं देते हैं), तो दूसरा अपडेट करने में सक्षम होगा।

 || => COMMIT;

 | UPDATE 1

 | => ROLLBACK;

शायद यह कुछ व्यावहारिक निष्कर्ष निकालने का समय है।

कई समानांतर प्रक्रियाओं में एक ही समय में एक ही पंक्ति को एक तालिका में अद्यतन करना एक अच्छा विचार नहीं है।
यदि आप एप्लिकेशन में साझा प्रकार के साझा ताले का उपयोग करते हैं, तो सावधानीपूर्वक करें।
विदेशी कुंजियों की जांच में हस्तक्षेप नहीं करना चाहिए, क्योंकि प्रमुख फ़ील्ड आमतौर पर बदलती नहीं हैं, और कुंजी साझा करें और कोई कुंजी अद्यतन मोड संगत नहीं हैं।

उधार न लेने को कहा

आमतौर पर, SQL कमांड को उन संसाधनों को जारी करने की अपेक्षा होती है जिनकी उन्हें आवश्यकता होती है। लेकिन कभी-कभी आप कमांड को निष्पादित करने से इंकार करना चाहते हैं यदि लॉक तुरंत प्राप्त नहीं किया जा सकता है। ऐसा करने के लिए, SELECT, LOCK, ALTER जैसे कमांड आपको NowAIT वाक्यांश का उपयोग करने की अनुमति देते हैं।

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

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

 | => SELECT * FROM accounts FOR UPDATE NOWAIT;

 | ERROR: could not obtain lock on row in relation "accounts"

यदि संसाधन व्यस्त है, तो कमांड तुरंत विफल हो जाता है। एप्लिकेशन कोड में, इस तरह की त्रुटि को अवरोधन और संसाधित किया जा सकता है।

आप UPDATE और DELETE कमांड के लिए NowAIT वाक्यांश निर्दिष्ट नहीं कर सकते हैं, लेकिन आप पहले चयन करें के लिए चयन करें और उसके बाद, यदि संभव हो तो, अद्यतन करें या लाइन हटाएं।

प्रतीक्षा न करने का एक और विकल्प है - SKIP LOCKED वाक्यांश के साथ SELECT FOR कमांड का उपयोग करना। इस तरह की कमांड लॉक लाइनों को छोड़ देगी, लेकिन मुफ्त में प्रोसेस करेगी।

 | => BEGIN; | => DECLARE c CURSOR FOR | SELECT * FROM accounts ORDER BY acc_no FOR UPDATE SKIP LOCKED; | => FETCH c;

 | acc_no | amount | --------+-------- | 2 | 200.00 | (1 row)

इस उदाहरण में, पहली - अवरुद्ध - रेखा को छोड़ दिया गया था और हम तुरंत दूसरे (और अवरुद्ध) प्राप्त हुए थे।

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

 => ROLLBACK;

 | => ROLLBACK;

जारी रखा जाए ।

PostgreSQL ताले: 2. स्ट्रिंग ताले