Re: [HACKERS] pg_terminate_backend() idea

2008-04-15 Thread Gregory Stark
"Bruce Momjian" <[EMAIL PROTECTED]> writes: > Gregory Stark wrote: > >> It seems to me we could replace all of the above with either SIGINT or USR1 >> and have a bunch of boolean flags in MyProc. I'm not sure of the implication >> for sinval processing of having to get a whole bunch of LWLocks tho

[HACKERS] pg_terminate_backend() idea

2008-04-15 Thread Bruce Momjian
Gregory Stark wrote: > >> > Add pg_terminate_backend() to allow terminating only a single session. > > I'm interested in this because I was already looking for a solution to the > "out of signals" problem we have. > > I think we could expand this by having a bunch of boolean flags, one each for >

Re: [HACKERS] pg_terminate_backend idea

2006-07-10 Thread Rod Taylor
On Tue, 2005-06-21 at 23:34 -0400, Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> In any case the correct way to solve the problem is to find out what's > >> being left corrupt by SIGTERM, rather than install more messiness in > >> order to avoid facing the real issue ... > > >

Re: [HACKERS] pg_terminate_backend idea

2005-06-24 Thread Bruce Momjian
Tom Lane wrote: > Bruce Momjian writes: > > I have been running some tests to try to see the lock table corruption > > but I have been unable to reproduce the problem. > > It's possible that what Rod was complaining of is fixed in CVS tip --- > see discussion about RemoveFromWaitQueue() bug. If

Re: [HACKERS] pg_terminate_backend idea

2005-06-24 Thread Tom Lane
Bruce Momjian writes: > I have been running some tests to try to see the lock table corruption > but I have been unable to reproduce the problem. It's possible that what Rod was complaining of is fixed in CVS tip --- see discussion about RemoveFromWaitQueue() bug. If so, it would have been a bug

Re: [HACKERS] pg_terminate_backend idea

2005-06-24 Thread Bruce Momjian
Tom Lane wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> writes: > > Assuming we don't get such a case, and a chance to fix it, before 8.1 > > (while still hoping we will get it fixed properly, we can't be sure, can > > we? If we were, it'd be fixed already). In this case, will you consider > > such

Re: [HACKERS] pg_terminate_backend idea

2005-06-22 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > Assuming we don't get such a case, and a chance to fix it, before 8.1 > (while still hoping we will get it fixed properly, we can't be sure, can > we? If we were, it'd be fixed already). In this case, will you consider > such a kludgy solution as a te

Re: [HACKERS] pg_terminate_backend idea

2005-06-22 Thread Magnus Hagander
> >> In any case the correct way to solve the problem is to find out > >> what's being left corrupt by SIGTERM, rather than install more > >> messiness in order to avoid facing the real issue ... > > > That is unfortunatly way over my head. And it doesn't seem like > > anybody who actually has

Re: [HACKERS] pg_terminate_backend idea

2005-06-22 Thread Andrew - Supernews
On 2005-06-22, Tom Lane <[EMAIL PROTECTED]> wrote: > Andrew - Supernews <[EMAIL PROTECTED]> writes: >> On 2005-06-22, Tom Lane <[EMAIL PROTECTED]> wrote: >>> Andreas Pflug <[EMAIL PROTECTED]> writes: I've seen cancel *not* working. >>> >>> Even a moment's perusal of the code will prove that t

Re: [HACKERS] pg_terminate_backend idea

2005-06-22 Thread Tom Lane
Andrew - Supernews <[EMAIL PROTECTED]> writes: > On 2005-06-22, Tom Lane <[EMAIL PROTECTED]> wrote: >> Andreas Pflug <[EMAIL PROTECTED]> writes: >>> I've seen cancel *not* working. >> >> Even a moment's perusal of the code will prove that there is no >> situation in which a backend will respond to

Re: [HACKERS] pg_terminate_backend idea

2005-06-22 Thread Andrew - Supernews
On 2005-06-22, Tom Lane <[EMAIL PROTECTED]> wrote: > Andreas Pflug <[EMAIL PROTECTED]> writes: >>> I thought we agreed that using the cancel functionality, which we know >>> works and is tested, > >> I've seen cancel *not* working. In 80 % this was the reason to use >> terminate. > > Even a moment

Re: [HACKERS] pg_terminate_backend idea

2005-06-22 Thread Tom Lane
Andreas Pflug <[EMAIL PROTECTED]> writes: >> I thought we agreed that using the cancel functionality, which we know >> works and is tested, > I've seen cancel *not* working. In 80 % this was the reason to use > terminate. Even a moment's perusal of the code will prove that there is no situation

Re: [HACKERS] pg_terminate_backend idea

2005-06-22 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> In any case the correct way to solve the problem is to find >> out what's being left corrupt by SIGTERM, rather than install >> more messiness in order to avoid facing the real issue ... > That is unfortunatly way over my head. And it doesn't seem

Re: [HACKERS] pg_terminate_backend idea

2005-06-22 Thread Andreas Pflug
Bruce Momjian wrote: Tom Lane wrote: "Magnus Hagander" <[EMAIL PROTECTED]> writes: But it still requires me to send some data (such as a dummy query) to the backend before it exits. This is because server side libpq blocks when reading and ignores signals at this time. I believe the fix for t

Re: [HACKERS] pg_terminate_backend idea

2005-06-22 Thread Magnus Hagander
> > But it still requires me to send some data (such as a dummy > query) to > > the backend before it exits. This is because server side > libpq blocks > > when reading and ignores signals at this time. I believe > the fix for > > this would be to pass a flag down to the libpq routines > tha

Re: [HACKERS] pg_terminate_backend idea

2005-06-21 Thread Rod Taylor
On Tue, 2005-06-21 at 23:34 -0400, Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> In any case the correct way to solve the problem is to find out what's > >> being left corrupt by SIGTERM, rather than install more messiness in > >> order to avoid facing the real issue ... > > >

Re: [HACKERS] pg_terminate_backend idea

2005-06-21 Thread Tom Lane
Bruce Momjian writes: > Tom Lane wrote: >> In any case the correct way to solve the problem is to find out what's >> being left corrupt by SIGTERM, rather than install more messiness in >> order to avoid facing the real issue ... > I am confused. Are you talking about the client SIGTERM or the s

Re: [HACKERS] pg_terminate_backend idea

2005-06-21 Thread Bruce Momjian
Tom Lane wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> writes: > > But it still requires me to send some data (such as a dummy query) to > > the backend before it exits. This is because server side libpq blocks > > when reading and ignores signals at this time. I believe the fix for > > this would

Re: [HACKERS] pg_terminate_backend idea

2005-06-21 Thread Oliver Jowett
Tom Lane wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> writes: > >>But it still requires me to send some data (such as a dummy query) to >>the backend before it exits. This is because server side libpq blocks >>when reading and ignores signals at this time. I believe the fix for >>this would be t

Re: [HACKERS] pg_terminate_backend idea

2005-06-21 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > But it still requires me to send some data (such as a dummy query) to > the backend before it exits. This is because server side libpq blocks > when reading and ignores signals at this time. I believe the fix for > this would be to pass a flag down to

[HACKERS] pg_terminate_backend idea

2005-06-21 Thread Magnus Hagander
I had an idea about how to possibly solve the pg_terminate_backend issue. How about we add a field to PGPROC (or is there a better place?) called shouldExit. pg_terminate_backend will set this field to "true" in the target backend, and then send the normal "cancel query" signal. The receiving ba