At 03:29 PM 10/2/2001, Tom Lane wrote: >Once a lock has been grabbed, the *only* way it can be let go is to end >the transaction.
That's my understanding as well. >So my new theory is that the JDBC driver is issuing an auto-commit at >points where you're not expecting it. But I'm only issuing *one* JDBC statement: select next_id_block(?, ?) Once it returns, I grab the single value from the ResultSet, close the ResultSet, and commit the transaction. All of the SQL magic is being done by the PLpgSQL stored function on the backend. It's almost like the PLpgSQL function itself is running in auto-commit mode, but then I don't see how I could be getting a serialization error. And the docs say that the function will run in the caller's transaction, so I'm just confused. My suspicion was that JDBC was somehow interacting oddly with PLpgSQL, but more and more it's looking like PLpgSQL is the culprit all on its own. I'll try posing the question to the general mailing list since there are none specific to stored procedure languages, or is there a more appropriate list? >but if you turn on query logging in the server you'll probably see the >evidence soon enough. Y'know, that's a very good idea. I haven't done that before -- is it fairly prominent in the online documentation? I'm off to find it now... Thanks. Peace, Dave ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster