Re: timeout implementation issues

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

In response to

Responses

Browse pgsql-hackers by date

  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