Re: setBinaryStream can abandon connection
От | Kris Jurka |
---|---|
Тема | Re: setBinaryStream can abandon connection |
Дата | |
Msg-id | Pine.BSO.4.56.0410171635180.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: > Kris Jurka wrote: > > > The message length will not cause the backend to allocate large amounts of > > memory, the individual parameter lengths are what actually allocates > > memory. > > Are you sure about this? I see in pq_getmessage (called from the main > backend loop via SocketBackend): > > 'len' is the total packet length, not a per-parameter length. Right you are. I was just looking in enlargeStringInfo and not where it was called from. > > > 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. > > I'd still like to see a more useful error message in the overflow case. > We really shouldn't be generating a negative message length in the first > place. OK. So we should calculate the total message length using a "long" variable to guard against overflow and then check that it doesn't exceed MaxAllocSize. If it does, do not issue the bind at all and throw an Exception in a fashion that keeps the connection in working order. I suppose we could also put direct checks on the setXXXStream calls to give a better error message to the user. Instead of a "total message length exceeded" it would tell you the failing call immediately. We'd still need the total message length check, but this would probably catch the majority of the cases. Yeah, we need to guard against negative message lengths somewhere. Kris Jurka
В списке pgsql-jdbc по дате отправления: