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

हैडर

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

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

जब एक लाइन बनाई जाती है, तो Xmin को INSERT कमांड को निष्पादित करने वाले लेनदेन नंबर पर सेट किया जाता है, और xmax पॉपुलेटेड नहीं होता है।

जब कोई पंक्ति हटा दी जाती है, तो वर्तमान संस्करण के xmax मान को उस लेनदेन संख्या से चिह्नित किया जाता है जो DELETE करता है।

जब एक पंक्ति को UPDATE कमांड के साथ संशोधित किया जाता है, तो दो ऑपरेशन वास्तव में किए जाते हैं: DELETE और INSERT। लाइन के वर्तमान संस्करण में, xmax को उस लेनदेन की संख्या के बराबर सेट किया जाता है जो UPDATE को किया गया था। फिर उसी लाइन का एक नया संस्करण बनाया जाता है; इसका xmin मान पिछले संस्करण के xmax मान से मेल खाता है।

Xmin और xmax फ़ील्ड्स को पंक्ति संस्करण हेडर में शामिल किया गया है। इन क्षेत्रों के अलावा, हेडर में अन्य होते हैं, उदाहरण के लिए:

infomask - इस संस्करण के गुणों को परिभाषित करने वाली बिट्स की एक श्रृंखला। उनमें से काफी हैं; मुख्य रूप से हम धीरे-धीरे विचार करेंगे।
ctid - उसी पंक्ति के अगले, नए संस्करण का लिंक। स्ट्रिंग के सबसे नए, नवीनतम संस्करण में, ctid इस संस्करण को संदर्भित करता है। संख्या में प्रपत्र (x, y) है, जहां x पृष्ठ संख्या है, y सरणी में सूचक की क्रम संख्या है।
अपरिभाषित मानों के बिटमैप - इस संस्करण के उन स्तंभों को चिह्नित करते हैं जिनमें अपरिभाषित मान (NULL) होता है। NULL डेटा प्रकारों के सामान्य मानों में से एक नहीं है, इसलिए विशेषता को अलग से संग्रहीत किया जाना चाहिए।

नतीजतन, हेडर काफी बड़ा है - स्ट्रिंग के प्रति संस्करण कम से कम 23 बाइट्स, और आमतौर पर NULL बिटमैप के कारण। यदि तालिका "संकीर्ण" है (अर्थात, इसमें कुछ कॉलम हैं), ओवरहेड उपयोगी जानकारी से अधिक ले सकता है।

डालने

आइए देखें कि निम्न स्तर पर स्ट्रिंग ऑपरेशन कैसे किए जाते हैं, और डालने के साथ शुरू करें।

प्रयोगों के लिए, दो स्तंभों और उनमें से एक पर एक सूचकांक के साथ एक नई तालिका बनाएं:

=> CREATE TABLE t( id serial, s text ); => CREATE INDEX ON t(s);

लेन-देन शुरू करने के बाद, एक पंक्ति डालें।

 => BEGIN; => INSERT INTO t(s) VALUES ('FOO');

यहाँ हमारे वर्तमान लेनदेन की संख्या है:

 => SELECT txid_current();

  txid_current -------------- 3664 (1 row)

पृष्ठ की सामग्री पर एक नज़र डालें। पेजिन्सपेक्ट एक्सटेंशन का heap_page_items फ़ंक्शन संकेत और पंक्ति संस्करणों के बारे में जानकारी प्रदान करता है:

 => SELECT * FROM heap_page_items(get_raw_page('t',0)) \gx

 -[ RECORD 1 ]------------------- lp | 1 lp_off | 8160 lp_flags | 1 lp_len | 32 t_xmin | 3664 t_xmax | 0 t_field3 | 0 t_ctid | (0,1) t_infomask2 | 2 t_infomask | 2050 t_hoff | 24 t_bits | t_oid | t_data | \x0100000009464f4f

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

