>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