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 pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073