On Wed, May 12, 2021 at 4:54 PM torikoshia <torikoshia@oss.nttdata.com> wrote:
>
> Hi,
>
> During the discussion about memory contexts dumping[1], there
> was a comment that exposing not only memory contexts but also
> query plans and untruncated query string would be useful.
>
> I also feel that it would be nice when thinking about situations
> such as troubleshooting a long-running query on production
> environments where we cannot use debuggers.
>
> At that point of the above comment, I was considering exposing
> such information on the shared memory.
> However, since memory contexts are now exposed on the log by
> pg_log_backend_memory_contexts(PID), I'm thinking about
> defining a function that logs the plan of a running query and
> untruncated query string on the specified PID in the same way
> as below.
>
> postgres=# SELECT * FROM pg_log_current_plan(2155192);
> pg_log_current_plan
> ---------------------
> t
> (1 row)
+1 for the idea. I did not read the complete patch but while reading
through the patch, I noticed that you using elevel as LOG for printing
the stack trace. But I think the backend whose pid you have passed,
the connected client to that backend might not have superuser
privileges and if you use elevel LOG then that message will be sent to
that connected client as well and I don't think that is secure. So
can we use LOG_SERVER_ONLY so that we can prevent
it from sending to the client.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
