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