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
