Re: LOCK TABLE oddness in PLpgSQL function called via

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