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

On Sun, Jun 8, 2025 at 8:09 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Sat, Jun 07, 2025 at 10:19:53PM +0530, Dilip Kumar wrote:
> > I didn't get time to debug, I might look into it tomorrow if someone
> > doesn't do it before that, but I am able to reproduce the issue and
> > seems like problem is with respect to computing the quer_loc in below
> > loop, and due to that 'quer_loc' is becoming bigger than query_len and
> > hitting the assert.
>
> The loop in charge of assigning the constants in the queries needs to
> be smarter in terms of the new locations assigned to sub-queries, here
> the VALUES one.
>
> 499edb09741b is the origin of the regression, so open item assigned to
> me (will look into it later), adding Anthonin in CC.

Thanks, I was looking into the commit pointed by you, I found this
change problematic,

transformTopLevelStmt(ParseState *pstate, RawStmt *parseTree)
{
Query *result;

+ /* Store RawStmt's length and location in pstate */
+ pstate->p_stmt_len = parseTree->stmt_len;
+ pstate->p_stmt_location = parseTree->stmt_location;
+
/* We're at top level, so allow SELECT INTO */
result = transformOptionalSelectInto(pstate, parseTree->stmt);

- result->stmt_location = parseTree->stmt_location;
- result->stmt_len = parseTree->stmt_len;

So here before this commit we were setting the 'query->stmt_len' as
parseTree->stmt_len from the Top level statement, but after this fix,
we are setting the length of the select statement, in query->stmt_len,
because now we are doing that in
transformOptionalSelectInto->transformStmt->setQueryLocationAndLength
so that is just transferring the select statement and has length of
that. Due to that in generate_normalized_query() we are getting
'quer_loc' bigger than the 'query_len'.

--
Regards,
Dilip Kumar
Google