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