Re: pg_stat_statements: Fix nested tracking for implicitly closed cursors

On Sun, Jan 18, 2026 at 7:18 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> Hmm. While reading through the patch, I am wondering if this approach
> to this kind of problem is the right thing to do long-term, relying on
> a static flag to decide if the nesting level should be manipulated or
> not when we end the executor. pgss is not the only module where I
> have seen that we want to track a nesting level in a precise way. So
> could be it more flexible to attach that to a backend structure at
> this point and make manipulations of this number through the core
> backend, reducing TRY/CATCH blocks required in extension code?

+1

I think tracking nesting level in core would make a lot of sense -
I've noticed this too that extensions (pg_wait_sampling, pg_qualstats,
pg_stat_plans, etc) seem to keep re-inventing this, and I assume the
definition of this would be the same across extensions.

Not sure if you already had a place in mind, but thinking through
where we could attach it, I realized two things:

1) QueryDesc seems like a reasonable struct to communicate nesting
level (since it gets passed to the relevant executor hooks already),
but that doesn't get passed to ProcessUtility today
2) ProcessUtility has an existing indicator for top-level statements
in ProcessUtilityContext (PROCESS_UTILITY_TOPLEVEL)

Were you thinking of actually using a backend struct (i.e.
PgBackendStatus) and keep changing that as we run through the
different execution levels, and exposing a helper function to retrieve
it?

Thanks,
Lukas

--
Lukas Fittl