Re: RFC: Logging plan of the running query
torikoshia <torikoshia@oss.nttdata.com>
From: torikoshia <torikoshia@oss.nttdata.com>
To: Ekaterina Sokolova <e.sokolova@postgrespro.ru>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2021-10-15T10:12:26Z
Lists: 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
Commits
-
Allow GRANT on pg_log_backend_memory_contexts().
- f0b051e322d5 15.0 cited