Horton

Re: Bug in pg_stat_statements

Sami Imseih <samimseih@gmail.com>

View thread
From: Sami Imseih <samimseih@gmail.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Konstantin Knizhnik <knizhnik@garret.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-10-28T17:55:05Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_stat_statements: Fix handling of duplicate constant locations

>
> > > On Fri, Oct 24, 2025 at 07:04:59PM -0500, Sami Imseih wrote:
> > > v4 corrects some code comments.
> >
> > The fix in the first patch looks good, thanks.
>
> Yeah, I think this general idea is sensible.  However, I think we should
> take it one step further and just remove last_loc entirely.  I think
> this makes the code a bit clearer.  How about the attached?

getting rid of last_loc makes sense because the list is sorted makes
sense. I like this, definitely cleaner.

One minor comment is to change is to remove the "let's save it" but
in the comments, as we are no longer saving a last_loc.

                /*
-                * We have a valid location for a constant that's not
a dupe, let's
-                * save it.  Lex tokens until we find the desired constant.
+                * We have a valid location for a constant that's not
a dupe. We Lex
+                * tokens until we find the desired constant.
                 */


--
Sami