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.


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to