Re: issues with SQL size st.execute(SQL) in 8.3.3

From: Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: issues with SQL size st.execute(SQL) in 8.3.3
Date: 2008-10-18 19:24:35
Message-ID: 200810182224.35872.achill@matrix.gatewaynet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Στις Saturday 18 October 2008 16:48:12 ο/η Kris Jurka έγραψε:
>
> On Sat, 18 Oct 2008, Achilleas Mantzios wrote:
>
> > Στις Friday 17 October 2008 20:34:57 ο/η Kris Jurka έγραψε:
> >>
> >> It all depends on whether you are relying on any V3 features in other
> >> places. I have a fix for the issue (attached). I'm still testing it and
> >> will hopefully apply it this weekend.
> >
> > Regarding V2, its just a simple program like the one i showed,
> > can you point some cases which would explicitly rely on V3 features ?
> > Which JDBC method calls would be affected by the enforcement of V2?
> > Can the rest of the backends (other than the one serving the v2 client) be
> > affected in any way by this?
>
> If it's just this connection, then switching to V2 is a fine solution. A
> simple execute works fine and won't affect anything else. I thought you
> were considering switching your whole application to V2 which needs a
> little more thought. As an example ParameterMetaData is only
> implementable with the V3 protocol.
>
> I have applied to previous patch to CVS, and it should fix your problem,
> but it does not solve every deadlock situation. The deadlock avoidance
> code was originally written for batch execution which should not be
> returning ResultSets. If many long queries that return significant
> results are issued with a single execute we will still deadlock. Solving
> this would require tracking the bytes actually sent rather than the number
> of queries sent, or a more significant redesign to use multiple threads or
> NIO. Attached is sample code which still deadlocks.

Kris,
many thanx for the explanation of the problem and the patch.

>
> Kris Jurka

--
Achilleas Mantzios

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message jgassner 2008-10-21 06:27:11 Connection hanging on INSERT apparently due to large batch size and 4 CPU cores
Previous Message Kris Jurka 2008-10-18 13:48:12 Re: issues with SQL size st.execute(SQL) in 8.3.3