Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning

> On 30 May 2024, at 11:10, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Thu, 30 May 2024 at 18:25, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>>
>>> On 30 May 2024, at 03:26, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>>> The above will become:
>>> ERROR: string buffer exceeds maximum allowed length (1073741823)
>>> DETAIL: Cannot enlarge string buffer containing 1073741812 bytes by 32 more
>>
>> Should we use a more human readable unit than bytes in the errmsg as well?
>
> I wondered about that too. There were a couple of reasons I didn't. 1)
> It's easy to see that 1073741812 + 32 is greater than 1073741823. If
> we divided those down by 1024 a few times then that calculation can no
> longer be done. 2) I wanted to use MaxAllocSize rather than hard wire
> anything into the string. That left just doing something like
> MaxAllocSize / 1024 / 1024. If you did that with the limit size and
> the current string size, it would likely just turn into the same
> number and make the complaint confusing. e.g:
>
> ERROR: string buffer exceeds maximum allowed length (1023MB)
> DETAIL: Cannot enlarge string buffer containing 1023MB by 32 bytes more
>
> or
>
> ERROR: string buffer exceeds maximum allowed length (1023MB)
> DETAIL: Cannot enlarge string buffer containing 1023MB by 0MB more
>
> I know the bytes are hard to read, but I just don't feel either of the
> above are easier for a user to process. The first one gives them 2
> different units that they need to convert between

Fair enough, mixing units probably wont be more readable. The middle ground
might be a bit much:

ERROR: string buffer exceeds maximum allowed length (1023MB)
DETAIL: Cannot enlarge string buffer containing 1023MB (1073741823 bytes) by 32 bytes more

Did you omit bytes from the errmsg on purpose? "length" of a string buffer can
be interpreted as the number of characters, and that wouldn't be true for wide
chars.

> and the 2nd is
> confusing because being unable to enlarge by zero seems like a strange
> limitation.

Yeah, that would no doubt be a source of endless bug reports and Stack Overflow
searches.

--
Daniel Gustafsson