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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, a(dot)kozhemyakin(at)postgrespro(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18947: TRAP: failed Assert("len_to_wrt >= 0") in pg_stat_statements
Date: 2025-06-10 11:14:40
Message-ID: aEgToLnBX9W43ne-@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Laurenz Albe 2025-06-10 14:44:42 Re: BUG #18804: LISTEN on channel fails with "could not access status of transaction"
Previous Message Andrei Varashen 2025-06-10 10:02:38 Re: BUG #18804: LISTEN on channel fails with "could not access status of transaction"