Hi,
(adding TOm in Cc as committer/co-author of the original patch)
While adapting in pg_stat_kcache the fix for buggy nesting level calculation, I
noticed that one comment referencing the old approach was missed. Trivial
patch attached.
>From 3ca50f1e66896c9ffd4eff8c151f98735b928219 Mon Sep 17 00:00:00 2001
From: Julien Rouhaud <julien.rouh...@free.fr>
Date: Sat, 14 Sep 2024 12:18:19 +0800
Subject: [PATCH v1] Remove obsolete comment in pg_stat_statements
Commit 76db9cb6368 removed the use of multiple nesting counters but missed an
associated comment.
---
contrib/pg_stat_statements/pg_stat_statements.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/contrib/pg_stat_statements/pg_stat_statements.c
b/contrib/pg_stat_statements/pg_stat_statements.c
index 362d222f63..3c72e437f7 100644
--- a/contrib/pg_stat_statements/pg_stat_statements.c
+++ b/contrib/pg_stat_statements/pg_stat_statements.c
@@ -886,13 +886,6 @@ pgss_planner(Query *parse,
* We can't process the query if no query_string is provided, as
* pgss_store needs it. We also ignore query without queryid, as it
would
* be treated as a utility statement, which may not be the case.
- *
- * Note that planner_hook can be called from the planner itself, so we
- * have a specific nesting level for the planner. However, utility
- * commands containing optimizable statements can also call the planner,
- * same for regular DML (for instance for underlying foreign key
queries).
- * So testing the planner nesting level only is not enough to detect
real
- * top level planner call.
*/
if (pgss_enabled(nesting_level)
&& pgss_track_planning && query_string
--
2.46.0
