Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Dave Page
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 26 July 2004 04:46 To: Dave Page Cc: Magnus Hagander; Bruce Momjian; Josh Berkus; PostgreSQL-patches Subject: Re: [PATCHES] [HACKERS] Function to kill backend If you don't mind plastering a use at your own risk

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Andreas Pflug
Tom Lane wrote: If you don't mind plastering a use at your own risk sign on it, then go for it. killing a backend is obviously much more at your own risk than a descent function. Taken from your mail, I understand that a killed backend might leave some loose ends, eg. open locks, which would

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Tom Lane
Andreas Pflug [EMAIL PROTECTED] writes: Taken from your mail, I understand that a killed backend might leave some loose ends, eg. open locks, which would degrade the cluster's performance. Still, it should not corrupt the shared mem, just leave it as if the backend's still alive and

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Christopher Kings-Lynne
If you want to put in the function and document that it may cause problems, I won't object; it's not like we don't have other features that are poorly implemented :-(. But my vote would be to remove it. I'm down with removing it - people don't read documentation :/ Chris

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Tom Lane
Oliver Jowett [EMAIL PROTECTED] writes: What about implementing kill as cancel then exit? Does that guarantee a safe exit in all cases? That was exactly what Bruce's patch turned it into. That would be workable if we separated this case from the existing elog(FATAL) behavior, but doing it

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Oliver Jowett
Tom Lane wrote: So what you'd basically need is a separate signal to trigger that sort of exit, which would be easy ... if we had any spare signal numbers. What about multiplexing it onto an existing signal? e.g. set a shared-mem flag saying exit after cancel then send SIGINT? I guess this is

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Tom Lane
Oliver Jowett [EMAIL PROTECTED] writes: Tom Lane wrote: So what you'd basically need is a separate signal to trigger that sort of exit, which would be easy ... if we had any spare signal numbers. What about multiplexing it onto an existing signal? e.g. set a shared-mem flag saying exit

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-26 Thread Bruce Momjian
Tom Lane wrote: Oliver Jowett [EMAIL PROTECTED] writes: Tom Lane wrote: So what you'd basically need is a separate signal to trigger that sort of exit, which would be easy ... if we had any spare signal numbers. What about multiplexing it onto an existing signal? e.g. set a

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-25 Thread Magnus Hagander
OK, I see your point. Can anyone remember why this was needed? I remember Magnus wanted query cancel, but what was the logic for session termination? I think the argument for it went along the lines of what if you've got a misbehaving client that continually issues expensive queries, so

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-25 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes: That's not quite the argument I think I had :-) But withuot being able to kill the backends, there just no way for me to handle the sitaution when I have a hundred clients eating up all available connections and/or memory, just sitting idle, because of

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-25 Thread Magnus Hagander
That's not quite the argument I think I had :-) But withuot being able to kill the backends, there just no way for me to handle the sitaution when I have a hundred clients eating up all available connections and/or memory, just sitting idle, because of some freak bug in a client. Yes, if

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-25 Thread Christopher Kings-Lynne
Would you use a kill operation in the way you describe above if you knew that it had, say, a 1% chance of causing a database-wide PANIC each time you used it? The odds of a problem are probably a great deal less than 1%, especially if the backend is sitting idle. But they're not nil, and I don't

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-25 Thread Bruce Momjian
Christopher Kings-Lynne wrote: Would you use a kill operation in the way you describe above if you knew that it had, say, a 1% chance of causing a database-wide PANIC each time you used it? The odds of a problem are probably a great deal less than 1%, especially if the backend is

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-25 Thread Christopher Kings-Lynne
The first time I used it was for precisely this reason - some buggy PHP code opened hundreds of connections to a dev server which then remained open doing nothing except wasting resources. It was particularly useful in that case as I didn't have access to the web server at the time. Shortly

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-25 Thread Tom Lane
Dave Page [EMAIL PROTECTED] writes: I don't know the details of how it works, but is it any worse/better than 'kill -9' (which iirc is no longer considered an absolute no-no)? What I've been trying to remind people of is that killing just a single backend with SIGTERM is not the normal code

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-25 Thread Tom Lane
Andreas Pflug [EMAIL PROTECTED] writes: If there's a .1 % chance it *corrupts* the cluster, the function is not acceptable. See my response to Dave Page just now. Not only wouldn't I give you those odds today, but I don't think we could ever get to the point of saying that session kill is

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-25 Thread Tom Lane
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Can we keep the cancel query function and just lose the kill one? That would be my druthers. I have no problem with the cancel function. regards, tom lane ---(end of

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-24 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: I have applied the attached patch: Exit backend from SIGTERM or FATAL by simulating client EOF, rather than calling proc_exit() directly. This should make SIGTERM more reliable. After further consideration I have concluded that this was a

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-24 Thread Bruce Momjian
OK, I see your point. Can anyone remember why this was needed? I remember Magnus wanted query cancel, but what was the logic for session termination? --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I have

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-24 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: OK, I see your point. Can anyone remember why this was needed? I remember Magnus wanted query cancel, but what was the logic for session termination? I think the argument for it went along the lines of what if you've got a misbehaving client that

Re: [PATCHES] [HACKERS] Function to kill backend

2004-07-24 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, I see your point. Can anyone remember why this was needed? I remember Magnus wanted query cancel, but what was the logic for session termination? I think the argument for it went along the lines of what if you've got a

Re: [PATCHES] [HACKERS] Function to kill backend

2004-04-10 Thread Bruce Momjian
I have applied the attached patch: Exit backend from SIGTERM or FATAL by simulating client EOF, rather than calling proc_exit() directly. This should make SIGTERM more reliable. --- Tom Lane wrote: Bruce Momjian

Re: [PATCHES] [HACKERS] Function to kill backend

2004-04-08 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: On first glance, I don't see anything dangerous about SIGTERM. You haven't thought about it very hard :-( Yea, that's why I said on first glance. The major difference I see is that elog(FATAL) will call proc_exit directly from elog,

Re: [PATCHES] [HACKERS] Function to kill backend

2004-04-03 Thread Andrew Dunstan
Magnus Hagander wrote: I think any such facility is inherently a security risk, since it means that a remote attacker who's managed to break into your superuser account can randomly zap other backends. Now admittedly there's plenty of other mischief he can do with superuser privs,