Re: Cancel race condition

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 <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Jun 9, 2015 at 4:42 AM, Shay Rojansky <roji(at)roji(dot)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
>