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

> On 30 May 2024, at 11:10, David Rowley <dgrowleyml@gmail.com> wrote:
> 
> On Thu, 30 May 2024 at 18:25, Daniel Gustafsson <daniel@yesql.se> wrote:
>> 
>>> On 30 May 2024, at 03:26, David Rowley <dgrowleyml@gmail.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