Re: postgresql and process titles

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Kris Kennaway <kris(at)obsecurity(dot)org>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: postgresql and process titles
Date: 2006-06-13 21:05:31
Message-ID: 200606132105.k5DL5VS26849@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-06-13 21:08:43 Re: CSV mode option for pg_dump
Previous Message Magnus Hagander 2006-06-13 20:59:19 Re: postgresql and process titles