In what range of the code can we read debug_query_string? - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject In what range of the code can we read debug_query_string?
Date
Msg-id 20180525.145450.145433303.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
Responses Re: In what range of the code can we read debug_query_string?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hello.

While looking into *some* tool that heavily reliant on
debug_query_string, I found that the tool can miss it.  However I
believed that it is always set when post_parse_analyze_hook is
called, it is not while processing DESCRIBE message of extended
protocol. I believe that the assumption is not so ridiculous.

The call stack is as the follows.

parse_analze()
pg_analyze_and_rewrite()
RevalidateCachedQuery()
CachedPlanGetTargetList()
exec_describe_statement_message()
PostgreMain() (message 'DS')

It is set for other kinds of message, (parse, bind, execute). I
think fastpath, close, flush and sync don't need that. If it is
reasonable to assume that we can see debug_query_string in the
DESCRIBE path, the attached patch would work.

The exec_describe_statement_message() case seems rather simple
but the exec_describe_portal_message() case is troublesome.

But, in the first place, the biggest problem is the fact that I
myself haven't been able to run the path...

Any suggestions, thoughts, opinions are welcome.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
*** a/src/backend/tcop/postgres.c
--- b/src/backend/tcop/postgres.c
***************
*** 2399,2407 **** exec_describe_statement_message(const char *stmt_name)
--- 2399,2414 ----
      {
          List       *tlist;
  
+         /*
+          * Report query to various monitoring facilities.
+          */
+         debug_query_string = psrc->query_string;
+ 
          /* Get the plan's primary targetlist */
          tlist = CachedPlanGetTargetList(psrc, NULL);
  
+         debug_query_string = NULL;
+ 
          SendRowDescriptionMessage(&row_description_buf,
                                    psrc->resultDesc,
                                    tlist,
*** a/src/backend/utils/cache/plancache.c
--- b/src/backend/utils/cache/plancache.c
***************
*** 1429,1434 **** CachedPlanGetTargetList(CachedPlanSource *plansource,
--- 1429,1436 ----
                          QueryEnvironment *queryEnv)
  {
      Query       *pstmt;
+     bool        reset_debug_query_string = false;
+     List       *ret;
  
      /* Assert caller is doing things in a sane order */
      Assert(plansource->magic == CACHEDPLANSOURCE_MAGIC);
***************
*** 1441,1453 **** CachedPlanGetTargetList(CachedPlanSource *plansource,
      if (plansource->resultDesc == NULL)
          return NIL;
  
      /* Make sure the querytree list is valid and we have parse-time locks */
      RevalidateCachedQuery(plansource, queryEnv);
  
      /* Get the primary statement and find out what it returns */
      pstmt = QueryListGetPrimaryStmt(plansource->query_list);
  
!     return FetchStatementTargetList((Node *) pstmt);
  }
  
  /*
--- 1443,1470 ----
      if (plansource->resultDesc == NULL)
          return NIL;
  
+     
+     /*
+      * Report query to various monitoring facilities if we haven't done.
+      */
+     if (!debug_query_string && plansource->query_string)
+     {
+         debug_query_string = plansource->query_string;
+         reset_debug_query_string = true;
+     }
+ 
      /* Make sure the querytree list is valid and we have parse-time locks */
      RevalidateCachedQuery(plansource, queryEnv);
  
      /* Get the primary statement and find out what it returns */
      pstmt = QueryListGetPrimaryStmt(plansource->query_list);
  
!     ret = FetchStatementTargetList((Node *) pstmt);
! 
!     if (reset_debug_query_string)
!         debug_query_string = NULL;
! 
!     return ret;
  }
  
  /*

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: pg_replication_slot_advance to return NULL instead of 0/0 if slotnot advanced
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..