From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jessica Perry Hekman <jphekman(at)dynamicdiagrams(dot)com> |
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:32:51 |
Message-ID: | 2861.1017516771@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jessica Perry Hekman <jphekman(at)dynamicdiagrams(dot)com> writes:
> If I understand the code correctly, in the case of a cancel signal, the
> driver sends the signal and then assumes that the backend has accepted it
> and cancelled; the back end does not report back.
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.
> In this case, the driver
> would not be sending a signal, so it would not know that the process had
> reached the timeout and stopped (and it needs to know that).
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-03-30 20:36:18 | Re: PGSTAT start failure probably shouldn't disable Postgres |
Previous Message | Jessica Perry Hekman | 2002-03-30 19:31:34 | Re: timeout implementation issues |