Re: Server instrumentation for 8.1
От | Jim C. Nasby |
---|---|
Тема | Re: Server instrumentation for 8.1 |
Дата | |
Msg-id | 20050514140044.GB30902@decibel.org обсуждение исходный текст |
Ответ на | Re: Server instrumentation for 8.1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Server instrumentation for 8.1
|
Список | pgsql-hackers |
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?"
В списке pgsql-hackers по дате отправления: