Skip site navigation (1) Skip section navigation (2)

Re: currval() race condition on server?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Adriaan Joubert <a(dot)joubert(at)albourne(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: currval() race condition on server?
Date: 2006-10-24 14:18:21
Message-ID: 8427.1161699501@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-jdbc
Adriaan Joubert <a(dot)joubert(at)albourne(dot)com> writes:
> It feels an awful lot like a timing issue where the sequence 
> number is retrieved, but there is a delay until currval can use it. I'm 
> not sure how currval works.

There is no "timing issue" in currval --- the server is single-threaded
and it's simply not possible that currval wouldn't be aware of a
previous nextval.

The theory that sounds best to me is the one someone already mentioned
about your trigger having a code path that doesn't execute nextval.
Another straw to grasp at is connection pooling: are you using it,
if so is it conceivable that the SELECT is being issued on a different
connection than the UPDATE?

			regards, tom lane

In response to

Responses

pgsql-admin by date

Next:From: Scott MarloweDate: 2006-10-24 16:03:09
Subject: Re: materialized view
Previous:From: Antonios KatsikadamosDate: 2006-10-24 13:31:29
Subject: postgres under suse linux

pgsql-jdbc by date

Next:From: Dave CramerDate: 2006-10-24 16:13:29
Subject: Re: currval() race condition on server?
Previous:From: Dave CramerDate: 2006-10-24 13:10:08
Subject: Re: currval() race condition on server?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group