X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id F405511F6605 for ; Thu, 13 Apr 2006 17:52:51 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 required=5 tests=[AWL=0.127] Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id SE7IL4jzgx5q for ; Thu, 13 Apr 2006 17:52:46 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) by postgresql.org (Postfix) with ESMTP id 6958A11F6603 for ; Thu, 13 Apr 2006 17:52:47 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1FU8nt-00050x-00; Thu, 13 Apr 2006 16:52:37 -0400 To: Tom Lane Cc: Christian Storm , "Jim C. Nasby" , Josh Berkus , pgsql-performance@postgresql.org, PFC Subject: Re: pgmemcache References: <1144135482.063425.33380@z34g2000cwc.googlegroups.com> <20060411225515.GZ49405@pervasive.com> <200604121603.43986.josh@agliodbs.com> <20060413001024.GP49405@pervasive.com> <6236.1144888514@sss.pgh.pa.us> <4D23826E-7325-4946-B79A-80E321E0E497@gmail.com> <26792.1144949880@sss.pgh.pa.us> In-Reply-To: <26792.1144949880@sss.pgh.pa.us> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 13 Apr 2006 16:52:37 -0400 Message-ID: <87irpdgpuy.fsf@stark.xeocode.com> Lines: 28 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Archive-Number: 200604/317 X-Sequence-Number: 18401 Tom Lane writes: > Christian Storm 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. Maybe it just means they would have to be limited to not making any database modifications. Ie, all they can do is notify the outside world that the transaction committed. Presumably if you wanted to make any database modifications you would just do it in the transaction anyways since they wouldn't show up until the transaction commits. -- greg