> Couldn't it be possible that we reach this stack of execution with > is_txn_end = true but we don't intend it to be so? For example, > imagine first that we reach pgss_ProcessUtility() for a COMMIT > TransactionStmt, second we error without resetting is_txn_end, third a > different portal is executed a with the same backend: we could exit > the executor with is_txn_end set and nesting_level increased but we > did not intend these events to happen.
This is the key point to this fix. So, in v2, is_txn_end is reset at the start of pgss_planner, pgss_post_parse_analyze and pgss_ProcessUtility. But now I realized that is_txn_end should also be reset at pgss_ExecutorStart/Run and should always be reset at the end of pgss_ExecutorEnd. So in your example above the new portal will go through one of the hooks which will reset is_txn_end at the start. Basically, we have to go through one of pgss_planner, pgss_post_parse_analyze and pgss_ProcessUtility, pgss_ExecutorRun or pgss_ExecutorStart for any command, so resetting this value at the start of these hooks should ensure that is_txn_end = true does not incorrectly persist across statements. right? ( oops, I just realized my example at the start of the thread doe not indicate that this issue only occurs with pg_stat_statements.track="all" ) -- Sami Imseih Amazon Web Services (AWS)
v3-0001-pg_stat_statements-Fix-nested-tracking-for-implic.patch
Description: Binary data
