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
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
pgsql-admin by date
|Next:||From: Scott Marlowe||Date: 2006-10-24 16:03:09|
|Subject: Re: materialized view|
|Previous:||From: Antonios Katsikadamos||Date: 2006-10-24 13:31:29|
|Subject: postgres under suse linux|
pgsql-jdbc by date
|Next:||From: Dave Cramer||Date: 2006-10-24 16:13:29|
|Subject: Re: currval() race condition on server? |
|Previous:||From: Dave Cramer||Date: 2006-10-24 13:10:08|
|Subject: Re: currval() race condition on server?|