Jim C. Nasby wrote:
On Thu, May 12, 2005 at 10:39:14AM -0400, Tom Lane wrote:
"Magnus Hagander" <[EMAIL PROTECTED]> 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?
Incidentally, if there are serious worries about it, testing would be a *really* good thing ... it's more or less officially sanctioned, since TERM is on the list of signals supported by pg_ctl's kill mode.
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
