From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <josh(at)agliodbs(dot)com>, "Magnus Hagander" <mha(at)sollentuna(dot)net>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Function to kill backend |
Date: | 2004-04-06 22:19:21 |
Message-ID: | KGEFLMPJFBNNLNOOOPLGCEJACHAA.simon@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>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
From | Date | Subject | |
---|---|---|---|
Next Message | scott.marlowe | 2004-04-06 22:20:50 | Re: what do postgresql with view ? |
Previous Message | Andrew Dunstan | 2004-04-06 22:09:36 | Re: [PATCHES] logging statement levels |