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 A556D11F623A for ; Thu, 13 Apr 2006 17:22:41 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: 0.133 X-Spam-Level: X-Spam-Status: No, score=0.133 required=5 tests=[AWL=0.133] Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id Ktk8VOr3RT4q for ; Thu, 13 Apr 2006 17:22:33 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from peufeu.com (boutiquenumerique.com [82.67.9.10]) by postgresql.org (Postfix) with ESMTP id ECE0C11F623B for ; Thu, 13 Apr 2006 17:22:34 -0300 (ADT) Received: (qmail 29848 invoked from network); 13 Apr 2006 22:23:32 +0200 Received: from boutiquenumerique.com (HELO apollo13) (82.67.9.10) by boutiquenumerique.com with SMTP; 13 Apr 2006 22:23:32 +0200 Date: Thu, 13 Apr 2006 22:23:31 +0200 To: "Tom Lane" , "Christian Storm" Subject: Re: pgmemcache Cc: "Jim C. Nasby" , "Josh Berkus" , pgsql-performance@postgresql.org 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> From: PFC Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <26792.1144949880@sss.pgh.pa.us> User-Agent: Opera M2/8.51 (Linux, build 1462) X-Archive-Number: 200604/316 X-Sequence-Number: 18400 > An AFTER COMMIT trigger would have to be in a separate transaction. I guess AFTER COMMIT triggers would be like a NOTIFY, but more powerful. While NOTIFY can't transmit information to another process, this trigger could, and the other process could then view the results of the commited transaction. Also, implementing a long process (something involving network roundtrips, for instance) in a BEFORE COMMIT trigger would delay the transaction and any locks it holds with no benefit. > What happens if there's more than one, and one of them fails? Each one in its own transaction ? > 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. I guess AFTER COMMIT triggers are most useful when coupled to a trigger on a modification to a table. So, the "before / after commit" could be an attribute of an AFTER INSERT/UPDATE/DELETE trigger. If the AFTER COMMIT trigger doesn't do any modifications to the target table, there will be no infinite loop. The before/after commit could also be implemented not via triggers, but via deferred actions, by telling postgres to execute a specific query just before/after the transaction commits. This could be used to implement the triggers, but would also be more generic : a trigger on INSERT could then defer a call to memcache update once the transaction is commited. It gets lisp-ish, but it would be really cool?