Message-ID: <3B4A58B2.2080303@xythos.com>
Date: Mon, 09 Jul 2001 18:21:54 -0700
From: Barry Lind <barry@xythos.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010628
MIME-Version: 1.0
To: Steve Wampler <swampler@noao.edu>
CC: postgres-jdbc <pgsql-jdbc@postgresql.org>
Subject: Re: Too much data received?
References: <3B45E785.6CAB7273@noao.edu> <3B49E980.4396628B@noao.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Steve,

In looking at the source code I couldn't explain why you would be 
getting the error below.  (All of the places that I see a max buffer 
size specified, seem to be appropriate and shouldn't generate the error 
you are seeing).  Can you send a test case to the list for me to 
investigate this further?

thanks,
--Barry

Steve Wampler wrote:

> Steve Wampler wrote:
> 
> ...
> 
>>Too much data was received.
>>        at org.postgresql.PG_Stream.ReceiveString(PG_Stream.java:306)
>>        at org.postgresql.Connection.ExecSQL(Connection.java:532)
>>        at org.postgresql.jdbc2.Statement.execute(Statement.java:294)
>>        at org.postgresql.jdbc2.Statement.executeUpdate(Statement.java:78)
>>        at OCS.database.DbServer.execute(DbServer.java:271)
>>
>>I seem to remember discussion on a limit in the jdbc driver that might
>>be causing this, but couldn't find it in the psql-jdbc mail archives.
>>
>>Am I likely correct in this being the problem?  Is there a fix in the
>>works?
>>
> 
> I took a look at the code for the jdbc driver and see how to increase the
> size of the receive string buffer.  (I think that there is no limit on
> the size of a query/command, just on results - is that correct?)
> 
> Is any one looking at removing the limit entirely?  I can (and have)
> bumped the limit up, but wonder if it might not be better to just avoid
> the problem entirely (if the back end can handle sending an absurdly
> long result, why shouldn't the front end accept it?).  Since the
> data is coming from the backend (presumably a comparitively slow
> operation), it doesn't seem that any performance hit would be
> particularly noticable (if well designed) and could likely be restricted
> to those cases where the results are absurdly long...
> 
> 
> ----
> Steve Wampler-  SOLIS Project, National Solar Observatory
> swampler@noao.edu
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 
>