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
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 "
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 g
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
Andreas Pflug wrote:
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.
[...]
What about implementing "kill" as "cancel then exit"? Does that
guarantee a safe exit
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
--
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 sl
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
> -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 m
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 broadcast)-
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
"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 cod
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 afte
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 back
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 t
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?
Seems there's the need for some connection killing functionality. If
it's not present, the whole cluster needs to be shut down, which mak
-Original Message-
From: [EMAIL PROTECTED] on behalf of Magnus Hagander
Sent: Sun 7/25/2004 12:07 PM
To: Tom Lane; Bruce Momjian
Cc: Josh Berkus; PostgreSQL-patches
Subject: Re: [PATCHES] [HACKERS] Function to kill backend
> >much further. I recall being voted down
>> 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
"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, bec
>> 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 queri
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 go
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
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 ha
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
spec
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 <
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
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,
27 matches
Mail list logo
