Thread: Re: [GENERAL] killing process question

On 19 Sep 2002 at 11:19, Johnson, Shaunn wrote:

>
> --howdy:
> --not that the process is doing a lot or taking up
> --a lot of resources, it's just something
> --that i allow the users to kill and then
> --it get's passed to me for correction if the
> --simple 'kill <pid>' thing doesn't work.
> --what i'm trying to understand is if there
> --is a way to do this without having to restart
> --the database (remember, it's still production)
> --everytime there is a runaway process AND not
> --kill -9 <pid>.
> --how can i do this?

I did a quick 'grep -rin' on postgresql source code I have(CVS, a week old).
Looks like postgresql backend is ignoring the SISPIPE which is delivered to
backend process when other end is closed. Obviously this is going to cause
hanging back-ends.

I guess a backend should terminate as if connection is closed. What say?



Bye
 Shridhar

--
Guillotine, n.:    A French chopping center.

"Shridhar Daithankar" <shridhar_daithankar@persistent.co.in> writes:
> I guess a backend should terminate as if connection is closed. What say?

No.

It will terminate when it tries to read the next query from the client.

            regards, tom lane

On 19 Sep 2002 at 11:49, Tom Lane wrote:

> "Shridhar Daithankar" <shridhar_daithankar@persistent.co.in> writes:
> > I guess a backend should terminate as if connection is closed. What say?
>
> No.
>
> It will terminate when it tries to read the next query from the client.

OK. But what if it never reads anything? I mean if the client dies after a
complete transaction i.e. no input pending for either back end or client, will
it just sit around waiting for select to signal that fd?(AFAIU, that's how
things goes in there..)

Clearly we have a case where backend is hung persumably. Either it has to have
an explanation(OK client did aborted abruptly) and/or a possible corrective
action..

Just some thoughts..


Bye
 Shridhar

--
QOTD:    "I won't say he's untruthful, but his wife has to call the    dog for
dinner."