In article <200103081735.MAA06567@candle.pha.pa.us>, "Bruce Momjian"
<pgman@candle.pha.pa.us> wrote:
> The problem I see with the shared memory idea is that some of the
> information needed may be quite large. For example, query strings can
> be very long. Do we just allocate 512 bytes and clip off the rest. And
> as I add more info, I need more shared memory per backend. I just liked
> the file system dump solution because I could modify it pretty easily,
> and because the info only appears when you click on the process, it
> doesn't happen often.
>
> Of course, if we start getting the full display partly from each
> backend, we will have to use shared memory.
Long-term, perhaps a monitor server (like Sybase ASE uses) might
be a reasonable approach. That way, only one process (and a well-
regulated one at that) would be accessing the shared memory, which
should make it safer and have less of an impact performance-wise
if semaphores are needed to regulate access to the various regions
of shared memory.
Then, 1-N clients may access the monitor server to get performance
data w/o impacting the backends.
Gordon.
--
It doesn't get any easier, you just go faster. -- Greg LeMond