Re: [JDBC] currval() race condition on server?

From: "Adriaan Joubert" <a(dot)joubert(at)albourne(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: [JDBC] currval() race condition on server?
Date: 2006-10-24 16:20:04
Message-ID: 20061024162004.3e08f577@mailhost.albourne.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

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.Thanks! That is good to know, as it makes clear that the problem is elsewhere!


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?
Yes, I am using a connection pool, but from the jdbc log it looks as if both statements are executed in a single trip to the backend, so this leaves the trigger. Best guess, as you say, is that there is an error condition somewhere in the trigger so that nextval is not executed. I'll have another close look at the trigger code - it was written 6-7 years ago and only patched up for the new protocol version and to add the macros required in 8.2, so it could do with a good going over.

Thanks to everybody for all the help!

Adriaan

Browse pgsql-jdbc by date

  From Date Subject
Next Message JEAN-PIERRE PELLETIER 2006-10-24 20:45:08 server process (PID 1188) exited with exit code -1073741819, 8.2 beta1
Previous Message Dave Cramer 2006-10-24 16:13:29 Re: currval() race condition on server?