X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id F35FF329E7E for ; Wed, 20 Oct 2004 18:00:49 +0100 (BST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 39826-09 for ; Wed, 20 Oct 2004 17:00:42 +0000 (GMT) Received: from mr1.surnet.cl (av1.surnet.cl [216.155.73.168]) by svr1.postgresql.org (Postfix) with ESMTP id 4E8F7329D7C for ; Wed, 20 Oct 2004 18:00:38 +0100 (BST) Received: from smtp1.surnet.cl (216.155.73.168) by mr1.surnet.cl (7.0.024) id 415C6677004695F1 for pgsql-general@postgresql.org; Wed, 20 Oct 2004 13:59:48 -0300 Received: from av1.surnet.cl ([216.155.73.168]) by smtp1.surnet.cl (MailMonitor for SMTP v1.2.2 ) ; Wed, 20 Oct 2004 13:59:48 -0300 (CLST) Received: from cluster.surnet.cl (216.155.73.165) by smtp1.surnet.cl (7.0.024) id 415C63130057FEF5 for pgsql-general@postgresql.org; Wed, 20 Oct 2004 13:59:48 -0300 Received: from localhost (216.155.78.254) by cluster.surnet.cl (7.0.024) (authenticated as alvherre@surnet.cl) id 4134D3220059E3BC for pgsql-general@postgresql.org; Wed, 20 Oct 2004 14:00:09 -0300 Received: by localhost (Postfix, from userid 1000) id 2FD58DF9D0; Wed, 20 Oct 2004 14:00:22 -0300 (CLST) Date: Wed, 20 Oct 2004 14:00:22 -0300 From: Alvaro Herrera To: pgsql-general@postgresql.org Subject: Re: Sequence question Message-ID: <20041020170022.GB5096@dcc.uchile.cl> References: <41753069.3000406@bonbon.net> <20041020155742.GB8721@phlogiston.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20041020155742.GB8721@phlogiston.dyndns.org> User-Agent: Mutt/1.5.6+20040722i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200410/919 X-Sequence-Number: 67442 On Wed, Oct 20, 2004 at 11:57:42AM -0400, Andrew Sullivan wrote: > Now, how do you handle the cases where either the transaction fails > so you can't set it to 3? Simple: your client captures errors and > then sets the value back to 1 later. Has anyone read "the Sagas paper" by Garcia-Molina? They present a way to handle "extended transaction models", trying to cope sort-of automatically with this kind of situations. More generally, AFAIU the idea is to have multi-transaction recoverability and rollback-ability. It seems interesting. http://portal.acm.org/citation.cfm?doid=38713.38742 I have only skimmed through it, but it sounds somewhat interesting. I'd love to know what do people think of this. -- Alvaro Herrera () "Los dioses no protegen a los insensatos. Éstos reciben protección de otros insensatos mejor dotados" (Luis Wu, Mundo Anillo)