Joe Conway <mail@joeconway.com> writes:
> On 7/1/20 6:22 PM, Tom Lane wrote:
>> Hm, I was expecting that the last successful iteration of
>> enlargeStringInfo would increase the buffer size to MaxAllocSize,
>> so that we'd really only be losing one byte (which we can't avoid
>> if we use stringinfo). But you're right that it's most likely moot
>> since later manipulations of such a result would risk hitting overflows.
> Sorry to open this can of worms again, but I couldn't get my head past the fact
> that reading the entire file would have a different size limit than reading the
> exact number of bytes in the file.
Are you sure there actually is any such limit in the other code,
after accounting for the way that stringinfo.c will enlarge its
buffer? That is, I believe that the limit is MaxAllocSize minus
five bytes, not something less.
> So, inspired by what you did (and StringInfo itself) I came up with the
> attached. This version performs equivalently to your patch (and HEAD), and
> allows files up to and including (MaxAllocSize - VARHDRSZ) -- i.e. exactly the
> same as the specified-length case and legacy behavior for the full file read.
I find this way overcomplicated for what it accomplishes. In the
real world there's not much difference between MaxAllocSize minus
five and MaxAllocSize minus four.
regards, tom lane