On Thu, May 12, 2005 at 10:39:14AM -0400, Tom Lane wrote:
> "Magnus Hagander" <mha@sollentuna.net> writes:
> > Another thought I had along that line was use a different signal to
> > simply do a "query cancel" and set a global flag that is more or less
> > "get out when you're done with query cancel". Then if that flag is set,
> > just close the connection and proceed as if the client dropped the
> > connection - that has to be a well tested codepath.
>
> This is pretty much exactly what kill -TERM does today, and the point is
> that the code path has only been extensively tested in the context of
> database-wide shutdown. No one can honestly say that they are sure
> there are no resource leaks, locks left unreleased, stuff like that.
> That kind of problem wouldn't be visible after a shutdown, but it will
> become visible if backends are killed individually with -TERM.
>
> Now in theory there are no bugs and this'll work fine. What disturbs me
> is the lack of testing by anyone who knows what to look for ...
Would a script/program that starts connections, runs a query, and then
kills the backend repeatedly suffice?
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"
