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 ...
Right now the way we do cancel is to catch a signal from the postmaster,
set a flag, then check it later at a safe point to decide if we should
cancel the query. It seems any code that would allow backends to exit
is going to have to use the same logic for safety. I don't see how
stress testing is going to ever be sure to catch all problems. Can't we
have a signal that does a query cancel, does the normal cancel cleanup,
then exits rather than asking for another query? Is that what is
already being talked about?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
