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

Log Message:
-----------
Add GUC update_process_title to control whether 'ps' display is updated
for every command, default to on.

Modified Files:
--------------
pgsql/doc/src/sgml:
config.sgml (r1.67 -> r1.68)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml.diff?r1=1.67&r2=1.68)
pgsql/src/backend/bootstrap:
bootstrap.c (r1.217 -> r1.218)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/bootstrap/bootstrap.c.diff?r1=1.217&r2=1.218)
pgsql/src/backend/commands:
async.c (r1.131 -> r1.132)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/async.c.diff?r1=1.131&r2=1.132)
pgsql/src/backend/postmaster:
autovacuum.c (r1.20 -> r1.21)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/autovacuum.c.diff?r1=1.20&r2=1.21)
pgarch.c (r1.23 -> r1.24)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgarch.c.diff?r1=1.23&r2=1.24)
pgstat.c (r1.131 -> r1.132)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/pgstat.c.diff?r1=1.131&r2=1.132)
postmaster.c (r1.488 -> r1.489)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/postmaster.c.diff?r1=1.488&r2=1.489)
syslogger.c (r1.25 -> r1.26)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/postmaster/syslogger.c.diff?r1=1.25&r2=1.26)
pgsql/src/backend/storage/lmgr:
lock.c (r1.164 -> r1.165)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/lmgr/lock.c.diff?r1=1.164&r2=1.165)
pgsql/src/backend/tcop:
postgres.c (r1.489 -> r1.490)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/tcop/postgres.c.diff?r1=1.489&r2=1.490)
pgsql/src/backend/utils/misc:
guc.c (r1.323 -> r1.324)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c.diff?r1=1.323&r2=1.324)
postgresql.conf.sample (r1.181 -> r1.182)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/postgresql.conf.sample.diff?r1=1.181&r2=1.182)
ps_status.c (r1.30 -> r1.31)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/ps_status.c.diff?r1=1.30&r2=1.31)
pgsql/src/include/utils:
ps_status.h (r1.26 -> r1.27)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/ps_status.h.diff?r1=1.26&r2=1.27)

momjian(at)postgresql(dot)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.

regards, tom lane

Tom Lane wrote:
> momjian(at)postgresql(dot)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.

Nice idea.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Tom Lane wrote:
> momjian(at)postgresql(dot)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.
>
>

Funny - today I was just thinking how useful that would be!

Cheers

Mark

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> momjian(at)postgresql(dot)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

* Stephen Frost (sfrost(at)snowman(dot)net) wrote:
> 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.

Additionally, Tom, and I hate to point this out here but I don't see
much of an alternative; your mail system blocked my mail and apparently
would block any mail from theplanet.com (a rather large hosting company
based in Texas). Having been harrassed by their support folks for
running a couple rather large mailing lists (the MythTV ones at
mythtv.org) more than once I'm thinking this is a rather poor RBL. I'd
encourage you to drop it in favor of something a bit more sane.

Thanks,

Stephen