[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] timeout implementation issues
From:       Tom Lane <tgl () sss ! pgh ! pa ! us>
Date:       2002-03-30 19:32:51
[Download RAW message or body]

Jessica Perry Hekman <jphekman@dynamicdiagrams.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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
[prev in list] [next in list] [prev in thread] [next in thread]