Re: RFC: Logging plan of the running query
От | Bharath Rupireddy |
---|---|
Тема | Re: RFC: Logging plan of the running query |
Дата | |
Msg-id | CALj2ACXpvVeLstnNG1Oris0VpxbSdLNdh_r-v6YxTEY5vcDHAA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: Logging plan of the running query (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: RFC: Logging plan of the running query
Re: RFC: Logging plan of the running query |
Список | pgsql-hackers |
On Thu, May 13, 2021 at 2:57 PM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > On Thu, May 13, 2021 at 2:44 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > +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. > > True, we should use LOG_SERVER_ONLY and not send any logs to the client. I further tend to think that, is it correct to log queries with LOG level when log_statement GUC is set? Or should it also be LOG_SERVER_ONLY? /* Log immediately if dictated by log_statement */ if (check_log_statement(parsetree_list)) { ereport(LOG, (errmsg("statement: %s", query_string), errhidestmt(true), errdetail_execute(parsetree_list))); With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: