Re: On-demand running query plans using auto_explain and signals

>
> 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.

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).

--
Alex