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

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 will we test all the possible
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

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2021 Grokbase