Re: Server instrumentation for 8.1
От | Andrew Dunstan |
---|---|
Тема | Re: Server instrumentation for 8.1 |
Дата | |
Msg-id | 42860989.1000003@dunslane.net обсуждение исходный текст |
Ответ на | Re: Server instrumentation for 8.1 ("Jim C. Nasby" <decibel@decibel.org>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: