Thanks for the extra consideration Robert. 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 Thu, Jun 11, 2015 at 9:50 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Jun 9, 2015 at 4:42 AM, Shay Rojansky <r...@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 >
