Re: pgmemcache - Mailing list pgsql-performance

From Tom Lane
Subject Re: pgmemcache
Date
Msg-id 26792.1144949880@sss.pgh.pa.us
Whole thread Raw
In response to pgmemcache  ("C Storm" <christian.storm@gmail.com>)
Responses Re: pgmemcache  (Jim Nasby <jnasby@pervasive.com>)
Re: pgmemcache  (PFC <lists@peufeu.com>)
Re: pgmemcache  (Greg Stark <gsstark@mit.edu>)
List 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 by date:

Previous
From: "Jim Nasby"
Date:
Subject: Re: multi column query
Next
From: Robert Lor
Date:
Subject: Re: bad performance on Solaris 10