Re: Too much data received? - Mailing list pgsql-jdbc

Barry Lind wrote:
>
> 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)

Hi Barry,

Hmmm, maybe the problem is only with the handling of error responses from
the back end?

The problem arises because PG_Stream.ReceiveString calls in Connection.ExecSQL
class put a bound on the length of strings received from the backend.

I think I originally saw the problem when an INSERT that included a
*very* long text field entry generated an exception (I had dropped a
function used as a trigger on inserts)) - the message that
comes back from the back end includes (as near as I can remember)
the original insert text, generating the above.  The exception above
went away when I bumped the size of receive_sbuf to something larger
than 8096 [this was with jdbc7.1-1.2.jar] and changed the calls
to use the new size where they had been using 8096 before.  I bumped it to
262144, incidently - these were large text fields.  This enabled me to
find the other error and fix it.

I'm not sure if ReceiveString is used when dealing with INSERT/SELECT of
text fields or not - I had assumed it was, but if you don't see the problem
then perhaps it's limited only to similar error cases?  If that's the case, then
there's really no need for the changes I've made!  [And I'll happily
drop them!] (but perhaps there should be another way to handle this situation?)

It's a little difficult for me to produce a small test case - this arose
when running an application that's pretty large and uses a lot of custom
classes -as well as needing several other applications (logging service,
message service, etc.).  I'm reluctant to try and pare it down if this was
really only a problem when dealing with error message text.

If you'd like to pursue it (that is, this is more than a problem when
receiving the text from error messages), let me know and I'll see if I
can generate it again.

Thanks!
--
Steve Wampler-  SOLIS Project, National Solar Observatory
swampler@noao.edu