From: | Andrew Sullivan <ajs(at)crankycanuck(dot)ca> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Question on triggers and plpgsql |
Date: | 2005-04-08 14:59:28 |
Message-ID: | 20050408145928.GA27718@phlogiston.dyndns.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On Fri, Apr 08, 2005 at 10:36:26AM -0400, Tom Lane wrote:
> AFAICS the only way that you could get into a can't-roll-back situation
> is if the trigger tries to propagate the update outside the database.
> For instance, the proverbial trigger to send mail: once sent you can't
> cancel it. But really this is dangerous even in an AFTER trigger ---
> the transaction could still be rolled back after the AFTER trigger
> fires.
People who know more about this will no doubt correct me, but isn't
such a case crying out for LISTEN/NOTIFY instead? That is, your
trigger puts the mail content into a table of mails to be sent, and
wakes up the mail-sender client with the NOTIFY; the NOTIFY and the
commit to the mail-it table only happen in that case if the
transaction commits. And since mail is async anyway, the extra few
seconds shouldn't make any difference, right?
A
--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
The plural of anecdote is not data.
--Roger Brinner
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2005-04-08 15:07:31 | Re: getting count for a specific querry |
Previous Message | Tom Lane | 2005-04-08 14:36:26 | Re: Question on triggers and plpgsql |