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

फिर हमने विभिन्न प्रकार की सफाई की जांच की: इंट्रा-पेज (HOT-अपडेट के साथ), नियमित और स्वचालित ।

और इस चक्र के अंतिम विषय के लिए मिला। आज हम लेनदेन आईडी रैपराउंड और फ्रीजिंग की समस्या के बारे में बात करेंगे।

लेन-देन काउंटर अतिप्रवाह

PostgreSQL में लेनदेन संख्या के लिए 32 बिट्स आबंटित हैं। यह एक काफी बड़ी संख्या (लगभग 4 बिलियन) है, लेकिन सर्वर के सक्रिय संचालन के साथ, यह अच्छी तरह से समाप्त हो सकता है। उदाहरण के लिए, प्रति सेकंड 1000 लेन-देन के लोड पर, यह केवल डेढ़ महीने और निरंतर संचालन के बाद होगा।

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



ऐसा क्यों है कि लेनदेन संख्या के लिए 64 बिट्स आवंटित नहीं किए गए हैं - क्योंकि इससे समस्या पूरी तरह से समाप्त हो जाएगी? तथ्य यह है कि (जैसा कि पहले चर्चा की गई है) लाइन के प्रत्येक संस्करण के हेडर में दो लेनदेन संख्या - एक्समिन और एक्समैक्स संग्रहीत हैं। हेडर पहले से ही काफी बड़ा है, कम से कम 23 बाइट्स, और बिट गहराई में वृद्धि से इसके 8 बाइट्स में वृद्धि होगी। यह बिल्कुल कोई रास्ता नहीं है।

हमारी कंपनी के उत्पाद में 64-बिट लेनदेन नंबर लागू होते हैं, प्रो एंटरप्राइज को पोस्टग्रेज करते हैं, लेकिन वे पूरी तरह से वहां भी ईमानदार नहीं हैं: xmin और xmax 32-bit रहते हैं, और पृष्ठ की हेडिंग में एक आम तौर पर "एक युग की शुरुआत" पेज चौड़ा होता है।

क्या करें? एक रैखिक आरेख के बजाय, सभी लेनदेन संख्याओं को लूप किया जाता है। किसी भी लेन-देन के लिए, "वामावर्त" संख्याओं में से आधे को अतीत से संबंधित माना जाता है, और भविष्य के लिए आधा "दक्षिणावर्त"।

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



लेकिन ऐसे लूपेड सर्किट में, एक अप्रिय स्थिति उत्पन्न होती है। एक लेनदेन जो दूर के अतीत में था (आंकड़ा 1 में लेनदेन), थोड़ी देर के बाद सर्कल के उस आधे हिस्से में होगा जो भविष्य से संबंधित है। यह, ज़ाहिर है, दृश्यता के नियमों का उल्लंघन करता है और समस्याओं को जन्म देगा - लेनदेन 1 द्वारा किए गए परिवर्तन बस दृश्य से गायब हो जाएंगे।

संस्करण बर्फ़ीली और दृश्यता नियम

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



जमे हुए के रूप में लेनदेन संख्या xmin को चिह्नित करने के लिए, दोनों संकेत बिट्स एक ही समय में सेट किए जाते हैं - कमिट बिट और रद्द बिट।

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

प्रयोगों के लिए, एक तालिका बनाएं। हम इसके लिए न्यूनतम भराव निर्धारित करते हैं ताकि प्रत्येक पृष्ठ पर केवल दो लाइनें फिट हों - इसलिए हमारे लिए यह देखना अधिक सुविधाजनक होगा कि क्या हो रहा है। और सफाई के समय को नियंत्रित करने के लिए स्वचालन को बंद कर दें।

=> CREATE TABLE tfreeze( id integer, s char(300) ) WITH (fillfactor = 10, autovacuum_enabled = off); 

