म्हणून, आम्ही संबंधित समस्यांचा विचार केला आहे इन्सुलेशन, आणि बद्दल माघार घेतली निम्न स्तरावर डेटा आयोजित करणे. आणि शेवटी आम्ही सर्वात मनोरंजक भागावर पोहोचलो - स्ट्रिंग आवृत्त्या.

शीर्षलेख

आम्ही आधीच म्हटल्याप्रमाणे, प्रत्येक पंक्ती डेटाबेसमधील अनेक आवृत्त्यांमध्ये एकाच वेळी अस्तित्वात असू शकते. एक आवृत्ती दुसर्‍यापेक्षा कशी तरी वेगळी असणे आवश्यक आहे. या उद्देशासाठी, प्रत्येक आवृत्तीचे दोन गुण आहेत जे या आवृत्तीच्या क्रियेची "वेळ" निर्धारित करतात (xmin आणि xmax). अवतरणांमध्ये - कारण ती वेळ नाही जी वापरली जाते, परंतु विशेष वाढणारी काउंटर. आणि हा काउंटर म्हणजे व्यवहार क्रमांक.

(नेहमीप्रमाणे, वास्तविकता अधिक क्लिष्ट आहे: काउंटरच्या मर्यादित बिट क्षमतेमुळे व्यवहाराची संख्या नेहमीच वाढू शकत नाही. परंतु जेव्हा आपण गोठवू तेव्हा आम्ही हे तपशील तपशीलवार पाहू.)

एक पंक्ती तयार केल्यावर, INSERT आदेश जारी केलेल्या व्यवहार क्रमांकावर xmin सेट केला जातो आणि xmax रिक्त ठेवला जातो.

जेव्हा एखादी पंक्ती हटविली जाते, तेव्हा वर्तमान आवृत्तीचे xmax मूल्य DELETE केलेल्या व्यवहाराच्या संख्येसह चिन्हांकित केले जाते.

अद्ययावत कमांडद्वारे पंक्ती सुधारली जाते तेव्हा, दोन ऑपरेशन्स प्रत्यक्षात केल्या जातात: हटवा आणि घाला. पंक्तीची वर्तमान आवृत्ती अपडेट केलेल्या व्यवहाराच्या संख्येइतकी xmax सेट करते. नंतर त्याच स्ट्रिंगची नवीन आवृत्ती तयार केली जाते; त्याचे xmin मूल्य मागील आवृत्तीच्या xmax मूल्याशी जुळते.

xmin आणि xmax फील्ड पंक्ती आवृत्ती शीर्षलेख मध्ये समाविष्ट आहेत. या फील्ड व्यतिरिक्त, शीर्षलेखात इतर समाविष्ट आहेत, उदाहरणार्थ:

इन्फोमास्क ही बिट्सची मालिका आहे जी या आवृत्तीचे गुणधर्म परिभाषित करते. त्यापैकी बरेच आहेत; आम्ही हळूहळू मुख्य गोष्टींचा विचार करू.
ctid ही त्याच ओळीच्या पुढील, नवीन आवृत्तीची लिंक आहे. स्ट्रिंगच्या नवीनतम, सर्वात वर्तमान आवृत्तीसाठी, ctid या आवृत्तीचाच संदर्भ देते. नंबरमध्ये फॉर्म (x,y) आहे, जेथे x हा पृष्ठ क्रमांक आहे, y हा अॅरेमधील अनुक्रमणिका क्रमांक आहे.
null bitmap - दिलेल्या आवृत्तीच्या त्या स्तंभांना चिन्हांकित करते ज्यात शून्य मूल्य (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 मधील heap हा शब्द टेबल्सचा संदर्भ देतो. हा शब्दाचा आणखी एक विचित्र वापर आहे - एक ढीग ज्ञात आहे डेटा संरचना, ज्याचे टेबलशी काहीही साम्य नाही. येथे हा शब्द ऑर्डर केलेल्या निर्देशांकाच्या विरूद्ध "सर्व काही एकत्र टाकले आहे" या अर्थाने वापरला आहे.

फंक्शन डेटा "जसा आहे तसा" दर्शविते, जे समजण्यास कठीण आहे. हे शोधण्यासाठी, आम्ही माहितीचा फक्त काही भाग सोडू आणि त्याचा उलगडा करू:

=> 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 मध्ये व्यवहार केला जातो, तेव्हा या व्यवहारासाठी वचनबद्ध बिट सेट केला जातो. आणि हे सर्व कमिटिंग दरम्यान घडते (जरी आम्ही अद्याप प्री-रेकॉर्डिंग लॉगबद्दल बोलत नाही).

आम्ही नुकतेच पाहिलेल्या टेबल पेजवर दुसरा व्यवहार प्रवेश करतो तेव्हा त्याला अनेक प्रश्नांची उत्तरे द्यावी लागतील.

xmin व्यवहार पूर्ण झाला आहे का? नसल्यास, स्ट्रिंगची तयार केलेली आवृत्ती दृश्यमान नसावी.
ही तपासणी दुसरी रचना पाहून केली जाते, जी उदाहरणाच्या सामायिक मेमरीमध्ये असते आणि त्याला ProcArray म्हणतात. यात सर्व सक्रिय प्रक्रियांची सूची आहे आणि प्रत्येकासाठी त्याच्या वर्तमान (सक्रिय) व्यवहाराची संख्या दर्शविली आहे.
पूर्ण झाले, तर कसे - कमिट करून किंवा रद्द करून? रद्द केल्यास, पंक्ती आवृत्ती देखील दृश्यमान नसावी.
हेच 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;

निर्देशांक

आतापर्यंत आपण फक्त टेबलच्या पानांबद्दल बोललो आहोत. निर्देशांकांमध्ये काय होते?

अनुक्रमणिका पृष्ठांमधील माहिती विशिष्ट प्रकारच्या निर्देशांकावर अवलंबून मोठ्या प्रमाणात बदलते. आणि अगदी एका प्रकारच्या इंडेक्समध्ये वेगवेगळ्या प्रकारची पृष्ठे असतात. उदाहरणार्थ, बी-ट्रीमध्ये मेटाडेटा पृष्ठ आणि "नियमित" पृष्ठे असतात.

तथापि, पृष्ठामध्ये सामान्यतः पंक्ती आणि पंक्तींकडे पॉइंटरची अ‍ॅरे असते (फक्त सारणी पृष्ठाप्रमाणे). याव्यतिरिक्त, पृष्ठाच्या शेवटी विशेष डेटासाठी जागा आहे.

अनुक्रमणिकेच्या पंक्तींमध्ये निर्देशांकाच्या प्रकारानुसार खूप भिन्न रचना देखील असू शकतात. उदाहरणार्थ, बी-ट्रीसाठी, पानांच्या पानांशी संबंधित पंक्तींमध्ये अनुक्रमणिका की मूल्य आणि संबंधित सारणी पंक्तीचा संदर्भ (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 मध्ये परिभाषित गुण जतन करा (सेव्हपॉइंट), जे तुम्हाला व्यवहाराचा भाग पूर्णपणे व्यत्यय न आणता रद्द करण्याची परवानगी देते. परंतु हे वरील आकृतीमध्ये बसत नाही, कारण व्यवहारात सर्व बदलांसाठी समान स्थिती आहे आणि भौतिकदृष्ट्या कोणताही डेटा परत केला जात नाही.

ही कार्यक्षमता अंमलात आणण्यासाठी, सेव्हपॉईंटसह व्यवहार अनेक विभक्तांमध्ये विभागला जातो नेस्टेड व्यवहार (उपव्यवहार), ज्याची स्थिती स्वतंत्रपणे व्यवस्थापित केली जाऊ शकते.

नेस्टेड व्यवहारांची स्वतःची संख्या असते (मुख्य व्यवहाराच्या संख्येपेक्षा जास्त). नेस्टेड व्यवहारांची स्थिती 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

MVCC-3. स्ट्रिंग आवृत्त्या