फ़ंक्शन डेटा "जैसा है" एक प्रारूप में प्रदर्शित करता है जिसे पढ़ना मुश्किल है। समझने के लिए, हम केवल जानकारी का एक हिस्सा छोड़ देंगे और इसे डिक्रिप्ट करेंगे:

 => SELECT '(0,'||lp||')' AS ctid, CASE lp_flags WHEN 0 THEN 'unused' WHEN 1 THEN 'normal' WHEN 2 THEN 'redirect to '||lp_off WHEN 3 THEN 'dead' END AS state, t_xmin as xmin, t_xmax as xmax, (t_infomask & 256) > 0 AS xmin_commited, (t_infomask & 512) > 0 AS xmin_aborted, (t_infomask & 1024) > 0 AS xmax_commited, (t_infomask & 2048) > 0 AS xmax_aborted, t_ctid FROM heap_page_items(get_raw_page('t',0)) \gx

 -[ RECORD 1 ]-+------- ctid | (0,1) state | normal xmin | 3664 xmax | 0 xmin_commited | f xmin_aborted | f xmax_commited | f xmax_aborted | t t_ctid | (0,1)

यहाँ हमने क्या किया:

हमने इसे t_ctid: (पृष्ठ संख्या, अनुक्रमणिका संख्या) के समान रूप में लाने के लिए अनुक्रमणिका संख्या में एक शून्य जोड़ा।
Lp_flags पॉइंटर की स्थिति को डिक्रिप्ट किया गया। यहां यह "सामान्य" है - इसका मतलब है कि सूचक वास्तव में स्ट्रिंग के संस्करण को संदर्भित करता है। अन्य मूल्यों पर बाद में विचार किया जाएगा।
सभी सूचना बिट्स में से अब तक केवल दो जोड़े आवंटित किए गए हैं। Xmin_committed और xmin_aborted बिट्स इंगित करते हैं कि क्या xmin नंबर के साथ लेनदेन प्रतिबद्ध है (रद्द)। दो समान बिट्स लेनदेन संख्या xmax को संदर्भित करते हैं।

हम क्या देखते हैं? जब आप तालिका पृष्ठ में एक पंक्ति सम्मिलित करते हैं, तो एक सूचक संख्या 1 के साथ दिखाई देता है, पंक्ति के पहले और एकमात्र संस्करण का उल्लेख करता है।

लाइन के संस्करण में, xmin फ़ील्ड वर्तमान लेनदेन की संख्या से भरी हुई है। लेन-देन अभी भी सक्रिय है, इसलिए दोनों बिट्स xmin_committed और xmin_aborted सेट नहीं हैं।

पंक्ति संस्करण का ctid फ़ील्ड उसी पंक्ति को संदर्भित करता है। इसका मतलब यह है कि एक नया संस्करण मौजूद नहीं है।

Xmax फ़ील्ड को डमी नंबर 0 से भरा गया है, क्योंकि लाइन का यह संस्करण हटा नहीं है और प्रासंगिक है। लेन-देन इस संख्या पर ध्यान नहीं देंगे, क्योंकि xmax_aborted बिट सेट है।

लेन-देन संख्याओं में सूचना बिट्स जोड़कर पठनीयता में सुधार करने के लिए एक और कदम उठाएं। और हम एक फ़ंक्शन बनाएंगे, क्योंकि हमें एक से अधिक बार अनुरोध की आवश्यकता होगी:

 => CREATE FUNCTION heap_page(relname text, pageno integer) RETURNS TABLE(ctid tid, state text, xmin text, xmax text, t_ctid tid) AS $$ SELECT (pageno,lp)::text::tid AS ctid, CASE lp_flags WHEN 0 THEN 'unused' WHEN 1 THEN 'normal' WHEN 2 THEN 'redirect to '||lp_off WHEN 3 THEN 'dead' END AS state, t_xmin || CASE WHEN (t_infomask & 256) > 0 THEN ' (c)' WHEN (t_infomask & 512) > 0 THEN ' (a)' ELSE '' END AS xmin, t_xmax || CASE WHEN (t_infomask & 1024) > 0 THEN ' (c)' WHEN (t_infomask & 2048) > 0 THEN ' (a)' ELSE '' END AS xmax, t_ctid FROM heap_page_items(get_raw_page(relname,pageno)) ORDER BY lp; $$ LANGUAGE SQL;

