| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Christian Storm <christian(dot)storm(at)gmail(dot)com> |
| Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org, PFC <lists(at)peufeu(dot)com> |
| Subject: | Re: pgmemcache |
| Date: | 2006-04-13 17:38:00 |
| Message-ID: | 26792.1144949880@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Christian Storm <christian(dot)storm(at)gmail(dot)com> writes:
> Not sure if I follow why this is a problem. Seems like it would be
> beneficial to have both BEFORE and AFTER COMMIT triggers.
> With the BEFORE COMMIT trigger you would have the ability to 'un-
> commit' (rollback) the transaction. With
> the AFTER COMMIT trigger you wouldn't have that option because the
> commit has already been successful. However,
> with an AFTER COMMIT you would be able to trigger other downstream
> events that rely on a transaction successfully committing.
An AFTER COMMIT trigger would have to be in a separate transaction.
What happens if there's more than one, and one of them fails? Even
more to the point, if it's a separate transaction, don't you have
to fire all these triggers again when you commit that transaction?
The idea seems circular.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Lor | 2006-04-13 17:40:08 | Re: bad performance on Solaris 10 |
| Previous Message | Christian Storm | 2006-04-13 17:29:28 | Re: pgmemcache |