Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning - Mailing list pgsql-bugs

From Daniel Gustafsson
Subject Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning
Date
Msg-id 7AED6906-7A2E-47CB-93D4-C193D406417B@yesql.se
Whole thread Raw
In response to Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning
List pgsql-bugs
> 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




pgsql-bugs by date:

Previous
From: David Rowley
Date:
Subject: Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning
Next
From: David Rowley
Date:
Subject: Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning