Bruce Momjian <pgman@candle.pha.pa.us> writes: > Jim C. Nasby wrote: >> Excellent. Did I miss discussion of that or have you not mentioned it? >> I'm curious as to how you're fixing it...
> The patches are in the hold queue: > http://momjian.postgresql.org/cgi-bin/pgpatches_hold 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). As far as Kris' complaint goes, one thing that might be interesting is to delay both the setproctitle call and the stats command message send until the current command has been running a little while (say 100ms or so). The main objection I see to this is that it replaces a kernel call that actually does some work with a kernel call to start a timer, plus possibly a later kernel call to actually do the work. Not clear that there's a win there. (If you're using statement_timeout it might not matter, but if you aren't...) Also not clear how you make the necessary actions happen when the timer expires --- I seriously doubt it'd be safe to try to do either action directly in a signal handler. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org