Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kg3Zn-0004oz-R5 for pgsql-sql@arkaria.postgresql.org; Fri, 20 Nov 2020 10:23:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kg3Zk-0008E1-Is for pgsql-sql@arkaria.postgresql.org; Fri, 20 Nov 2020 10:23:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kg3Zk-0008Dt-Cd for pgsql-sql@lists.postgresql.org; Fri, 20 Nov 2020 10:23:32 +0000 Received: from mail150.strasbourg.4js.com ([77.159.205.150]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kg3Ze-0003PQ-JM for pgsql-sql@lists.postgresql.org; Fri, 20 Nov 2020 10:23:31 +0000 Received: from [10.6.0.200] ([10.6.0.200]) (authenticated bits=0) by mail150.strasbourg.4js.com (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 0AKANOi1018016 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 20 Nov 2020 11:23:24 +0100 Subject: Re: Get last generated serial sequence and set it up when explicit value is used To: "David G. Johnston" Cc: pgsql-sql References: <10622684-b74b-39d2-83d8-4ed2d8d52915@4js.com> From: Sebastien FLAESCH Organization: Four Js Development Tools Message-ID: <4279b691-5699-4e83-2337-e1a4f30553bd@4js.com> Date: Fri, 20 Nov 2020 11:23:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.4 at mail150 X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail150.strasbourg.4js.com [10.10.0.1]); Fri, 20 Nov 2020 11:23:24 +0100 (CET) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 11/20/20 9:49 AM, David G. Johnston wrote: > On Friday, November 20, 2020, Sebastien FLAESCH > wrote: > > Is there any way to avoid the error produced by currval()? > > > No > > Ideally, currval() should return zero when no serial was produced yet. > > > I’d accept null, zero is a valid value. > > > Is it possible to write that in a simple SQL expression so it can be used in > the RETURNING clause of my INSERTs ? > > > Not that I can think of.  Maybe as the docs suggest, just do an unconditional setval()?  You might be able to combine that with a non-default > isolation level (guessing here) to get close-enough behavior.  You are fighting the existing design of the feature, looking for an in-between position > of fast-and-concurrent (existing) and fully serialized (where this would be mostly trivial to implement).  I don’t know of such a method. > > David J. > Thanks David for your comments. I will give a chance to: insert into table1 (name) values ('aaaa') returning pkey, (select last_value from table1_pkey_seq); Followed by a setval('seq',pkey,true), if pkey > last_value ... In fact I wonder how PostgreSQL actually executes such statement. To me, it should be an atomic operation so I guess the (SELECT last_value FROM seq-name) Should either return the new serial produced by this current INSERT, or a new serial produced previously by the INSERT in another session, when the current INSERT do not produce a new serial value. But it should not return a new serial value that was produced by another session between the actual local INSERT and the SELECT last_val sub-query in the RETURNING clause... Anyway, doing the setval(...pkey...) when pkey value is greater than the last_value, should also be ok if a new last_value was produced by another session in-between... Does that make sense? Seb