| From: | Jessica Perry Hekman <jphekman(at)dynamicdiagrams(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: timeout implementation issues |
| Date: | 2002-03-30 19:31:34 |
| Message-ID: | Pine.LNX.4.21.0203301430450.2658-100000@atalanta.dynamicdiagrams.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, 30 Mar 2002, Tom Lane wrote:
> Au contraire, it is not assuming anything. It is sending off a cancel
> request and then waiting to see what happens. Maybe the query will be
> canceled, or maybe it will complete normally, or maybe it will fail
> because of some error unrelated to the cancel request. In any case the
> backend *will* eventually report completion/error status, and the
> frontend does not assume anything until it gets that report.
Ah, okay; this was not my understanding. I'll look at the code again.
> Why does it need to know that? When it gets the error report back, it
> can notice that the error says "Query aborted by timeout" (or however we
> phrase it) ... but I'm not seeing why it should care.
I just meant it needed to know that the process had stopped prematurely; I
didn't mean it needed to know why.
I'll get back to you after doing a little more research.
j
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-03-30 19:32:51 | Re: timeout implementation issues |
| Previous Message | Jessica Perry Hekman | 2002-03-30 19:20:19 | Re: timeout implementation issues |