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

हेडर

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

(सामान्य रूपमा, वास्तविकता झन् जटिल छ: काउन्टरको सीमित बिट क्षमताको कारण लेनदेन नम्बर सधैं बढ्न सक्दैन। तर हामी फ्रिजिङमा पुग्दा यी विवरणहरूलाई विस्तृत रूपमा हेर्नेछौं।)

जब पङ्क्ति बनाइन्छ, xmin लाई INSERT आदेश जारी गर्ने लेनदेन नम्बरमा सेट गरिन्छ, र xmax खाली छोडिन्छ।

जब पङ्क्ति मेटाइन्छ, हालको संस्करणको xmax मान DELETE प्रदर्शन गर्ने लेनदेनको संख्यासँग चिन्ह लगाइन्छ।

जब पङ्क्ति अपडेट आदेशद्वारा परिमार्जन गरिन्छ, दुई कार्यहरू वास्तवमा प्रदर्शन गरिन्छ: DELETE र INSERT। पङ्क्तिको हालको संस्करणले अद्यावधिक प्रदर्शन गरेको लेनदेनको संख्या बराबर xmax सेट गर्दछ। एउटै स्ट्रिङको नयाँ संस्करण त्यसपछि सिर्जना गरिन्छ; यसको xmin मान अघिल्लो संस्करणको xmax मानसँग मेल खान्छ।

xmin र xmax क्षेत्रहरू पङ्क्ति संस्करण हेडरमा समावेश छन्। यी क्षेत्रहरू बाहेक, हेडरले अन्य समावेश गर्दछ, उदाहरणका लागि:

• infomask यस संस्करणको गुणहरू परिभाषित गर्ने बिटहरूको श्रृंखला हो। तिनीहरूमध्ये धेरै छन्; हामी बिस्तारै मुख्य विचार गर्नेछौं।
• ctid उही लाइनको अर्को, नयाँ संस्करणको लिङ्क हो। स्ट्रिङको सबैभन्दा नयाँ, सबैभन्दा हालको संस्करणको लागि, ctid ले यो संस्करणलाई बुझाउँछ। संख्यामा फारम (x,y) छ, जहाँ x पृष्ठ नम्बर हो, y array मा अनुक्रमणिका नम्बर हो।
• नल बिटम्याप - दिइएको संस्करणको ती स्तम्भहरूलाई चिन्ह लगाउँछ जसमा शून्य मान (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)

पृष्ठको सामग्रीहरू हेरौं। 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: (पृष्ठ नम्बर, अनुक्रमणिका नम्बर) जस्तै देखिनको लागि अनुक्रमणिका नम्बरमा शून्य थपियो।
• lp_flags सूचकको अवस्था बुझियो। यहाँ यो "सामान्य" हो - यसको मतलब यो हो कि सूचकले वास्तवमा स्ट्रिङको संस्करणलाई जनाउँछ। हामी पछि अन्य अर्थहरू हेर्नेछौं।
• सबै जानकारी बिटहरू मध्ये, अहिलेसम्म दुई जोडी मात्र पहिचान गरिएको छ। xmin_committed र xmin_aborted बिटहरूले लेनदेन नम्बर xmin प्रतिबद्ध छ कि छैन भनेर संकेत गर्दछ (अबर्ट गरिएको)। दुई समान बिट्स लेनदेन नम्बर xmax लाई बुझाउँछ।

हामी के देख्छौं? जब तपाइँ पङ्क्ति सम्मिलित गर्नुहुन्छ, तालिका पृष्ठमा अनुक्रमणिका नम्बर 1 देखा पर्नेछ, पङ्क्तिको पहिलो र एकमात्र संस्करणलाई संकेत गर्दै।

स्ट्रिङ संस्करणमा, xmin फिल्ड हालको लेनदेन नम्बरले भरिएको छ। लेनदेन अझै सक्रिय छ, त्यसैले दुबै xmin_committed र xmin_aborted बिटहरू सेट गरिएका छैनन्।

पङ्क्ति संस्करण ctid फिल्डले उही पङ्क्तिलाई जनाउँछ। यसको मतलब नयाँ संस्करण अवस्थित छैन।

xmax फिल्ड डमी नम्बर ० ले भरिएको छ किनभने पङ्क्तिको यो संस्करण मेटाइएको छैन र हालको छ। लेनदेनले यो नम्बरमा ध्यान दिनेछैन किनभने 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 पहुँच गर्नु पर्दैन।

