Re: pg_terminate_backend() issues - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_terminate_backend() issues
Date
Msg-id 200804160358.m3G3weS25011@momjian.us
Whole thread Raw
In response to Re: pg_terminate_backend() issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_terminate_backend() issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pg_terminate_backend() issues  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> >> I think if we want pg_terminate_backend, we have to do it the way that
> >> was originally discussed: have it issue SIGTERM and fix whatever needs
> >> to be fixed in the SIGTERM code path.
> 
> > Well, with no movement on this TODO item since it was removed in 8.0, I
> > am willing to give users something that works most of the time.
> 
> If the users want it so bad, why has no one stepped up to do the
> testing?

Good question.  Tom and I talked about this on the phone today.

I think the problem is testing to try to prove the lack of a bug.  How
long does someone test to know they have reasonably proven a bug doesn't
exist?  

I think the other problem is what to test.  One SIGTERM problem that was
reported was related to schema changes.  Certainly that has to be
tested, but what else:  prepared statements, queries, HOT updates,
connect/disconnect, notify?  There are lots of place to test and it is
hard to know which ones, and for how long.

I am starting to think we need to analyze the source code rather than
testing, because of what we are testing for.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: count(*) performance improvement ideas
Next
From: Bruce Momjian
Date:
Subject: Re: pg_terminate_backend() issues