खैर, हमने पहले ही अलगाव पर चर्चा की है और निम्न-स्तरीय डेटा संरचना के बारे में एक विषयांतर किया है। और हम अंत में सबसे आकर्षक चीज़ तक पहुँच गए हैं, वह है, पंक्ति संस्करण (ट्यूपल्स)।

टपल शीर्षक

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

(हमेशा की तरह, वास्तव में यह अधिक जटिल है: लेन-देन आईडी हमेशा काउंटर की एक सीमित बिट गहराई के कारण वृद्धि नहीं कर सकती है। लेकिन हम इस बारे में अधिक जानकारी तब पाएंगे जब हमारी चर्चा ठंड तक पहुंच जाएगी।)

जब एक पंक्ति बनाई जाती है, तो xmin का मूल्य INSERT कमांड निष्पादित करने वाले लेनदेन की आईडी के बराबर सेट होता है, जबकि xmax में भरा नहीं जाता है।

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

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

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

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

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

सम्मिलित करें

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

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

 => 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)

पेज की सामग्री पर नजर डालते हैं। "Pageinspect" एक्सटेंशन से 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 जैसा t_ctid : (पृष्ठ संख्या, सूचक संख्या)।
lp_flags पॉइंटर की स्थिति की व्याख्या की। यह यहां "सामान्य" है, जिसका अर्थ है कि सूचक वास्तव में एक पंक्ति संस्करण का संदर्भ देता है। हम बाद में अन्य मूल्यों पर चर्चा करेंगे।
सभी सूचना बिट्स में से, हमने अब तक केवल दो जोड़े चुने हैं। xmin_committed और xmin_aborted बिट्स दिखाते हैं कि ID xmin साथ लेन-देन प्रतिबद्ध है (वापस लुढ़का)। समान बिट्स की एक जोड़ी आईडी xmax साथ लेनदेन से संबंधित है।

हम क्या निरीक्षण करते हैं? जब एक पंक्ति डाली जाती है, तो तालिका पृष्ठ में एक संकेतक दिखाई देता है जिसमें नंबर 1 होता है और पंक्ति के पहले और एकमात्र संस्करण को संदर्भित करता है।

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

पंक्ति संस्करण का 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 निर्देशिका में फ़ाइलें। प्रत्येक लेनदेन के लिए इन फ़ाइलों में दो बिट्स आवंटित किए गए हैं - "प्रतिबद्ध" और "निरस्त" - ठीक उसी तरह जैसे टुपेल हैडर में होता है। यह जानकारी केवल सुविधा के लिए कई फाइलों में फैली हुई है; जब हम ठंड पर चर्चा करेंगे तो हम इस पर वापस लौट आएंगे। PostgreSQL इन फ़ाइलों को पेज के साथ काम करता है, अन्य सभी के साथ।

इसलिए, जब कोई लेनदेन किया जाता है, तो XACT में इस लेनदेन के लिए "प्रतिबद्ध" बिट सेट होता है। और यह सब तब होता है जब लेनदेन प्रतिबद्ध होता है (हालांकि हम अभी तक राइट-फॉरवर्ड लॉग का उल्लेख नहीं करते हैं)।

जब कुछ अन्य लेन-देन तालिका पृष्ठ पर पहुंचते हैं, जिसे हम अभी देख रहे थे, तो पूर्व को कुछ सवालों के जवाब देने होंगे।

क्या लेनदेन xmin पूरा हुआ था? यदि नहीं, तो बनाई गई टपल दिखाई नहीं देनी चाहिए।
यह एक अन्य संरचना को देखकर जांचा जाता है, जो कि इंस्टा की साझा मेमोरी में स्थित है और जिसे 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 फ़ील्ड को लिखा गया है, लेकिन सूचना बिट्स 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; => 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 बिट रीसेट है क्योंकि वर्तमान लेनदेन की स्थिति अभी तक अज्ञात है।

पंक्ति का पहला संस्करण अब दूसरे को संदर्भित कर रहा है, एक नए के रूप में।

इंडेक्स पेज में अब दूसरी पॉइंटर और दूसरी पंक्ति है, जो टेबल पेज में दूसरे संस्करण का संदर्भ देती है।

हटाने के लिए उसी तरह, पहले संस्करण में xmax का मान इंगित करता है कि पंक्ति लॉक है।

अंत में, हम लेन-देन करते हैं।

 => COMMIT;

इंडेक्स

हम अब तक केवल तालिका पृष्ठों के बारे में बात कर रहे थे। लेकिन इंडेक्स के अंदर क्या होता है?

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

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

सूचकांक में पंक्तियों में सूचकांक प्रकार के आधार पर अलग-अलग संरचनाएं भी हो सकती हैं। उदाहरण के लिए: एक बी-ट्री में, पत्ता पन्नों के लिए उपयुक्त पंक्तियों में अनुक्रमण कुंजी और एक संदर्भ ( ctid ) का 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;

Subtransactions

Savepoints

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

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

Subtrabsactions की अपनी आईडी (मुख्य लेनदेन की आईडी से अधिक) होती है। सबट्रांसपोर्ट की स्थिति एक सामान्य तरीके से 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 स्थापित करते हैं और दूसरी पंक्ति सम्मिलित करते हैं।

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

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

ध्यान दें कि txid_current फ़ंक्शन मुख्य लेन-देन की आईडी को 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 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)

अब यह स्पष्ट रूप से देखा गया है कि प्रत्येक घटाव की अपनी स्थिति है।

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

 => 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 वास्तव में प्रत्येक कमांड से पहले एक अंतर्निहित बचत बिंदु स्थापित करता है और विफलता की स्थिति में इसे रोलबैक करता है। इस मोड का उपयोग डिफ़ॉल्ट रूप से सेवपॉइंट स्थापित करने के बाद से नहीं किया जाता है (यहां तक कि उनके लिए रोलबैक के बिना) एक महत्वपूर्ण ओवरहेड पर जोर देता है।

पर पढ़ें ।

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