X-Original-To: pgsql-sql-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 082D59FA65C for ; Wed, 16 Aug 2006 11:17:59 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 93591-01 for ; Wed, 16 Aug 2006 14:17:47 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from main2.mycybernet.net (main2.mycybernet.net [209.222.63.140]) by postgresql.org (Postfix) with ESMTP id 365E39FA7BA for ; Wed, 16 Aug 2006 11:17:46 -0300 (ADT) Received: from 227-54-222-209.mycybernet.net ([209.222.54.227] helo=phlogiston.dydns.org) by main2.mycybernet.net with esmtp (Exim 4.62) (envelope-from ) id 1GDMPY-0003ky-4R for pgsql-sql@postgresql.org; Wed, 16 Aug 2006 10:30:24 -0400 Received: by phlogiston.dydns.org (Postfix, from userid 1000) id 3B721417B; Wed, 16 Aug 2006 10:17:35 -0400 (EDT) Date: Wed, 16 Aug 2006 10:17:35 -0400 From: Andrew Sullivan To: pgsql-sql@postgresql.org Subject: Re: problem with sequence..... Message-ID: <20060816141735.GB25228@phlogiston.dyndns.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.135 tagged_above=0 required=5 tests=FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200608/120 X-Sequence-Number: 26078 On Wed, Aug 16, 2006 at 05:01:09PM +0530, Penchalaiah P. wrote: > If again I pass correct values to that function that values can see in > view data with increment value of sequence > > > Any one can tell me how to stop that sequence value when ever I was > passing wrong values to that function.... I'm not entirely sure I understood you, but if what you're asking is for the sequence not to increment on transaction rollback, then you can't have it. The sequence system guarantees that the numbers will be in increasing order (subject to rollover), but it does not guarantee that there will be no gaps. This is to avoid some unpleasant concurrency side-effects from the no-gaps approach. If you really need that, then you have two choices: 1. Roll your own, using some sort of interlock table. This will not play nicely with a lot of concurrent writes, however (which is the disadvantage the current implementation is designed to avoid). 2. In recent PostgreSQL releases, you could use a savepoint. So, get the nextval() of your serial number. Set a savepoint. Try your insert. If that fails, roll back and save the currval() as VOIDed. (This isn't completely safe. You can make it completely safe by doing it in two transactions, but that's best left as an exercise for the reader.) A -- Andrew Sullivan | ajs@crankycanuck.ca If they don't do anything, we don't need their acronym. --Josh Hamilton, on the US FEMA