Re: setBinaryStream can abandon connection
От | Kris Jurka |
---|---|
Тема | Re: setBinaryStream can abandon connection |
Дата | |
Msg-id | Pine.BSO.4.56.0410171602050.16087@leary.csoft.net обсуждение исходный текст |
Ответ на | Re: setBinaryStream can abandon connection (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: setBinaryStream can abandon connection
|
Список | 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
В списке pgsql-jdbc по дате отправления: