Re: pgmemcache
| От | Tom Lane |
|---|---|
| Тема | Re: pgmemcache |
| Дата | |
| Msg-id | 26792.1144949880@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | pgmemcache ("C Storm" <christian.storm@gmail.com>) |
| Ответы |
Re: pgmemcache
Re: pgmemcache Re: pgmemcache |
| Список | pgsql-performance |
Christian Storm <christian.storm@gmail.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
В списке pgsql-performance по дате отправления: