Bob Cart wrote:
> On Nov 30, 2003, at 4:40 PM, Oliver Jowett wrote:
>
>> AFAIK the driver never generates SET AUTOCOMMIT TO OFF; the only
>> thing it
>> does with server-side autocommit is to turn it on if the backend
>> defaults to
>> off (as is possible with a 7.3 server). So I'd hazard a guess that the
>> problematic query is actually being generated by your application
>> code, not
>> the JDBC driver; there's not much the driver can do about that case.
>>
>> Can you provide the full exception & stack trace that's generated, and
>> ideally a statement trace from the backend?
>>
>> (I took a quick look at the download URL you mentioned in a later
>> email, but
>> it's registration-required).
>>
>> -O
>
>
> Right. The driver for 7.4 should not even be able to generate SET
> AUTOCOMMIT TO OFF. That's one reason why I think this is a jdbc issue
> and not an application issue. The other reason is that the app works
> with so many other databases - including postgres 7.3. Also, the
> logistics of the release don't make it likely that the driver has been
> updated for all the changes that happened late in teh development
> cycle of pg7.4. 7.4 was just released a couple of weeks ago. From
> looking at various threads out on the net, Tom Lane removed the server
> side autocommit pretty recently. Now that the most recent jdbc driver
> the 7.4 beta was posted back in september, I don't see how it could
> have been patched up to support the autocommit change. Now if you are
> right and the driver never was able to SET AUTOCOMMIT TO OFF anyway,
> well we do have a tricky one. My guess is the application I'm using
> isn't smart enough to come up with an error string that says, "Error:
> SET AUTOCOMMIT TO OFF no longer supported". That's delivered via the
> jdbc driver. Doesn't seem to me that an app should be able to make the
> drive throw that even if it tried.
>
> Some brave soul out there needs to dig into that part of the driver
> code to see what's up. Go for it Oliver!
A stacktrace is really called for first before asking some soul to
review this. A very reasonable request.
The original report said that this was third party code. Any third
party code can have a statement.execute("SET AUTOCOMMIT OFF")
in their library because they naively implemented their transaction
model. And early postgres versions wouldn't have complained
(though they might not have generated the right results!).
I speak from experience since I was once new enough to JDBC to have done
just this and it ran for a long time before I fixed it.
So a stacktrace will clarify whether the third party code is doing this,
or whether postgresql is doing it,
and if so, where it's being done.
