Re: postgresql and process titles - Mailing list pgsql-hackers

Tom Lane wrote:
> 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

I thought the bug reporter was asking about the stats code was well.

> 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

Agreed, that's what I would prefer, and tested something like that, but
even pulling the packet into the buffer and throwing them away had
significant overhead, so I think the timeout trick has to be employed as
well as going to a single process.

> 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.

Right.  What if the postmaster signals the backend once a second to do
their reporting.  I am not sure what the final solution will be, but we
_need_ one based on the performance numbers I and others have seen. 
Could we have PGPROC have a reporting boolean that is set every second
and somehow checked by each backend?

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +