Re: pg_stat_statements: Fix nested tracking for implicitly closed cursors

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-19 03:18:24
Message-ID: aW2igHBhiRI_Ud7Q@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 16, 2026 at 06:12:16PM -0600, Sami Imseih wrote:
> 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.

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?
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2026-01-19 03:22:21 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Richard Guo 2026-01-19 02:39:37 Re: Fwd: pg18 bug? SELECT query doesn't work