From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <mha(at)sollentuna(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_terminate_backend idea |
Date: | 2005-06-22 08:14:56 |
Message-ID: | 42B91E00.1080401@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
> Tom Lane wrote:
>
>>"Magnus Hagander" <mha(at)sollentuna(dot)net> 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 the libpq routines that we want to
>>>be abort in case of signal+flag, set only when doing the "main call" to
>>>recv, so we can kill idle process.
>>
>>Yech! That code is messy enough already, lets not pile another kluge
>>atop it in order to handle something that's not even being requested
>>AFAIR.
>>
>>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 server?
> 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.
Regards,
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Yann Michel | 2005-06-22 08:19:46 | Re: User Quota Implementation |
Previous Message | Magnus Hagander | 2005-06-22 08:02:41 | Re: pg_terminate_backend idea |