हमने पहले ही फ़ंक्शन के कई वेरिएंट बनाए हैं, जो पेजिन्सपेक्ट एक्सटेंशन का उपयोग करते हुए, पेज पर मौजूद लाइनों का संस्करण दिखाया गया है। अब हम एक ही फ़ंक्शन का दूसरा संस्करण बनाएंगे: अब यह एक ही बार में कई पेज प्रदर्शित करेगा और xmin लेनदेन की आयु दिखाएगा (इसके लिए सिस्टम फ़ंक्शन आयु का उपयोग किया जाता है):

 => CREATE FUNCTION heap_page(relname text, pageno_from integer, pageno_to integer) RETURNS TABLE(ctid tid, state text, xmin text, xmin_age integer, 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+512) = 256+512 THEN ' (f)' WHEN (t_infomask & 256) > 0 THEN ' (c)' WHEN (t_infomask & 512) > 0 THEN ' (a)' ELSE '' END AS xmin, age(t_xmin) xmin_age, t_xmax || CASE WHEN (t_infomask & 1024) > 0 THEN ' (c)' WHEN (t_infomask & 2048) > 0 THEN ' (a)' ELSE '' END AS xmax, t_ctid FROM generate_series(pageno_from, pageno_to) p(pageno), heap_page_items(get_raw_page(relname, pageno)) ORDER BY pageno, lp; $$ LANGUAGE SQL; 

कृपया ध्यान दें कि ठंड का संकेत (जो हम कोष्ठक में अक्षर f के साथ दिखाते हैं) प्रतिबद्ध और निरस्त संकेतों की एक साथ स्थापना द्वारा निर्धारित किया जाता है। कई स्रोतों (प्रलेखन सहित) में विशेष संख्या फ्रोजनट्रांसआईड = 2 का उल्लेख है, जो जमे हुए लेनदेन को चिह्नित करता है। ऐसी प्रणाली संस्करण 9.4 तक संचालित होती है, लेकिन अब इसे टूलटिप बिट्स द्वारा बदल दिया गया है - यह आपको लाइन संस्करण में मूल लेनदेन संख्या को बचाने की अनुमति देता है, जो समर्थन और डीबगिंग उद्देश्यों के लिए सुविधाजनक है। हालांकि, नंबर 2 के साथ लेनदेन अभी भी पुराने सिस्टम में हो सकता है, यहां तक ​​कि नवीनतम संस्करणों में भी अपग्रेड किया जा सकता है।

हमें pg_visibility एक्सटेंशन की भी आवश्यकता है, जो आपको दृश्यता मानचित्र में देखने की अनुमति देता है:

 => CREATE EXTENSION pg_visibility; 

PostgreSQL 9.6 से पहले, दृश्यता मानचित्र में प्रति पृष्ठ एक बिट शामिल था; यह उन स्ट्रिंग के केवल "काफी पुराने" संस्करणों वाले पृष्ठों को चिह्नित करता है जो पहले से ही सभी चित्रों में दिखाई देने की गारंटी हैं। यहां विचार यह है कि यदि पृष्ठ दृश्यता मानचित्र में चिह्नित है, तो लाइनों के इसके संस्करण के लिए आपको दृश्यता नियमों की जांच करने की आवश्यकता नहीं है।

संस्करण 9.6 से शुरू होकर, एक फ़्रीज़ मैप एक ही परत में जोड़ा गया था - प्रति पृष्ठ एक और बिट। फ़्रीज़ मैप उन पृष्ठों को चिह्नित करता है जिन पर पंक्तियों के सभी संस्करण जमे हुए हैं।

हम तालिका में कई पंक्तियाँ सम्मिलित करते हैं और दृश्यता मानचित्र बनाने के लिए तुरंत सफाई करते हैं:

 => INSERT INTO tfreeze(id, s) SELECT g.id, 'FOO' FROM generate_series(1,100) g(id); => VACUUM tfreeze; 

और हम देखते हैं कि दोनों पृष्ठ अब दृश्यता मानचित्र (all_v अदृश्य) में चिह्नित हैं, लेकिन अभी तक जमे हुए नहीं हैं (all_frozen):

 => SELECT * FROM generate_series(0,1) g(blkno), pg_visibility_map('tfreeze',g.blkno) ORDER BY g.blkno; 

  blkno | all_visible | all_frozen -------+-------------+------------ 0 | t | f 1 | t | f (2 rows) 

लेन-देन की आयु जिसने पंक्तियों को बनाया (xmin_age) 1 है - यह अंतिम लेनदेन है जो सिस्टम पर किया गया था:

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

  ctid | state | xmin | xmin_age | xmax | t_ctid -------+--------+---------+----------+-------+-------- (0,1) | normal | 697 (c) | 1 | 0 (a) | (0,1) (0,2) | normal | 697 (c) | 1 | 0 (a) | (0,2) (1,1) | normal | 697 (c) | 1 | 0 (a) | (1,1) (1,2) | normal | 697 (c) | 1 | 0 (a) | (1,2) (4 rows) 

ठंड के लिए न्यूनतम आयु

तीन मुख्य पैरामीटर ठंड को नियंत्रित करते हैं, और हम उन्हें बदले में विचार करेंगे।

