From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
Cc: | "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-12 14:39:14 |
Message-ID: | 511.1115908754@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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 ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2005-05-12 14:46:38 | Re: New Contrib Build? |
Previous Message | Tom Lane | 2005-05-12 14:33:43 | Re: SQL_ASCII vs. 7-bit ASCII encodings |