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

From Tom Lane
Subject Re: In what range of the code can we read debug_query_string?
Date
Msg-id 3389.1527257288@sss.pgh.pa.us
Whole thread Raw
In response to In what range of the code can we read debug_query_string?  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: In what range of the code can we read debug_query_string?  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> 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.

I think this patch is a bad idea.  In the first place, debug_query_string
is generally understood as the current *client* command string, not
something internally generated.  In the second place, it looks way too
easy for this to leave debug_query_string as a dangling pointer,
ie pointing at a dropped plancache entry.

There might be a case for providing some way to get at the current
actively-executing query's string, using a protocol that can deal
with nesting of execution.  (This might already be more or less
possible via ActivePortal->sourceText, depending on what you think
the semantics ought to be.)  But debug_query_string was never
intended to do that.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: rule-related crash in v11
Next
From: Andrew Dunstan
Date:
Subject: Re: Enhancement Idea - Expose the active value of a parameter in pg_settings