In article <[EMAIL PROTECTED]>, "Bruce Momjian"
<[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
