On Mon, Aug 31, 2009 at 21:49, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Tom Lane wrote:
>>> Well, I'm not sure the average user knows or cares about the difference
>>> between the launcher and the workers. The thing that was in the back of
>>> my mind was that we would now have the option to have the launcher show
>>> up in pg_stat_activity. If we were to do that then the case for
>>> counting it in the user-visible number-of-processes parameter would get
>>> a lot stronger (enough to justify renaming the parameter, if you insist
>>> that the launcher isn't a worker). I don't however have any strong
>>> opinion on whether we *should* include it in pg_stat_activity ---
>>> comments?
>
>> The user may not care about the difference, but there's a point in
>> having the limit be the simpler concept of "this is the maximum amount
>> of processes running vacuum at any time". The launcher is very
>> uninteresting to users.
>
> I committed things that way, but I'm still not convinced that we
> shouldn't expose the launcher in pg_stat_activity. The thing that
> is bothering me is that it is now able to take locks and potentially
> could block some other process or even participate in a deadlock.
> Do we really want to have entries in pg_locks that don't match any
> entry in pg_stat_activity?
At first I'd have voted that we don't have it in pg_stat_activity, but
the argument about pg_locks really is the killer on. IMHO, it *has* to
go there then.
I would also suggest that we add a separate column to pg_stat_activity
indicating what type of process it is, so that monitoring tools can
figure that out without having to resort to string matching on the
current query field. This field would indicate if it's a backend,
autovac worker, autovac launcher. And perhaps we should even add the
other utility processes to pg_stat_activity, for completeness?
Another thought along a similar line is some way to detect the idle
and idle-in-transaction states without doing string matching as well.
Perhaps this could be overloaded on said extra field, or should it
have a separate one?
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
