Server instrumentation for 8.1

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Server instrumentation for 8.1
Date: 2005-05-11 16:44:21
Message-ID: 42823665.4030702@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Held 2005-05-11 16:54:40 Re: Oracle Style packages on postgres
Previous Message Josh Berkus 2005-05-11 16:35:44 Re: Views, views, views: Summary of Arguments