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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2006-10-24 16:03:09 | Re: materialized view |
Previous Message | Antonios Katsikadamos | 2006-10-24 13:31:29 | postgres under suse linux |
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2006-10-24 16:13:29 | Re: currval() race condition on server? |
Previous Message | Dave Cramer | 2006-10-24 13:10:08 | Re: currval() race condition on server? |