From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | josh(at)agliodbs(dot)com, Magnus Hagander <mha(at)sollentuna(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Function to kill backend |
Date: | 2004-04-06 19:39:59 |
Message-ID: | 745.1081280399@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> OK, you have a runaway report. You want to stop it. Query cancel is
> only going to stop the current query, and once you do that the next
> query is fed in so there is no way to actually stop the report,
> especially if the report is not being run from the same machine as the
> server (you can't kill the report process).
> I don't think most apps reconnect on disconnect, except maybe pooled
> connections where you don't expect your state to be stable between
> connections. Certainly most reports can't just reconnect and keep
> going.
You're hypothecating a report generator that can recover from failed
queries, but not a failed connection? Seems a rather contrived case.
Stupid apps are most likely gonna curl up and die on any unexpected
error (which is what the query cancel would look like to them). Smart
apps may try harder to recover than you think.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-04-06 19:43:58 | Re: Function to kill backend |
Previous Message | Rod Taylor | 2004-04-06 19:38:26 | Re: Function to kill backend |