Re: pgmemcache
- 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. 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: Thu, 13 Apr 2006 13:38:00 -0400
- Message-id: <26792(dot)1144949880(at)sss(dot)pgh(dot)pa(dot)us>
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
Home |
Main Index |
Thread Index