| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | Martin Huang <jjja5555(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_stat_statements: Fix nested tracking for implicitly closed cursors |
| Date: | 2026-01-16 22:12:48 |
| Message-ID: | aWq34FtyC6Y4pdig@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jan 13, 2026 at 07:01:48PM -0600, Sami Imseih wrote:
> Correct.Thanks for spotting this oversight. I think the is_txn_end flag must
> be reset in all hook functions that call pgss_store, except in pgss_ExecutorEnd,
> where we just have to check is_txn_end and increment the nesting_level. Also,
> I added a PG_TRY/FINALLY inside pgss_ExecutorEnd to ensure we reset the
> nesting_level is reset.
>
> I added a test case for the query you mentioned above.
@@ -1079,35 +1095,47 @@ pgss_ExecutorEnd(QueryDesc *queryDesc)
{
int64 queryId = queryDesc->plannedstmt->queryId;
- if (queryId != INT64CONST(0) && queryDesc->totaltime &&
- pgss_enabled(nesting_level))
+ if (is_txn_end)
+ nesting_level++;
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.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2026-01-16 22:20:14 | Re: POC: Parallel processing of indexes in autovacuum |
| Previous Message | Michael Paquier | 2026-01-16 22:04:53 | Re: [PATCH] remove incorrect comment in pg_resetwal.c |