I'd say we should hide the so-designed pg_cmdstatus() interface behind more friendly calls like pg_explain_backend() and pg_backend_progress() to give some naming examples, to remove the need for magic numbers in the second arg.
I had similar idea - this is good enough for start, but target interface iis based on integration with EXPLAIN statement
some like EXPLAIN PROCESS or EXPLAIN PID or EXPLAIN VERBOSE PID ..
Yes, that's another way to do it.
the important functionality is drawing complete text of query - it was my original motivation, because I had not way how to get complete query before its finishing
Probably the communication between processes should be more complex :( - the SHM queue should be used there, because some plans can be terrible long.
The using shared write buffer (one for all) is too simply solution probably - good for prototype, but not good for core.
I have a idea about communication:
1. caller prepare buffer, shm queue and signalize target process - parameter is pid od caller
2. target process fills a write buffer and close queue
3. caller show data and close buffer, close queue
Now almost all code for communication is in upstream - the missing part is injection one end of queue to any process dynamicaly.
I'm not familiar with the shared memory handling, but could we not allocate just enough shared memory to fit the data we're going to write instead of the fixed 8k? It's not that we cannot know the length of the resulting plan text in advance.
the shared memory cannot be reused - (released) :(, so allocating enough memory is not effective. More - in this moment it has not sense. Shared memory queue can do almost all work.
I think we can remove buffer_is_free/buffer_holds_data and just use the buffer != NULL to check if there's some data to be read (and buffer == NULL to check if we can write).
