Simon Riggs wrote:
> > > 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.
No, we are going to create server-side function that mimick SIGINT
(though using xid, we can ignore if the xid change), and SIGTERM.
Server-side functions are required for clients not running on the
server.
> Even if the primary behaviour is indeed exactly similar, are the
> secondary and subsequent behaviours similar also?
>
You mean calling them several times? Well, SIGTERM will terminate, and
SIGINT will keep canceling xid's, though you have to update the xid to
the newer xid because you canceled the old one.
> 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...
No, these are super-user-only commands. Not much more we can do on that
front.
-- 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