Re: postgresql and process titles

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(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 20:35:24
Message-ID: 10286.1150230924@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-06-13 20:44:20 Re: postgresql and process titles
Previous Message Ron Mayer 2006-06-13 20:28:27 Re: Fabian Pascal and RDBMS deficiencies in fully implementing