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
BODY {font:10pt Tahoma,Verdana,sans-serif;}