चलो वैक्यूम_फ्रीज_मिन_जेज से शुरू करते हैं, जो न्यूनतम लेन-देन की उम्र xmin को परिभाषित करता है, जिस पर स्ट्रिंग संस्करण जमे हुए हो सकते हैं। यह मान जितना छोटा होगा, उतनी ही अनावश्यक ओवरहेड लागतें बदल सकती हैं: यदि हम "हॉट" के साथ काम कर रहे हैं, तो डेटा को सक्रिय रूप से बदल रहा है, तो अधिक से अधिक नए संस्करण बिना किसी लाभ के गायब हो जाएंगे। इस मामले में, इंतजार करना बेहतर है।

इस पैरामीटर के लिए डिफ़ॉल्ट मान सेट करता है कि लेनदेन 50 मिलियन के बाद फ्रीज होना शुरू हो जाता है जब से वे दिखाई देते हैं:

 => SHOW vacuum_freeze_min_age; 

  vacuum_freeze_min_age ----------------------- 50000000 (1 row) 

यह देखने के लिए कि ठंड कैसे होती है, हम इस पैरामीटर के मूल्य को एकता में कम कर देते हैं।

 => ALTER SYSTEM SET vacuum_freeze_min_age = 1; => SELECT pg_reload_conf(); 

और हम शून्य पृष्ठ पर एक पंक्ति को अपडेट करेंगे। नया संस्करण छोटे फिलफैक्टर मान के कारण उसी पृष्ठ पर पहुंच जाएगा।

 => UPDATE tfreeze SET s = 'BAR' WHERE id = 1; 

यहाँ अब हम डेटा पृष्ठों में देखते हैं:

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

  ctid | state | xmin | xmin_age | xmax | t_ctid -------+--------+---------+----------+-------+-------- (0,1) | normal | 697 (c) | 2 | 698 | (0,3) (0,2) | normal | 697 (c) | 2 | 0 (a) | (0,2) (0,3) | normal | 698 | 1 | 0 (a) | (0,3) (1,1) | normal | 697 (c) | 2 | 0 (a) | (1,1) (1,2) | normal | 697 (c) | 2 | 0 (a) | (1,2) (5 rows) 

अब वैक्यूम_फ्रीज_मिन_एज = 1 से पुरानी लाइनों को फ्रीज किया जाना है। लेकिन ध्यान दें कि दृश्यता मानचित्र में शून्य रेखा चिह्नित नहीं है (बिट को UPDATE कमांड द्वारा रीसेट किया गया था, जिससे पृष्ठ बदल गया था), और पहले वाला चेक बना रहता है:

 => SELECT * FROM generate_series(0,1) g(blkno), pg_visibility_map('tfreeze',g.blkno) ORDER BY g.blkno; 

  blkno | all_visible | all_frozen -------+-------------+------------ 0 | f | f 1 | t | f (2 rows) 

हमने पहले ही कहा है कि सफाई केवल उन पृष्ठों को स्कैन करती है जो दृश्यता मानचित्र में चिह्नित नहीं हैं। और इसलिए यह पता चला है:

 => VACUUM tfreeze; => SELECT * FROM heap_page('tfreeze',0,1); 

  ctid | state | xmin | xmin_age | xmax | t_ctid -------+---------------+---------+----------+-------+-------- (0,1) | redirect to 3 | | | | (0,2) | normal | 697 (f) | 2 | 0 (a) | (0,2) (0,3) | normal | 698 (c) | 1 | 0 (a) | (0,3) (1,1) | normal | 697 (c) | 2 | 0 (a) | (1,1) (1,2) | normal | 697 (c) | 2 | 0 (a) | (1,2) (5 rows) 

शून्य पृष्ठ पर, एक संस्करण जमे हुए है, लेकिन पहले पृष्ठ ने बिल्कुल सफाई पर विचार नहीं किया। इस प्रकार, यदि पृष्ठ पर केवल वर्तमान संस्करण बचे हैं, तो सफाई ऐसे पृष्ठ पर नहीं आएगी और उन्हें फ्रीज नहीं करेगी।

 => SELECT * FROM generate_series(0,1) g(blkno), pg_visibility_map('tfreeze',g.blkno) ORDER BY g.blkno; 

  blkno | all_visible | all_frozen -------+-------------+------------ 0 | t | f 1 | t | f (2 rows) 

पूरी तालिका को फ्रीज करने के लिए आयु

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

