Re: queryId constant squashing does not support prepared statements
Álvaro Herrera <alvherre@kurilemu.de>
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Sami Imseih <samimseih@gmail.com>, Dmitry Dolgov <9erthalion6@gmail.com>, Junwang Zhao <zhjwpku@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-06-26T16:42:46Z
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 →
-
Fix typo in comment
- a3994ec6acb2 18.0 landed
-
Make query jumbling also squash PARAM_EXTERN params
- c2da1a5d6325 18.0 landed
-
Fix squashing algorithm for query texts
- 0f65f3eec478 18.0 landed
-
pg_stat_statements: Fix parameter number gaps in normalized queries
- 3c03b8cd7979 13.22 landed
- 8a1459f62ad1 14.19 landed
- 130300a15407 15.14 landed
- 7e8b44f4e0e6 16.10 landed
- 290e8ab32ac5 17.6 landed
- 35a428f30b15 18.0 landed
On 2025-Jun-25, Michael Paquier wrote:
> On Tue, Jun 24, 2025 at 07:45:15PM +0200, Alvaro Herrera wrote:
> > + /*
> > + * If we have an external param at this location, but no lists are
> > + * being squashed across the query, then we skip here; this will make
> > + * us print print the characters found in the original query that
> > + * represent the parameter in the next iteration (or after the loop is
> > + * done), which is a bit odd but seems to work okay in most cases.
> > + */
> > + if (jstate->clocations[i].extern_param && !jstate->has_squashed_lists)
> > + continue;
>
> + * us print print the characters found in the original query that
>
> The final commit includes this comment, with a s/print print/print/
> required.
Ugh. Fixed, thanks for noticing that.
> > Lastly, I decided not to do a catversion bump. As far as I can tell,
> > changes in the jumbling functions do not need them. I tried an
> > 'installcheck' run with a datadir initdb'd with the original code, and
> > it works fine.
>
> This reminds me of 4c7cd07aa62a and this thread:
> https://www.postgresql.org/message-id/1364409.1727673407@sss.pgh.pa.us
>
> Doesn't the change in the Param structure actually require one because
> it can change the representation of some SQL functions? I am not
> completely sure.
Hmm, but the Param structure didn't actually change; only its jumbling
function did (and others that rely on LocationLen). So I think what
could happen here if there's no catversion is that somebody has a
pg_stat_statements populated with query Ids for some queries that have a
different queryIds when computed with the new code. So they're going to
have duplicates in pg_stat_statements. I think this is a pretty minor
problem, so I'm not inclined to do a catversion bump for it.
Anyway we have one due to 0cd69b3d7ef3, so it's moot now. (But it's a
good discussion to have, for the future.)
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Niemand ist mehr Sklave, als der sich für frei hält, ohne es zu sein."
Nadie está tan esclavizado como el que se cree libre no siéndolo
(Johann Wolfgang von Goethe)