Server instrumentation for 8.1 - Mailing list pgsql-hackers

From Andreas Pflug
Subject Server instrumentation for 8.1
Date
Msg-id 42823665.4030702@pse-consulting.de
Whole thread Raw
Responses Re: Server instrumentation for 8.1
Re: Server instrumentation for 8.1
Re: Server instrumentation for 8.1
List pgsql-hackers
There's still a lengthy discussion going on whether it's a good idea to 
add a forth way to read pgsql's schema (pg_* tables, pg_* views, 
information_schema, did I miss one?), but I'd like to see helper 
functions for issues *not* covered in the core package.

- 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.

- 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).

Both these modules are bundled with the pgsql win32 installer, and are 
installed by default. Both are supported by (at least) pgAdmin.


- 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)

- 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.

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....

Regards,
Andreas


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Views, views, views: Summary of Arguments
Next
From: Robert Treat
Date:
Subject: 7.3.10 working