Interesting, and what about COPY operations and WaitAsync?

Also, there might be a different CancellationToken between ExecuteReaderAsync and ReadAsync.

Interesting, and what about COPY operations and WaitAsync?

I've left those out for now since they have their own full-blown work items (e.g. #1328) - but we'd presumably use the same mechanism. I'll add a note to those issues, and let's keep this open as well so we don't forget.

Also, there might be a different CancellationToken between ExecuteReaderAsync and ReadAsync.

Good point.

Something what came to my mind - how the cancellation should work for the auth?

Also, there might be a different CancellationToken between ExecuteReaderAsync and ReadAsync.

I just pushed a commit which takes care of this, and also adds tests for soft/hard cancellation on NpgsqlDataReader.{ReadAsync,NextResultAsync} (using the PG mock). Can you re-review?

I also noticed that we don't handle cancellation for the async column operations on DbDataReader - GetFieldValueAsync and IsDBNullAsync. Both of these always completely synchronously by default (when CommandBehavior.SequentialAccess isn't set) - this is because the reader buffers entire rows, so all column operations have data in memory and return immediately. This means that we only need to handle cancellation for CommandBehavior.SequentialAccess - I'll work on that soon too (not sure if in this PR though).

Something what came to my mind - how the cancellation should work for the auth?

Good point. There's no PG cancellation at that point of course, so we need to go directly to hard socket cancellation. This is a bit similar to Wait cancellation (there's nothing to cancel).

Merged via bd3e617