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
