Since I'm implementing a generic driver, users can send either single-statement transactions or actual multiple-statement transaction. However, whether we're in a transaction or not doesn't seem to affect Npgsql logic (unless I'm missing something) - if the cancellation does hit a query the transaction will be cancelled and it's up to the user to roll it back as is required in PostgreSQL...
On Tue, Jun 9, 2015 at 4:42 AM, Shay Rojansky <roji@roji.org> wrote: > 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?
Blocking new queries seems like a good idea. Note that the entire transaction (whether single-statement or multi-statement) will be aborted, or at least the currently-active subtransaction, not just the current query. If you're using single-statement transactions I guess there is not much practical difference, but if you are using multi-statement transactions the application kind of needs to be aware of this, since it needs to know that any work it did got rolled back, and everything's going to fail up until the current (sub)transaction is rolled back. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