प्रत्येक तालिका एक लेन-देन संख्या संग्रहीत करती है, जिसके लिए यह ज्ञात है कि सभी पुराने लेनदेन जमे हुए होने की गारंटी है (pg_class.relfrozenxid)। इस याद किए गए लेनदेन की उम्र के साथ, वैक्यूम_फ्रीज_टेबल_एज पैरामीटर के मूल्य की तुलना की जाती है ।

 => SELECT relfrozenxid, age(relfrozenxid) FROM pg_class WHERE relname = 'tfreeze'; 

  relfrozenxid | age --------------+----- 694 | 5 (1 row) 

PostgreSQL 9.6 से पहले, यह सुनिश्चित करने के लिए कि सभी पृष्ठ क्रॉल किए गए थे, क्लीनअप ने एक पूर्ण तालिका स्कैन किया। बड़ी तालिकाओं के लिए, यह ऑपरेशन लंबा और दुखद था। मामला इस तथ्य से बढ़ गया था कि यदि सफाई अंत तक पहुंचने में विफल रही (उदाहरण के लिए, एक अधीर प्रशासक ने एक कमांड के निष्पादन को बाधित किया), तो शुरुआत से ही शुरू करना आवश्यक था।

संस्करण 9.6 से शुरू होकर, फ़्रीज़ मैप के लिए धन्यवाद (जिसे हम pg_visibility_map आउटपुट में all_frozen कॉलम में देखते हैं), केवल उन पृष्ठों को बाइपास करते हैं जो मानचित्र में पहले से चिह्नित नहीं हैं। यह न केवल बहुत छोटी मात्रा में काम है, बल्कि रुकावटों के लिए भी प्रतिरोध है: यदि सफाई प्रक्रिया को रोक दिया जाता है और फिर से शुरू किया जाता है, तो उसे फिर से उन पृष्ठों को नहीं देखना होगा जो वह पिछली बार ठंड के नक्शे में चिह्नित करने में कामयाब रहे थे।

एक तरह से या किसी अन्य, तालिका के सभी पृष्ठ एक बार ( वैक्यूम_फ्रीज_टेबल_जैसे - वैक्यूम_फ्रीज_मिन_जेज ) लेनदेन में जमे हुए हैं। डिफ़ॉल्ट मानों के साथ, यह प्रति मिलियन लेनदेन एक बार होता है:

 => SHOW vacuum_freeze_table_age; 

  vacuum_freeze_table_age ------------------------- 150000000 (1 row) 

इस प्रकार, यह स्पष्ट है कि बहुत अधिक वैक्यूम_फ्रीज_मिन_जेज को सेट नहीं किया जाना चाहिए, क्योंकि ओवरहेड को कम करने के बजाय, यह उन्हें बढ़ाना शुरू कर देगा।

आइए देखें कि पूरी मेज कैसे जमी हुई है, और ऐसा करने के लिए, वैक्यूम_फ्रीज_टेबल_पेज को 5 तक कम करें ताकि ठंड की स्थिति पूरी हो सके।

 => ALTER SYSTEM SET vacuum_freeze_table_age = 5; => SELECT pg_reload_conf(); 

साफ करते हैं:

 => VACUUM tfreeze; 

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

 => SELECT relfrozenxid, age(relfrozenxid) FROM pg_class WHERE relname = 'tfreeze'; 

  relfrozenxid | age --------------+----- 698 | 1 (1 row) 

अब पहले पृष्ठ की सभी पंक्तियाँ जमी हुई हैं:

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

  ctid | state | xmin | xmin_age | xmax | t_ctid -------+---------------+---------+----------+-------+-------- (0,1) | redirect to 3 | | | | (0,2) | normal | 697 (f) | 2 | 0 (a) | (0,2) (0,3) | normal | 698 (c) | 1 | 0 (a) | (0,3) (1,1) | normal | 697 (f) | 2 | 0 (a) | (1,1) (1,2) | normal | 697 (f) | 2 | 0 (a) | (1,2) (5 rows) 

इसके अलावा, पहला पृष्ठ फ्रीज़ मैप में चिह्नित किया गया है:

 => SELECT * FROM generate_series(0,1) g(blkno), pg_visibility_map('tfreeze',g.blkno) ORDER BY g.blkno; 

  blkno | all_visible | all_frozen -------+-------------+------------ 0 | t | f 1 | t | t (2 rows) 

"आक्रामक" प्रतिक्रिया के लिए आयु

