Re: Problems with protocol V3 after migration to latest driver

From: Kris Jurka <books(at)ejurka(dot)com>
To: Alexey Yudichev <Alexey(at)francoudi(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Problems with protocol V3 after migration to latest driver
Date: 2004-10-25 08:06:42
Message-ID: Pine.BSO.4.56.0410250254430.5934@leary.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
LOB.java text/plain 876 bytes

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Markus Schaber 2004-10-25 09:15:08 Re: Calling functions with smallint fails
Previous Message Alexey Yudichev 2004-10-25 07:36:11 Re: Problems with protocol V3 after migration to latest driver