इस रूप में, यह बहुत स्पष्ट है कि स्ट्रिंग के संस्करण के शीर्षलेख में क्या हो रहा है:

 => SELECT * FROM heap_page('t',0);

  ctid | state | xmin | xmax | t_ctid -------+--------+------+-------+-------- (0,1) | normal | 3664 | 0 (a) | (0,1) (1 row)

इसी तरह, लेकिन काफी कम विस्तृत, छद्म-स्तंभ xmin और xmax का उपयोग करते हुए, जानकारी तालिका से ही प्राप्त की जा सकती है:

 => SELECT xmin, xmax, * FROM t;

  xmin | xmax | id | s ------+------+----+----- 3664 | 0 | 1 | FOO (1 row)

निर्धारण

लेनदेन के सफल समापन पर, आपको इसकी स्थिति याद रखने की आवश्यकता है - ध्यान दें कि यह तय हो गया है। ऐसा करने के लिए, XACT नामक एक संरचना का उपयोग करें (और संस्करण 10 से पहले इसे CLOG (कमिट लॉग) कहा जाता था और यह नाम अभी भी विभिन्न स्थानों में पाया जा सकता है)।

XACT सिस्टम कैटलॉग तालिका नहीं है; ये PGDATA / pg_xact निर्देशिका में फ़ाइलें हैं। उनमें, प्रत्येक लेनदेन के लिए, दो बिट्स आवंटित किए जाते हैं: प्रतिबद्ध और निरस्त - ठीक उसी तरह जैसे कि लाइन के संस्करण के हेडर में। यह जानकारी पूरी तरह से सुविधा के लिए कई फाइलों में विभाजित है, हम इस मुद्दे पर लौटेंगे जब हम ठंड पर विचार करेंगे। और इन फाइलों के साथ काम पेज द्वारा पृष्ठ के रूप में किया जाता है, अन्य सभी के साथ।

इसलिए, XACT में लेनदेन करते समय, इस लेनदेन के लिए प्रतिबद्ध बिट सेट है। और वह सब जो कमिट के दौरान होता है (हालाँकि हम अभी तक पूर्वगामी पत्रिका के बारे में बात नहीं कर रहे हैं)।

जब कोई अन्य लेन-देन हमारे द्वारा देखे गए टेबल पेज तक पहुंचता है, तो उसे कुछ सवालों के जवाब देने होंगे।

क्या लेनदेन एक्समिन पूरा हो गया है? यदि नहीं, तो स्ट्रिंग का उत्पन्न संस्करण दिखाई नहीं देना चाहिए।
इस तरह के सत्यापन को अभी तक एक और संरचना को देखते हुए किया जाता है, जो उदाहरण की साझा स्मृति में स्थित है और इसे ProcArray कहा जाता है। इसमें सभी सक्रिय प्रक्रियाओं की एक सूची शामिल है, और प्रत्येक के लिए इसकी वर्तमान (सक्रिय) लेनदेन की संख्या इंगित की गई है।
यदि पूरा किया जाता है, तो कैसे - निर्धारण या रद्द करके? यदि रद्द किया जाता है, तो स्ट्रिंग का संस्करण भी दिखाई नहीं देना चाहिए।
यह वही है जो XACT के लिए है। लेकिन, हालांकि अंतिम XACT पेज रैम में बफ़र्स में संग्रहीत हैं, लेकिन हर बार XACT की जाँच करना अनावश्यक है। इसलिए, एक बार स्पष्ट किए जाने वाले लेन-देन की स्थिति को xmin_committed और पंक्ति संस्करण के xmin_aborted बिट्स में दर्ज किया जाता है। यदि इनमें से एक बिट सेट किया जाता है, तो लेनदेन की स्थिति को ज्ञात माना जाता है और अगले लेनदेन को अब XACT तक नहीं पहुंचना होगा।

