stats_command_string default?

From: Kevin Brown <kevin(at)sysexperts(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: stats_command_string default?
Date: 2003-02-14 19:17:53
Message-ID: 20030214191753.GF1833@filer
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


One of the functions of the DBA is to monitor what people are doing to
the database. My experience is that "ps" is often sorely lacking in
this regard: its output is somewhat limited, from what I've seen, and
in any case the DBA's domain is the database itself: that's the
environment he's going to be most proficient in.

The ability to select the list of current connections from
pg_stat_activity is really handy for monitoring the database, but the
default configuration disables stats_command_string -- so the
current_query winds up being blank by default.

That's not exactly the most useful configuration for the DBA.

Would it make more sense to enable stats_command_string by default?
It could be a problem if doing so would have a significant impact on
performance, but that's the only reason I can think of for not doing
it. Are there others?

It would also be handy if users could see their own queries while the
rest remain blank. That would require changing
pg_stat_get_backend_activity() so that it returns a value if the user
is the superuser or if the user asking for the answer is the same as
the user who owns the backend entry being looked up. Are there any
pitfalls to implementing that?

--
Kevin Brown kevin(at)sysexperts(dot)com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Curtis Faith 2003-02-14 19:22:54 Re: Brain dump: btree collapsing
Previous Message Bruce Momjian 2003-02-14 19:12:06 Re: Berkeley and CMU classes adopt/extend PostgreSQL

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2003-02-14 19:53:12 Re: fix regression in .pgpass handling
Previous Message greg 2003-02-14 14:37:17 Re: Cosmetic change in catalog/index.c