From: | Marc Mamin <M(dot)Mamin(at)intershop(dot)de> |
---|---|
To: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Row visibility issue with consecutive triggers, one being DEFERRED |
Date: | 2015-06-04 08:46:32 |
Message-ID: | B6F6FD62F2624C4C9916AC0175D56D8828BDC4F9@jenmbs01.ad.intershop.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hello,
The test below is running fine
but if you add the trigger push_foo_tr (uncomment)
then the exception is raised.
It seems that this additional trigger to be called at the first place
changes the deferrable status of the second one.
Is this an expected behaviour ?
regards,
Marc Mamin
DROP TABLE IF EXISTS foo;
DROP FUNCTION IF EXISTS push_foo_trf();
DROP FUNCTION IF EXISTS check_foo_trf();
CREATE TABLE foo (id int, v int);
INSERT INTO foo select 1,3;
INSERT INTO foo select 2,6;
CREATE OR REPLACE FUNCTION push_foo_trf () returns trigger AS $$
BEGIN
UPDATE foo SET (id,v) = (NEW.id,NEW.v) WHERE id=NEW.id;
RETURN NEW;
END; $$ language plpgsql;
CREATE OR REPLACE FUNCTION check_foo_trf () returns trigger AS $$
DECLARE
visible_sum int;
table_view text;
BEGIN
SELECT sum(v) from foo into visible_sum;
IF 9 <> visible_sum THEN
SELECT string_agg (id||', '||v ,E' | ') FROM foo INTO table_view;
raise exception 'Check failed. Visible: %',table_view;
END IF;
RETURN NULL;
END; $$ language plpgsql;
--CREATE TRIGGER push_foo_tr
-- AFTER UPDATE ON foo
-- FOR EACH ROW EXECUTE PROCEDURE check_foo_trf();
CREATE CONSTRAINT TRIGGER check_foo_tr
AFTER UPDATE ON foo
DEFERRABLE INITIALLY DEFERRED
FOR EACH ROW EXECUTE PROCEDURE check_foo_trf();
BEGIN;
update foo set v=6 WHERE id = 1;
update foo set v=3 WHERE id = 2;
END;
--cleanup
DROP TABLE IF EXISTS foo;
DROP FUNCTION IF EXISTS push_foo_trf();
DROP FUNCTION IF EXISTS check_foo_trf();
From | Date | Subject | |
---|---|---|---|
Next Message | Hans Guijt | 2015-06-04 10:14:25 | pg_relation_size performance issue |
Previous Message | Noah Misch | 2015-06-04 06:42:26 | Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 |