Re: RFC: Logging plan of the running query
От | torikoshia |
---|---|
Тема | Re: RFC: Logging plan of the running query |
Дата | |
Msg-id | 0eafbfbe8dc39e80bce358b48a258510@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: RFC: Logging plan of the running query (Étienne BERSAC <etienne.bersac@dalibo.com>) |
Ответы |
Re: RFC: Logging plan of the running query
|
Список | pgsql-hackers |
On 2023-10-27 16:06, Étienne BERSAC wrote: > Hi Torikoshia, > >> If so, we once tried to implement such function for getting memory >> contexts. >> However, this attempt didn't succeed because it could lead dead lock >> situation[1]. > > Thanks for the pointer. Why not use client log message to allow client > to get plan without locking backend memory context and without access > to server log ? I missed the rationnal for not sending the plan to > client. If we use client log message, that message is shown on the target process whose pid is specified by the parameter of pg_log_query_plan(): (pid:1000)=# select pg_sleep(60); (pid:1001)=# select pg_log_query_plan(1000); (pid:1000)=# LOG: query plan running on backend with PID 1000 is: Query Text: select pg_sleep(1000); Result (cost=0.00..0.01 rows=1 width=4) Output: pg_sleep('1000'::double precision) I think this is not an expected behavior and we set elevel to LOG_SERVER_ONLY. -- Regards, -- Atsushi Torikoshi NTT DATA Group Corporation
В списке pgsql-hackers по дате отправления: