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

From David Rowley
Subject Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning
Date
Msg-id CAApHDvqpUu-B4AEy6On7nwOfYz=V7HuhCgm9_UFr2i08_oKfdQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning
List pgsql-bugs
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 and the 2nd is
confusing because being unable to enlarge by zero seems like a strange
limitation.

David

David



pgsql-bugs by date:

Previous
From: Önder Kalacı
Date:
Subject: Re: BUG #18467: postgres_fdw (deparser) ignores LimitOption
Next
From: Daniel Gustafsson
Date:
Subject: Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning