Re: Cancel race condition - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Cancel race condition
Date
Msg-id 11268.1433800860@sss.pgh.pa.us
Whole thread Raw
In response to Cancel race condition  (Shay Rojansky <roji@roji.org>)
Responses Re: Cancel race condition  (Shay Rojansky <roji@roji.org>)
List pgsql-hackers
Shay Rojansky <roji@roji.org> writes:
> My questions/comments:
>    - Does PostgreSQL *guarantee* that once the connection used to send the
>    cancellation request is closed by the server, the cancellation has been
>    delivered (as mentioned by Tom)? In other words, should I be designing a
>    .NET driver around this behavior?

The signal's been *sent*.  Whether it's been *delivered* is something
you'd have to ask your local kernel hacker.  The POSIX standard appears
to specifically disclaim any such guarantee; in fact, it doesn't even
entirely promise that a self-signal is synchronous.  There are also
issues like what if the target process currently has signals blocked;
does "delivery" mean that the signal handler's been entered, or something
weaker?

In any case, Postgres has always considered that query cancel is a "best
effort" thing, so even if I thought this was 100% portably reliable,
I would not be in favor of promising anything in the docs.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Gavin Flower
Date:
Subject: Re: [CORE] Restore-reliability mode
Next
From: David Gould
Date:
Subject: Re: [CORE] Restore-reliability mode