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 →
-
pg_stat_statements: Fix handling of duplicate constant locations
- b1635c166698 18.1 landed
- 16edc1b94fc2 19 (unreleased) landed
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