Re: Bug in pg_stat_statements

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Sami Imseih <samimseih(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Bug in pg_stat_statements
Date: 2025-10-29 01:16:40
Message-ID: aQFq-OAgR7Fr3u3I@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Manni Wood 2025-10-29 01:23:50 [PATCH] Add pg_get_tablespace_ddl() function to reconstruct CREATE TABLESPACE statement
Previous Message Jim Jones 2025-10-29 01:16:32 Re: display hot standby state in psql prompt