यह महत्वपूर्ण है कि पंक्ति संस्करण समय पर फ्रीज हो जाएं। यदि ऐसी स्थिति उत्पन्न होती है जहां एक लेनदेन जो अभी तक भविष्य में प्रवेश करने के लिए जमे हुए जोखिम नहीं है, तो संभावित समस्याओं को रोकने के लिए PostgreSQL दुर्घटनाग्रस्त हो जाएगा।

इसका क्या कारण हो सकता है? इसके विभिन्न कारण हैं।

• ऑटो सफाई को बंद किया जा सकता है, और नियमित सफाई भी शुरू नहीं होती है। हम पहले ही कह चुके हैं कि यह आवश्यक नहीं है, लेकिन तकनीकी रूप से यह संभव है।
• यहां तक ​​कि शामिल ऑटो-सफाई उन डेटाबेसों में नहीं आती है जिनका उपयोग नहीं किया जाता है ( ट्रैक_काउंट पैरामीटर और टेम्पलेट0 डेटाबेस याद रखें)।
• जैसा कि हमने पिछली बार देखा था , स्किड टेबल को साफ करना जिसमें डेटा केवल जोड़ा जाता है, लेकिन हटाया या बदला नहीं गया है।

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

डिफ़ॉल्ट मूल्य बहुत रूढ़िवादी है:

 => SHOW autovacuum_freeze_max_age; 

  autovacuum_freeze_max_age --------------------------- 200000000 (1 row) 

ऑटोवैक्यूम_फ्रीज_मैक्स_एज की सीमा 2 बिलियन लेनदेन है, और 10 गुना छोटे मूल्य का उपयोग किया जाता है। यह समझ में आता है: मूल्य बढ़ाने से हम जोखिम बढ़ाते हैं कि शेष समय के लिए, ऑटो-सफाई में लाइनों के सभी आवश्यक संस्करणों को फ्रीज करने का समय नहीं होता है।

इसके अलावा, इस पैरामीटर का मान XACT संरचना के आकार को निर्धारित करता है: चूंकि सिस्टम में कोई पुराना लेनदेन नहीं होना चाहिए, जिसके लिए आपको स्थिति का पता लगाने की आवश्यकता हो सकती है, स्वत:-सफाई अनावश्यक XACT सेगमेंट फ़ाइलों को हटा देती है, स्थान खाली करती है।

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

ऑटोवैक्यूम_फ्रीज_मैक्स_एज पैरामीटर को बदलने के लिए सर्वर रीस्टार्ट की आवश्यकता होती है। लेकिन ऊपर चर्चा किए गए सभी मापदंडों को भंडारण मापदंडों का उपयोग करके व्यक्तिगत तालिकाओं के स्तर पर भी सेट किया जा सकता है। आमतौर पर यह केवल विशेष मामलों में ऐसा करने के लिए समझ में आता है, जब तालिका को वास्तव में विशेष देखभाल की आवश्यकता होती है।

इसलिए, हम टेबल स्तर पर (और उसी समय सामान्य भराव को वापस लौटाते हैं) पर ऑटोवैक्यूम_फ्रीज_मैक्स_एज सेट करेंगे। दुर्भाग्य से, न्यूनतम संभव मूल्य 100,000 है:

 => ALTER TABLE tfreeze SET (autovacuum_freeze_max_age = 100000, fillfactor = 100); 

दुर्भाग्य से, क्योंकि हमें उस स्थिति को पुन: उत्पन्न करने के लिए 100,000 लेनदेन को पूरा करना होगा जो हमें रुचती है। लेकिन, ज़ाहिर है, व्यावहारिक उद्देश्यों के लिए, यह एक बहुत ही कम मूल्य है।

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

 => CREATE PROCEDURE foo(id integer) AS $$ BEGIN INSERT INTO tfreeze VALUES (id, 'FOO'); COMMIT; END; $$ LANGUAGE plpgsql; => DO $$ BEGIN FOR i IN 101 .. 100100 LOOP CALL foo(i); END LOOP; END; $$; 

जैसा कि हम देख सकते हैं, तालिका में अंतिम जमे हुए लेनदेन की आयु सीमा मूल्य से अधिक हो गई है:

 => SELECT relfrozenxid, age(relfrozenxid) FROM pg_class WHERE relname = 'tfreeze'; 

  relfrozenxid | age --------------+-------- 698 | 100006 (1 row) 