इन बिट्स को ट्रांजेक्शन करने वाले खुद ट्रांजेक्शन द्वारा सेट क्यों नहीं किया जाता है? जब कोई प्रविष्टि होती है, तो लेनदेन अभी तक नहीं जानता है कि यह सफलतापूर्वक पूरा होगा या नहीं। और फिक्सिंग के क्षण में यह पहले से ही स्पष्ट नहीं है कि कौन सी लाइनें किन पृष्ठों में बदली गई थीं। ऐसे कई पृष्ठ हो सकते हैं, और उन्हें याद रखना नुकसानदेह है। इसके अलावा, पृष्ठों का हिस्सा बफर कैश से डिस्क पर धकेल दिया जा सकता है; बिट्स को बदलने के लिए उन्हें फिर से पढ़ने का मतलब होगा कमिटमेंट को धीमा करना।

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

इसलिए, परिवर्तन को ठीक करें।

 => COMMIT;

पृष्ठ में कुछ भी नहीं बदला है (लेकिन हम जानते हैं कि लेनदेन की स्थिति पहले से ही XACT में दर्ज है):

 => SELECT * FROM heap_page('t',0);

  ctid | state | xmin | xmax | t_ctid -------+--------+------+-------+-------- (0,1) | normal | 3664 | 0 (a) | (0,1) (1 row)

अब लेन-देन जो पहले पृष्ठ तक पहुंचता है, उसे लेन-देन की स्थिति xmin निर्धारित करनी होगी और इसे सूचना बिट्स पर लिखना होगा:

 => SELECT * FROM t;

  id | s ----+----- 1 | FOO (1 row)

 => SELECT * FROM heap_page('t',0);

  ctid | state | xmin | xmax | t_ctid -------+--------+----------+-------+-------- (0,1) | normal | 3664 (c) | 0 (a) | (0,1) (1 row)

निष्कासन

जब कोई लाइन हटा दी जाती है, तो वर्तमान संस्करण के xmax फ़ील्ड में वर्तमान हटाने वाले लेनदेन की संख्या दर्ज की जाती है, और xmax_aborted बिट रीसेट हो जाता है।

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

लाइन को हटा दें।

 => BEGIN; => DELETE FROM t; => SELECT txid_current();

  txid_current -------------- 3665 (1 row)

हम देखते हैं कि लेनदेन संख्या xmax फ़ील्ड में दर्ज की गई है, लेकिन सूचना बिट्स सेट नहीं हैं:

 => SELECT * FROM heap_page('t',0);

  ctid | state | xmin | xmax | t_ctid -------+--------+----------+------+-------- (0,1) | normal | 3664 (c) | 3665 | (0,1) (1 row)

रद्द करना

परिवर्तन बदलने के लिए इसी तरह से काम करता है, केवल XACT में लेन-देन के लिए गर्भपात बिट सेट है। रद्दीकरण प्रतिबद्ध रूप में तेजी से है। हालाँकि कमांड को ROLLBACK कहा जाता है, लेकिन परिवर्तन को वापस नहीं लाया जाता है: डेटा पेजों में परिवर्तन के लिए प्रबंधित सब कुछ अपरिवर्तित रहता है।

 => ROLLBACK; => SELECT * FROM heap_page('t',0);

  ctid | state | xmin | xmax | t_ctid -------+--------+----------+------+-------- (0,1) | normal | 3664 (c) | 3665 | (0,1) (1 row)

पृष्ठ तक पहुंचने पर, स्थिति की जाँच की जाएगी और xmax_aborted संकेत बिट लाइन के संस्करण में सेट किया जाएगा। पेज में स्वयं xmax नंबर रहता है, लेकिन कोई भी इसे नहीं देखेगा।

 => SELECT * FROM t;

  id | s ----+----- 1 | FOO (1 row)

 => SELECT * FROM heap_page('t',0);

  ctid | state | xmin | xmax | t_ctid -------+--------+----------+----------+-------- (0,1) | normal | 3664 (c) | 3665 (a) | (0,1) (1 row)

