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 по дате отправления: