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

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: michael(dot)banck(at)netapp(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning
Date: 2024-05-30 10:27:12
Message-ID: 9DF26EE9-811F-465B-9999-9B8D47AB6139@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On 30 May 2024, at 11:55, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

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

Good point.

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

+1

--
Daniel Gustafsson

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message vaibhave postgres 2024-05-30 10:58:00 pg_restore: fails to restore post-data items due to circular FK deadlock
Previous Message David Rowley 2024-05-30 09:55:49 Re: BUG #18484: "Cannot enlarge string buffer" during parallel execution of prepared statement/partitioning