अद्यतन

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

 => BEGIN; => UPDATE t SET s = 'BAR'; => SELECT txid_current();

  txid_current -------------- 3666 (1 row)

अनुरोध एक पंक्ति (नया संस्करण) उत्पन्न करता है:

 => SELECT * FROM t;

  id | s ----+----- 1 | BAR (1 row)

लेकिन पृष्ठ में हम दोनों संस्करण देखते हैं:

 => SELECT * FROM heap_page('t',0);

  ctid | state | xmin | xmax | t_ctid -------+--------+----------+-------+-------- (0,1) | normal | 3664 (c) | 3666 | (0,2) (0,2) | normal | 3666 | 0 (a) | (0,2) (2 rows)

दूरस्थ संस्करण xmax फ़ील्ड में वर्तमान लेनदेन संख्या के साथ चिह्नित है। इसके अलावा, यह मूल्य पुराने वाले पर लिखा गया है, क्योंकि पिछला लेनदेन रद्द कर दिया गया था। और xmax_aborted बिट रीसेट है, क्योंकि वर्तमान लेनदेन की स्थिति अभी भी अज्ञात है।

लाइन का पहला संस्करण अब दूसरे (t_ctid फ़ील्ड) को एक नए के रूप में संदर्भित करता है।

इंडेक्स पेज में एक दूसरी पॉइंटर और एक दूसरी लाइन दिखाई देती है, जो टेबल पेज के दूसरे वर्जन से लिंक होती है।

हटाने के साथ, स्ट्रिंग के पहले संस्करण में xmax मान एक संकेत है जो स्ट्रिंग लॉक है।

ठीक है, लेन-देन पूरा करें।

 => COMMIT;

सूचकांक

अब तक, हमने केवल सारणीबद्ध पृष्ठों के बारे में बात की है। और सूचकांकों के अंदर क्या होता है?

सूचकांक पृष्ठों में जानकारी विशेष प्रकार के सूचकांक पर अत्यधिक निर्भर है। और यहां तक कि एक प्रकार के सूचकांक में विभिन्न प्रकार के पृष्ठ हैं। उदाहरण के लिए, बी-ट्री में मेटाडेटा और "नियमित" पृष्ठों वाला एक पृष्ठ होता है।

हालांकि, एक पृष्ठ में आमतौर पर लाइनों और खुद को लाइनों के संकेत की एक सरणी होती है (बस एक तालिका पृष्ठ की तरह)। इसके अलावा, पृष्ठ के अंत में विशेष डेटा के लिए एक जगह है।

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

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

उसी समय, इंडेक्स पेज में हम दोनों संस्करणों के लिए संकेत पाते हैं, दोनों वर्तमान और पुराने:

 => SELECT itemoffset, ctid FROM bt_page_items('t_s_idx',1);

  itemoffset | ctid ------------+------- 1 | (0,2) 2 | (0,1) (2 rows)

आभासी लेनदेन

व्यवहार में, PostgreSQL लेनदेन संख्या को "सहेजने" के लिए अनुकूलन का उपयोग करता है।

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

इस संख्या को जारी करने के लिए सभी प्रक्रियाओं के बीच सिंक्रनाइज़ेशन की आवश्यकता नहीं होती है और इसलिए यह बहुत तेज है। जब हम ठंड के बारे में बात करते हैं तो हमें वर्चुअल नंबर का उपयोग करने का एक और कारण पता चल जाएगा।

डेटा स्नैपशॉट में वर्चुअल नंबर को ध्यान में नहीं रखा जाता है।

समय में विभिन्न बिंदुओं पर, पहले से ही उपयोग किए जा चुके अंकों के साथ वर्चुअल लेनदेन सिस्टम में अच्छी तरह से दिखाई दे सकता है, और यह सामान्य है। लेकिन ऐसी संख्या को डेटा पृष्ठों पर नहीं लिखा जा सकता है, क्योंकि अगली बार जब आप पृष्ठ तक पहुंचते हैं, तो यह सभी अर्थ खो सकता है।

 => BEGIN; => SELECT txid_current_if_assigned();

  txid_current_if_assigned -------------------------- (1 row)

