Re: Server instrumentation for 8.1

On 2005-05-12, Andreas Pflug <pgadmin(at)pse-consulting(dot)de> 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