PostgreSQL Antipatterns: changing data bypassing the trigger

Varsti või hiljem puutuvad paljud kokku vajadusega midagi massiliselt tabeli kirjetes parandada. Olen juba rääkinud, kuidas seda paremini teha, ja kuidas — mitte teha. Täna räägin massiivse uuendamise teisest aspektist — käivituvatest trigeritest.

Näiteks, tabelil, kus peate midagi korrigeerima, on kurja triger ON UPDATE, mis viib kõik muudatused mingitesse aggregeeridesse. Ja teil on vaja kõik uuendada (uue välja initsialiseerida näiteks) nii ettevaatlikult, et need aggregeedid ei puudutaks.

Lähme lihtsalt trigerite väljalülitamise teed!

BEGIN;
  ALTER TABLE ... DISABLE TRIGGER ...;
  UPDATE ...; -- siin läheb kaua
  ALTER TABLE ... ENABLE TRIGGER ...;
COMMIT;

Loomulikult, siin see kõik on — kõik on juba käimas.

Sest ALTER TABLE kehtestab AccessExclusive-lukustuse all, mille all keegi, kes teostab samaaegset tööd, isegi lihtne SELECT, ei saa tabelist midagi lugeda. See tähendab, et kuni see tehing ei ole lõppenud, ootavad kõik, kes tahavad isegi 'lihtsalt lugeda'. Ja me mäletame, et KUUDA meil on pi-ii-ikalt…

Lähme siis kiiresti välja lülitama, siis kiiresti sisse lülitame!

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

UPDATE ...;

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

Siin on olukord juba parem, ooteaeg on oluliselt lühem. Kuid kaks probleemi rikuvad kogu ilu:

• ALTER TABLE ootab endiselt kõiki teisi operatsioone tabelis, sealhulgas pikki SELECT
• Praegu on triger välja lülitatud, igal muutusel on võimalus «mööda minna» tabelis, isegi mitte meie oma. Ja agregaatidesse ei pääse, kuigi peaks. Häda!

Seansi muutujate haldamine

Nii et eelmisel variandil sattusime põhimõttelisele punktile — peame kuidagi õpetama triggest eristama tabelis «meie» muudatusi «mitte meie» omadest. «Meie» lubame sellisena, kuid «mitte meie» korral peame reageerima. Selleks saab kasutada seansi muutujaid.

session_replication_role

Lugeda kasutajate käsiraamat:

Triggerite aktiveerimise mehhanismile mõjutab ka konfiguratsioonimuutuja session_replication_role. Ilma täiendavate märkusteta (vaikimisi) aktiveeruvad triggerrid, kui replikatsiooni roll on — „origin“ (vaikimisi) või „local“. Trigged, mis aktiveeritakse näidatud ENABLE REPLICA, aktiveeruvad ainult siis, kui praegune seanss on — „replica“, ning trigged, mis aktiveeritakse näidatud ENABLE ALWAYS, aktiveeruvad olenemata praegusest replikatsiooni režiimist.

Eriti rõhutan, et seadistus ei kehti kõigile korraga, nagu ALTER TABLE, vaid ainult meie konkreetse spetsiaalsete ühenduste jaoks. Seega, et ei toimiks mingeid rakenduslikke käivitusmehhanisme:

SET session_replication_role = replica; -- keelame käivitushoobad
UPDATE ...;
SET session_replication_role = DEFAULT; -- taastame algse seisundi

Käivitushoobade tingimus

Kuid eespool toodud variant töötab kõigi käivitushoobade jaoks korraga (või peab eelnevalt "muutma" neid käivitushoobasid, mida ei soovi keelata). Aga kui me peame "keelama" ühe konkreetse käivitushoova?

Seda aitab meil "kasutaja" seansi muutuja:

Laiendite parameetrite nimed kirjutatakse järgmiselt: laiendi nimi, punkt ja seejärel parameetri enda nimi, sarnaselt SQL-i täielike objektinimedega. Näiteks: plpgsql.variable_conflict.
Kuna süsteemi välist parameetrit võib seadistada protsessides, mis ei laadita vastavat laiendimoodulit, aktsepteerib PostgreSQL väärtusi igasuguste kahe komponendiga nimede jaoks.

Alustame käivitushoova täiustamist umbes nii:

BEGIN
    -- konverteerimisprotsessis võib teha kõike
    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;
...

Üksikasjalikult, seda saab teha "reaalses" ajas, ilma blokeeringuteta, läbi CREATE OR REPLACE triggereid funktsioonide jaoks. Seejärel määrame spetsiaalses ühenduses meie muutuja:

SET mycfg.my_table_convert_process = 'TRUE';
UPDATE ...;
SET mycfg.my_table_convert_process = ''; -- taastatud algsesse olekusse

Kas tead muid viise? Jagage kommentaarides.

Allikas: habr.com