Re: pg_stat_statements: Fix nested tracking for implicitly closed cursors

> > 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?
>
> I did not have in mind a backend structure with a state allocated for
> as long as the session lives would be a good fit. It is a bit better
> than a static flag to drive the decisions, but it is still open to
> being incorrect because it would require more code paths to reset it.
> Something like QueryDesc would be a better fit, for a state that
> sticks for as long as a top-level transaction is running. We are not
> doing that stuff really well yet, though, if we want to track data
> like a nesting level. So my short answer is that I do not know yet
> what a good answer is, but it is definitely a problem to have some
> duplicated logic to calculate a nesting level across many extensions.
> QueryDesc was one that popped in mind, like you, but I got reminded
> that utility.c has no idea about that, so... Now QueryDesc knows
> about a PlannedStmt, which is something that utility.c knows.

Before going down the fix in pg_stat_statements directly, it did cross my
mind about doing nesting_level tracking in core, but I was not sure if
there is an appetite for this. I may have been wrong.

nesting_level is used in both auto_explain and pg_stat_statements
in contrib, and as mentioned by Lukas there are other extensions
out in the ecosystem that do the same.

I am not opposed to the idea of going down this path. I took a brief look
today and found some missing nesting_level tests [0].

My initial thought is this would need some type of a backend stucture.
I am not sure how attaching this to something like a queryDesc will
be useful ( couldn't a single execution have multiple queryDesc? i.e
nested queries, etc. )

[0] https://www.postgresql.org/message-id/CAA5RZ0uK1PSrgf52bWCtDpzaqbWt04o6ZA7zBm6UQyv7vyvf9w%40mail.gmail.com

--
Sami Imseih
Amazon Web Services (AWS)