PostgreSQL Antipatterns: एक ट्रिगर को बायपास करते हुए डेटा बदलें

जल्दी या बाद में, कई लोगों को टेबल रिकॉर्ड में बड़े पैमाने पर कुछ ठीक करने की आवश्यकता का सामना करना पड़ता है। मेरे पास पहले से ही है मुझे बताओ कि इसे बेहतर कैसे करें, और कैसे - यह बेहतर नहीं है। आज मैं मास अपडेट के दूसरे पहलू की बात करूंगा - ट्रिगर्स के बारे में.

उदाहरण के लिए, एक मेज पर जिसमें आपको कुछ ठीक करने की आवश्यकता होती है, एक दुष्ट ट्रिगर लटका हुआ है ON UPDATE, सभी परिवर्तनों को कुछ समुच्चय में स्थानांतरित करना। और आपको सब कुछ अपडेट करने की आवश्यकता है (उदाहरण के लिए, एक नया क्षेत्र आरंभ करें) इतनी सावधानी से कि ये समुच्चय प्रभावित न हों।

चलो बस ट्रिगर्स को अक्षम करें!

BEGIN;
  ALTER TABLE ... DISABLE TRIGGER ...;
  UPDATE ...; -- тут долго-долго
  ALTER TABLE ... ENABLE TRIGGER ...;
COMMIT;

दरअसल, बस इतना ही- सब कुछ लटक रहा है.

क्योंकि ALTER TABLE लगाता एक्सेस एक्सक्लूसिव- एक ताला जिसके नीचे कोई भी समानांतर नहीं चल रहा है, यहां तक ​​​​कि एक साधारण भी SELECT, तालिका से कुछ भी पढ़ने में सक्षम नहीं होगा। यही है, जब तक यह लेन-देन समाप्त नहीं हो जाता, तब तक हर कोई जो "सिर्फ पढ़ना" चाहता है, इंतजार करेगा। और हमें वह याद है UPDATE हमारे पास एक लंबा...

चलो जल्दी से इसे बंद कर दें, फिर जल्दी से चालू करें!

BEGIN;
  ALTER TABLE ... DISABLE TRIGGER ...;
COMMIT;

UPDATE ...;

BEGIN;
  ALTER TABLE ... ENABLE TRIGGER ...;
COMMIT;

यहां स्थिति पहले से बेहतर है, वेटिंग टाइम काफी कम है। लेकिन केवल दो समस्याएं ही सारी सुंदरता बिगाड़ देती हैं:

• ALTER TABLE मेज पर अन्य सभी परिचालनों के लिए स्वयं प्रतीक्षा करता है, जिसमें लंबे भी शामिल हैं SELECT
• जबकि ट्रिगर बंद है, किसी भी बदलाव से "उड़ान भरें" तालिका में, हमारा भी नहीं। और यह समुच्चय में नहीं आएगा, हालाँकि इसे होना चाहिए। मुश्किल!

सत्र चर प्रबंधित करना

इसलिए, पिछले संस्करण में, हम एक मौलिक बिंदु पर ठोकर खा गए - हमें किसी तरह ट्रिगर को "हमारे नहीं" से तालिका में "हमारे" परिवर्तनों को अलग करने के लिए सिखाने की आवश्यकता है। "हमारा" वैसे ही छोड़ दिया जाता है, लेकिन "हमारा नहीं" पर वे ट्रिगर हो जाते हैं। इसके लिए आप प्रयोग कर सकते हैं सत्र चर.

सत्र_प्रतिकृति_भूमिका

हम पढ़ते हैं नियमावली:

ट्रिगर तंत्र भी कॉन्फ़िगरेशन चर से प्रभावित होता है सत्र_प्रतिकृति_भूमिका. अतिरिक्त निर्देशों (डिफ़ॉल्ट) के बिना सक्षम, प्रतिकृति भूमिका "मूल" (डिफ़ॉल्ट) या "स्थानीय" होने पर ट्रिगर सक्रिय हो जाएंगे। ट्रिगर निर्दिष्ट करके सक्षम किया गया ENABLE REPLICA, तभी काम करेगा वर्तमान सत्र मोड - "प्रतिकृति", और ट्रिगर निर्दिष्ट करके सक्षम ENABLE ALWAYS, वर्तमान प्रतिकृति मोड पर ध्यान दिए बिना काम करेगा।

मैं विशेष रूप से इस बात पर जोर दूंगा कि सेटिंग सभी-सभी पर एक साथ लागू नहीं होती है, जैसे ALTER TABLE, लेकिन केवल हमारे अलग विशेष कनेक्शन के लिए। कुल मिलाकर, ताकि कोई भी एप्लिकेशन ट्रिगर काम न करे:

SET session_replication_role = replica; -- выключили триггеры
UPDATE ...;
SET session_replication_role = DEFAULT; -- вернули в исходное состояние

ट्रिगर के अंदर की स्थिति

लेकिन उपरोक्त विकल्प एक साथ सभी ट्रिगर के लिए काम करता है (या आपको पहले से "वैकल्पिक" ट्रिगर करने की आवश्यकता है जिसे आप अक्षम नहीं करना चाहते हैं)। और अगर हमें चाहिए एक विशिष्ट ट्रिगर "बंद करें"?

इससे हमें मदद मिलेगी "उपयोगकर्ता" सत्र चर:

एक्सटेंशन पैरामीटर नाम निम्नानुसार लिखे गए हैं: एक्सटेंशन नाम के बाद डॉट और उसके बाद पैरामीटर नाम, SQL में पूर्ण ऑब्जेक्ट नामों के समान। उदाहरण के लिए: plpgsql.variable_conflict।
क्योंकि आउट-ऑफ़-सिस्टम विकल्प उन प्रक्रियाओं में सेट किए जा सकते हैं जो उपयुक्त एक्सटेंशन मॉड्यूल को लोड नहीं करते हैं, PostgreSQL स्वीकार करता है दो घटकों वाले किसी भी नाम के मान.

सबसे पहले, हम ट्रिगर को अंतिम रूप देते हैं, कुछ इस तरह:

BEGIN
    -- процессу конвертации можно делать все
    IF current_setting('mycfg.my_table_convert_process') = 'TRUE' THEN
        IF TG_OP IN ('INSERT', 'UPDATE') THEN
            RETURN NEW;
        ELSE
            RETURN OLD;
        END IF;
    END IF;
...

वैसे, यह "लाभ के लिए" किया जा सकता है, बिना अवरुद्ध किए CREATE OR REPLACE ट्रिगर समारोह के लिए। और फिर विशेष संबंध में हम "हमारे" चर को कॉक करते हैं:

SET mycfg.my_table_convert_process = 'TRUE';
UPDATE ...;
SET mycfg.my_table_convert_process = ''; -- вернули в исходное состояние

क्या आप अन्य तरीके जानते हैं? टिप्पणियों में साझा करें।

स्रोत: www.habr.com