Re: Server instrumentation for 8.1
От | Andreas Pflug |
---|---|
Тема | Re: Server instrumentation for 8.1 |
Дата | |
Msg-id | 428314EB.8070908@pse-consulting.de обсуждение исходный текст |
Ответ на | Re: Server instrumentation for 8.1 (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Server instrumentation for 8.1
|
Список | pgsql-hackers |
Josh Berkus wrote: >>- 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. First, as some other msg states the views will estimate the sizes, dbsize uses actual file sizes. Second, in contrast to CKL, I would *not* use these fancy new system views, because they mean yet another dependency for pgAdmin. > Not that multiple options isn't cool. What do you mean? Those views aren't an option for me. > >>- 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. Not more dangerous than "drop table pg_class". The file functions are restricted to the cluster directory. >>- 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. Hm, don't remember that, AFAIR it was removed after a discussion between Tom and Dave that kill -9 would stress a code path that still isn't elaborated too much. But in the situations mentioned above, I took the risk and would like a function for that. Regards, Andreas
В списке pgsql-hackers по дате отправления: