Jim C. Nasby wrote:
>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?
>
>
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