यदि लेनदेन डेटा बदलना शुरू करता है, तो उसे एक वास्तविक, अद्वितीय लेनदेन नंबर दिया जाता है।

 => UPDATE accounts SET amount = amount - 1.00; => SELECT txid_current_if_assigned();

  txid_current_if_assigned -------------------------- 3667 (1 row)

 => COMMIT;

नेस्टेड लेनदेन

अंक बचाओ

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

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

नेस्टेड लेनदेन की अपनी संख्या (मुख्य लेनदेन संख्या से अधिक) होती है। नेस्टेड लेनदेन की स्थिति सामान्य रूप से XACT में दर्ज की जाती है, हालांकि, अंतिम स्थिति मुख्य लेनदेन की स्थिति पर निर्भर करती है: यदि इसे रद्द कर दिया जाता है, तो सभी नेस्टेड लेनदेन भी रद्द हो जाते हैं।

लेन-देन घोंसले के शिकार की जानकारी PGDATA / pg_subtrans निर्देशिका में फ़ाइलों में संग्रहीत है। फ़ाइल को उदाहरण के साझा स्मृति में बफ़र्स के माध्यम से एक्सेस किया जाता है, उसी तरह XACT बफ़र्स के रूप में आयोजित किया जाता है।

नेस्टेड लेनदेन और स्वायत्त लेनदेन को भ्रमित न करें। स्वायत्त लेनदेन किसी भी तरह से एक दूसरे पर निर्भर नहीं हैं, और नेस्टेड निर्भर हैं। सामान्य PostgreSQL में कोई स्वायत्त लेनदेन नहीं हैं, और, शायद, बेहतर के लिए: मामले में उनकी बहुत आवश्यकता है, बहुत कम ही, और अन्य DBMS में उनकी उपस्थिति दुरुपयोग को उत्तेजित करती है, जिससे हर कोई तब पीड़ित होता है।

तालिका साफ़ करें, लेन-देन शुरू करें और लाइन डालें:

 => TRUNCATE TABLE t; => BEGIN; => INSERT INTO t(s) VALUES ('FOO'); => SELECT txid_current();

  txid_current -------------- 3669 (1 row)

 => SELECT xmin, xmax, * FROM t;

  xmin | xmax | id | s ------+------+----+----- 3669 | 0 | 2 | FOO (1 row)

 => SELECT * FROM heap_page('t',0);

  ctid | state | xmin | xmax | t_ctid -------+--------+------+-------+-------- (0,1) | normal | 3669 | 0 (a) | (0,1) (1 row)

अब एक सेवपॉइंट लगाएं और दूसरी पंक्ति डालें।

 => SAVEPOINT sp; => INSERT INTO t(s) VALUES ('XYZ'); => SELECT txid_current();

  txid_current -------------- 3669 (1 row)

ध्यान दें कि txid_current () फ़ंक्शन मुख्य की संख्या लौटाता है, नेस्टेड, लेनदेन नहीं।

 => SELECT xmin, xmax, * FROM t;

  xmin | xmax | id | s ------+------+----+----- 3669 | 0 | 2 | FOO 3670 | 0 | 3 | XYZ (2 rows)

 => SELECT * FROM heap_page('t',0);

  ctid | state | xmin | xmax | t_ctid -------+--------+------+-------+-------- (0,1) | normal | 3669 | 0 (a) | (0,1) (0,2) | normal | 3670 | 0 (a) | (0,2) (2 rows)

हम सहेजने वाले बिंदु पर वापस जाते हैं और तीसरी पंक्ति सम्मिलित करते हैं।

 => ROLLBACK TO sp; => INSERT INTO t(s) VALUES ('BAR'); => SELECT xmin, xmax, * FROM t;

  xmin | xmax | id | s ------+------+----+----- 3669 | 0 | 2 | FOO 3671 | 0 | 4 | BAR (2 rows)

 => SELECT * FROM heap_page('t',0);

  ctid | state | xmin | xmax | t_ctid -------+--------+----------+-------+-------- (0,1) | normal | 3669 | 0 (a) | (0,1) (0,2) | normal | 3670 (a) | 0 (a) | (0,2) (0,3) | normal | 3671 | 0 (a) | (0,3) (3 rows)

