> 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)
