Server instrumentation for 8.1

Поиск
Список
Период
Сортировка
От Andreas Pflug
Тема Server instrumentation for 8.1
Дата
Msg-id 42823665.4030702@pse-consulting.de
обсуждение исходный текст
Ответы Re: Server instrumentation for 8.1  (Andrew Sullivan <ajs@crankycanuck.ca>)
Re: Server instrumentation for 8.1  ("Jim C. Nasby" <decibel@decibel.org>)
Re: Server instrumentation for 8.1  (Josh Berkus <josh@agliodbs.com>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Views, views, views: Summary of Arguments
Следующее
От: Robert Treat
Дата:
Сообщение: 7.3.10 working