पृष्ठ में, हम रद्द किए गए नेस्टेड लेनदेन द्वारा जोड़ी गई पंक्ति को देखना जारी रखते हैं।

हम परिवर्तनों को ठीक करते हैं।

 => COMMIT; => SELECT xmin, xmax, * FROM t;

  xmin | xmax | id | s ------+------+----+----- 3669 | 0 | 2 | FOO 3671 | 0 | 4 | BAR (2 rows)

 => SELECT * FROM heap_page('t',0);

  ctid | state | xmin | xmax | t_ctid -------+--------+----------+-------+-------- (0,1) | normal | 3669 (c) | 0 (a) | (0,1) (0,2) | normal | 3670 (a) | 0 (a) | (0,2) (0,3) | normal | 3671 (c) | 0 (a) | (0,3) (3 rows)

अब आप स्पष्ट रूप से देख सकते हैं कि प्रत्येक नेस्टेड लेनदेन की अपनी स्थिति है।

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

 => BEGIN;

 BEGIN

 => BEGIN;

 WARNING: there is already a transaction in progress BEGIN

 => COMMIT;

 COMMIT

 => COMMIT;

 WARNING: there is no transaction in progress COMMIT

त्रुटियों और संचालन की परमाणुता

यदि ऑपरेशन के दौरान कोई त्रुटि होती है तो क्या होता है? उदाहरण के लिए, इस तरह:

 => BEGIN; => SELECT * FROM t;

  id | s ----+----- 2 | FOO 4 | BAR (2 rows)

 => UPDATE t SET s = repeat('X', 1/(id-4));

 ERROR: division by zero

एक त्रुटि हुई है। अब लेन-देन निरस्त माना जाता है और इसमें एक भी ऑपरेशन की अनुमति नहीं है:

 => SELECT * FROM t;

 ERROR: current transaction is aborted, commands ignored until end of transaction block

और यहां तक कि अगर आप बदलाव करने की कोशिश करते हैं, तो PostgreSQL रद्द करने की रिपोर्ट करेगा:

 => COMMIT;

 ROLLBACK

असफलता के बाद मैं लेन-देन जारी क्यों नहीं रख सकता? तथ्य यह है कि एक त्रुटि हो सकती है ताकि हम परिवर्तनों के हिस्से तक पहुंच प्राप्त करें - लेनदेन की भी परमाणुता नहीं, लेकिन ऑपरेटर का उल्लंघन होगा। हमारे उदाहरण के अनुसार, जहां ऑपरेटर त्रुटि से पहले एक लाइन को अपडेट करने में कामयाब रहा:

 => SELECT * FROM heap_page('t',0);

  ctid | state | xmin | xmax | t_ctid -------+--------+----------+-------+-------- (0,1) | normal | 3669 (c) | 3672 | (0,4) (0,2) | normal | 3670 (a) | 0 (a) | (0,2) (0,3) | normal | 3671 (c) | 0 (a) | (0,3) (0,4) | normal | 3672 | 0 (a) | (0,4) (4 rows)

मुझे कहना होगा कि psql में एक मोड है जो अभी भी आपको विफलता के बाद लेन-देन जारी रखने की अनुमति देता है, जैसे कि त्रुटिपूर्ण ऑपरेटर की कार्रवाइयों को वापस लाया जाता है।

 => \set ON_ERROR_ROLLBACK on => BEGIN; => SELECT * FROM t;

  id | s ----+----- 2 | FOO 4 | BAR (2 rows)

 => UPDATE t SET s = repeat('X', 1/(id-4));

 ERROR: division by zero

 => SELECT * FROM t;

  id | s ----+----- 2 | FOO 4 | BAR (2 rows)

 => COMMIT;

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

जारी रखा जाए।

MVCC -3। पंक्ति संस्करण