Received: from noao.edu (email.tuc.noao.edu [140.252.1.54]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f69HRTa80845 for ; Mon, 9 Jul 2001 13:27:30 -0400 (EDT) (envelope-from swampler@noao.edu) Received: from reynaud.tuc.noao.edu ([140.252.38.6] verified) by noao.edu (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1333485; Mon, 09 Jul 2001 10:27:28 -0700 Received: from noao.edu (localhost [127.0.0.1]) by reynaud.tuc.noao.edu (8.9.1/8.9.1/SAG-04Feb01) with ESMTP id KAA27149; Mon, 9 Jul 2001 10:27:28 -0700 (MST) Message-ID: <3B49E980.4396628B@noao.edu> Date: Mon, 09 Jul 2001 10:27:28 -0700 From: Steve Wampler Organization: National Solar Observatory X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: postgres-jdbc Subject: Re: Too much data received? References: <3B45E785.6CAB7273@noao.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Archive-Number: 200107/53 X-Sequence-Number: 973 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