Re: BUG #18947: TRAP: failed Assert("len_to_wrt >= 0") in pg_stat_statements

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, Dilip Kumar <dilipbalaut@gmail.com>, a.kozhemyakin@postgrespro.ru, pgsql-bugs@lists.postgresql.org
Date: 2025-06-10T11:14:40Z
Lists: pgsql-bugs
On Tue, Jun 10, 2025 at 12:02:06PM +0200, Anthonin Bonnefoy wrote:
> One wrong assumption I made was that parenthesis aren't part of the
> select statement, which is definitely wrong with queries like '(SELECT
> 1) limit 1;'. As we don't have end location tracking, we don't have
> the possibility to get the length of the select statement.

Yeah.

> I've joined a possible (and very rough, this would definitely require
> more tests) fix:
> - SelectStmt's location is now the outermost '(' position
> - Don't track the length anymore in 'select_no_parens'
> - Nodes that are embedding a SelectStatement would need to update its
> length if necessary. For COPY, this is straightforward as we can use
> the parenthesis location surrounding the statement. With CTAS,
> SelectStmt's length should be updated if there's an existing
> opt_with_data.

Hmm.  I am wondering whether this would be enough; these are not the
only places where we use select_no_parens and select_with_parens.  I'd
be curious to see what you think a fully-bloomed fix should look like.
--
Michael

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Revert support for improved tracking of nested queries

  2. psql: fix order of join clauses when listing extensions