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

On Thu, 30 May 2024 at 21:27, Daniel Gustafsson <daniel@yesql.se> wrote:
> ERROR:  string buffer exceeds maximum allowed length (1023MB)
> DETAIL:  Cannot enlarge string buffer containing 1023MB (1073741823 bytes) by 32 bytes more

That's better than the two alternatives I showed. The problem now is
that the actual limit (0x3fffffff), is 1 byte less than 1024MB, so
showing 1023MB is likely debatable. It's just 1 byte in a ~million
short.  I kinda think we could just avoid any future revisits from
people having concern about which direction we round to by just not
rounding and doing bytes.  It's not as if it's a message we expect
many people to see, but if they do see it, it's probably going to be
analyzed quite a bit. Having the highest level of detail for that
seems like a good idea.  I don't think it should leave any other
questions other than "Why is Postgres trying to build such a long
string?". Of course, fixing that one is harder.

> 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.

Not on purpose. I do think (%zu bytes) would be better than (%zu).  I
only thought about that while typing "MB" in the 2nd email.

David