>Bruce Momjian > Simon Riggs wrote: > > The "function to kill backend" seems no longer in doubt, but the > > *reason* is still blurred, other than we don't want to > bring down the > > postmaster to do this. > > So far, reasons given have been: > > 1. to kill idlers > > 2. to kill runaway queries/statements, which has transaction > > implications > > > > I'd like to be able to do both of those, though they are fairly > > different situations, perhaps with different implementations. > > > > >Tom Lane writes > > > Some people think that making a database hard to kill is > a good thing. > > > > I'm with Tom on this. I'm working on PITR...what happens > when you shut > > down backends uncleanly...how will we test all the possible > event/states > > to ensure xlog history doesn't get broken? Please lets work on a > > "humane" approach to handling offending sessions...IMHO the various > > signals mentioned are merely blunt instruments; we have > been exhorted > > daily not to "kill the postmaster", now we seem to be > suggesting that we > > allow that to happen to backends. Isn't there a better way...? > > > > Other RDBMSs support the ability to terminate specific sessions, but > > none of them to my knowledge offer this facility by means > of an external > > executable, which has many implications - how would you > know (prove) it > > had been used? what security protection does the DBA have > over its use? > > > > The way forward seems safest if this is a command, not an external > > executable. e.g. ALTER SYSTEM STOP BACKEND <x>. That way we > have control > > over the implementation/porting, security, logging/audit. > Anybody that > > wants to can then wrap that in a script if they choose. > > > > Internally, we could then implement it however we chose. > > The current plan is to create server-side functions to do this. We > believe sending a SIGTERM to a backend via kill already has > this effect.
If I understand you then, you believe you have found a way to short cut implementing the server-side function. Even if the primary behaviour is indeed exactly similar, are the secondary and subsequent behaviours similar also? Does your plan allow for: i) logging the activity (both the send and the effect of receiving it) ii) full security control of the facility other secondary behaviours... Forgive me if I become over-protective on robustness issues... Best Regards, Simon ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster