Re: pg_terminate_backend idea

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

In response to

Responses

Browse pgsql-hackers by date

  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