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.
Best Regards, Simon Riggs
