Re: Fully replacing ps_status (was Re: [COMMITTERS] pgsql: Add GUC update_process_title to control whether 'ps' display is) - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Fully replacing ps_status (was Re: [COMMITTERS] pgsql: Add GUC update_process_title to control whether 'ps' display is)
Date
Msg-id 20060628014330.GL7539@kenobi.snowman.net
Whole thread Raw
In response to Fully replacing ps_status (was Re: [COMMITTERS] pgsql: Add GUC update_process_title to control whether 'ps' display is)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fully replacing ps_status (was Re: [COMMITTERS] pgsql: Add GUC update_process_title to control whether 'ps' display is)  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> momjian@postgresql.org (Bruce Momjian) writes:
> > Add GUC update_process_title to control whether 'ps' display is updated
> > for every command, default to on.
>
> It strikes me that the ps_status support provides one important bit of
> information that is currently hard to get elsewhere; specifically, the
> "waiting" flag that gets added while blocked on a lock.  You can find
> out if a process is blocked by looking in pg_locks, but that's a fairly
> expensive probe in itself and then you have to join to pg_stat_activity
> to make any sense of it.  I wonder if we should add a "waiting" boolean
> column to pg_stat_activity?  Given the new implementation of
> pg_stat_activity, updating such a flag would be pretty cheap.

That would be an *excellent* addition..  Honestly, I think it'd be nice
to get a 'NOTICE' in such cases too, but having it in pg_stat_activity
will help alot.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Fully replacing ps_status (was Re: [COMMITTERS] pgsql:
Next
From: Stephen Frost
Date:
Subject: Re: Fully replacing ps_status (was Re: [COMMITTERS] pgsql: Add GUC update_process_title to control whether 'ps' display is)