"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
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
>
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 ...
>
> >
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
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
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
"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
> >> 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
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
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
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
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
"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
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
> > 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
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 ...
>
> >
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
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
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
"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
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
21 matches
Mail list logo
