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