> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
