Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

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

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group