Re: timeout implementation issues - Mailing list pgsql-hackers

From Jessica Perry Hekman
Subject Re: timeout implementation issues
Date
Msg-id Pine.LNX.4.21.0203301430450.2658-100000@atalanta.dynamicdiagrams.com
Whole thread Raw
In response to Re: timeout implementation issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: timeout implementation issues  (Jessica Perry Hekman <jphekman@dynamicdiagrams.com>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: timeout implementation issues
Next
From: Bruce Momjian
Date:
Subject: Re: PGSTAT start failure probably shouldn't disable Postgres