किन यी बिट्स लेनदेन आफैंले सम्मिलित गर्दैनन्? जब सम्मिलित हुन्छ, लेनदेन सफल हुन्छ कि छैन थाहा छैन। र प्रतिबद्धताको क्षणमा, यो अब स्पष्ट छैन कुन लाइनहरूमा कुन पृष्ठहरू परिवर्तन गरियो। त्यहाँ त्यस्ता पृष्ठहरू धेरै हुन सक्छन्, र तिनीहरूलाई सम्झना लाभदायक छैन। थप रूपमा, केही पृष्ठहरू बफर क्यासबाट डिस्कमा हटाउन सकिन्छ; बिट्स परिवर्तन गर्न तिनीहरूलाई पुन: पढ्नाले कमिटलाई महत्त्वपूर्ण रूपमा ढिलो गर्नेछ।

बचतको नकारात्मक पक्ष यो हो कि परिवर्तन पछि, कुनै पनि लेनदेन (एक साधारण पढ्ने प्रदर्शन - SELECT) ले बफर क्यासमा डेटा पृष्ठहरू परिवर्तन गर्न सुरु गर्न सक्छ।

त्यसोभए, परिवर्तन ठीक गरौं।

=> 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 पूरा हुनको लागि पर्खन बाध्य हुनेछ। हामी पछि अवरुद्ध बारे थप कुरा गर्नेछौं। अहिलेको लागि, हामी पङ्क्ति लकहरूको संख्या असीमित छ भनेर ध्यान दिन्छौं। तिनीहरूले RAM मा ठाउँ लिन सक्दैनन् र प्रणाली प्रदर्शन तिनीहरूको संख्या ग्रस्त छैन। साँचो, "लामो" लेनदेनका अन्य बेफाइदाहरू छन्, तर पछि थप।

लाइन मेटौं।

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

अनुक्रमणिका

अहिलेसम्म हामीले टेबलका पानाहरूको बारेमा मात्र कुरा गरेका छौं। अनुक्रमणिका भित्र के हुन्छ?

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

यद्यपि, पृष्ठमा प्राय: पङ्क्तिहरू र पङ्क्तिहरू आफैंमा पोइन्टर्सको एर्रे हुन्छ (टेबल पृष्ठ जस्तै)। थप रूपमा, पृष्ठको अन्त्यमा विशेष डाटाको लागि ठाउँ छ।

अनुक्रमणिकामा पङ्क्तिहरू पनि अनुक्रमणिकाको प्रकारको आधारमा धेरै फरक संरचनाहरू हुन सक्छन्। उदाहरणका लागि, बी-ट्रीको लागि, पात पृष्ठहरूसँग सम्बन्धित पङ्क्तिहरूमा अनुक्रमणिका कुञ्जी मान र सम्बन्धित तालिका पङ्क्तिको सन्दर्भ (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;

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

अंकहरू बचत गर्नुहोस्

SQL मा परिभाषित अंक बचत गर्नुहोस् (savepoint), जसले तपाईंलाई पूर्ण रूपमा अवरोध नगरी लेनदेनको अंश रद्द गर्न अनुमति दिन्छ। तर यो माथिको रेखाचित्रमा फिट हुँदैन, किनकि लेनदेनमा सबै परिवर्तनहरूको लागि समान स्थिति छ, र भौतिक रूपमा कुनै डेटा फिर्ता हुँदैन।

यो कार्यक्षमता लागू गर्न, बचत पोइन्टको साथ एक लेनदेन धेरै अलग मा विभाजित छ नेस्टेड लेनदेन (उपलेनदेन), जसको स्थिति छुट्टै व्यवस्थापन गर्न सकिन्छ।

नेस्टेड लेनदेनको आफ्नै नम्बर हुन्छ (मुख्य लेनदेनको संख्या भन्दा बढी)। नेस्टेड लेनदेनको स्थिति 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 मा स्पष्ट रूपमा प्रयोग गर्न सकिँदैन, अर्थात्, तपाईंले हालको एक पूरा नगरी नयाँ कारोबार सुरु गर्न सक्नुहुन्न। बचत पोइन्टहरू प्रयोग गर्दा, साथै PL/pgSQL अपवादहरू ह्यान्डल गर्दा र अन्य धेरै विदेशी केसहरूमा यो मेकानिज्म स्पष्ट रूपमा सक्रिय हुन्छ।

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