From: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <mha(at)sollentuna(dot)net>, Alvaro Herrera <alvherre(at)surnet(dot)cl>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Server instrumentation for 8.1 |
Date: | 2005-05-14 14:00:44 |
Message-ID: | 20050514140044.GB30902@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 12, 2005 at 10:39:14AM -0400, Tom Lane wrote:
> "Magnus Hagander" <mha(at)sollentuna(dot)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(at)decibel(dot)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?"
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2005-05-14 14:07:52 | Re: Catalog Security WAS: Views, views, views: Summary |
Previous Message | Stephen Frost | 2005-05-14 14:00:09 | Re: Catalog Security WAS: Views, views, views: Summary |