> That's talking about the stats code, which has approximately
> zip to do with setproctitle (ps_status.c). But IIRC that
> patch is on hold because nobody particularly liked the
> approach it's taking. I think we should investigate
> rewriting the stats communication architecture entirely ---
> in particular, do we really need the stats buffer process at
> all? It'd be interesting to see what happens if we just make
> the collector process read the UDP socket directly. Or
> alternatively drop the UDP socket in favor of having the
> backends write directly to the collector process'
> input pipe (not sure if this would port to Windows though).
(Yes, Iremember saying I was planning to look at this. As is probably
obvious by now, I haven't had the time to do that (yet)).
As for your question, it will be a bit painful to port to windows. We
did have a lot of problems with the pgstat pipe in the initial porting
work, and I'm not convinced that there aren't some small issues still
lurking there under heavy load. The point is that the whole concept of
sharing socket descriptors doesn't really play well between processes on
Windows.
Using UDP would make that a whole lot better. Without knowing anything,
I would assume the overhead of a localhost UDP packet isn't very large
on a reasonably modern platform.
//Magnus
