2015-09-01 15:00 GMT+02:00 Shulgin, Oleksandr <oleksandr.shul...@zalando.de> :
> 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). > > -- > Alex > >
