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

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 and the 2nd is
confusing because being unable to enlarge by zero seems like a strange
limitation.

David

David