Skip site navigation (1) Skip section navigation (2)

Re: setBinaryStream can abandon connection

From: Kris Jurka <books(at)ejurka(dot)com>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: setBinaryStream can abandon connection
Date: 2004-10-17 21:15:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc

On Mon, 18 Oct 2004, Oliver Jowett wrote:

> I think we have a secondary problem here in that we've seen at least one 
> instance where app code passes Integer.MAX_VALUE as the length argument 
> when it does not know the actual length beforehand. a) we are going to 
> overflow a signed 32-bit int for the Bind message's length and b) even 
> if we have a large-but-not-too-large length, isn't the backend going to 
> run out of memory if we pass that on directly?

Some details on what actually happens:

When overflow happens the backend logs "invalid message length" and the 
connection is broken.

The message length will not cause the backend to allocate large amounts of 
memory, the individual parameter lengths are what actually allocates 
memory.  In the case of very large parameter values the error, "invalid 
string enlargement request size XXXXX", occurs.  This makes sense because 
the largest a text/bytea field can be is 1 GB in size.  So it is not an 
arbitrary length check depending on the number of parameters, but instead 
an exact check on each parameter.

So if we don't have a problem with a broken connection we don't actually 
need to check for these errors because they don't do anything terrible, 
but obviously I believe a broken connection is bad.

Kris Jurka

In response to


pgsql-jdbc by date

Next:From: Oliver JowettDate: 2004-10-17 21:27:08
Subject: Re: setBinaryStream can abandon connection
Previous:From: Oliver JowettDate: 2004-10-17 20:31:04
Subject: Re: Problem with PostgreSQL JDBC driver

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group