Dotaz: Postgres sequence

[Marek]

Dobrý den,

Nevíte, prosím, někdo, zda je u postgres zaručeno, že ID získané autoinkrementací je vždy u posledního zápisu nejvyšší (když pominu přetečení)?

Jde mi o případ transakcí/nezávaslých připojení, kdy jedna transakce "A" vkládájící záznam začne dřív, ale zároveň i skončí později, než druhá:

1) v transakci A je přidán záznam 2) v transakci B je přidán záznam 3) transakce B je commitnuta 4) transakce A je commitnuta

Je ID záznamu A zaručeně vyšší než ID záznamu B?

Děkuji

---

---

Odpovědi

[okbob]

Sekvence nemají žádnou závislost na transakce - číslo se generuje v okamžiku, kdy si o něj řeknete - tj typicky, kdy provádíte INSERT. Pak jestli a kdy provedete COMMIT je vůči získané hodnotě a stavu sekvence absolutně jedno.

[okbob]

Suhlas. Ak by som mal toto prelozit do odpovede na povodnu otazku:

ID zaznamu A je nizsie nez ID zaznamu B. - pretoze transakcia A vygenerovala sequencerom cislo skor nez transakcia B

Jediny sposob (ktory ma napada), akym zhruba monitorovat cas/poradie commitov je pouzit DEFERRED (CONSTRAINT) TRIGGER.

[okbob]

CONSTRAINT TRIGGER může být pouze typu AFTER - tj nelze v něm již měnit data.

[EtDirloth]

Sice to nejde cez record NEW, ale ide to SQL statementom:

CREATE SEQUENCE commit_seq;

CREATE TABLE t
(
   id          serial    NOT NULL PRIMARY KEY
 , tsInsert    timestamp NOT NULL DEFAULT clock_timestamp()
 , seqCommit   int
 , tsCommit    timestamp
);

CREATE OR REPLACE FUNCTION ai_d_commit()
RETURNS trigger AS
$$
   BEGIN
      UPDATE t
         SET seqCommit = nextval('commit_seq'::regclass)
           , tsCommit  = clock_timestamp()
         WHERE id = NEW.id
      ;
      RETURN NEW;
   END;
$$
LANGUAGE plpgsql
VOLATILE;

CREATE CONSTRAINT TRIGGER ai_d_commit
   AFTER INSERT
   ON t
   DEFERRABLE INITIALLY DEFERRED
   FOR EACH ROW
   EXECUTE PROCEDURE ai_d_commit()
;

BEGIN;
INSERT INTO t DEFAULT VALUES;
SELECT pg_sleep(2);
COMMIT;
SELECT * FROM t;

CLI test:

psql -Upostgres -c"BEGIN; INSERT INTO t DEFAULT VALUES; SELECT pg_sleep(2); COMMIT; SELECT * FROM t ORDER BY id;" &\
sleep 1;\
psql -Upostgres -c"BEGIN; INSERT INTO t DEFAULT VALUES; COMMIT; SELECT * FROM t ORDER BY id;"

Este skusam vymysliet naco by to komu bolo. Navyse to poradie bude iba priblizne - kedze to pochopitelne bezi pred commitom, tak moment skutocneho commitu moze byt v inom poradi, nez aky ukazuje sequencer. Ak by to bolo naozaj dolezite, rozmyslal by som skor nad serializaciou.

[okbob]

Trochu bych se bal v triggeru delat DML nad stejnou tabulkou - pro kombinaci INSERT/UPDATE to zafunguje (problem je vetsi narocnost - generuji se nove verze), pro kombinaci UPDATE/UPDATE nedokazi odhadnout, jestli tam nebude side effect pripadne rekurze na triggerech. Rozhodne bych do takoveho navrhu za zadnych okolnosti nesel.

[EtDirloth]

Je asi jedno, ci clovek robi DML nad rovnakou, alebo inou tabulkou: v oboch pripadoch vznika novy tuple a nepriama rekurzia hrozi tiez. Napriklad v SQLite triggeroch ani ina moznost nie je - len pouzitie DML. Urcite by som bol opatrny, ale zbytocne by som sa neobmedzoval. Nakoniec, nasledujuca veta je v dokumentacii viac nez desat rokov:

It is the trigger programmer's responsibility to avoid infinite recursion

Zo skusenosti, pre zamedzenie rekurzie triggerov je rozumne pouzit klauzulu WHEN.

[Marek]

Dik moc obema.

[cronin]

Je chybou, ak sa aplikačná logika spolieha na usporiadanie hodnôt generovaných sekvenciou, resp. na usporiadanie hodnôt syntetického primárneho kľúča vo všeobecnosti. Ak aplikačná logika potrebuje usporiadanie, mala by mať na tento účel určený stĺpec a generovanie jeho hodôt má byť starostlivo navrhnuté a implementované s ohľadom na potreby aplikácie; ak sa bude jednať o usporiadanie úplné, nie čiastočné, môže sa teoreticky tento stĺpec stať aj primárnym kľúčom, prakticky to ale tiež nie najlepší nápad.

Inak povedané, nechajte zodpovednosť jednoznačnej identifikácie záznamu na primárnom kľúči, ale zodpovednosť za usporiadanie záznamov v tabuľke urobte zodpovedným iný, špeciálne na tento účel navrhnutý stĺpec. Naplníte tak princíp jednej zodpovednosti a oceníte to okamžite, ako nastane potreba usporiadať záznamy podľa iného, v tejto chvíli ešte neznámeho kritéria.