Re: Bug in pg_stat_statements

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Sami Imseih <samimseih@gmail.com>, Dmitry Dolgov <9erthalion6@gmail.com>, Konstantin Knizhnik <knizhnik@garret.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-10-29T01:16:40Z
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 Tue, Oct 28, 2025 at 12:31:23PM +0200, Alvaro Herrera wrote:
> Hmm, yeah, now that you mention this, it seems rather odd that
> pgss_store() is messing with (modifying) the jstate it is given.  If we
> had multiple modules using a planner_hook to interact with the query
> representation, what each module sees would be different depending on
> which hook is called first, which sounds wrong.  Maybe, as you say, we
> do need to consider this a design flaw that should be fixed in a more
> principled fashion ... and it's pretty hard to see that we could
> backpatch any such fixes.  It's a pretty old issue though (you probably
> notice I hesitate to call it a bug.)

It's hard to call that a bug when nothing in core is broken directly
because of it, we are just assuming that it impacts other extensions.
Now we have always been kind of bad in terms of defining what loaded
extensions should or not should be able to do, also depending on the
order their hooks are loaded.

> So I agree with you: we should fix
> the specific bug first across branches, and the reworking of the
> jumbling framework should be done afterwards in master only.

Agreedn.

> I'm going to get the first patch pushed, after looking at it more
> carefully.

Cool, thanks!
--
Michael