Re: Terminating a backend

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Terminating a backend
Date: 2008-03-11 03:03:58
Message-ID: 200803110303.m2B33wX22364@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> Keep in mind that 99% of the excuse for people to want to use SIGTERM is
> >> that the backend isn't responding to SIGINT. If you've fixed things so
> >> that SIGTERM cannot get them out of any situation that SIGINT doesn't
> >> get them out of, I don't think it's a step forward.
>
> > What I hear people ask is that they don't want the backend to read the
> > next command but to exit. That seems like a reasonable request.
>
> [shrug...] They can do that now, most of the time. What this is about
> is dealing with corner cases, and in that respect what your proposal
> will do is replace soluble problems with insoluble ones. But I suppose
> I can't stop you if you're insistent.

I am kind of confused by your reaction to my idea. I thought we agreed
that there was going to be no way to cleanly terminate a backend at an
arbitrary time, and I thought we were getting better at having query
cancel work in most cases, so it seems combining these two ideas that
query cancel with an immediate exit from the query loop was a perfect
solution to a feature request we get regularly.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2008-03-11 07:27:07 Re: [PATCHES] Fix for large file support (nonsegment mode support)
Previous Message Mark Mielke 2008-03-11 02:05:09 Re: LISTEN vs. two-phase commit

Browse pgsql-patches by date

  From Date Subject
Next Message Pavan Deolasee 2008-03-11 06:24:42 Re: Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Previous Message Tom Lane 2008-03-11 01:45:48 Re: [PATCHES] Fix for large file support (nonsegment mode support)