From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Shay Rojansky <roji(at)roji(dot)org> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Cancel race condition |
Date: | 2015-06-08 22:01:00 |
Message-ID: | 11268.1433800860@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Shay Rojansky <roji(at)roji(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David Gould | 2015-06-08 23:02:21 | Re: [CORE] Restore-reliability mode |
Previous Message | Gavin Flower | 2015-06-08 21:35:12 | Re: [CORE] Restore-reliability mode |