Re: Row visibility issue with consecutive triggers, one being DEFERRED

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marc Mamin <M(dot)Mamin(at)intershop(dot)de>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Row visibility issue with consecutive triggers, one being DEFERRED
Date: 2015-06-04 13:56:18
Message-ID: 30506.1433426178@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Marc Mamin <M(dot)Mamin(at)intershop(dot)de> writes:
> The test below is running fine
> but if you add the trigger push_foo_tr (uncomment)
> then the exception is raised.

Doesn't that trigger result in infinite recursion?

> 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 TRIGGER push_foo_tr
> -- AFTER UPDATE ON foo
> -- FOR EACH ROW EXECUTE PROCEDURE check_foo_trf();

AFAICS, each trigger firing would re-queue another one because of
the fresh UPDATE.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Melvin Davidson 2015-06-04 14:03:27 Re: pg_relation_size performance issue
Previous Message Tom Lane 2015-06-04 13:50:55 Re: pg_relation_size performance issue