Re: Problems with protocol V3 after migration to latest driver - Mailing list pgsql-jdbc

From Kris Jurka
Subject Re: Problems with protocol V3 after migration to latest driver
Date
Msg-id Pine.BSO.4.56.0410250254430.5934@leary.csoft.net
Whole thread Raw
In response to Re: Problems with protocol V3 after migration to latest driver  ("Alexey Yudichev" <Alexey@francoudi.com>)
Responses Re: Problems with protocol V3 after migration to latest driver
Re: Problems with protocol V3 after migration to latest driver
List pgsql-jdbc

On Mon, 25 Oct 2004, Alexey Yudichev wrote:

> java.sql.SQLException: ERROR: large object 36376616 does not exist
>     at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1187)
>     at org.postgresql.core.v3.QueryExecutorImpl.receiveFastpathResult(QueryExecutorImpl.java:409)
>     at org.postgresql.core.v3.QueryExecutorImpl.fastpathCall(QueryExecutorImpl.java:345)
>     at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:67)
>     at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:106)
>     at org.postgresql.fastpath.Fastpath.getInteger(Fastpath.java:118)
>     at org.postgresql.largeobject.LargeObject.<init>(LargeObject.java:89)
>     at org.postgresql.largeobject.LargeObjectManager.open(LargeObjectManager.java:150)
>     at org.postgresql.jdbc2.AbstractJdbc2Statement.setBytes(AbstractJdbc2Statement.java:1011)
> [...]
>
> I repeat, with 7.4 drivers it works OK and, surprisingly, it works OK
> even with newest drivers on one of two server installations I have.

I can generate a similar failure with the attached test case.  The failure
only happens on the second time through and is caused by the fastpath API
not being aware of the transaction state.  In the example I've shown the
first time through it does setAutoCommit(false), but that doesn't actually
start a transaction (as it does in the 7.4 series) instead it waits for
the first query to be issued to start the transaction.  When using large
objects the large object needs to be created first before the INSERT query
is issued.  The first time through it does not fail because the driver
needs to query the backend to get some setup information for large objects
which starts a transaction.  The second time through it has this
information cached, so it proceeds to try and create a large object
without ever issuing a BEGIN.

I do notice that my stacktrace is different than yours, showing an error
on LargeObject.write while yours is in LargeObjectManager.open.  Let me
fix the problem I found first because there's not much point in further
testing of a known broken area.

Kris Jurka

Exception in thread "main" java.sql.SQLException: ERROR:  invalid
large-object descriptor: 0
    at
org.postgresql.core.v2.QueryExecutorImpl.receiveErrorMessage(QueryExecutorImpl.java:418)
    at
org.postgresql.core.v2.QueryExecutorImpl.receiveFastpathResult(QueryExecutorImpl.java:97)
    at
org.postgresql.core.v2.QueryExecutorImpl.fastpathCall(QueryExecutorImpl.java:59)
    at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:67)
    at org.postgresql.fastpath.Fastpath.fastpath(Fastpath.java:106)
    at
org.postgresql.largeobject.LargeObject.write(LargeObject.java:192)
    at
org.postgresql.jdbc2.AbstractJdbc2Statement.setBytes(AbstractJdbc2Statement.java:1016)
    at LOB.main(LOB.java:23)


Attachment

pgsql-jdbc by date:

Previous
From: "Alexey Yudichev"
Date:
Subject: Re: Problems with protocol V3 after migration to latest driver
Next
From: Markus Schaber
Date:
Subject: Re: Calling functions with smallint fails