लेकिन अगर आप अभी थोड़ा इंतजार करते हैं, तो सर्वर के मैसेज लॉग में टेबल के स्वचालित आक्रामक वैक्यूम "टेस्ट.पब्लिक.ट्रेस" के बारे में एक प्रविष्टि होगी, जमे हुए लेनदेन की संख्या बदल जाएगी, और इसकी आयु शालीनता में लौट आएगी:

 => SELECT relfrozenxid, age(relfrozenxid) FROM pg_class WHERE relname = 'tfreeze'; 

  relfrozenxid | age --------------+----- 100703 | 3 (1 row) 

बहु-लेन-देन को फ्रीज़ करने जैसी कोई बात नहीं है, लेकिन हमने अभी इसके बारे में बात नहीं की है - हम इसे तब तक के लिए स्थगित कर देंगे जब तक हम ताले के बारे में बात नहीं करते हैं ताकि हम खुद से आगे न निकल सकें।

मैनुअल ठंड

कभी-कभी ऑटो-सफाई के आगमन की प्रतीक्षा करने के बजाय फ्रीज को मैन्युअल रूप से नियंत्रित करना सुविधाजनक होता है।

आप मैन्युअल रूप से VACUUM FREEZE कमांड का उपयोग करके एक कमांड को फ्रीज कर सकते हैं - लेन-देन की उम्र की परवाह किए बिना सभी पंक्ति संस्करण जमे हुए होंगे (जैसे कि ऑटोवैक्यूम_फ्रीज_मिन_ज = 0 पैरामीटर)। जब एक तालिका VACUUM FULL या CLUSTER कमांड के साथ फिर से बनाई जाती है, तो सभी पंक्तियाँ भी जमी हुई होती हैं।

सभी डेटाबेस को फ्रीज करने के लिए, आप उपयोगिता का उपयोग कर सकते हैं:

 vacuumdb --all --freeze 

FREEZE पैरामीटर निर्दिष्ट करके COPY कमांड का उपयोग करके प्रारंभिक लोडिंग के दौरान डेटा को भी फ्रीज किया जा सकता है। ऐसा करने के लिए, तालिका को उसी में बनाया जाना चाहिए (या TRUNCATE कमांड से खाली किया गया)
COPY के रूप में लेनदेन।

चूंकि जमे हुए पंक्तियों के लिए अलग-अलग दृश्यता नियम हैं, इसलिए ऐसी पंक्तियाँ सामान्य अलगाव नियमों के उल्लंघन में अन्य लेनदेन से डेटा के स्नैपशॉट में दिखाई देंगी (यह पुनरावर्ती पढ़ने या सीरियल स्तर के साथ लेनदेन पर लागू होता है)।

इसे सत्यापित करने के लिए, दूसरे सत्र में, दोहराने योग्य अलगाव स्तर के साथ एक लेनदेन शुरू करें:

 | => BEGIN ISOLATION LEVEL REPEATABLE READ; | => SELECT txid_current(); 

ध्यान दें कि इस लेन-देन ने डेटा का एक स्नैपशॉट बनाया, लेकिन टफ़्रीज़ टेबल तक नहीं पहुंचा। अब हम टैफ्री टेबल को खाली करेंगे और एक ट्रांजेक्शन में नई पंक्तियों को लोड करेंगे। यदि एक समानांतर लेन-देन tfreeze की सामग्री को पढ़ता है, तो TRUNCATE आदेश लेनदेन के अंत तक लॉक हो जाएगा।

 => BEGIN; => TRUNCATE tfreeze; => COPY tfreeze FROM stdin WITH FREEZE; 

 1 FOO 2 BAR 3 BAZ \. 

 => COMMIT; 

अब एक समानांतर लेनदेन नया डेटा देखता है, हालांकि यह अलगाव को तोड़ता है:

 | => SELECT count(*) FROM tfreeze; 

 | count | ------- | 3 | (1 row) 

 | => COMMIT; 

लेकिन, चूंकि इस तरह के डेटा लोडिंग नियमित रूप से होने की संभावना नहीं है, यह आमतौर पर कोई समस्या नहीं है।

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

निष्कर्ष

यह PostgreSQL अलगाव और मल्टीवोर्स पर लेखों की मेरी श्रृंखला को समाप्त करता है। आपके ध्यान के लिए और विशेष रूप से टिप्पणियों के लिए धन्यवाद - वे सामग्री में सुधार करते हैं और अक्सर उन क्षेत्रों को इंगित करते हैं जिन्हें मेरे हिस्से पर अधिक ध्यान देने की आवश्यकता होती है।

जारी रखने के लिए, हमारे साथ बने रहें!