Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning
От | Daniel Gustafsson |
---|---|
Тема | Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning |
Дата | |
Msg-id | 7AED6906-7A2E-47CB-93D4-C193D406417B@yesql.se обсуждение исходный текст |
Ответ на | Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning
|
Список | 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 по дате отправления: