Re: Regression in statement locations

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Sami Imseih <samimseih(at)gmail(dot)com>, David Steele <david(at)pgbackrest(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>
Subject: Re: Regression in statement locations
Date: 2025-05-20 06:41:28
Message-ID: CACJufxF+Eh8BeByxi1N8erUS128ttVbYR+=7HbU+xQ-HYp-L7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 20, 2025 at 11:59 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Tue, May 20, 2025 at 08:38:47AM +0900, Michael Paquier wrote:
> > With the semicolon in place, stmt_len gets set for the last query of
> > the string. Still digging more..
>
> And got it. The problem is that we are failing to update the
> statement location in a couple of cases with subqueries, and that we
> should handle (p_stmt_len == 0) as of using the remaining bytes in
> the string when a location is available, but the code was too
> aggressive in thinking that the length = 0 case should be always
> discarded.
>

I was thinking of using strlen(pstate->p_sourcetext) - qry->stmt_location;
in setQueryLocationAndLength,
then I saw your changes in the pg_overexplain module.

maybe put some comments on top of setQueryLocationAndLength
for (qry->stmt_len == 0) case, but i saw the comments on the bottom
of setQueryLocationAndLength.

Overall, it looks good to me.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2025-05-20 06:49:28 Please update the pgconf.dev Unconference notes
Previous Message Michael Paquier 2025-05-20 06:38:13 Re: Add comment explaining why queryid is int64 in pg_stat_statements