From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | In what range of the code can we read debug_query_string? |
Date: | 2018-05-25 05:54:50 |
Message-ID: | 20180525.145450.145433303.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
set_query_debug_string.patch | text/x-patch | 2.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-05-25 05:58:41 | Re: [HACKERS] lseek/read/write overhead becomes visible at scale .. |
Previous Message | Michael Paquier | 2018-05-25 05:28:05 | pg_replication_slot_advance to return NULL instead of 0/0 if slot not advanced |