PostgreSQL Antipatterns: ngganti data liwat pemicu

Cepet utawa mengko, akeh wong sing kudu nggawe suntingan gedhe kanggo entri tabel. aku wis marang kula carane nindakake iku luwih apik, nanging luwih becik ora nglakoni mangkono. Dina iki aku bakal ngomong babagan aspek kaloro saka nganyari massa- babagan pemicu.

Contone, ana pemicu ala nggandhol ing meja sing sampeyan kudu mbenerake soko. ON UPDATE, sing nransfer kabeh owah-owahan menyang agregat tartamtu. Lan sampeyan kudu nganyari kabeh (miwiti lapangan anyar, contone) kanthi ati-ati supaya agregat kasebut ora kena pengaruh.

Ayo mateni pemicu!

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

Sing kabeh ana kanggo iku, bener. kabeh wis nggantung.

Amarga ALTER TABLE nemtokke Akses Eksklusif- kunci sing ora ana sing mlaku sejajar, malah sing prasaja SELECT, ora bakal bisa maca apa-apa saka meja. Iki tegese nganti transaksi iki rampung, sapa wae sing pengin "mung maca" kudu ngenteni. Lan kita elinga UPDATE kita duwe lo-o-o-ong...

Ayo cepet mateni banjur cepet nguripake!

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

UPDATE ...;

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

Kahanan wis luwih apik ing kene, wektu ngenteni luwih sithik. Nanging mung rong masalah ngrusak kaendahan:

• ALTER TABLE ngenteni kabeh operasi liyane ing meja, kalebu dawa SELECT
• Nalika pemicu mati, owah-owahan apa wae bakal mabur ing meja, iku ora malah kita. Lan mung ora bakal nggawe agregat, sanajan kudune. Apa bilai!

Ngatur variabel sesi

Dadi, ing versi sadurunge, kita kesandhung ing titik penting: kita kudu piye wae ngajari pemicu kanggo mbedakake antarane owah-owahan "kita" ing meja lan "dudu kita." Iku kudu skip "kita" minangka, lan micu ing "ora kita." Kanggo iki, kita bisa nggunakake variabel sesi.

session_replication_role

Wacan manual:

Mekanisme pemicu uga kena pengaruh variabel konfigurasi session_replication_rolePemicu diaktifake tanpa spesifikasi tambahan (kanthi standar) bakal murub nalika peran replikasi "asal" (kanthi standar) utawa "lokal". Pemicu diaktifake kanthi nemtokake ENABLE REPLICA, mung bakal bisa yen mode sesi saiki - "replika", lan pemicu diaktifake kanthi nemtokake ENABLE ALWAYS, bakal micu preduli saka mode replikasi saiki.

Aku kaya kanggo utamané nandheske sing setelan ora aplikasi kanggo saben wong bebarengan, minangka ALTER TABLE, nanging mung kanggo sambungan khusus kita kapisah. Dadi, kanggo nyegah pemicu aplikasi apa wae sing dipicu:

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

Kondisi ing njero pemicu

Nanging pilihan ing ndhuwur bisa digunakake kanggo kabeh pemicu bebarengan (utawa kita kudu "ngganti" pemicu sing ora pengin mateni luwih dhisik). Lan yen kita perlu "pateni" siji pemicu tartamtu?

Iki bakal mbantu kita variabel sesi "pangguna".:

Jeneng parameter ekstensi ditulis kaya ing ngisor iki: jeneng ekstensi, titik, banjur jeneng parameter dhewe, padha karo jeneng obyek sing mumpuni ing SQL. Contone: plpgsql.variable_conflict.
Amarga paramèter non-sistem bisa disetel ing proses sing ora ngemot modul ekstensi sing cocog, PostgreSQL nampa Nilai kanggo jeneng apa wae kanthi rong komponen.

Pisanan, kita ngowahi pemicu, kaya iki:

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;
...

Miturut cara, iki bisa rampung "urip", tanpa mblokir, liwat CREATE OR REPLACE kanggo fungsi pemicu. Banjur ing sambungan khusus kita nyiyapake variabel "kita":

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

Ngerti cara liyane? Nuduhake ing komentar.

Source: www.habr.com