In what range of the code can we read debug_query_string?

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

Responses

Browse pgsql-hackers by date

  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