Ah, OK - I wasn't aware that cancellation was actually delivered as a regular POSIX signal... You're right about the lack of guarantees then.
In that case, I'm guessing not much could be do to guarantee sane cancellation behavior... I do understand the "best effort" idea around cancellations. However, it seems different to say "we'll try our best and the cancellation may not be delivered" (no bad consequences except maybe performance), and to say "we'll try our best but the cancellation may be delivered randomly to any query you send from the moment you send the cancellation". The second makes it very difficult to design a 100% sane, deterministic application... Any plans to address this in protocol 4? Would you have any further recommendations or guidelines to make the situation as sane as possible? I guess I could block any new SQL queries while a cancellation on that connection is still outstanding (meaning that the cancellation connection hasn't yet been closed). As you mentioned this wouldn't be a 100% solution since it would only cover signal sending, but better than nothing? On Tue, Jun 9, 2015 at 1:01 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Shay Rojansky <r...@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 >
