Re: Server instrumentation for 8.1 - Mailing list pgsql-hackers

Andreas,

I think you bring up some good points, but I also think that each package you 
propose needs to be dealt with individually.

> - dbsize has been in contrib for a long time, though it appears to me as
> quite a basic functionality to find out about storage needs.

Although not needed so much if the new system views are approved; we have a 
view that calculates database size.  Not that multiple options isn't cool.

> - The superuser only generic file functions in the admin package have
> been posted for 8.0, but where (more or less ) silently dropped. These
> functions allow pgadmin to display the server logs, as well as editing
> pg_hba.conf and postgresql.conf without console access to
> whatever-pgsql-is-running-on.  I'd like to see this at least as contrib
> module (the functions are probably safer than pl_sh).

Heck, I didn't even see these.  I was going to write some in pgperl for my own 
use.  These seem potentially very dangerous though, so we wouldn't want them 
installed by default.

> - There was a pg_kill_backend function in pre-8.0, but it was dropped
> because "it's too dangerous". Incidentially, I've been in the situation
> more than once where I needed to kill a backend process that was running
> wild; alternatively, I'd have to shutdown the whole server. I had to do
> this on the linux console with kill -9 (fortunately I did have access),
> or using the win32 task manager (same). This appears even more error
> prone to me than to point to the malicious process and kill it (through
> pgadmin/pg_kill_backend)

Certainly.  But this was dropped because Tom couldn't get the bugs out (as I 
recall) and make it "safe" to use, even for the superuser.  You could take a 
stab at fixing it.   Also, if this were an "enable-at-build-time" option, it 
would also help defuse the security argument, since it wouldn't necessarily 
be installed.

> - We don't have a profiling facility to tap an individual backend for a
> limited period to find out what the client is doing there, so we need to
> use log_statement for this (I'd like to work on profiling, but I didn't
> find the time so far). Consequently, we have to deal with long logfiles,
> containing much stuff we don't need. In the past, I found it to be very
> helpful if a fresh logfile could be used (on a private installation,
> stop/start server), that's why my logfile process implementation did
> include a logfile rotation trigger functionality. Tom didn't need it, so
> he dropped it. I'd opt for re-adding it again.

+1

> Yes yes I know, all of these can be done by a local administrator with
> console access and an editor and cmd line tools, but there are indeed
> people that do *not* have console access, or like to use decent tools....

To support Andrew's assertion, automated server room administration tools 
(like Hyperic and Embarcadero) could really use the above tools.  

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco