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. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
