Re: RFC: Logging plan of the running query
От | torikoshia |
---|---|
Тема | Re: RFC: Logging plan of the running query |
Дата | |
Msg-id | 41d139f1b377500ad0295cb9a10e8969@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: RFC: Logging plan of the running query (torikoshia <torikoshia@oss.nttdata.com>) |
Список | pgsql-hackers |
On 2021-10-15 15:17, torikoshia wrote: > I only took a quick look at pg_query_state, I have some questions. > > pg_query_state seems using shm_mq to expose the plan information, but > there was a discussion that this kind of architecture would be tricky > to do properly [1]. > Does pg_query_state handle difficulties listed on the discussion? Sorry, I forgot to add the URL. [1] https://www.postgresql.org/message-id/9a50371e15e741e295accabc72a41df1%40oss.nttdata.com > It seems the caller of the pg_query_state() has to wait until the > target process pushes the plan information into shared memory, can it > lead to deadlock situations? > I came up with this question because when trying to make a view for > memory contexts of other backends, we encountered deadlock situations. > After all, we gave up view design and adopted sending signal and > logging. Discussion at the following URL. https://www.postgresql.org/message-id/9a50371e15e741e295accabc72a41df1%40oss.nttdata.com Regards, -- Atsushi Torikoshi NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: