Re: pg_stat_statements stores WITH HOLD cursor query with literals

On Mon, Oct 26, 2026 at 05:16:45PM -0500, Sami Imseih wrote:
> I spent some time thinking about this today, and I can now see
> its usefulness. Initially I was thinking that nesting_level is the only
> thing that needs this state in pg_stat_statements and auto_explain, and
> was not sure if this complexity is worth it.

I was wondering a bit myself about the potential interactions between
auto_explain and PGSS, especially once they're bundled together, but I
did not dig much about the details of the interactions..

> Take for example a role switch between the DECLARE CURSOR and the cursor
> cleanup. Maybe not very common, but perhaps applications dealing with
> multi-tenancy/RLS could end up running into this without realizing.
>
> ```
> userid | toplevel | calls | query
> --------+----------+-------+----------------------------------------------
> user1 | t | 1 | DECLARE c CURSOR FOR SELECT $1 WHERE $2 = $3
> user2 | t | 1 | DECLARE c CURSOR FOR SELECT 1 WHERE 1 = 1;
> ```

Fancy. I've never seen that, but I suspect you would..

> There is also a similar shape with auto_explain. The cursors were not
> sampled when they started. After raising auto_explain.sample_rate, the
> later SELECT makes the new sample rate effective. Then COMMIT closes
> the cursors while auto_explain thinks the current query should be
> sampled.

That counts as one more case here.

> One could argue which behavior we want to see in the above, but I think
> the point is that this QueryDesc state support could help us close some
> of these issues.

I don't really want to enter in the realm where we add more
per-extension fields in backend structures, especially if multiple
extensions have a risk of stepping on each other.

> As far as v3- goes, they both look good to me, and I could not find
> anything wrong with them.

Okay, thanks. Let's use this infrastructure, then. I suspect that
Lukas Fittl would also find uses for it, as he's a lot into monitoring
and, err.. analyzing. I am adding him in CC to make him aware of this
thread, at least, with QueryDesc extensibility in mind.
--
Michael