On 2005-05-12, Andreas Pflug <[EMAIL PROTECTED]> wrote: >> These seem potentially very dangerous though, so we wouldn't want them >> installed by default. > > Not more dangerous than "drop table pg_class".
Have you ever tried that? test=# drop table pg_class; ERROR: permission denied: "pg_class" is a system catalog That said, there are several functions built-in already that allow the superuser to write files (COPY TO and lo_export being the main ones). >>>- 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. There seems to be some confusion here - kill -9 on a single backend is unlikely to ever be safe, since the backend could be in the middle of updates to shared memory at the time, and while it is certainly possible to code it so that cleanup can still be done in this case, the current code certainly does not try. (I've done it for a database I wrote myself in the past: what's needed to make it feasible is that all shared memory updates, without exception, must either be atomic replacements of values of type volatile sig_atomic_t or must be updates to data structures that are already known to be in-use by the specific backend and which can be cleaned up even if they are in an internally corrupt state. This is unlikely to be either possible or desirable for postgres.) What currently happens is that backends respond to kill -15 (_NOT_ -9) by cleaning up and exiting. This code path is used for implementing the stop -mfast option, which means that as it currently exists, the cleanup only has to be good enough to let other backends get out of critical sections and complete their own rollback-and-exit safely. (I've never tried it, but I'd expect the postmaster to respond to a kill -9 of an individual backend by doing a panic shutdown and restart anyway, so there's no advantage to doing that rather than doing, say, restart -mfast or -mimmediate. I _have_ on very rare occasions done kill -15 on individual backends and got away with it, usually when those backends were idle anyway, but I'd never recommend it as a routine technique without a lot more confidence in the correctness of the code in question.) -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
