From: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Étienne BERSAC <etienne(dot)bersac(at)dalibo(dot)com> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, jtc331(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: RFC: Logging plan of the running query |
Date: | 2023-10-27 12:30:02 |
Message-ID: | 0eafbfbe8dc39e80bce358b48a258510@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2023-10-27 12:42:52 | Re: btree_gin: Incorrect leftmost interval value |
Previous Message | Victor Wagner | 2023-10-27 12:20:49 | Enderbury Island disappeared from timezone database |