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
