On Mon, Nov 15, 2021 at 6:29 PM torikoshia <torikos...@oss.nttdata.com> wrote: > > 3) I think SendProcSignalForLogInfo can be more generic, meaning, it > > can also send signal to auxiliary processes if asked to do this will > > simplify the things for pg_log_backend_memory_contexts and other > > patches like pg_print_backtrace. I would imagine it to be "bool > > SendProcSignalForLogInfo(pid_t pid, ProcSignalReason reason, bool > > signal_aux_proc);". > > I agree with your idea. > Since sending signals to auxiliary processes to dump memory contexts and > pg_print_backtrace is still under discussion, IMHO it would be better to > refactor SendProcSignalForLogInfo after these patches are commited.
+1. I have another comment: isn't it a good idea that an overloaded version of the new function pg_log_query_plan can take the available explain command options as a text argument? I'm not sure if it is possible to get the stats like buffers, costs etc of a running query, if yes, something like pg_log_query_plan(pid, 'buffers', 'costs'....);? It looks to be an overkill at first sight, but these can be useful to know more detailed plan of the query. Thoughts? Regards, Bharath Rupireddy.