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