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

शीर्षक

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

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

जब एक पंक्ति बनाई जाती है, तो xmin को उस लेनदेन संख्या पर सेट किया जाता है जिसने INSERT कमांड जारी किया था, और xmax को खाली छोड़ दिया गया है।

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

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

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

• इन्फोमास्क बिट्स की एक श्रृंखला है जो इस संस्करण के गुणों को परिभाषित करती है। उनमें से बहुत सारे हैं; हम धीरे-धीरे मुख्य बातों पर विचार करेंगे।
• 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 फ़ील्ड उसी पंक्ति को संदर्भित करता है। इसका मतलब यह है कि कोई नया संस्करण मौजूद नहीं है.

एक्समैक्स फ़ील्ड एक डमी नंबर 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 में कोई लेनदेन प्रतिबद्ध होता है, तो इस लेनदेन के लिए प्रतिबद्ध बिट सेट किया जाता है। और कमिटिंग के दौरान यही सब होता है (हालाँकि हम अभी प्री-रिकॉर्डिंग लॉग के बारे में बात नहीं कर रहे हैं)।

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

1. क्या xmin लेनदेन पूरा हो गया है? यदि नहीं, तो स्ट्रिंग का निर्मित संस्करण दिखाई नहीं देना चाहिए।
   यह जाँच किसी अन्य संरचना को देखकर की जाती है, जो उदाहरण की साझा मेमोरी में स्थित होती है और इसे ProcArray कहा जाता है। इसमें सभी सक्रिय प्रक्रियाओं की एक सूची है, और प्रत्येक के लिए उसके वर्तमान (सक्रिय) लेनदेन की संख्या इंगित की गई है।
2. अगर पूरा हुआ तो कैसे - कमिट करके या रद्द करके? यदि रद्द किया गया है, तो पंक्ति संस्करण भी दिखाई नहीं देना चाहिए।
   XACT बिल्कुल इसी के लिए है। लेकिन, हालाँकि XACT के अंतिम पृष्ठ RAM में बफ़र्स में संग्रहीत हैं, फिर भी हर बार XACT की जाँच करना महंगा है। इसलिए, एक बार लेन-देन की स्थिति निर्धारित हो जाने के बाद, इसे स्ट्रिंग संस्करण के xmin_committed और xmin_aborted बिट्स पर लिखा जाता है। यदि इनमें से एक बिट सेट किया गया है, तो लेनदेन xmin की स्थिति ज्ञात मानी जाती है और अगले लेनदेन को 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;
=> SELECT * FROM heap_page('t',0);

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

जब पेज एक्सेस किया जाएगा, तो स्थिति की जांच की जाएगी और xmax_aborted संकेत बिट को पंक्ति संस्करण पर सेट किया जाएगा। एक्समैक्स नंबर पेज पर ही रहता है, लेकिन कोई उस पर नजर नहीं डालेगा।

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

सूचकांक

अभी तक हमने केवल टेबल पेजों के बारे में बात की है। इंडेक्स के अंदर क्या होता है?

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

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

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

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

जारी रहेगा।

स्रोत: www.habr.com