PostgreSQL अँटीपॅटर्न: ट्रिगर बायपास करून डेटा बदला

लवकरच किंवा नंतर, पुष्कळांना टेबल रेकॉर्डमध्ये मोठ्या प्रमाणात काहीतरी निश्चित करण्याची गरज भासते. माझ्याकडे आधीच आहे ते चांगले कसे करायचे ते मला सांगा, आणि कसे - ते न करणे चांगले आहे. आज मी मास अपडेटच्या दुसऱ्या पैलूबद्दल बोलणार आहे - ट्रिगर बद्दल.

उदाहरणार्थ, एखाद्या टेबलवर ज्यामध्ये आपल्याला काहीतरी निराकरण करण्याची आवश्यकता आहे, एक वाईट ट्रिगर लटकतो 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